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

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Thu, 2026-10-08 at 22:47 +0000, Richard Patel 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.

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

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