linux-kernel - Re: [PATCH v3 16/16] objtool,x86: Rewrite retpoline thunk calls

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: <YL5kgx53yQeoJua3@hirez.programming.kicks-ass.net>
Date:   Mon, 7 Jun 2021 20:25:07 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Fāng-ruì Sòng <maskray@...gle.com>
Cc:     Nick Desaulniers <ndesaulniers@...gle.com>,
        Josh Poimboeuf <jpoimboe@...hat.com>, lma@...ihalf.com,
        Guenter Roeck <groeck@...gle.com>,
        Juergen Gross <jgross@...e.com>, lb@...ihalf.com,
        LKML <linux-kernel@...r.kernel.org>, mbenes@...e.com,
        Radosław Biernacki <rad@...ihalf.com>,
        upstream@...ihalf.com,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        clang-built-linux <clang-built-linux@...glegroups.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Sami Tolvanen <samitolvanen@...gle.com>
Subject: Re: [PATCH v3 16/16] objtool,x86: Rewrite retpoline thunk calls

On Mon, Jun 07, 2021 at 10:23:11AM -0700, Fāng-ruì Sòng wrote:
> On 2021-06-07, Peter Zijlstra wrote:

> > That does indeed seem to do the trick. Bit daft if you ask me, anybody
> > reading that file ought to have a handy bucket of 0s available, but
> > whatever.
> 
> Does the representation use the section index directly? (sym->sym.st_shndx)
> This can be fragile when the number of sections changes..., e.g. elf_add_section

No, things are supposed to use sym->sec, which is a pointer to our
struct section representation.

> So in llvm-objcopy's representation, the section index is represented as
> the section object.
> 
> struct Symbol {
>   ...
>   SectionBase *DefinedIn = nullptr;
>   ...
> };

Somewhat like that.

> In the writer stage, sections are assigned 32-bit indexes and the writer
> knows that an SHN_XINDEX for a symbol is needed if the index is >= 0xff00.

I think we only ever append sections, so pre-existing section numbers
stay correct. If libelf somehow does something else, we rely on it to
then keep the section numbers internally consistent.

And the only symbol write is this append of undef symbols, which are
always on section 0.