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: <CAK7LNARUCpzr+1ey0MKmyCdTbaVOq8o7_42t4x5BW=4dyy4wPQ@mail.gmail.com>
Date: Fri, 27 Dec 2024 11:52:17 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, 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>, 
	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 Fri, Dec 27, 2024 at 11:19 AM Steven Rostedt <rostedt@...dmis.org> wrote:
>
> On Thu, 26 Dec 2024 15:01:07 -0800
> Linus Torvalds <torvalds@...ux-foundation.org> wrote:
>
> > On Thu, 26 Dec 2024 at 13:49, Steven Rostedt <rostedt@...dmis.org> wrote:
> > >
> > > But then, when the linker removes these functions because they were
> > > overridden, the code does not disappear, leaving the pointers in the
> > > __mcount_loc locations.
> >
> > This seems entirely unrelated to weak functions, and will be true for
> > any other "linker removed it" (which can happen for other reasons
> > too).
> >
> > So your "fix" seems to be hacking around a symptom.
>
> Yeah, that's why this was just a POC.
>
> >
> > And honestly, the kallsyms argument seems bogus too. The problem with
> > kallsyms is that it looks up the size the wrong way. Making up new
> > function names doesn't fix the problem, it - once again - just hacks
> > around the symptom of doing something wrong.
> >
> > Christ, kallsyms looking at nm output and going by "next symbol" was
> > always bogus, but I think that's how the old a.out format worked
> > originally.
> >
> > But "nm" literally takes a "-S" argument. We just don't use it.
> >
> > So I think the fix is literally to just make kallsysms have the size
> > data. Of course, very annoyingly out /proc/kallsyms file format also
> > tracks the (legacy) nm output that doesn't have size information.
> >
> > But I do think that if you hit real problems, you need to fix the
> > *source* of the issue, not add another ugly hack around things.
>
> So basically the real solution is to fix kallsyms to know about the end
> of functions. Peter Zijlstra mentioned that before, but it would take a
> bit more work and understanding of kallsyms to fix it properly.
>
> I'm fine not doing the hack and hopefully one day someone will have the
> time to fix kallsyms. This was just something I could do quickly,
> knowing it is mostly keeping with the status quo and not actually
> fixing the root of the issue. I also needed to refresh my ELF parsing
> abilities ;-)
>
> I may take a look at kallsyms internals. I have some spare time before
> the new year to try and work on things I don't normally get time to
> work on.
>
> -- Steve


So, does the kallsyms patch set from Zheng Yejian fix the issues?

It was a long time ago that I reviewed his v1.
I need to take a look if we decide to go with that approach.

-- 
Best Regards
Masahiro Yamada