linux-kernel - Re: [PATCH] kallsyms: fix nonconverging kallsyms table with lld

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: <CAK8P3a1kgc6+fSHr7ddMRHxh+znW6jL2ZSo=JLWa-Uuzw7UZ-w@mail.gmail.com>
Date:   Wed, 9 Jun 2021 22:30:23 +0200
From:   Arnd Bergmann <arnd@...nel.org>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Michal Marek <michal.lkml@...kovi.net>,
        David Brazdil <dbrazdil@...gle.com>,
        Marc Zyngier <maz@...nel.org>,
        Mikhail Petrov <Mikhail.Petrov@....dev>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        mfaltesek@...gle.com
Subject: Re: [PATCH] kallsyms: fix nonconverging kallsyms table with lld

On Wed, Jun 9, 2021 at 9:15 PM Guenter Roeck <linux@...ck-us.net> wrote:
> On Wed, Jun 09, 2021 at 08:16:11AM -0700, Guenter Roeck wrote:
> > > I suppose we could improve the situation if scripts/link-vmlinux.sh was able
> > > to do that automatically, and compare the kallsyms output .S file between
> > > steps 1 and 2.
> >
> > Comparing the .S files doesn't result in useful data; turns out there are
> > always irrelevant differences. We'll try to run a diff on the output of
> > "objdump --syms". Hopefully that will generate something useful.
> >
>
> Turns out it wasn't that useful.
>
> chromeos-kernel-5_10-5.10.42-r406: Symbol file differences:
> chromeos-kernel-5_10-5.10.42-r406: 7c7
> chromeos-kernel-5_10-5.10.42-r406: < 00000000000325c8 g       .rodata   0000000000000000 kallsyms_relative_base
> chromeos-kernel-5_10-5.10.42-r406: ---
> chromeos-kernel-5_10-5.10.42-r406: > 00000000000325c0 g       .rodata   0000000000000000 kallsyms_relative_base
> chromeos-kernel-5_10-5.10.42-r406: 9,13c9,13
> chromeos-kernel-5_10-5.10.42-r406: < 00000000000325d0 g       .rodata   0000000000000000 kallsyms_num_syms
> chromeos-kernel-5_10-5.10.42-r406: < 00000000000325d8 g       .rodata   0000000000000000 kallsyms_names
> chromeos-kernel-5_10-5.10.42-r406: < 00000000000cd7f0 g       .rodata   0000000000000000 kallsyms_markers
> chromeos-kernel-5_10-5.10.42-r406: < 00000000000cdb18 g       .rodata   0000000000000000 kallsyms_token_table
> chromeos-kernel-5_10-5.10.42-r406: < 00000000000cde78 g       .rodata   0000000000000000 kallsyms_token_index
> chromeos-kernel-5_10-5.10.42-r406: ---
> chromeos-kernel-5_10-5.10.42-r406: > 00000000000325c8 g       .rodata   0000000000000000 kallsyms_num_syms
> chromeos-kernel-5_10-5.10.42-r406: > 00000000000325d0 g       .rodata   0000000000000000 kallsyms_names
> chromeos-kernel-5_10-5.10.42-r406: > 00000000000cd7d8 g       .rodata   0000000000000000 kallsyms_markers
> chromeos-kernel-5_10-5.10.42-r406: > 00000000000cdb00 g       .rodata   0000000000000000 kallsyms_token_table
> chromeos-kernel-5_10-5.10.42-r406: > 00000000000cde60 g       .rodata   0000000000000000 kallsyms_token_index
>
> I thought I'd see the added symbols, but it looks like the only difference
> between the two files is the addresses.
>
> What am I missing ?

I probably misremembered the part about 'objdump --syms' and there was
something more to it.

Maybe this was the last version before converging? It looks like the '<' version
has one extra symbol ompared to the '>' version. The diff has no context, but I
assume the first symbol that has a different size is 'kallsyms_offsets', which
is generated by kallsyms.

I see that link-vmlinux.sh already compares the System.map files, using
"cmp -s System.map .tmp_System.map", which is roughly the same as the
objdump --syms diff you got, so comparing these files probably doesn't
help either. However, comparing the .tmp_System.map file with the previous
version might reveal the problem. This might need another step to filter out
the address and only compare the symbol names.

      Arnd