LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: Kees Cook <keescook@chromium.org>
Cc: jeyu@kernel.org, masahiroy@kernel.org,
	linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org,
	arnd@arndb.de, eugene.loh@oracle.com, kris.van.hees@oracle.com
Subject: Re: [PATCH v5] kallsyms: new /proc/kallmodsyms with builtin modules
Date: Thu, 30 Sep 2021 18:19:55 +0100	[thread overview]
Message-ID: <875yui0ymc.fsf@esperi.org.uk> (raw)
In-Reply-To: <202109291629.81106C83D@keescook> (Kees Cook's message of "Wed, 29 Sep 2021 16:34:39 -0700")

On 30 Sep 2021, Kees Cook said:

> On Wed, Sep 29, 2021 at 10:51:47PM +0100, Nick Alcock wrote:
>> It would be useful if there were a mapping between kernel symbol and module
>> name that only changed when the kernel source code is changed.  This mapping
>> should not change simply because a module becomes built into the kernel.
>> 
>> It might also be useful if there were reliable symbol size information to
>> determine whether an address is within a symbol or outside it, especially
>> given that there could be huge gaps between symbols.
>
> This is a pretty cool series, but I'm left wondering "for what reason?" :)
> Perhaps I missed the specific rationale; there was a lot to run. ;)

The underlying rationale that the earliest, crude version of this patch
was written for is that DTrace allows symbol and type names to be
module-qualified (e.g. hid`names) and we don't want people's scripts to
break just because they recompile the kernel to make things a module
versus not. But this problem is not DTrace-specific: given that names
are not unique across the kernel when things are built as modules, many
tracing tools that introspect the values of kernel symbols etc might
want to let users qualify names with the modules they apply to, and more
or less none of those are going to want a script that asks for "foo in
the bar module" to suddenly become invalid because the user changed
CONFIG_FOO=m to CONFIG_FOO=y.

Obviously, if they change it to CONFIG_FOO=n, any script that uses names
from FOO is going to break: there's nothing we can do about that. But
not breaking the m/y case seems like a simple quality-of- implementation
issue to make it easier to redistribute scripts to anyone using FOO no
matter what their module/non-module configuration, and a nice easy one
to fix, if only we could easily tell what the module/symbol mapping was.
And with this patch we can (at minimal cost).

(I have also found it to be useful for by-hand stuff, when I can't
remember where the heck some symbol with a non-qualified name is,
usually a file-scope variable: it's faster to grep kallmodsyms than to
do a tags lookup, let alone a grep, if I'm debugging something I know is
loaded into the kernel right now. Which often one is if one is
reproducing the bug... and often the module a symbol is part of is
informative. This is, obviously, crude, but it's still more useful to
have more module names there than fewer if one is doing this sort of
thing.)


(As an aside, this is not all a tracing system needs to do to get this
sort of thing right, particularly where types are concerned: it's still
possible to have conflicting type names across translation units within
a single module. CTF deals with that case perfectly well via child CTF
dicts, and GNU ld splits ambiguously-defined types out so that the user
can say "foo_t in the bar module in wombat.c" in the rare cases where
ambiguity exists.)

> It would be useful, sure, but is there something that does, in fact,
> need this, or would like this if it were available? Since this provides
> a userspace API, what would be consuming that API? For example, when
> Syscall User Dispatch was added, it was clear it was for Wine[1].

We have a long-term consumer in DTrace (e.g.
<https://github.com/oracle/dtrace-utils/blob/dev/libdtrace/dt_module.c#L1323>).
(But since we control this consumer we are quite happy to change the
format of kallmodsyms, integrate it with kallsyms so that kallsyms just
provides the same information if the file format break were acceptable,
or whatever you think most sensible. We just want this information
somehow. :) e.g. the code there doesn't yet handle the
symbol-in-multiple-modules case: I'll have to add that.)

But this feels useful enough to me that I'm hoping that more consumers
will grow.  I'm sure SystemTap would find it useful, and I'm hoping
bpftrace etc might as well once that starts to handle modules. They're
all going to need some sort of namespace-qualification and then they're
all going to run into the same script-stability problem as soon as users
try to share scripts at all. We can make that problem largely go away :)

-- 
NULL && (void)

  reply	other threads:[~2021-09-30 17:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-29 21:51 Nick Alcock
2021-09-29 21:51 ` [PATCH v5 1/7] kbuild: bring back tristate.conf Nick Alcock
2021-09-29 21:51 ` [PATCH v5 2/7] kbuild: add modules_thick.builtin Nick Alcock
2021-09-29 21:51 ` [PATCH v5 3/7] kbuild: generate an address ranges map at vmlinux link time Nick Alcock
2021-09-29 21:51 ` [PATCH v5 4/7] kallsyms: introduce sections needed to map symbols to built-in modules Nick Alcock
2021-09-29 21:51 ` [PATCH v5 5/7] kallsyms: optimize .kallsyms_modules* Nick Alcock
2021-09-29 21:51 ` [PATCH v5 6/7] kallsyms: add /proc/kallmodsyms Nick Alcock
2021-09-29 21:51 ` [PATCH v5 7/7] kallsyms: add reliable symbol size info Nick Alcock
2021-09-29 23:34 ` [PATCH v5] kallsyms: new /proc/kallmodsyms with builtin modules Kees Cook
2021-09-30 17:19   ` Nick Alcock [this message]
2021-09-30 17:53     ` Kees Cook
2021-10-27 17:46 ` [PING PATCH " Nick Alcock
2021-10-27 17:47   ` [PATCH v5 1/7] kbuild: bring back tristate.conf Nick Alcock
2021-10-27 17:47   ` [PATCH v5 2/7] kbuild: add modules_thick.builtin Nick Alcock
2021-10-27 17:47   ` [PATCH v5 3/7] kbuild: generate an address ranges map at vmlinux link time Nick Alcock
2021-10-30 16:49     ` kernel test robot
2021-10-27 17:47   ` [PATCH v5 4/7] kallsyms: introduce sections needed to map symbols to built-in modules Nick Alcock
2021-10-27 17:47   ` [PATCH v5 5/7] kallsyms: optimize .kallsyms_modules* Nick Alcock
2021-10-27 17:47   ` [PATCH v5 6/7] kallsyms: add /proc/kallmodsyms Nick Alcock
2021-10-28 11:36     ` kernel test robot
2021-10-28 21:52       ` Nick Alcock
2021-10-27 17:47   ` [PATCH v5 7/7] kallsyms: add reliable symbol size info Nick Alcock

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=875yui0ymc.fsf@esperi.org.uk \
    --to=nick.alcock@oracle.com \
    --cc=arnd@arndb.de \
    --cc=eugene.loh@oracle.com \
    --cc=jeyu@kernel.org \
    --cc=keescook@chromium.org \
    --cc=kris.van.hees@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=masahiroy@kernel.org \
    --subject='Re: [PATCH v5] kallsyms: new /proc/kallmodsyms with builtin modules' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).