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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wii_nN1X4O9=nztJy3rexKp9w5Gsp=J5kZ43Hekja+Omg@mail.gmail.com>
Date: Thu, 26 Dec 2024 18:58:24 -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 18:19, Steven Rostedt <rostedt@...dmis.org> wrote:
>
> 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.

Yeah. The kallsyms code *used* to be pretty simple - really just a
list of symbols and addresses.

But it took up a lot of memory, so back in the day (two decades ago by
now) it started growing some name compression code, and then some
serious speedups for lookup.

See

    https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/?id=e10392112d315c45f054c22c862e3a7ae27d17d4

for when it went from basically a very simple array of names to be a
lot less obvious with that table lookup name compression (but it had
_some_ name compression even before that).

That said, I think it's really mainly just the name compression that
is a bit obscure and looks odd, and it's only used for the builtin
kernel symbols (module symbols are still just a per-module array of
"const Elf_Sym *").

And you can actually largely ignore the odd name compression - because
the *rest* is fairly straightforward.

For example, the actual offset of the symbol is simply a plain array
still: kallsyms_offsets[]. It's slightly oddly encoded (see
kallsyms_sym_address() if you care), but that's because it's an array
of 32-bit values used to encode kernel symbol offsets that can
obviously be 64-bit.

Encoding the size of the symbols should be trivial: just add another
array: "kallsyms_sizes[]", and it wouldn't even need that odd
encoding.

So I actually think it *should* be fairly straightforward to do for
anybnody who knows the kallsyms code at all.

The main pain-point would be *if* we want to actually expose the sizes
in /proc/kallsyms. That would be a file format change. Which we can't
do, so we'd have to do it as some kind of strange ioctl setting (or
just add a new file under a new name).

But maybe we don't even need that. If all the uses are in-kernel, just
adding the kallsyms_sizes[] (and accessor helper functions) should be
fairly straightforward.

Of course, I say that without having done it. I might be overlooking something.

           Linus