linux-kernel - Re: [PING PATCH v7] kallsyms: new /proc/kallmodsyms with builtin modules

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

Message-ID: <878rvk7uv2.fsf@esperi.org.uk>
Date:   Wed, 12 Jan 2022 16:59:45 +0000
From:   Nick Alcock <nick.alcock@...cle.com>
To:     Luis Chamberlain <mcgrof@...nel.org>
Cc:     jeyu@...nel.org, masahiroy@...nel.org,
        linux-modules@...r.kernel.org, linux-kernel@...r.kernel.org,
        arnd@...db.de, akpm@...ux-foundation.org, eugene.loh@...cle.com,
        kris.van.hees@...cle.com
Subject: Re: [PING PATCH v7] kallsyms: new /proc/kallmodsyms with builtin
 modules

On 12 Jan 2022, Luis Chamberlain stated:

> On Thu, Dec 16, 2021 at 08:19:12PM +0000, Nick Alcock wrote:
>> /proc/kallsyms is very useful for tracers and other tools that need to
>> map kernel symbols to addresses.
>> 
>> It would be useful
>
> It took me digging on archives to see to *who* this is useful to.
> The short answer seeme to be dtrace. Can you work on getting use
> of this for something (I don't know, maybe kernelshark?) that does
> not taint the kernel? Last I checked using dtrace on linux taints the
> kernel.

It hasn't tainted the kernel for at least four years :) v1 (with a
kernel module) has been GPLv2 since 2017; v2 is pure-BPF and has no
DTrace-specific kernel modules, just using some new things we have to
add to the kernel, most of which seem plausibly useful to others too
(kallmodsyms, waitfd pro tem until pidfd supports ptracers, and CTF).

This is not a DTrace-specific feature in any case: all my submissions
have noted that it seems likely to be useful to anyone who wants a
stable reference to modules that doesn't change whenever the kernel
config changes, which probably means most tracers with support for
kernel modules which implement anything like a programming language.

> Without valid upstream users I see no need to add more complexity to the
> kernel. And complexity added by tainting modules or not upstream modules

We don't need any of those any more :) Even CTF is now generated by GCC
(once GCC 12 is released) and deduplicated by GNU ld: the CTF patch will
be only a few hundred lines long once GCC 12 is out and I drop the
DWARF->CTF translator.

> Without a valid non-taining user being made very clear with a value-add,
> I will have to ignore this.

I hope this gives you a reason to not ignore it! Have some links:

DTrace v1 (maintenance mode, fairly hefty GPL kernel module, UPL
userspace; fully-functional including fbt, kernel side will shrink):

  https://github.com/oracle/dtrace-linux-kernel v1/5.15
  https://github.com/oracle/dtrace-utils 1.x-branch-dev

DTrace v2 based on BPF, in progress, some features still missing (UPL
userspace and a few GPL kernel patches, including this one: needs a BPF
cross-compiler, which is a new GCC 12 target):

  https://github.com/oracle/dtrace-linux-kernel v2/5.14.9
  https://github.com/oracle/dtrace-utils 2.0-branch

(I'm going to respin all of these kernel branches against 5.17-rc once
the merge window closes, and bring the things both kernel trees have in
common into sync. I'll drop you a line once that's done.)

Config-wise both of these need kernels with CONFIG_KALLMODSYMS,
CONFIG_WAITFD and CONFIG_CTF turned on, and a kernel built with a 'make
ctf' done after 'make', and the kernel source tree available when DTrace
proper is built.

-- 
NULL && (void)