linux-kernel - Re: [RFC] Circumventing FineIBT Via Entrypoints

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250217103952.GM14028@noisy.programming.kicks-ass.net>
Date: Mon, 17 Feb 2025 11:39:52 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Kees Cook <kees@...nel.org>
Cc: Andrew Cooper <andrew.cooper3@...rix.com>, jannh@...gle.com,
	jmill@....edu, joao@...rdrivepizza.com,
	linux-hardening@...r.kernel.org, linux-kernel@...r.kernel.org,
	luto@...nel.org, samitolvanen@...gle.com,
	scott.d.constable@...el.com, x86@...nel.org
Subject: Re: [RFC] Circumventing FineIBT Via Entrypoints

On Sun, Feb 16, 2025 at 03:51:27PM -0800, Kees Cook wrote:
> 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. :) 

Excellent!

> (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?)

No space; UD2 is a 2 byte instruction. IIUC all the single byte
instructions that trip #UD are more or less 'reserved' and we shouldn't
be using them, but I think we can use 0xEA here since it is specific to
the paranoid FineIBT thing -- and if people want to reclaim the usage,
all they need to do is fix IBT :-) -- which as I said before should be
done once FRED happens.

(/me makes note to go read the very latest FRED spec -- its been a
while).

> > 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?

Sami was, he reminded me I forgot to hook up FineIBT, so I did :-)

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

Thanks!