On Sun, 24 May 2026 21:53:09 +0000 Richard Patel <[email protected]> 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 <[email protected]> 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 >
