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, 20 Apr 2022 08:17:14 -0700 From: Josh Poimboeuf <jpoimboe@...hat.com> To: Peter Zijlstra <peterz@...radead.org> Cc: 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 00/11] Kernel FineIBT Support On Wed, Apr 20, 2022 at 09:40:44AM +0200, Peter Zijlstra wrote: > On Tue, Apr 19, 2022 at 05:42:30PM -0700, joao@...rdrivepizza.com wrote: > > @PeterZ @JoshP > > > > I'm a bit unaware of the details on why the objtool approach to bypass ENDBRs > > was removed from the IBT series. Is this approach now sensible considering that > > it is a requirement for a new/enhanced feature? If not, how extending the Linker > > to emit already fixed offsets sounds like? > > Josh hates objtool modifying actualy code. He much prefers objtool only > emits out of band data. > > Now, I did sneak in that jump_label nop'ing, and necessity (broken > compilers) had us do the KCOV nop'ing in noinstr, but if you look at the > recent objtool series here: > > https://lkml.kernel.org/r/cover.1650300597.git.jpoimboe@redhat.com > > you'll see his thoughs on that :-) > > Now, I obviously don't mind, it's easy enough to figure out what objtool > actually does with something like: > > $ OBJTOOL_ARGS="--backup" make O=ibt-build/ -j$lots vmlinux > $ objdiff.sh ibt-build/vmlinux.o > > Where objdiff.sh is the below crummy script. > > Now, one compromise that I did get out of Josh was that he objected less > to rewriting relocations than to rewriting the immediates. From my > testing the relocations got us the vast majority of direct call sites, > very few are immediates. > > Josh, any way you might reconsider all that? :-) If I remember correctly, the goal of --ibt-fix-direct was to avoid hitting unnecessary ENDBRs, which basically decode to NOPs, so the ghastly hack wasn't worth it. If FineIBT needs it, I could reconsider. But I think there's a strong case to be made that the linker should be doing that instead. -- Josh
Powered by blists - more mailing lists