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] [thread-next>] [day] [month] [year] [list]

Message-ID: <eab692794cbc82080b708c581efd5973b6004be0.camel@intel.com>
Date: Fri, 26 Sep 2025 15:46:26 +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>, "libc-alpha@...rceware.org"
	<libc-alpha@...rceware.org>, "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 Fri, 2025-09-26 at 01:44 +0100, Mark Brown wrote:
> > I don't know about substantial, but I'd love to hear some offensive
> > security persons analysis. There definitely was a school of thought
> > though, that shadow stack should be turned on as widely as
> > possible. If we need WRSS to make that happen in a sane way, you
> > could argue there is sort of a security at scale
> > benefit.
> 
> I agree it seems clearly better from a security point of view to have
> writable shadow stacks than none at all, I don't think there's much
> argument there other than the concerns about the memory consumption
> and performance tradeoffs.

IIRC the WRSS equivalent works the same for ARM where you need to use a
special instruction, right? So we are not talking about full writable
shadow stacks that could get attacked from any overflow, rather,
limited spots that have the WRSS (or similar) instruction. In the
presence of forward edge CFI, we might be able to worry less about
attackers being able to actually reach it? Still not quite as locked
down as having it disabled, but maybe not such a huge gap compared to
the mmap/munmap() stuff that is the alternative we are weighing.

> 
> > > > 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.
> 
> > Agree. But for the mseal stuff, I think you would want to have
> > map_shadow_stack not available.
> 
> That seems like something userspace could enforce with existing
> security mechanisms?  I can imagine a system might want different
> policies for different programs.

Yes, you could already do it with seccomp or something. Not sure if it
will work for the distro-wide enabling schemes or not though.