linux-kernel - Re: [PATCH v8 2/4] kbuild: generate offset range data for 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: <CABCJKucamgTpEhU5E=dL3tNc84yzwzFh7uNW-arhN-qDm-3nMw@mail.gmail.com>
Date: Fri, 23 Aug 2024 10:23:46 -0700
From: Sami Tolvanen <samitolvanen@...gle.com>
To: Kris Van Hees <kris.van.hees@...cle.com>, Miguel Ojeda <ojeda@...nel.org>
Cc: linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org, 
	linux-modules@...r.kernel.org, linux-trace-kernel@...r.kernel.org, 
	Nick Alcock <nick.alcock@...cle.com>, Alan Maguire <alan.maguire@...cle.com>, 
	Steven Rostedt <rostedt@...dmis.org>, Masahiro Yamada <masahiroy@...nel.org>, 
	Luis Chamberlain <mcgrof@...nel.org>, Masami Hiramatsu <mhiramat@...nel.org>, 
	Nick Desaulniers <ndesaulniers@...gle.com>, Jiri Olsa <olsajiri@...il.com>, 
	Elena Zannoni <elena.zannoni@...cle.com>
Subject: Re: [PATCH v8 2/4] kbuild: generate offset range data for builtin modules

On Fri, Aug 23, 2024 at 10:06 AM Kris Van Hees <kris.van.hees@...cle.com> wrote:
>
> On Fri, Aug 23, 2024 at 04:53:29PM +0000, Sami Tolvanen wrote:
> > Hi Kris,
> >
> > On Thu, Aug 22, 2024 at 02:19:39PM -0400, Kris Van Hees wrote:
> > > diff --git a/scripts/generate_builtin_ranges.awk b/scripts/generate_builtin_ranges.awk
> > > new file mode 100755
> > > index 000000000000..68df05fd3036
> > > --- /dev/null
> > > +++ b/scripts/generate_builtin_ranges.awk
> > > @@ -0,0 +1,505 @@
> > > +#!/usr/bin/gawk -f
> > > +# SPDX-License-Identifier: GPL-2.0
> > > +# generate_builtin_ranges.awk: Generate address range data for builtin modules
> > > +# Written by Kris Van Hees <kris.van.hees@...cle.com>
> > > +#
> > > +# Usage: generate_builtin_ranges.awk modules.builtin vmlinux.map \
> > > +#          vmlinux.o.map > modules.builtin.ranges
> > > +#
> > > +
> > > +# Return the module name(s) (if any) associated with the given object.
> > > +#
> > > +# If we have seen this object before, return information from the cache.
> > > +# Otherwise, retrieve it from the corresponding .cmd file.
> > > +#
> > > +function get_module_info(fn, mod, obj, s) {
> > > +   if (fn in omod)
> > > +           return omod[fn];
> > > +
> > > +   if (match(fn, /\/[^/]+$/) == 0)
> > > +           return "";
> > > +
> > > +   obj = fn;
> > > +   mod = "";
> > > +   fn = substr(fn, 1, RSTART) "." substr(fn, RSTART + 1) ".cmd";
> > > +   if (getline s <fn == 1) {
> > > +           if (match(s, /DKBUILD_MODFILE=['"]+[^'"]+/) > 0) {
> > > +                   mod = substr(s, RSTART + 16, RLENGTH - 16);
> > > +                   gsub(/['"]/, "", mod);
> > > +           }
> > > +   }
> >
> > This doesn't work with built-in Rust modules because there's no
> > -DKBUILD_MODFILE flag passed to the compiler. The .cmd files do have
> > RUST_MODFILE set though, so presumably you could match that too?
>
> Thanks for looking at the patch series.  I'll look into this.
>
> Is there a reason why Rust modules are using RUST_MODFILE rather than also
> using KBUILD_MODFILE as the macro to pass information about what module(s)
> the object belongs to?

I assume they wanted to avoid conflicts between Rust-specific
environment variables and existing Kbuild variables. Note that
KBUILD_MODFILE is also double quoted for the C preprocessor, which
isn't needed for Rust. Miguel, do you remember if there's another
reason for the different variable name?

Sami