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
| ||
|
Date: Mon, 7 Oct 2019 13:26:06 +0200 From: Ingo Molnar <mingo@...nel.org> To: Peter Zijlstra <peterz@...radead.org> Cc: x86@...nel.org, linux-kernel@...r.kernel.org, rostedt@...dmis.org, mhiramat@...nel.org, bristot@...hat.com, jbaron@...mai.com, torvalds@...ux-foundation.org, tglx@...utronix.de, namit@...are.com, hpa@...or.com, luto@...nel.org, ard.biesheuvel@...aro.org, jpoimboe@...hat.com, hjl.tools@...il.com, Andrew Morton <akpm@...ux-foundation.org>, Borislav Petkov <bp@...en8.de>, Denys Vlasenko <dvlasenk@...hat.com> Subject: Re: [RFC][PATCH 0/9] Variable size jump_label support [ Sorry, fixed the Cc:lkml line. ] * Peter Zijlstra <peterz@...radead.org> wrote: > These here patches are something I've been poking at for a while, > enabling jump_label to use 2 byte jumps/nops. > > It _almost_ works :-/ > > That is, you can build some kernels with it (x86_64-defconfig for > example works just fine). > > The problem comes when GCC generates a branch into another section, > mostly .text.unlikely. At that point GAS just gives up and throws a fit > (more details in the last patch). > > Aside from anyone coming up with a really clever GAS trick, I don't see > how we can do this other than: > - use 'jmp' and get objtool to rewrite the text. Steven has earlier proposed > something like that (using recordmcount) and Linus hated that. As long as GCC+GAS correctly generates a 2-byte or 5-byte JMP depending on the target distance, the objtool solution should work fine, shouldn't it? I can see the recordmcount solution sucking, it would depend on early kernel patchery. But build time patchery is something we already depend on, so assuming some objtool catastrophy it's a more robust solution, isn't it? Thanks, Ingo
Powered by blists - more mailing lists