Message-ID: <e3a432c0fa9f5fe837e9d2fc7b36304709a34428.camel@intel.com>
Date: Wed, 21 Feb 2024 19:22:21 +0000
From: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
To: "dalias@...c.org" <dalias@...c.org>
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, 2024-02-21 at 14:06 -0500, dalias@...c.org wrote:
> 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.

Doh! Yep, it is not robust to this. The only thing that could be done
would be a timeout in dlopen(). Which would make the whole thing just
better than nothing.

> 
> > 
> 
> 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.

We can't intercept RDSSP, but it becomes a NOP by default. (disclaimer
x86-only knowledge).

>  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.

This would have to be thought through functionally and performance
wise. I'm not opposed if can come up with a fully fleshed out plan. How
serious are you in pursuing musl support, if we had something like
this?

HJ, any thoughts on whether glibc would use this as well?

It is probably worth mentioning that from the security side (as Mark
mentioned there is always tension in the tradeoffs on these features),
permissive mode is seen by some as something that weakens security too
much. Apps could call dlopen() on a known unsupported DSO before doing
ROP. I don't know if you have any musl users with specific shadow stack
use cases to ask about this.

Powered by blists - more mailing lists