linux-kernel - Re: [PATCH v2] modpost: Skip .llvm.call-graph-profile section check

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: <CAFP8O3+3++awDi9uZueFC_xi+KAud0Ds3k3vdd_ruVngOEOKiw@mail.gmail.com>
Date:   Wed, 23 Aug 2023 16:54:10 -0700
From:   Fangrui Song <maskray@...gle.com>
To:     Masahiro Yamada <masahiroy@...nel.org>
Cc:     Denis Nikitin <denik@...omium.org>, linux-kbuild@...r.kernel.org,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nathan Chancellor <nathan@...nel.org>,
        Nicolas Schier <nicolas@...sle.eu>, Tom Rix <trix@...hat.com>,
        linux-kernel@...r.kernel.org, llvm@...ts.linux.dev,
        Douglas Anderson <dianders@...omium.org>
Subject: Re: [PATCH v2] modpost: Skip .llvm.call-graph-profile section check

On Wed, Aug 23, 2023 at 4:13 PM Denis Nikitin <denik@...omium.org> wrote:
>
> On Wed, Aug 23, 2023 at 4:02 PM Masahiro Yamada <masahiroy@...nel.org> wrote:
> >
> > On Wed, Aug 23, 2023 at 3:00 AM Fangrui Song <maskray@...gle.com> wrote:
> > >
> > > On Tue, Aug 22, 2023 at 10:49 AM Denis Nikitin <denik@...omium.org> wrote:
> > > >
> > > > .llvm.call-graph-profile section is added by clang when the kernel is
> > > > built with profiles (e.g. -fprofile-sample-use= or -fprofile-use=).
> > > >
> > > > The section contains edge information derived from text sections,
> > > > so .llvm.call-graph-profile itself doesn't need more analysis as
> > > > the text sections have been analyzed.
> > > >
> > > > This change fixes the kernel build with clang and a sample profile
> > > > which currently fails with:
> > > >
> > > > "FATAL: modpost: Please add code to calculate addend for this architecture"
> >
> >
> > Curious.
> >
> > This message is only displayed for REL.
> >
> > (Please not it is located in section_rel() function)
> >
> >
> > I think modern architectures use RELA instead of REL.
> > Which architecture are we talking about?
>
> Aarch64. There was also a report on x86-64 but the error message could be
> different there.

Regarding REL:

The original format of .llvm.call-graph-profile
(SHT_LLVM_CALL_GRAPH_PROFILE=0x6fff4c02) used symbol indices without
relocations and could be corrupted by symbol table change.
https://github.com/llvm/llvm-project/commit/a224c5199b327ed0efcdcd87b6dbf950cf4d9ee1
(2021) changed the format to represent call edge information with
R_*_NONE and changed SHT_LLVM_CALL_GRAPH_PROFILE to 0x6fff4c09.

We don't use the addend field of R_*_NONE relocations, so I proposed
that we use REL for all targets.
My https://github.com/llvm/llvm-project/commit/ca3bdb57fa1ac98b711a735de048c12b5fdd8086
selected REL for .llvm.call-graph-profile

aaelf64 says:

> A binary file may use ``REL`` or ``RELA`` relocations or a mixture of the two (but multiple relocations of the same place must use only one type).

Other psABI documents may be more vague on how REL is used, but as
long as the tool that needs to process it (currently just lld and
readelf like tools) supports it, it's fine.
binutils seems to support REL for all ELF targets, even if its
objcopy/strip may unintentionally convert REL to RELA. lld can consume
RELA SHT_LLVM_CALL_GRAPH_PROFILE.

> >
> >
> > What does the output of this command look like?
> >
> > $ llvm-readelf -S vmlinux.o | grep  .llvm.call-graph-profile
> >
> >
> > Is it REL?
> >
>
>   [119] .llvm.call-graph-profile LLVM_CALL_GRAPH_PROFILE 0000000000000000
> 1c74a458 0104c8 08   E  0   0  1
>   [120] .rel.llvm.call-graph-profile REL 0000000000000000 1c75a920 041320 10
> I 26090 119  8
>
> Thanks,
> Denis



-- 
宋方睿