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

[Richard Patel]

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