[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f1a8da89-7522-429e-a4ba-4794222f1541@sirena.org.uk>
Date: Fri, 15 Aug 2025 16:28:23 +0100
From: Mark Brown <broonie@...nel.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
"mingo@...nel.org" <mingo@...nel.org>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>,
"bp@...en8.de" <bp@...en8.de>,
"peterz@...radead.org" <peterz@...radead.org>,
"hpa@...or.com" <hpa@...or.com>,
"axboe@...nel.dk" <axboe@...nel.dk>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"Mehta, Sohil" <sohil.mehta@...el.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"x86@...nel.org" <x86@...nel.org>,
"debug@...osinc.com" <debug@...osinc.com>
Subject: Re: [PATCH 5/6] x86/shstk: don't create the shadow stack for
PF_USER_WORKERs
On Fri, Aug 15, 2025 at 03:08:52PM +0200, Oleg Nesterov wrote:
> On 08/15, Oleg Nesterov wrote:
> > On 08/14, Mark Brown wrote:
> > > I agree that it's better to leave userspace shadow stacks enabled, given
> > > that the reason we're not allocating the shadow stack is that we don't
> > > expect to ever return to userspace then it should be fine to leave the
> > > feature turned on for userspace. If we mess up and do somehow return to
> > > userspace
> > But a PF_USER_WORKER task can never return to userspace. It doesn't differ
> > from PF_KTHREAD in this respect.
> ... of course unless it does exec.
Sure, but OTOH at least for arm64 there's no cost to leaving the feature
enabled unless you actually execute userspace code so if we never return
to userspace writing the code to disable isn't really buying us anything.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists