Re: [PATCH modules-next v10 00/13] kallsyms: reliable symbol->address lookup with /proc/kallmodsyms

From: Alexander Lobakin <aleksander.lobakin@intel.com>
To: Nick Alcock <nick.alcock@oracle.com>
Cc: Steven Rostedt <rostedt@goodmis.org>, <mcgrof@kernel.org>,
	<masahiroy@kernel.org>, <linux-modules@vger.kernel.org>,
	<linux-trace-kernel@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <arnd@arndb.de>,
	<akpm@linux-foundation.org>, <eugene.loh@oracle.com>,
	<kris.van.hees@oracle.com>, <bpf@vger.kernel.org>,
	Jiri Olsa <jolsa@redhat.com>
Subject: Re: [PATCH modules-next v10 00/13] kallsyms: reliable symbol->address lookup with /proc/kallmodsyms
Date: Fri, 19 May 2023 17:50:35 +0200	[thread overview]
Message-ID: <e6662717-61a1-3e3d-5804-66629a1691e2@intel.com> (raw)
In-Reply-To: <20230508180653.4791819e@rorschach.local.home>

From: Steven Rostedt <rostedt@goodmis.org>
Date: Mon, 8 May 2023 18:06:53 -0400

> This topic came up at LSFMM, presented by Jiri.
> 
> I'm Cc'ing this email to the BPF mailing list.
> 
> -- Steve
> 
> 
> On Mon,  5 Dec 2022 16:31:44 +0000
> Nick Alcock <nick.alcock@oracle.com> wrote:
> 
>> The kallmodsyms patch series was originally posted in Nov 2019, and the thread
>> (https://lore.kernel.org/linux-kbuild/20191114223036.9359-1-eugene.loh@oracle.com/t/#u)
>> shows review comments, questions, and feedback from interested parties.
>> Most recent posting: <https://lore.kernel.org/linux-modules/20221109134132.9052-1-nick.alcock@oracle.com/T/#t>.
>>
>> All review comments have been satisfied, as far as I know: in particular
>> Yamada's note about translation units that are shared between built-in
>> modules is satisfied with a better representation which is also much, much
>> smaller, and we are no longer using modules_thick.builtin but Luis's new
>> modules.builtin.objs.
>>
>> A kernel tree containing this series alone:
>>    https://github.com/oracle/dtrace-linux-kernel kallmodsyms/6.1-rc4-modules-next
>>
>>
>> The whole point of symbols is that their names are unique: you can look up a
>> symbol and get back a unique address, and vice versa.  Alas, because
>> /proc/kallsyms (rightly) reports all symbols, even hidden ones, it does not
>> really satisfy this requirement.  Large numbers of symbols are duplicated
>> many times (just search for __list_del_entry!), and while usually these are
>> just out-of-lined things defined in header files and thus all have the same
>> implementation, it does make it needlessly hard to figure out which one is
>> which in stack dumps, when tracing, and such things.  Some configuration
>> options make things much worse: my test make allyesconfig runs introduced
>> thousands of text symbols named _sub_I_65535_1, one per compiler-generated
>> object file, and it was fairly easy to make them appear in ftrace output.

FYI for devs: I posted RFC of kallsyms with file paths almost a year
ago[0], but it went unnoticed =\

`file name + function name` is not a unique pair: in one of FG-KASLR
discussions, someone even wrote simple script, which showed around 40
collisions in the kernel. My approach was to include file path starting
at the kernel root folder, i.e. `net/core/dev.o:register_netdev`.
I'm not sure why no comments happened back then tho. Maybe you could
take a look, I'm pretty busy with other projects, but if you find
anything useful there in the RFC, I could join to a little bit.

[0]
https://lore.kernel.org/all/20220818115306.1109642-1-alexandr.lobakin@intel.com

Thanks,
Olek