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

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

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.

-- David

> - There's some obvious overlap with arch_prctl(ARCH_SHSTK_*).
>   Happy to use that API instead.
...