Re: [PATCH 02/15] scripts/sbom: integrate script in make process

[Nathan Chancellor <nathan@kernel.org>]

On Tue, Mar 31, 2026 at 07:15:35AM +0200, Greg KH wrote:
> On Mon, Mar 30, 2026 at 10:32:00PM +0200, Luis Augenstein wrote:
> > Hi Nathan,
> > 
> > thanks a lot for your recommendations.
> > 
> > > Does sbom-roots.txt need to be cleaned up as well?
> > 
> > This file is only required to pass the roots into the python script.
> > We could also use a tmp file. Then we don't need to worry about clean
> > up. Together with your other suggested changes something like this
> > should work:
> > 
> > # Script to generate .spdx.json SBOM documents describing the build
> > #
> > ---------------------------------------------------------------------------
> > 
> > ifdef building_out_of_srctree
> > sbom_targets := sbom-source.spdx.json
> > endif
> > sbom_targets += sbom-build.spdx.json sbom-output.spdx.json
> > quiet_cmd_sbom = GEN     $(notdir $(sbom_targets))
> >       cmd_sbom = roots_file=$$(mktemp); \

I think I would rather have a named file in objtree instead of one in
/tmp, as we want all output to remain in the build folder.

> >                  printf "%s\n" "$(KBUILD_IMAGE)" >"$$roots_file"; \
> >                  $(if $(CONFIG_MODULES),sed 's/\.o$$/.ko/'
> > $(objtree)/modules.order >> "$$roots_file";) \
> >                  $(PYTHON3) $(srctree)/scripts/sbom/sbom.py \
> >                      --src-tree $(abspath $(srctree)) \
> >                      --obj-tree $(abspath $(objtree)) \
> >                      --roots-file "$$roots_file" \
> >                      --output-directory $(abspath $(objtree)) \
> >                      --generate-spdx \
> >                      --package-license "GPL-2.0 WITH Linux-syscall-note" \
> >                      --package-version "$(KERNELVERSION)" \
> >                      --write-output-on-error;
> >                  rm -f "$$roots_file"

The cmd macro uses 'set -e', so consider moving this up and making it

    trap  "rm -rf $$roots_file" EXIT; \

like try-run in scripts/Makefile.compiler does to ensure it is always
cleaned up.

> > PHONY += sbom
> > sbom: $(notdir $(KBUILD_IMAGE)) include/generated/autoconf.h $(if
> > $(CONFIG_MODULES),modules modules.order)
> > 	$(call cmd,sbom)
> > 
> > Note, I will also add the --write-output-on-error flag by default such
> > that the .spdx.json documents are generated as much as possible even if
> > some build commands are unknown to the parser.

Seems reasonable to me.

> > > FWIW, I get errors like
> > >
> > >   $ make -kj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux- O=build
> > mrproper defconfig sbom
> > >   ...
> > >     GEN     sbom-source.spdx.json sbom-build.spdx.json
> > sbom-output.spdx.json
> > >   [ERROR] File "/src/scripts/sbom/sbom/cmd_graph/savedcmd_parser.py",
> > line 630, in log_error_or_warning
> > >   Skipped parsing command ccache aarch64-linux-gcc ... -o init/main.o
> > /src/init/main.c because no matching parser was found
> > >   [ERROR] File "/src/scripts/sbom/sbom/cmd_graph/savedcmd_parser.py",
> > line 630, in log_error_or_warning
> > >   Skipped parsing command ccache aarch64-linux-gcc ... -o
> > arch/arm64/kernel/asm-offsets.s /src/arch/arm64/kernel/asm-offsets.c
> > because no matching parser was found
> > >   [ERROR] File "/src/scripts/sbom/sbom/cmd_graph/savedcmd_parser.py",
> > line 630, in log_error_or_warning
> > >   Skipped parsing command ccache aarch64-linux-gcc ... -o
> > kernel/bounds.s /src/kernel/bounds.c because no matching parser was found
> > >   ... (Found 10435 more instances of this error)
> > >
> > > when testing the whole series without any modifications, am I doing
> > > something wrong?
> > 
> > I was not aware of ccache. If you rebuild without using ccache the gcc
> > commands should be parsed correctly.
> > 
> > The parser expects gcc commands to be of the form
> > 	"^([^\s]+-)?(gcc|clang)\b"
> > When using tools like ccache this breaks. I will update the parser to
> > look for
> > 	"^(ccache\s+)?([^\s]+-)?(gcc|clang)\b"
> > instead.
> > 
> > Feedback like this is very helpful—thanks! Do you know of any other
> > commonly used tools that modify build commands in a similar way and
> > should be considered?
> 
> Ick, this might get messy as you can modify the compiler with the CC=
> option to be anything.  There are other build tools out there that do
> much the same as ccache does (which I should have caught this as I use
> ccache on my build systems), like distcc and friends, so this might just
> want to look at the result of "CC" instead?

Yeah, it would be much more robust to just look at $(CC) directly if it
is set (i.e., running within Kbuild) vs. having a separate parser like
this. If you want to keep a fallback for standalone usage for
development and such, that's fine, but we should use the information we
have available to be as accurate as possible.

Cheers,
Nathan