Re: [PATCH 1/3] x86/shstk: ban ia32 sigreturn when shadow stack is enabled

[Edgecombe, Rick P]

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 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. 

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.