On Thu, Oct 08, 2026 at 10:34:02PM +0000, Edgecombe, Rick P wrote: > On Thu, 2026-10-08 at 21:50 +0000, Richard Patel wrote: > > > How can it defeat protection? If doesn't process the shadow stack sigframe > > > at > > > all, leaving the SSP where ever it was originally. What am I missing? > > > > The selftest demonstrates that 'int $0x80' rt_sigreturn from 64-bit mode > > jumps to an arbitrary %eip in the signal frame (zero-extended to %rip), \ > > whereas the 'syscall' variant raises SIGSEGV if %rip is corrupt. > > > > It should just be restoring the SSP from the shadow stack signal frame. > Perhaps > you saw the syscall variant fail because it was not at the restorer. Since you > are manually calling sigreturn instead of returning normally. So then it was > was > not at the shadow stack signal frame and the shadow stack signal check thought > it was a forged SSP. And the 32 bit one succeed because there was nothing > checked. > > But that doesn't have to do with checking EIP matches where the signal was > generated?
I see now, sorry. Yes, I misread the code, and assumed the signal frame has a matching shadow stack entry that includes the RIP check. > > I don't think it matters that SSP is still at the old place. It would > > only break 'ret' after sigreturn, but the problem is that the sigreturn > > itself is a wild jump. > > > > "defeat protection" was badly worded, I just meant that the 'syscall' > > path has protections that the 'int $0x80' path doesn't have, so I > > thought it'd be worth fixing. > > > > I might be missing something, maybe SHSTK never intended to defend > > against a wild sigreturn? Either way, it's not a security thing. > > Hmm, I guess its kind of on the line between forward edge and backwards edge. > I > see your point. > > But today setting EIP to an arbitrary point is fairly easy. But even in a > future > case of IBT enabled, shadow stack would still need enhancements for the normal > 64 bit runtime to prevent this. What do you think of creating a shadow stack frame on signal delivery and popping that on sigreturn? I suppose that would need siglongjmp modifications and probably break CRIU. :( I wonder if there are real apps that abuse sigreturn as a forward edge. If so, they should not be advertising their DSO as shstk-compatible. > In the past we discussed hashing some amount of the sigframe and putting it on > the shadow stack to give some sigframe integrity. But this runs the risk of > breaking apps so would need to be an opt-in enhancement. Yes that seems a bit excessive to me. At least, the 64-bit path protects against obviously forged signal frames, so maybe there is still a case for the patch? -- Richard
