On Tue, May 19, 2026 at 02:28:08PM +0100, David Laight wrote: > On Tue, 19 May 2026 13:14:33 +0000 > Richard Patel <[email protected]> wrote: > > > On Tue, May 19, 2026 at 10:33:45AM +0100, David Laight wrote: > > > 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. > > > > You're right. I was worried about an invalid jump table index at first. > > Clang 22 happily optimizes away jump table index bounds checks. GCC 16 > > seems to be more careful. We should probably patch LLVM to never > > optimize it away, e.g.: > > > > // funny.c > > // clang -c -fcf-protection=branch -O2 -o funny.o funny.c > > // objdump -d funny.o -M intel > > int t0(void), t1(void), t2(void), t3(void); > > int funny(unsigned long target) { > > __builtin_assume(target < 4); > > If you use __builtin_assume() you get to clear up the mess.
I'm pretty sure you'd get the same result with cross-function optimization across a bunch of static functions or LTO. Compiler goes "oh, this internal function is only reachable from these 3 callers in the same unit, which all already bound their input params. Guess I will skip the bounds check". It is a compiler bug that Clang is at all able to generate unbounded 'notrack jmp' with -fcf-protection=branch, it blows a gap in IBT. Anyways, I don't think we need kernel support for banning notrack in userland? There is no ABI (GNU note) standard for 'notrack-free' binaries AFAIK, and as you point out notrack is a secure way to do jump tables (if done properly). > I don't know if userspace ever cares about speculative array access. > If it does you need one of the mitigration - eg using cmp+cmov > to generate a jump table index that references the 'default'. Intel docs say that "CET-IBT limits speculative execution at indirect branch targets that do not start with ENDBRANCH", with heavy emphasis on "limits" not "prevents" ... Is it too unreliable in practice? https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/technical-documentation/branch-history-injection.html#inpage-nav-4-3 -- Richard
