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

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?

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

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?

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.

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?

Thanks!

Cheers,
Miguel