Message-ID: <CANiq72=_tPP4cPaUMPiM14h1kk97EXSf5vg-yHHYo-Px+31ZSg@mail.gmail.com>
Date: Sun, 25 Jan 2026 18:24:51 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Greg KH <gregkh@...uxfoundation.org>
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 4:34 PM Greg KH <gregkh@...uxfoundation.org> wrote:
>
> 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 :)

Oof... So you really meant tracing the builder. :)

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

Yeah, I am aware -- I mentioned both sides to explain the upsides and
my worry about hardcoding all this stuff out of band.

> 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.

Well, Make can ""do"" things like that, in the sense that we can
program it, which is essentially what Kbuild does -- it "hacks" the
usual Make graph to do extra stuff on top.

i.e. Kbuild and friends are the ones writing the `.cmd` files and
running custom filtering and so on, not Make, and just like we abuse
Make to do that, in principle we could encode and output more
information (if that would help).

To be clear, I am not sure exactly what information it is needed --
when I was Cc'd for the Rust bit, I noticed it was parsing the command
line to try to guess more deps (?), which seemed odd and I wondered
whether we could provide that (even if it requires additions) so that
we don't need to parse those.

> 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.)

By "corner cases and exceptions", I assume you mean the hardcoded ones
(not the command line parsing), which I hadn't noticed yet.

Those aren't really documented from what I can see? It is just the
list of cases, which we will also have to maintain.

I also see the `.incbin` now, which is even more hardcoding, but I see
Makefiles explicitly adding the dependency on their side, which is
closer to what I am saying: that it would be better to add the
dependencies (or whatever information is needed) in the build system
side.

In other words, we could make those generate a `.cmd` file or similar,
rather than hardcode it on the script.

I guess my question to Luis et al. is: for things like `.incbin` and
the hardcoded dependencies, is there a reason to avoid declaring any
missing dependencies or to generate the `.cmd` files to begin with?

The patches say, for instance:

    Some files in the kernel build process are not tracked by the .cmd
dependency mechanism.
    Parsing these dependencies programmatically is too complex for the
scope of this project.
    Therefore, this function provides manually defined dependencies to
be added to the build graph.

And my point is precisely that we should not be parsing Makefiles, but
neither command lines, if at all possible. Instead, if there are
missing dependencies, we should fix them; and if there are missing
`.cmd`s (i.e. dependency information not saved) you need, we could add
those, and so on.

> 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?

Yeah, the extra information may be just in `deps_` in the `.cmd`, or
it could be an extra variable there or whatever is needed, i.e. no
need for a new format.

i.e. what I was trying to avoid was the out-of-band hardcoding as much
as possible.

> 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 :)

In case it wasn't clear: for the config bit, it wouldn't be a big
change -- it would just require removing ~10 lines unless I am missing
something.

But if this was already discussed with users or you think it will be
easier etc., then fine, I won't press. :)

> 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 :)

Just in case: debugging symbols are different -- they change the
actual build (e.g. flags), and even the actual image (unless requested
to be separate). So those make sense as a config option.

(We also have other targets that work like docs, i.e. it is not just
docs. But fine... :)

> 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.

To clarify, I didn't suggest we document the files in the tarball, nor
that the kernel config doesn't influence the SBOM contents.

What I am saying is that whether an SBOM is generated or not is
orthogonal to the kernel configuration, and as a user I would have
expected to be able to obtain one in my build without having to change
any configuration.

I hope that helps.

Cheers,
Miguel

Powered by blists - more mailing lists