lkml.org 
[lkml]   [2023]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH modules-next v10 00/13] kallsyms: reliable symbol->address lookup with /proc/kallmodsyms
From
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

\
 
 \ /
  Last update: 2023-05-19 17:52    [W:0.353 / U:0.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site