On Sun, May 17, 2026 at 01:30:17PM -0500, Richard Patel wrote: > I was quite surprised that the Linux kernel still does not allow > userspace to enable x86 IBT (indirect jmp/call integrity). > > Compilers and linkers have been emitting 'endbr64' IBT markers and ELF > support notes for a while now. > > The hard work was done years ago by Intel: > https://lore.kernel.org/all/[email protected]/ > > In summary, usermode IBT requires 3 things: > 1. Set the CET_ENDBR_EN bit in MSR_IA32_U_CET for each IBT-enabled thread > (PATCH 2,5) > 2. Back up the WAIT_FOR_ENDBR bit across signal handling (PATCH 3,4) > 3. Provide a way for usermode to enable it (PATCH 5) > > This builds on top of Yu Cheng's work, with some adaptations: > - FRED support > - Implemented the existing prctl(PR_CFI_*) API > - Removed ELF parsing (can be added later) > > Unresolved questions: > - Is there a cleaner way to do the WAIT_FOR_ENDBR XSAVE fallback? > - What to do about 'notrack jmp *rax'? > I leave CET_NO_TRACK_EN enabled, which weakens IBT, by enabling a jump > prefix that skips the ENDBR check. GCC emits it for jump tables > (-mcet-switch). We could introduce a PR_CFI_IBT_STRICT bit. > - There's some obvious overlap with arch_prctl(ARCH_SHSTK_*). > Happy to use that API instead.
Right, I think the problem was mostly one of ABI. Various distributions shipped with 'early' patches using an ABI that hadn't seen upstream review much, and when it hit we went uhhh, no! And then glibc and distros were like, but uhmm, it has to be. So here we are :-( Anyway, the most contentious part was the whole backwards compat bitmap crap. When the dynamic linker composes a process of parts that support IBT and parts that do not, you get to deal with fallout. The IBT spec has this horrid bitmap thing to try and deal with this, and those early patches exposed that piece of shit to userspace. Then later patches (suggested by me) used the ARM64/BTI approach of using PROT_BTI. We'd use a (software) page-table bit, and upon #CP consult that to see if we should eat the trap or produce a warn/signal whatever. I think we were near something workable there when Rick got pulled from this and put onto something more 'important' and things just haven't moved ever since. Anyway, glad to see someone has time to poke at this.
