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: <20260203004032.GA52989@ax162>
Date: Mon, 2 Feb 2026 17:40:32 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Luis Augenstein <luis.augenstein@...tech.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>,
	Greg KH <gregkh@...uxfoundation.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

Hi Luis,

On Mon, Feb 02, 2026 at 05:28:39PM +0100, Luis Augenstein wrote:
> > I wonder if it would be better for this to live within scripts/ instead
> > of tools/, as that should allow it to be integrated into the build
> > process a little bit more naturally, such as using $(Q) instead of @,
> > $(PYTHON3) instead of the bare python3, being able to access
> > CONFIG_MODULES directly, and cleaning up the actual implementation of
> > the sbom target in Makefile.
> 
> Thanks, I wasn’t aware that targets under scripts/ have access to more
> Make variables by default. During development, we didn’t have strong

I think this is a byproduct of being fully within Kbuild at that point,
rather than in the tools/ build system.

> reasons for choosing either tools/ or scripts/. I’m happy to move it to
> scripts/ if that is the preferred location.

Yes please. If this tool is designed to run within and parse Kbuild, it
should live fully within Kbuild, as the "tools build system" comment in
Makefile added by Masahiro in commit 6e6ef2da3a28 ("Makefile: add
comment to discourage tools/* addition for kernel builds") notes (even
though this is not a C program so the hostprogs comment is irrelevant
here). scripts/sbom seems entirely reasonable to me.

> Regarding $(Q) and $(PYTHON3), I noticed that these variables are
> actually available within the tools/ directory as well, so we could
> switch to using them even if we stay under tools/.

Ah, good to know. I do not delve into the tools build system all too
much.

> CONFIG_MODULES and src_tree, on the other hand, need to be passed
> explicitly when staying in tools/, whereas they would be available by
> default under scripts/ in which case we could simply invoke the script via:
> ```Makefile
> PHONY += sbom
> sbom: all
> 	$(Q)$(MAKE) $(build)=scripts/sbom
> ```
> 
> So yes, I think it makes sense to move it to scripts then.

Yeah, that looks much cleaner to me. I suspect scripts/sbom/Makefile
could be cleaned up a little bit as a result of that move as well.

Also, two other comments I forgot to bring up:

1. With the movement out of tools/, I think the README should become a
   proper Documentation file so that its contents is more discoverable.
   That should probably be separate from the change that adds the
   initial SBOM scaffolding in Kbuild to help with review.

2. This depends on having a clean initial build tree (either empty
   directory or 'clean' as a make target) due to needing to parse the
   .cmd files, which could be stale if someone builds a kernel, changes
   their config, and rebuilds, right? This should be documented since I
   do not think it is possible to do something like what Masahiro did in
   commit 3d32285fa995 ("kbuild: wire up the build rule of
   compile_commands.json to Makefile") because of the drawback that it
   misses too many things.

Cheers,
Nathan