linux-kernel - Re: [POC][RFC][PATCH] build: Make weak functions visible in 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wgoORBJ6OkOA1g2MNHW4oEMRSkCbnyf7Ab+CL8pCQ0-ag@mail.gmail.com>
Date: Fri, 27 Dec 2024 10:09:40 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: LKML <linux-kernel@...r.kernel.org>, 
	Linux Trace Kernel <linux-trace-kernel@...r.kernel.org>, bpf <bpf@...r.kernel.org>, 
	linux-kbuild@...r.kernel.org, Masami Hiramatsu <mhiramat@...nel.org>, 
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Peter Zijlstra <peterz@...radead.org>, 
	Masahiro Yamada <masahiroy@...nel.org>, Nathan Chancellor <nathan@...nel.org>, 
	Nicolas Schier <nicolas@...sle.eu>, Zheng Yejian <zhengyejian1@...wei.com>, 
	Martin Kelly <martin.kelly@...wdstrike.com>, 
	Christophe Leroy <christophe.leroy@...roup.eu>, Josh Poimboeuf <jpoimboe@...hat.com>, 
	Mark Rutland <mark.rutland@....com>
Subject: Re: [POC][RFC][PATCH] build: Make weak functions visible in kallsyms

On Thu, 26 Dec 2024 at 19:45, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> >
> > Btw, does this actually happen when the compiler does the mcount thing for us?
>
> Yes.

Ok, that's actually good.

I'm not really worried about the "unused symbols aren't in kallsyms"
issue, even if it confuses the mcount logic. THAT confusion is easy to
deal with by either adding symbol size information (which I think
would be a good thing in general, although perhaps not worth it).

Even without the symbol size, the mcount issue can be dealt with by
just knowing that the mcount location has to be at the very beginning
of the function and just taking the offset - that we already do have -
into account.

I was more worried that there might also be some much deeper confusion
with the linker actually garbage collecting the unused weak function
code away, and now an unused symbol that kallsyms doesn't know about
wouldn't just have an unexpected mcount pointer to it, but the mcount
pointer would actually be stale and point to some unrelated code.

So as long as *that* isn't what is happening, this all seems fairly benign.

               Linus