linux-kernel - Re: [PATCH v3 00/16] x86,objtool: Optimize !RETPOLINE

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LSU.2.21.2103301644250.11007@pobox.suse.cz>
Date:   Tue, 30 Mar 2021 17:02:13 +0200 (CEST)
From:   Miroslav Benes <mbenes@...e.com>
To:     Peter Zijlstra <peterz@...radead.org>
cc:     x86@...nel.org, jpoimboe@...hat.com, jgross@...e.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 00/16] x86,objtool: Optimize !RETPOLINE

On Fri, 26 Mar 2021, Peter Zijlstra wrote:

> Hi, another week, another update :-)
> 
> Respin of the !RETPOLINE optimization patches.
> 
> Boris, the first 3 should probably go into tip/x86/core, it's an ungodly tangle
> since it relies on the insn decoder patches in tip/x86/core, the NOP patches in
> tip/x86/cpu and the alternative patches in tip/x86/alternatives.
> 
> Just to make life easy I'd suggest merging everything in x86/core and
> forgetting about the other topic branches (that's what I ended up doing locally).
> 
> The remaining 13 patches depend on the first 3 as well as on the work in
> tip/objtool/core, just to make life more interesting still ;-)
> 
> All except the last 4 patches should be fairly uncontroversial (I hope...).
> 
> There's a fair number of new patches and another few have been completely
> rewritten, but it all seems to work nicely.

Reviewed-by: Miroslav Benes <mbenes@...e.cz>

for the objtool changes. All looks much better in this version.

I have only one minor thing. There are only two call sites of 
elf_add_string(). The one in elf_create_section() passes shstrtab, the 
other one in elf_create_undef_symbol() NULL. elf_add_string() then 
retrieves it itself. I think it would be nicer to just call 
find_section_by_name() in elf_create_undef_symbol(), pass it down and make 
it consistent. Might be a matter of taste.

Miroslav