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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 4 May 2022 10:04:02 -0700 From: Peter Collingbourne <pcc@...gle.com> To: Peter Zijlstra <peterz@...radead.org> Cc: Josh Poimboeuf <jpoimboe@...hat.com>, Joao Moreira <joao@...rdrivepizza.com>, linux-kernel@...r.kernel.org, linux-hardening@...r.kernel.org, andrew.cooper3@...rix.com, keescook@...omium.org, samitolvanen@...gle.com, mark.rutland@....com, hjl.tools@...il.com, alyssa.milburn@...ux.intel.com, ndesaulniers@...gle.com, gabriel.gomes@...ux.intel.com, rick.p.edgecombe@...el.com Subject: Re: [RFC PATCH 01/11] x86: kernel FineIBT On Wed, May 04, 2022 at 12:20:19PM +0200, Peter Zijlstra wrote: > On Tue, May 03, 2022 at 03:02:44PM -0700, Josh Poimboeuf wrote: > > > I'm not really qualified to comment on this too directly since I haven't > > looked very much at the variations on FineIBT/CFI/KCFI, and what the > > protections and drawbacks are for each approach, and when it might even > > make sense to combine them for a "paranoid user". > > > > Since we have multiple similar and possibly competing technologies being > > discussed, one thing I do want to warn against is that we as kernel > > developers tend to err on the side of giving people too many choices and > > combinations which *never* get used. > > So I don't think there's going to be a user choice here. If there's > hardware support, FineIBT makes more sense. That also means that kCFI no > longer needs to worry about IBT. > > If we do something like: > > > kCFI FineIBT > > __cfi_\sym: __cfi_\sym: > endbr # 4 endbr # 4 > sub $hash, %r10 # 7 sub $hash, %r10 # 7 > je \sym # 2 je \sym # 2 > ud2 # 2 ud2 # 2 > \sym: \sym: > > > caller: caller: > cmpl $hash, -8(%r11) # 8 movl $hash, %r10d # 6 > je 1f # 2 sub 15, %r11 # 4 > ud2 # 2 call *%r11 # 3 > 1: call __x86_indirect_thunk_r11 # 5 .nop 4 # 4 (could even fix up r11 again) > > > Then, all that's required is a slight tweak to apply_retpolines() to > rewrite a little more text. > > Note that this also does away with having to fix up the linker, since > all direct call will already point at \sym. It's just the IBT indirect > calls that need to frob the pointer in order to hit the ENDBR. > > On top of that, we no longer have to special case the objtool > instruction decoder, the prelude are proper instructions now. For kCFI this brings back the gadget problem that I mentioned here: https://lore.kernel.org/all/Yh7fLRYl8KgMcOe5@google.com/ because the hash at the call site is 8 bytes before the call instruction. Peter
Powered by blists - more mailing lists