[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <527e2b4d-5d2b-4993-a30a-834e77a23a40@sirena.org.uk>
Date: Tue, 20 Feb 2024 20:14:30 +0000
From: Mark Brown <broonie@...nel.org>
To: "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>
Cc: "corbet@....net" <corbet@....net>, "ardb@...nel.org" <ardb@...nel.org>,
"maz@...nel.org" <maz@...nel.org>,
"shuah@...nel.org" <shuah@...nel.org>,
"Szabolcs.Nagy@....com" <Szabolcs.Nagy@....com>,
"keescook@...omium.org" <keescook@...omium.org>,
"james.morse@....com" <james.morse@....com>,
"debug@...osinc.com" <debug@...osinc.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"oleg@...hat.com" <oleg@...hat.com>,
"arnd@...db.de" <arnd@...db.de>,
"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
"will@...nel.org" <will@...nel.org>,
"suzuki.poulose@....com" <suzuki.poulose@....com>,
"sorear@...tmail.com" <sorear@...tmail.com>,
"oliver.upton@...ux.dev" <oliver.upton@...ux.dev>,
"brauner@...nel.org" <brauner@...nel.org>,
"fweimer@...hat.com" <fweimer@...hat.com>,
"aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"paul.walmsley@...ive.com" <paul.walmsley@...ive.com>,
"hjl.tools@...il.com" <hjl.tools@...il.com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"palmer@...belt.com" <palmer@...belt.com>,
"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"thiago.bauermann@...aro.org" <thiago.bauermann@...aro.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"musl@...ts.openwall.com" <musl@...ts.openwall.com>,
"linux-riscv@...ts.infradead.org" <linux-riscv@...ts.infradead.org>
Subject: Re: [PATCH v8 00/38] arm64/gcs: Provide support for GCS in userspace
On Tue, Feb 20, 2024 at 06:41:05PM +0000, Edgecombe, Rick P wrote:
> On Tue, 2024-02-20 at 11:36 -0500, Stefan O'Rear wrote:
> > 2. Shadow stack faults on non-shadow stack pages, if flexible shadow
> > stack
> > handling is in effect, cause the affected page to become a shadow
> > stack
> > page. When this happens, the page filled with invalid address
> > tokens.
> Hmm, could the shadow stack underflow onto the real stack then? Not
> sure how bad that is. INCSSP (incrementing the SSP register on x86)
> loops are not rare so it seems like something that could happen.
Yes, they'd trash any pages of normal stack they touch as they do so but
otherwise seems similar to overflow.
> The situation (for arm and riscv too I think?) is that some
> applications will just not work automatically due to custom stack
> switching implementations. (user level threading libraries, JITs, etc).
> So I think it should be ok to ask for apps to change to enable shadow
> stack and we should avoid doing anything too awkward in pursuit of
> getting it to work completely transparently.
Yes, on arm64 anything that rewrites or is otherwise clever with the
stack is going to have to understand that the GCS exists on arm64 and do
matching rewrites/updates for the GCS. This includes anything that
switches stacks, it will need to use GCS specific instructions to change
the current shadow stack pointer.
> > MAP_SHARED; I consider this sufficiently perverse application
> > behavior that
> > it is not necessary to ensure exclusive use of the underlying pages
> > while
> > a shadow stack pte exists. (Applications that use MAP_SHARED for
> > stacks
> > do not get the full benefit of the shadow stack but they keep
> > POSIX.1-2004
> > conformance, applications that allocate stacks exclusively in
> > MAP_PRIVATE
> > memory lose no security.)
> On x86 we don't support MAP_SHARED shadow stacks. There is a whole
> snarl around the dirty bit in the PTE. I'm not sure it's impossible but
> it was gladly avoided. There is also a benefit in avoiding having them
> get mapped as writable in a different context.
Similarly for arm64, I think we can physically do it IIRC but between
having to map via map_shadow_stack() for security reasons and it just
generally not seeming like a clever idea the implementation shouldn't
actually let you get a MAP_SHARED GCS it's not something that's been
considered.
> > I am substantially less familiar with GCS and SHSTK than with
> > Zicfiss.
> > It is likely that a syscall or other mechanism is needed to
> > initialize the
> > shadow stack in flexible memory for makecontext.
> The ucontext stacks (and alt shadow stacks is the plan) need to have a
> "restore token". So, yea, you would probably need some syscall to
> "convert" the normal stack memory into shadow stack with a restore
> token.
Similar considerations for GCS, we need tokens and we don't want
userspace to be able to write by itself in the normal case.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
