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.
Attachment:
signature.asc
Description: PGP signature
