Re: [RFC] Circumventing FineIBT Via Entrypoints

[Kees Cook <kees@kernel.org>]

On Sat, Feb 15, 2025 at 10:07:29PM +0100, Peter Zijlstra 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)
> 
> Of which the last 6 bytes are the retpoline site (starting at 0x6e). It
> is trivially possible to re-arrange things to have both nops next to one
> another, giving us 7 bytes to muck about with.
> 
> And I think we can just about manage to do a caller side hash validation
> in them bytes like:
> 
> 0000000000000080 <fineibt_paranoid>:
>   80:   41 ba 78 56 34 12       mov    $0x12345678,%r10d
>   86:   49 83 eb 10             sub    $0x10,%r11
>   8a:   45 3b 53 07             cmp    0x7(%r11),%r10d
>   8e:   74 01                   je     91 <fineibt_paranoid+0x11>
>   90:   ea                      (bad)
>   91:   41 ff d3                call   *%r11

Ah nice! Yes, that would be great and removes all my concerns about
FineIBT. :) (And you went with EA just to distinguish it more easily?
Can't we still use the UD2 bug tables to find this like normal?)

> And while this is somewhat daft, it would close the hole vs this entry
> point swizzle afaict, no?
> 
> Patch against tip/x86/core (which includes the latest ibt bits as per
> this morning).
> 
> Boots and builds the next kernel on my ADL.

Lovely! Based on the patch, I assume you were testing CFI crash location
reporting too?

I'll try to get this spun up for testing here too.

-- 
Kees Cook