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: <ZsjBfjAuC5t/2Cex@oracle.com>
Date: Fri, 23 Aug 2024 13:06:06 -0400
From: Kris Van Hees <kris.van.hees@...cle.com>
To: Sami Tolvanen <samitolvanen@...gle.com>
Cc: Kris Van Hees <kris.van.hees@...cle.com>, 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 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?

Thanksm,
Kris