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
