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.