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

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] [day] [month] [year] [list]

Message-ID: <87wn0xn56i.fsf@esperi.org.uk>
Date:   Wed, 24 May 2023 16:02:29 +0100
From:   Nick Alcock <nick.alcock@...cle.com>
To:     Alexander Lobakin <aleksander.lobakin@...el.com>
Cc:     Nick Alcock <nick.alcock@...cle.com>,
        Steven Rostedt <rostedt@...dmis.org>, <mcgrof@...nel.org>,
        <masahiroy@...nel.org>, <linux-modules@...r.kernel.org>,
        <linux-trace-kernel@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <arnd@...db.de>,
        <akpm@...ux-foundation.org>, <eugene.loh@...cle.com>,
        <kris.van.hees@...cle.com>, <bpf@...r.kernel.org>,
        Jiri Olsa <jolsa@...hat.com>
Subject: Re: [PATCH modules-next v10 00/13] kallsyms: reliable
 symbol->address lookup with /proc/kallmodsyms

On 19 May 2023, Alexander Lobakin outgrape:
> `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.

My kallmodsyms patch does much the same, except to save space we
eliminate any leading path elements we can. Keeping those still
necessary to reduce redundancy, and eliminating the TU name entirely if
not necessary, saves several hundred KiB in my measurements and leads to
a total space hit for all of this of only about 12KiB. (Downside:
slightly less clear naming in /proc/kallmodsyms.)

-- 
NULL && (void)