[PATCH v9 05/39] arm64/gcs: Document the ABI for Guarded Control Stacks

[Mark Brown]

On Tue, Jul 16, 2024 at 06:50:12PM +0000, Edgecombe, Rick P wrote:
> On Wed, 2024-07-10 at 19:27 +0100, Mark Brown wrote:
> > On Wed, Jul 10, 2024 at 12:36:21PM +0200, Florian Weimer wrote:

> > > We also have a gap on x86-64 for backtrace generation because the
> > > interrupted instruction address does not end up on the shadow stack.
> > > This address is potentially quite interesting for backtrace generation.
> > > I assume it's currently missing because the kernel does not resume
> > > execution using a regular return instruction.  It would be really useful
> > > if it could be pushed to the shadow stack, or recoverable from the
> > > shadow stack in some other way (e.g., the address of the signal context
> > > could be pushed instead).  That would need some form of marker as well.

> > Right, we'd have to manually consume any extra address we put on the
> > GCS.  I'm not seeing any gagetisation issues with writing an extra value
> > there that isn't a valid stack cap at the minute but I'll need to think
> > it through properly - don't know if anyone else has thoughts here?

> Shadow stack has one main usage (security) and another less proven, but
> interesting usage for backtracing. I'm wary of adding things to the shadow stack
> as they come up in an ad-hoc fashion, especially for the fuzzier usage. Do you
> have a handle on everything the tracing usage would need?

Yeah, the current instruction pointer seems fairly straightforward to
idiomatically fit in there but going beyond that gets tricker.

> But besides that I've wondered if there could be a security benefit to adding
> some fields of the sigframe (RIP being the prime one) to the shadow stack, or a
> cryptographic hash of the sigframe.

One trick with trying to actually validate anything extra we put in
there from the sigframe would be that one of the things a signal handler
can do is modify the signal context - for the specific case of RIP
that'd be an issue for rseq for example.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-riscv/attachments/20240717/0dbf43a4/attachment.sig>