From: Nick Alcock <nick.alcock@oracle.com>
To: Alexander Lobakin <aleksander.lobakin@intel.com>
Cc: Nick Alcock <nick.alcock@oracle.com>,
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: Wed, 24 May 2023 16:02:29 +0100 [thread overview]
Message-ID: <87wn0xn56i.fsf@esperi.org.uk> (raw)
In-Reply-To: <e6662717-61a1-3e3d-5804-66629a1691e2@intel.com> (Alexander Lobakin's message of "Fri, 19 May 2023 17:50:35 +0200")
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)
prev parent reply other threads:[~2023-05-24 15:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20221205163157.269335-1-nick.alcock@oracle.com>
2023-05-08 22:06 ` [PATCH modules-next v10 00/13] kallsyms: reliable symbol->address lookup with /proc/kallmodsyms Steven Rostedt
2023-05-19 15:50 ` Alexander Lobakin
2023-05-22 23:21 ` Luis Chamberlain
2023-05-24 15:02 ` Nick Alcock [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wn0xn56i.fsf@esperi.org.uk \
--to=nick.alcock@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=aleksander.lobakin@intel.com \
--cc=arnd@arndb.de \
--cc=bpf@vger.kernel.org \
--cc=eugene.loh@oracle.com \
--cc=jolsa@redhat.com \
--cc=kris.van.hees@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=mcgrof@kernel.org \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox