Message-ID: <8aab0f36-52ad-4fd6-98c3-bcdba45dbe16@sirena.org.uk>
Date: Fri, 26 Sep 2025 00:22:24 +0100
From: Mark Brown <broonie@...nel.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "shuah@...nel.org" <shuah@...nel.org>,
	"brauner@...nel.org" <brauner@...nel.org>,
	"will@...nel.org" <will@...nel.org>,
	"catalin.marinas@....com" <catalin.marinas@....com>,
	"adhemerval.zanella@...aro.org" <adhemerval.zanella@...aro.org>,
	"nsz@...t70.net" <nsz@...t70.net>,
	"dalias@...c.org" <dalias@...c.org>,
	"debug@...osinc.com" <debug@...osinc.com>,
	"fweimer@...hat.com" <fweimer@...hat.com>,
	"libc-alpha@...rceware.org" <libc-alpha@...rceware.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"wilco.dijkstra@....com" <wilco.dijkstra@....com>,
	"jeffxu@...gle.com" <jeffxu@...gle.com>,
	"codonell@...hat.com" <codonell@...hat.com>,
	Yury Khrustalev <yury.khrustalev@....com>,
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>
Subject: Re: [PATCH RFC 0/3] arm64/gcs: Allow reuse of user managed shadow
 stacks

On Thu, Sep 25, 2025 at 08:40:56PM +0000, Edgecombe, Rick P wrote:

> Security-wise, it seems reasonable that if you are leaving a shadow stack, that
> you could leave a token behind. But for the userspace scheme to back up the SSP
> by doing a longjmp() or similar I have some doubts. IIRC there were some cross
> stack edge cases that we never figured out how to handle.

I think those were around the use of alt stacks, which we don't
currently do for shadow stacks at all because we couldn't figure out
those edge cases.  Possibly there's others as well, though - the alt
stacks issues dominated discussion a bit.

AFAICT those issues exist anyway, if userspace is already unwinding as
part of thread exit then they'll exercise that code though perhaps be
saved from any issues by virtue of not actually doing any function
calls.  Anything that actually does a longjmp() with the intent to
continue will do so more thoroughly.

> As far as re-using allocated shadow stacks, there is always the option to enable
> WRSS (or similar) to write the shadow stack as well as longjmp at will.

That's obviously a substantial downgrade in security though.

> I think we should see a fuller solution from the glibc side before adding new
> kernel features like this. (apologies if I missed it). I wonder if we are

I agree that we want to see some userspace code here, I'm hoping this
can be used for prototyping.  Yury has some code for the clone3() part
of things in glibc on arm64 already, hopefully that can be extended to
include the shadow stack in the thread stack cache.

> building something that will have an extremely complicated set of rules for what
> types of stack operations should be expected to work.

I think restricted more than complex?

> Sort of related, I think we might think about msealing shadow stacks, which will
> have trouble with a lot of these user managed shadow stack schemes. The reason
> is that as long as shadow stacks can be unmapped while a thread is on them (say
> a sleeping thread), a new shadow stack can be allocated in the same place with a
> token. Then a second thread can consume the token and possibly corrupt the
> shadow stack for the other thread with it's own calls. I don't know how
> realistic it is in practice, but it's something that guard gaps can't totally
> prevent.

> But for automatic thread created shadow stacks, there is no need to allow
> userspace to unmap a shadow stack, so the automatically created stacks could
> simply be msealed on creation and unmapped from the kernel. For a lot of apps
> (most?) this would work perfectly fine.

Indeed, we should be able to just do that if we're mseal()ing system
mappings I think - most likely anything that has a problem with it
probably already has a problem the existing mseal() stuff.  Yet another
reason we should be factoring more of this code out into the generic
code, like I say I'll try to look at that.

I do wonder if anyone would bother with those attacks if they've got
enough control over the process to do them, but equally a lot of this is
about how things chain together.

> I think we don't want 100 modes of shadow stack. If we have two, I'd think:
> 1. Msealed, simple more locked down kernel allocated shadow stack. Limited or
> none user space managed shadow stacks.
> 2. WRSS enabled, clone3-preferred max compatibility shadow stack. Longjmp via
> token writes and don't even have to think about taking signals while unwinding
> across stacks, or whatever other edge case.

I think the important thing from a kernel ABI point of view is to give
userspace the tools to do whatever it wants and get out of the way, and
that ideally this should include options that don't just make the shadow
stack writable since that's a substantial step down in protection.

That said your option 2 is already supported with the existing clone3()
on both arm64 and x86_64, policy for switching between that and kernel
managed stacks could be set by restricting the writable stacks flag on
the enable prctl(), and/or restricting map_shadow_stack().

> This RFC seems to be going down the path of addressing one edge case at a time.
> Alone it's fine, but I'd rather punt these types of usages to (2) by default. 

For me this is in the category of "oh, of course you should be able to
do that" where it feels like an obvious usability thing than an edge
case.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)

Powered by blists - more mailing lists