Re: [RFC] Circumventing FineIBT Via Entrypoints

[Peter Zijlstra <peterz@infradead.org>]

On Mon, Feb 17, 2025 at 01:06:29PM +0000, David Laight wrote:
> On Sat, 15 Feb 2025 22:07:29 +0100
> Peter Zijlstra <peterz@infradead.org> 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