linux-kernel - Re: [musl] Re: [PATCH v8 00/38] arm64/gcs: Provide support for GCS in userspace

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: <20240221190639.GU4163@brightrain.aerifal.cx>
Date: Wed, 21 Feb 2024 14:06:39 -0500
From: "dalias@...c.org" <dalias@...c.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"suzuki.poulose@....com" <suzuki.poulose@....com>,
	"Szabolcs.Nagy@....com" <Szabolcs.Nagy@....com>,
	"musl@...ts.openwall.com" <musl@...ts.openwall.com>,
	"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
	"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>,
	"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
	"corbet@....net" <corbet@....net>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"catalin.marinas@....com" <catalin.marinas@....com>,
	"broonie@...nel.org" <broonie@...nel.org>,
	"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
	"palmer@...belt.com" <palmer@...belt.com>,
	"debug@...osinc.com" <debug@...osinc.com>,
	"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
	"shuah@...nel.org" <shuah@...nel.org>,
	"arnd@...db.de" <arnd@...db.de>, "maz@...nel.org" <maz@...nel.org>,
	"oleg@...hat.com" <oleg@...hat.com>,
	"fweimer@...hat.com" <fweimer@...hat.com>,
	"keescook@...omium.org" <keescook@...omium.org>,
	"james.morse@....com" <james.morse@....com>,
	"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
	"will@...nel.org" <will@...nel.org>,
	"brauner@...nel.org" <brauner@...nel.org>,
	"hjl.tools@...il.com" <hjl.tools@...il.com>,
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
	"paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
	"ardb@...nel.org" <ardb@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>,
	"thiago.bauermann@...aro.org" <thiago.bauermann@...aro.org>,
	"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"sorear@...tmail.com" <sorear@...tmail.com>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [musl] Re: [PATCH v8 00/38] arm64/gcs: Provide support for GCS
 in userspace

On Wed, Feb 21, 2024 at 06:53:44PM +0000, Edgecombe, Rick P wrote:
> On Wed, 2024-02-21 at 13:30 -0500, dalias@...c.org wrote:
> > > 3 is the cleanest and safest I think, and it was thought it might
> > > not
> > > need kernel help, due to a scheme Florian had to direct signals to
> > > specific threads. It's my preference at this point.
> > 
> > The operations where the shadow stack has to be processed need to be
> > executable from async-signal context, so this imposes a requirement
> > to
> > block all signals around the lock. This makes all longjmps a heavy,
> > multi-syscall operation rather than O(1) userspace operation. I do
> > not
> > think this is an acceptable implementation, especially when there are
> > clearly superior alternatives without that cost or invasiveness.
> 
> That is a good point. Could the per-thread locks be nestable to address
> this? We just need to know if a thread *might* be using shadow stacks.
> So we really just need a per-thread count.

Due to arbitrarily nestable signal frames, no, this does not suffice.
An interrupted operation using the lock could be arbitrarily delayed,
even never execute again, making any call to dlopen deadlock.

> > > 1 and 2 are POCed here, if you are interested:
> > > https://github.com/rpedgeco/linux/commits/shstk_suppress_rfc/
> > 
> > I'm not clear why 2 (suppression of #CP) is desirable at all. If
> > shadow stack is being disabled, it should just be disabled, with
> > minimal fault handling to paper over any racing operations at the
> > moment it's disabled. Leaving it on with extreme slowness to make it
> > not actually do anything does not seem useful.
> 
> The benefit is that code that is using shadow stack instructions won't
> crash if it relies on them working. For example RDSSP turns into a NOP
> if shadow stack is disabled, and the intrinsic is written such that a
> NULL pointer is returned if shadow stack is disabled. The shadow stack
> is normally readable, and this happens in glibc sometimes. So if there
> was code like:
> 
>    long foo = *(long *)_get_ssp();
> 
> ...then it could suddenly read a NULL pointer if shadow stack got
> disabled. (notice, it's not even a "shadow stack access" fault-wise. So
> it was looked at as somewhat more robust. But neither 1 or 2 are
> perfect for apps that are manually using shadow stack instructions.

It's fine to turn RDSSP into an actual emulated read of the SSP, or at
least an emulated load of zero so that uninitialized data is not left
in the target register. If doing the latter, code working with the
shadow stack just needs to be prepared for the possibility that it
could be async-disabled, and check the return value.

I have not looked at all the instructions that become #UD but I
suspect they all have reasonable trivial ways to implement a
"disabled" version of them that userspace can act upon reasonably.

Rich