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] [day] [month] [year] [list]

Message-ID: <a01233b9-23a2-4666-91ed-f1cf030dcb9f@tngtech.com>
Date: Tue, 27 Jan 2026 09:03:53 +0100
From: Luis Augenstein <luis.augenstein@...tech.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
 Greg KH <gregkh@...uxfoundation.org>
Cc: 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

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

Thanks for this suggestion.
I explored this approach in v3 where I removed the CONFIG_SBOM option
and instead introduced the `make sbom` target to invoke the sbom tool.
This way the default `all` target is not changed at all. The `sbom`
target depends on `all` such that `make sbom` can be used to build the
kernel if not present and generate the SBOM afterwards. The environment
variables picked up by the SBOM remain the same as in v2. I like that
this solves the need to find a good place for a CONFIG_SBOM option since
the previous location in lib/Kconfig.debug was not optimal.
Let me know what you think.

> 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.
> [...]
> 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?

I agree that it would likely be a cleaner solution if the `.cmd` files
directly contained all dependencies. Ideally, the SBOM tool would only
need to consume dependency information from the existing `.cmd` files,
without parsing build commands or collecting additional dependencies
that are not tracked by the `.cmd` mechanism.

However, as mentioned previously, adapting the `.cmd` file generation
was considered out of scope for this project. Early on, we decided to
focus on an isolated tool that works with the information currently
available to keep the scope manageable. Improving dependency coverage at
the Kbuild level would certainly be a worthwhile follow-up, but it was
not something we could realistically address within this effort.

Best,
Luis

-- 
Luis Augenstein * luis.augenstein@...tech.com * +49-152-25275761
TNG Technology Consulting GmbH, Beta-Str. 13, 85774 Unterföhring
Geschäftsführer: Henrik Klagges, Dr. Robert Dahlke, Thomas Endres
Aufsichtsratsvorsitzender: Christoph Stock
Sitz: Unterföhring * Amtsgericht München * HRB 135082

Download attachment "OpenPGP_0x795C8ACACDDCFB34.asc" of type "application/pgp-keys" (3156 bytes)

Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (841 bytes)