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: <CANiq72mcDqAS-FUfkAnxa7OEO4Kq6r6=uvhEb_UW4sGattCOuQ@mail.gmail.com>
Date: Sun, 25 Jan 2026 16:20:40 +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 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.

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.

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.

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

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

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.

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.

I hope that helps somehow...

Cheers,
Miguel