Message-ID: <2026012533-preflight-surviving-43e5@gregkh>
Date: Sun, 25 Jan 2026 16:34:46 +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 Sun, Jan 25, 2026 at 04:20:40PM +0100, Miguel Ojeda wrote:
> On Thu, Jan 22, 2026 at 7:35 AM Greg KH <gregkh@...uxfoundation.org> wrote:
> >
> > 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.
> >
> > If you know of a better way, that would be great!
> 
> Yes, if I understand correctly, then this should be done on the build
> system side (i.e. I don't see how BPF/tracing could achieve this, so
> maybe I am missing something), but what I meant is that there are
> several ways to do this in the build system side.

for a horrible hack of an example of how you can do this using
bpf/tracing, see this "fun" thing that I use every so often:
	https://github.com/gregkh/gregkh-linux/blob/master/scripts/trace_kernel_build.sh
it uses bpftrace to inject a script and then do a build and then
post-process the output.  Not something you should ever do on a "real"
build system :)

> One is this kind of post-processing after the build, which is easier
> in that it avoids touching Kbuild and can be written in something like
> Python, which always helps. The downside (my worry) is that it
> introduces yet another layer to Kbuild.

That's what is happening here, it's post-processing the build files to
detetct the dependancy graph it already knows about.

> My first instinct would have been to try to see if the build system
> itself could already give us what is built while it gets built (i.e.
> just like it outputs the `cmd` files). So I wondered if that was
> considered.

cmake can do this, that's what Zephyr uses, but we don't use cmake for
kernel builds.  I know the gnu toolchain developers have talked about
adding this to make/gcc/whatever in the past, and I thought Red Hat was
funding them to do that, but it seems to have never gone anywhere and
it's been years since I last heard from them.

> > Changing kbuild would be great too, if you know of a way we can get that
> > info out of it.
> 
> It depends on what is needed, but Kbuild of course knows about input
> and output files and dependencies, so I was thinking of outputting
> that information in an easier format instead of having to parse
> command lines from the `cmd` files.

"all" we need is the list of files that are used to make the resulting
kernel image and modules.  Given that the kernel build is
self-contained, and does not pull in anything from outside of its tree
(well, with the exception of some rust things I think), we should be ok.

And kbuild already encodes this information in the cmd files, for the
most part (there are corner cases and exceptions which the developers
here have gone through great lengths to track down and document in the
scripts.)  So 99% of the info is there already, which is why the cmd
files are used for parsing, no need to re-create that info in
yet-another-format, right?

> > 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?)
> 
> Even with `CONFIG_SBOM`, they will need to modify at least their
> kernel configuration, and perhaps more if they want to save the SBOM
> files differently, e.g. in another package etc. So I am not sure if it
> is a big difference for any distro than adding a word to their `make`
> line.

Let's stick with a config option for now please.  If the distros who
will need/want this decide to do it in a different way, they can send
patches :)

For now, this should be sufficient.

> Now, I understand it may be easier to tell users to "just turn one
> more config", and perhaps it looks more "integrated" to them, but I
> mainly asked because, to me, the SBOM is orthogonal to the kernel
> configuration.

It's a build-time output, just like debugging symbols are, and
documentation.  Ok, documentation is a separate build target, and "to
the side" of the source build, but you get the idea :)

> In other words, I would have expected to be able to get an SBOM for
> any build, without having to modify the kernel configuration at all.
> After all, the kernel image should not change at all whether there is
> an SBOM or not. We also do not do that for some other big "globally
> orthogonal" things that involve generating extra files, like
> documentation.

The SBOM is directly tied to the kernel configuration in that it needs
to know the config in order to determine exactly what files were used to
generate the resulting binaries.  That's what the SBOM is documenting,
not "all of the files in the tarball", but just "these are the files
that are required to build the binaries".  Which is a tiny subset of the
overall files in the tree, and is really, all that the target system
cares about.

thanks,

greg k-h

Powered by blists - more mailing lists