[PATCH] arm64: treat PF_IO_WORKER like PF_KTHREAD for mitigations

[Catalin Marinas]

On Thu, Jan 26, 2023 at 07:07:45AM -0700, Jens Axboe wrote:
> On 1/26/23 7:00 AM, Will Deacon wrote:
> > On Wed, Jan 25, 2023 at 09:43:34AM -0700, Jens Axboe wrote:
> >> Like PF_KTHREAD, PF_IO_WORKER never exit to userspace. They exist
> >> entirely within the kernel, and hence don't need any task mitigations
> >> applied.
> >>
> >> Signed-off-by: Jens Axboe <axboe at kernel.dk>
> >>
> >> ---
> >>
> >> diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c
> >> index fca9cc6f5581..25a21c3d446c 100644
> >> --- a/arch/arm64/kernel/proton-pack.c
> >> +++ b/arch/arm64/kernel/proton-pack.c
> >> @@ -654,7 +654,7 @@ static void __update_pstate_ssbs(struct pt_regs *regs, bool state)
> >>  void spectre_v4_enable_task_mitigation(struct task_struct *tsk)
> >>  {
> >>  	struct pt_regs *regs = task_pt_regs(tsk);
> >> -	bool ssbs = false, kthread = tsk->flags & PF_KTHREAD;
> >> +	bool ssbs = false, kthread = tsk->flags & (PF_KTHREAD | PF_IO_WORKER);
> > 
> > Hmm, the other two uses of PF_KTHREAD in arch/arm64 also look pretty
> > suspect in light of this proposal. Should we also update
> > ssbs_thread_switch() and access_ok()? If not, then a comment would be
> > handy to say why PF_KTHREAD is sufficient there.
> 
> The uaccess one looks like, PF_IO_WORKER threads are just normal userspace
> threads. The only difference is that they never exit to userspace, they
> remain in the kernel. But everything else is just like a thread.

IIUC these threads are cloned from a user thread and inherit the TIF
flags. If the user already opted in to the tagged addr ABI (usually
early by libc), TIF_TAGGED_ADDR would be set for all threads and
inherited by io_worker threads so we get away with this. But it doesn't
hurt to extend the access_ok check to PF_IO_WORKER just in case the user
plays with the late enabling of TIF_TAGGED_ADDR.

-- 
Catalin