linux-kernel - Re: [PATCH v2 00/14] Add SPDX SBOM generation tool

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: <2026012214-magician-mashed-c84c@gregkh>
Date: Thu, 22 Jan 2026 07:35:42 +0100
From: Greg KH <gregkh@...uxfoundation.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Luis Augenstein <luis.augenstein@...tech.com>, nathan@...nel.org,
	nsc@...nel.org, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
	maximilian.huber@...tech.com
Subject: Re: [PATCH v2 00/14] Add SPDX SBOM generation tool

On Thu, Jan 22, 2026 at 07:18:18AM +0100, Miguel Ojeda wrote:
> On Wed, Jan 21, 2026 at 6:55 AM Luis Augenstein
> <luis.augenstein@...tech.com> wrote:
> >
> > The sbom tool is optional and runs only when CONFIG_SBOM is enabled. It
> > is invoked after the build, once all output artifacts have been
> > generated. Starting from the kernel image and modules as root nodes,
> > the tool reconstructs the dependency graph up to the original source
> > files. Build dependencies are primarily derived from the .cmd files
> > generated by Kbuild, which record the full command used to build
> > each output file.
> >
> > Currently, the tool only supports x86 and arm64 architectures.
> 
> I am out of the loop, and I don't know the requirements here, but what
> kind of approaches were considered for this?

Lots of different attempts, usually using bpf and other run-time tracing
tools.  But it was determined that we already have this info in our
build dependancy files, so parsing them was picked.

> Parsing the `.cmd`s seems a bit ad-hoc / after-the-fact approach, and
> from a very cursory look at the patches, it seems to require a fair
> amount of hardcoding, e.g. it seems we may need to list every
> generator tool in `SINGLE_COMMAND_PARSERS`?

If you know of a better way, that would be great!

> Now, if this is meant to be best-effort and cover the most important
> parts, it may be fine -- again, I don't know the requirements here.
> But if it is meant to accurately match everything, then it will
> require keeping those lists in sync with Kbuild, right?

It should match everything, and yes, it will require keeping things in
sync.

> Hmm... I feel like changing the build system itself (whether at the
> Kbuild level or even a customized Make itself if needed) to record
> this information would be conceptually simpler / more elegant, even if
> changing Kbuild itself can sometimes be quite a challenge.

Changing kbuild would be great too, if you know of a way we can get that
info out of it.

> In addition, why does this need to be a `CONFIG_` option? Should this
> be a separate tool or at most a target that supports whatever config
> happens to be, rather than part of the config itself?

It should be part of the kernel build process, and generated as part of
it as it will want to go into some packages directly.  Having to run the
build "again" is probably not a good idea (i.e. do you want to modify
all the distro rpm scripts?)

thanks,

greg k-h