linux-kernel - Re: Static call dependency on libelf version?

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: <d02d57308d9e8febd569c3fd3757dbcc87b1c4a1.camel@klomp.org>
Date:   Tue, 15 Sep 2020 13:24:17 +0200
From:   Mark Wielaard <mark@...mp.org>
To:     peterz@...radead.org, Hugh Dickins <hughd@...gle.com>
Cc:     Josh Poimboeuf <jpoimboe@...hat.com>, linux-kernel@...r.kernel.org,
        x86@...nel.org
Subject: Re: Static call dependency on libelf version?

H Peter,

On Tue, 2020-09-15 at 11:30 +0200, peterz@...radead.org wrote:
> On Tue, Sep 15, 2020 at 12:50:54AM -0700, Hugh Dickins wrote:
> > CONFIG_HAVE_STATIC_CALL=y
> > CONFIG_HAVE_STATIC_CALL_INLINE=y
> > stand out as new in the .config for 5.9-rc5-mm1, and references
> > to objtool in static_call.h and static_call_types.h took me to
> > tools/objtool/Makefile, with its use of libelf.
> > 
> > I've copied over files of the newer libelf (0.168) to the failing
> > machines, which are now building the 5.9-rc5-mm1 vmlinux correctly.
> > 
> > It looks as if CONFIG_HAVE_STATIC_CALL=y depends on a newer libelf
> > than I had before (0.155), and should either insist on a minimum
> > version, or else be adjusted to work with older versions.
> 
> Hurmph, I have no idea how this happened; clearly none of my machines
> have this older libelf :/ (the machines I use most seem to be on
> 0.180).
> 
> I'm also not sure what static_call is doing different from say orc
> data generation. Both create and fill sections in similar ways.
> 
> Mark, do you have any idea?

0.155 is more than 8 years old. Given that 0.168 (4 years old) works
fine and this might be an interaction with objtool, which if I remember
correctly uses ELF_C_RDWR to manipulate an ELF file in place, I suspect
it might be:

commit 88ad5ddb71bd1fa8ed043a840157ebf23c0057b3
Author: Mark Wielaard <mjw@...hat.com>
Date:   Tue Nov 5 16:27:32 2013 +0100

    libelf: Write all section headers if elf flags contains ELF_F_DIRTY.
    
    When ehdr e_shoff changes, elf flags is set dirty. This indicates that
    the section header moved because sections were added/removed or changed
    in size.
    
    Reported-by: Jiri Slaby <jslaby@...e.cz>
    Signed-off-by: Mark Wielaard <mjw@...hat.com>

Which is described as elfutils-0.157-15-g88ad5ddb so was in elfutils
0.158, but not before. At least the issue seems to mimics the bug
report a little:
https://sourceware.org/legacy-ml/elfutils-devel/imported/msg03724.html

But all this is for ancient versions of elfutils libelf. So it is hard
to say and my memory might be failing. If someone can confirm 0.158
(which is 6 years old) works fine I would pick that as minimum version,
otherwise simply go with 0.168 which is 4 years old and should be on
most systems by now.

Cheers,

Mark