linux-kernel - Re: [PATCH RFC 0/3] arm64/gcs: Allow reuse of user managed shadow stacks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <80f8389c5c136ce21d922be10e4978d1ae5f1139.camel@intel.com>
Date: Fri, 26 Sep 2025 19:17:16 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "broonie@...nel.org" <broonie@...nel.org>
CC: "adhemerval.zanella@...aro.org" <adhemerval.zanella@...aro.org>,
	"nsz@...t70.net" <nsz@...t70.net>, "brauner@...nel.org" <brauner@...nel.org>,
	"shuah@...nel.org" <shuah@...nel.org>, "debug@...osinc.com"
	<debug@...osinc.com>, "fweimer@...hat.com" <fweimer@...hat.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"catalin.marinas@....com" <catalin.marinas@....com>, "dalias@...c.org"
	<dalias@...c.org>, "jeffxu@...gle.com" <jeffxu@...gle.com>, "will@...nel.org"
	<will@...nel.org>, "yury.khrustalev@....com" <yury.khrustalev@....com>,
	"wilco.dijkstra@....com" <wilco.dijkstra@....com>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "codonell@...hat.com"
	<codonell@...hat.com>, "linux-kselftest@...r.kernel.org"
	<linux-kselftest@...r.kernel.org>, "libc-alpha@...rceware.org"
	<libc-alpha@...rceware.org>
Subject: Re: [PATCH RFC 0/3] arm64/gcs: Allow reuse of user managed shadow
 stacks

On Fri, 2025-09-26 at 17:03 +0100, Mark Brown wrote:
> On Fri, Sep 26, 2025 at 03:39:46PM +0000, Edgecombe, Rick P wrote:
> > On Fri, 2025-09-26 at 16:07 +0100, Yury Khrustalev wrote:
> 
> > > What do you mean by "a fuller solution from the glibc side"? A
> > > solution
> > > for re-using shadow stacks? 
> 
> > I mean some code or a fuller explained solution that uses this new
> > kernel functionality. I think the scheme that Florian suggested in
> > the
> > thread linked above (longjmp() to the start of the stack) will have
> > trouble if the thread pivots to a new shadow stack before exiting
> > (e.g.
> > ucontext).
> 
> Is that supported even without user managed stacks?

IIUC longjmp() is sometimes used to implement user level thread
switching. So for non-shadow stack my understanding is that longjmp()
between user level threads is supported.

For shadow stack, I think user level threads are intended to be
supported. So I don't see why a thread could never exit from another
shadow stack? Is that what you are asking? Maybe we need to discuss
this with the glibc folks.

What I read in that thread you linked was that Florian was considering
using longjmp() as a way to inherit the solution to these unwinding
problems:
   Not sure if it helps, but glibc always calls the exit system call from
   the start routine, after unwinding the stack (with longjmp if
   necessary).
https://marc.info/?l=glibc-alpha&m=175733266913483&w=2

Reading into the "...if necessary" a bit on my part. But if longjmp()
doesn't work to unwind from a non-thread shadow stack, then my question
would be how will glibc deal with if an app exits while on another
shadow stack? Just declare shadow stack re-use is not supported with
any user shadow stack pivoting? Does it need a new elf header bit then?

Again, I'm just thinking that we should vet the solution a bit more
before actually adding this to the kernel. If the combined shadow stack
effort eventually throws its hands up in frustration and goes with
WRSS/GCSSTR for apps that want to do more advanced threading patterns,
then we are already done on the kernel side.