Re: [PATCH 0/7] Usermode Indirect Branch Tracking

[Peter Zijlstra <peterz@infradead.org>]

On Tue, May 19, 2026 at 10:33:45AM +0100, David Laight wrote:
> On Sun, 17 May 2026 13:30:17 -0500
> Richard Patel <ripatel@wii.dev> 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/20210830182221.3535-1-yu-cheng.yu@intel.com/
> > 
> > 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.
> 
> Isn't using 'notrack jmp *reg' for jump tables actually more secure?
> If an attacker can write code it doesn't matter.
> The jump table in is RO memory so can't be written.
> But if there are ENDBR on all the jump table targets they become
> possibly useful code addresses to arrange to write into some RW
> function pointer table - which might be useful.

One of the many reasons the kernel is built without jump-tables.