Message ID | dfc03be2-e246-ed23-6efb-fbd54a8e7781@kernel.dk (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | arm64: treat PF_IO_WORKER like PF_KTHREAD for mitigations | expand |
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@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. Will
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@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. But yes, the ssbs_thread_switch() should have this check too. I'll send out an updated patch.
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@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.
Hey Jens, 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@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. > > But yes, the ssbs_thread_switch() should have this check too. I'll send > out an updated patch. I think this one slipped through the cracks, as I don't see any usage of PF_IO_WORKER in arch/arm64/. Do you plan to update the patch? Cheers, Will
On 3/28/23 8:14?AM, Will Deacon wrote: > Hey Jens, > > 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@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. >> >> But yes, the ssbs_thread_switch() should have this check too. I'll send >> out an updated patch. > > I think this one slipped through the cracks, as I don't see any usage of > PF_IO_WORKER in arch/arm64/. Do you plan to update the patch? > Oops, yes looks like it did. Should look something like this, added a comment as well. I'll send it out properly. diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c index 71d59b5abede..9ce614b2177e 100644 --- a/arch/arm64/kernel/process.c +++ b/arch/arm64/kernel/process.c @@ -445,9 +445,11 @@ static void ssbs_thread_switch(struct task_struct *next) { /* * Nothing to do for kernel threads, but 'regs' may be junk - * (e.g. idle task) so check the flags and bail early. + * (e.g. idle task) so check the flags and bail early. Nothing to do + * for IO worker threads either, as they never transition between + * kernel and userspace. */ - if (unlikely(next->flags & PF_KTHREAD)) + if (unlikely(next->flags & (PF_KTHREAD | PF_IO_WORKER))) return; /* 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); if (spectre_v4_mitigations_off()) ssbs = true;
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); if (spectre_v4_mitigations_off()) ssbs = true;
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@kernel.dk> ---