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 11:11:41PM +0000, Edgecombe, Rick P wrote:
> On Thu, 2026-10-08 at 22:47 +0000, Richard Patel wrote:
> > On Thu, Oct 08, 2026 at 10:34:02PM +0000, Edgecombe, Rick P wrote: 
> > > 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. :(
> 
> Yes I didn't know they did not parse the shadow stack signal frame
> appropriately. That is unfortunate. But we can still evolve the shadow stack ABI
> by adding new modes to the enable prctl if we want.

Will send libgcc and CRIU patches for this.

> > 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.
> 
> The wishes from the glibc/distro side were to support as many apps as possible.
> The other way would be to create a more locked down mode where developers need
> to carefully verify their apps.

I'll have an AI scan through all Debian repo sources to see if anyone
is doing naughty sigreturns. Even if so, if we evolve the user shstk
ABI, it might be worth breaking that (via opt-in arch_prctl), if it
helps with security.

> > > 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?
> 
> For the 32 bit signal blocking patch? I'm not sure why on the security grounds.
> I think it depends on how much we want to deflect ia32 mischief vs just ignore
> it.
> 
> To me it is a cost/benefit thing. Having to think through which syscalls matter
> was the point of blocking 32 bit runtime in the first place, so this evaluation
> seems too high on the cost. If we do anything more, it should be another small
> and complete thing. Like blocking all 32 bit syscalls.

Conceptually, I think shadow stack should authenticate all return
addresses placed on the stack. %rip in the signal frame is a return
address for any non-crazy use, but it's not authenticated. And IMHO that
should be fixed.

Unfortunately my patches fall short of plugging that gap, so I agree
they don't have a security benefit.

I'm eager to fix it and authenticate sigreturn rip, provided you think
it's worth doing.

Cheers,
-- Richard