On Mon, Feb 17, 2025 at 01:06:29PM +0000, David Laight wrote: > On Sat, 15 Feb 2025 22:07:29 +0100 > Peter Zijlstra <[email protected]> wrote: > > > On Fri, Feb 14, 2025 at 10:57:51AM +0100, Peter Zijlstra wrote: > > > On Thu, Feb 13, 2025 at 12:53:28PM -0800, Kees Cook wrote: > > > > > > > Right, the "if they can control a function pointer" is the part I'm > > > > focusing on. This attack depends on making an indirect call with a > > > > controlled pointer. Non-FineIBT CFI will protect against that step, > > > > so I think this is only an issue for IBT-only and FineIBT, but not CFI > > > > nor CFI+IBT. > > > > > > Yes, the whole caller side validation should stop this. > > > > And I think we can retro-fit that in FineIBT. Notably the current call > > sites look like: > > > > 0000000000000060 <fineibt_caller>: > > 60: 41 ba 78 56 34 12 mov $0x12345678,%r10d > > 66: 49 83 eb 10 sub $0x10,%r11 > > 6a: 0f 1f 40 00 nopl 0x0(%rax) > > 6e: 41 ff d3 call *%r11 > > 71: 0f 1f 00 nopl (%rax) > > I tried building a fineibt kernel (without LTO) and that isn't what I > see in the object files. > (I not trying to run it, just do some analysis.) > While the call targets have a 16 byte preamble it is all nops apart > from a final 'mov $hash,%rax'. > The call site loads $-hash and adds -4(target) and checks for zero. > It is too small to be patchable into the above.
Right after that comes the retpoline site, which is another 6 bytes (assuming you have indirect-branch-cs-prefix, which all kCFI enabled compilers should have). You need to go read arch/x86/kernel/alternative.c search for FineIBT
