Re: [PATCH 4/7] x86: ban 32-bit sigreturn when user IBT enabled

[David Laight <david.laight.linux@gmail.com>]

On Sun, 24 May 2026 21:53:09 +0000
Richard Patel <ripatel@wii.dev> wrote:

> On Mon, May 18, 2026 at 01:22:19PM -0700, H. Peter Anvin wrote:
> > On May 17, 2026 11:30:21 AM PDT, Richard Patel <ripatel@wii.dev> wrote:  
> > >diff --git a/arch/x86/kernel/signal_32.c b/arch/x86/kernel/signal_32.c
> > >index e55cf19e68fe..7cb76d794366 100644
> > >--- a/arch/x86/kernel/signal_32.c
> > >+++ b/arch/x86/kernel/signal_32.c
> > >@@ -143,6 +143,11 @@ static bool ia32_restore_sigcontext(struct pt_regs *regs,
> > > 	regs->ds = fixup_rpl(sc.ds);
> > > #endif
> > > 
> > >+#ifdef CONFIG_X86_USER_IBT
> > >+	if (current->thread.ibt)
> > >+		return false;
> > >+#endif
> > >+
> > > 	return fpu__restore_sig(compat_ptr(sc.fpstate), 1);
> > > }
> > >   
> > 
> > Dumb question: is there any reason not to just enable it for 32 bits? It doesn't seem that it would be that big of a delta to Just Do It.™
> > 
> > That being said, I suspect the number of users will be very small if any.  
> 
> Hello Peter,
> 
> I researched 32-bit user IBT support a bit more.
> 
> Intel's original patches used uc_flags, which is not available in the
> legacy 32-bit frame (breaks sigreturn(2)).
> 
> But you could also store Intel CET state via XSAVE into sigframe
> fpstate, like for Arm64 BTI.
> 
> Unfortunately though, this includes both CET control flags ("is IBT
> enabled?") and user state (WAIT_FOR_ENDBR). Since fpstate is writable,
> XFEATURE_USER_CET is in XFEATURE_MASK_SUPERVISOR_ALL.
> 
> So, we have 3 options:
> 
> 1. Include CET in both XSAVE and XRSTOR, but revert user changes to
>    control bits before restoring.
> 
> 2. Include CET in XSAVE, exclude CET from XRSTOR.
>    Parse XSAVE and restore IBT state "by hand".
>    * Breaking XSAVE/XRSTOR symmetry seems like a bad idea?
>      But the user can already remove xfeatures bits, I think.
> 
> 3. No CET in XSAVE, instead abuse uc_flags to save this state bit
>    (this patch series).
>    * uc_flags does not exist in sigframe_ia32, which hasn't been touched
>      in 10 years
> 
> IMO: Option 1 seems crazy. Option 2 worth a sketch. Option 3 is ugly.
> 
> Really curious what you think.  I'm going to send out v2 today with
> option 2 (CET XSAVE, software restore), and if anyone hates it,
> I will revert to option 3 (CET software backup and restore), and at
> least add rt_sigreturn ia32 support.
> 
> Btw, OpenBSD doesn't do any of these and discards IBT state.
> So, if you spam signals on OpenBSD, you can bypass their IBT.
> That is, uh, option 4, I guess.

That is still better than IBT disabled.
Wouldn't you crash the program when the signal 'missed'.
So there are probably easier ways to break things.

I think that would have the side effect that code would run when
single-stepped by gdb, but fail otherwise.
If true that would confuse things.

-- David

> 
> Thanks,
> -Richard
>