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

[Richard Patel <ripatel@wii.dev>]

On Thu, Oct 08, 2026 at 08:59:57PM +0000, Edgecombe, Rick P wrote:
> On Thu, 2026-10-08 at 20:16 +0000, Richard Patel wrote:
> > When returning from a signal via x32 or x64 rt_sigreturn, the
> > shadow-stack-restore token is validated, but ia32 (rt_)sigreturn
> > do not call restore_signal_shadow_stack().
> > 
> > With IA32_EMULATION, 'int $0x80' allows ia32 sigreturn in 64-bit
> > mode, which could defeat sigreturn protection.
> > 
> > Refuse ia32 sigreturn by forcing a SIGSEGV instead.
> 
> 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.

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.