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 for Android: free password hash cracker in your pocket

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

Message-ID: <d18f060d-37ac-48b1-9f67-a5c5db79b34e@sirena.org.uk>
Date: Wed, 21 Feb 2024 13:53:10 +0000
From: Mark Brown <broonie@...nel.org>
To: "dalias@...c.org" <dalias@...c.org>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
	"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>,
	"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 Tue, Feb 20, 2024 at 08:27:37PM -0500, dalias@...c.org wrote:
> On Wed, Feb 21, 2024 at 12:35:48AM +0000, Edgecombe, Rick P wrote:

> > (INCSSP, RSTORSSP, etc). These are a collection of instructions that
> > allow limited control of the SSP. When shadow stack gets disabled,
> > these suddenly turn into #UD generating instructions. So any other
> > threads executing those instructions when shadow stack got disabled
> > would be in for a nasty surprise.

> This is the kernel's problem if that's happening. It should be
> trapping these and returning immediately like a NOP if shadow stack
> has been disabled, not generating SIGILL.

I'm not sure that's going to work out well, all it takes is some code
that's looking at the shadow stack and expecting something to happen as
a result of the instructions it's executing and we run into trouble.  A
lot of things won't notice and will just happily carry on but I expect
there are going to be things that care.  We also end up with an
additional state for threads that have had shadow stacks transparently
disabled, that's managable but still.

> > > The place where it's really needed to be able to allocate the shadow
> > > stack synchronously under userspace control, in order to harden
> > > normal
> > > applications that aren't doing funny things, is in pthread_create
> > > without a caller-provided stack.

> > Yea most apps don't do anything too tricky. Mostly shadow stack "just
> > works". But it's no excuse to just crash for the others.

> One thing to note here is that, to enable this, we're going to need
> some way to detect "new enough kernel that shadow stack semantics are
> all right". If there are kernels that have shadow stack support but
> with problems that make it unsafe to use (this sounds like the case),
> we can't turn it on without a way to avoid trying to use it on those.

If we have this automatic conversion of pages to shadow stack then we
should have an API for enabling it, userspace should be able to use the
presence of that API to determine if the feature is there.

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