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!
