All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Jens Axboe <axboe@kernel.dk>
Cc: Will Deacon <will@kernel.org>, linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64: treat PF_IO_WORKER like PF_KTHREAD for mitigations
Date: Thu, 26 Jan 2023 15:04:27 +0000	[thread overview]
Message-ID: <Y9KWeyy9tAKYDxGA@arm.com> (raw)
In-Reply-To: <012e38c7-8cb9-a65c-a553-e8a2fafe6f3b@kernel.dk>

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.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-01-26 15:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-25 16:43 [PATCH] arm64: treat PF_IO_WORKER like PF_KTHREAD for mitigations Jens Axboe
2023-01-26 14:00 ` Will Deacon
2023-01-26 14:07   ` Jens Axboe
2023-01-26 15:04     ` Catalin Marinas [this message]
2023-03-28 14:14     ` Will Deacon
2023-03-28 16:47       ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y9KWeyy9tAKYDxGA@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=axboe@kernel.dk \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.