linux-kernel - Re: [PATCH v3] scripts/link-vmlinux.sh: Add alias to duplicate symbols for kallsyms

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] [day] [month] [year] [list]

Message-ID: <ZQFtdJEKJ9taYpA0@alley>
Date:   Wed, 13 Sep 2023 10:06:12 +0200
From:   Petr Mladek <pmladek@...e.com>
To:     Alessandro Carminati <alessandro.carminati@...il.com>
Cc:     Alexander Lobakin <aleksander.lobakin@...el.com>,
        Masami Hiramatsu <mhiramat@...nel.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Daniel Bristot de Oliveira <bristot@...nel.org>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Luis Chamberlain <mcgrof@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nicolas Schier <nicolas@...sle.eu>,
        Nick Alcock <nick.alcock@...cle.com>,
        Kris Van Hees <kris.van.hees@...cle.com>,
        Eugene Loh <eugene.loh@...cle.com>,
        Francis Laniel <flaniel@...ux.microsoft.com>,
        Viktor Malik <vmalik@...hat.com>, linux-kbuild@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
        live-patching@...r.kernel.org
Subject: Re: [PATCH v3] scripts/link-vmlinux.sh: Add alias to duplicate
 symbols for kallsyms

On Tue 2023-09-12 16:18:00, Alessandro Carminati wrote:
> <aleksander.lobakin@...el.com> ha scritto:
> > From: Alessandro Carminati (Red Hat) <alessandro.carminati@...il.com>
> > > sample from new v3
> > >
> > >  ~ # cat /proc/kallsyms | grep gic_mask_irq
> > >  ffffd0b03c04dae4 t gic_mask_irq
> > >  ffffd0b03c04dae4 t gic_mask_irq@...ivers_irqchip_irq-gic_c_167
> > >  ffffd0b03c050960 t gic_mask_irq
> > >  ffffd0b03c050960 t gic_mask_irq@...ivers_irqchip_irq-gic-v3_c_404
> >
> > BTW, why normalize them? Why not just
> >
> > gic_mask_irq@...vers/irqchip/...
> >
> > Aaaaand why line number? Line numbers break reproducible builds and also
> > would make it harder to refer to a particular symbol by its path and
> > name since we also have to pass its line number which may change once
> > you add a debug print there, for example.
> > OTOH there can't be 2 symbols with the same name within one file, so
> > just path + name would be enough. Or not?

I am afraid that there can be more symbols with the same name in a
single source file. For example, static variables defined inside
functions:

$> cat >test-duplicate-symbols.c <<EOT
#include <stdio.h>

void a(void)
{
	static int duplicate_var = 100;

	printf("%s: %d\n", __func__, duplicate_var);
}

void b(void)
{
	static int duplicate_var = 200;

	printf("%s: %d\n", __func__, duplicate_var);
}

int main(int argc, char *argv)
{
	a();
	b();
}
EOT

$> gcc -o test-duplicate-symbols test-duplicate-symbols.c

$> ./test-duplicate-symbols 
a: 100
b: 200

$> objdump -t test-duplicate-symbols | grep duplicate
test-duplicate-symbols:     file format elf64-x86-64
0000000000000000 l    df *ABS*  0000000000000000              test-duplicate-symbols.c
0000000000402018 l     O .data  0000000000000004              duplicate_var.2190
000000000040201c l     O .data  0000000000000004              duplicate_var.2195


> Regarding the use of full file paths and line numbers for symbol decoration,
> it indeed provides the highest level of uniqueness for each symbol.
> However, I understand your point that this level of detail might be more than
> necessary.
> 
> This approach was implemented in response to a specific request expressed in
> the live-patching list, and I wanted to ensure we met those requirements.
> I am open to revisiting this aspect, and I am willing to accommodate changes
> based on feedback.

Yeah, livepatching needs to be able to find any symbol which might
need to be accessed from the livepatch.

The line number is perfectly fine for livepatching because there
is 1:1:1 relationship between the kernel sources, binary, and
livepatch.

And it might be even useful for the tracing. It helps to find
and investigate the traced code easily.

Hmm, I understand that it complicates the live for the trace
tooling. I wonder if we could allow searching the symbols
with a pattern, e.g. the bash style
"duplicated_symbol_name-source_file_c*"


> If you believe that simplifying the format to just path + name would be more
> practical, or if you think that eliminating line numbers is a better choice
> to avoid potential issues while debugging builds, I'm open to considering
> these adjustments.
> Additionally, I've interpreted and implemented Francis's suggestion as making
> the separator a configurable option, but maybe a proper format string here,
> would be more appropriate.

Please, do not make the format configurable. I think that it will
cause more harm than good. It would make the life more complicated
for developing tracing tools.

The tools would need to support all the formats as well. Or they
would support only some and will not be able to trace kernels
with the others. Both is bad.

Anyway, thanks a lot for working on this.

Best Regards,
Petr