Re: [PATCH v5 00/15] add SPDX SBOM generation script

[Luis Augenstein]

On 4/30/26 02:23, Nathan Chancellor wrote:
> On Fri, 10 Apr 2026 23:22:40 +0200, Luis <luis.augenstein@xxxxxxxxxxx> wrote:
> > This patch series introduces a Python-based script for generating SBOM
> > documents in the SPDX 3.0.1 format for kernel builds.
>
> I see the following error when building ARCH=arm64 virtconfig sbom:
>
>    | $ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux- CROSS_COMPILE_COMPAT=arm-linux-gnueabi- mrproper virtconfig sbom
>    | [ERROR] File "/src/scripts/sbom/sbom/cmd_graph/savedcmd_parser/savedcmd_parser.py", line 33, in log_error_or_warning
>    | Skipped parsing command arch/arm64/kernel/vdso32/../../../arm/vdso/vdsomunge arch/arm64/kernel/vdso32/vdso.so.raw arch/arm64/kernel/vdso32/vdso32.so.dbg because no matching parser was found
>    | ...
>    | make[3]: *** [/src/Makefile:2184: sbom] Error 1
>    | ...
>
> I would highly recommend running some randconfig builds with ARCH=arm64
> and ARCH=x86_64 if you have not already done so to ensure you have
> caught all corner cases. This one was understandably missed because GCC
> builds require a separate 32-bit cross compiler (specified with
> CROSS_COMPILE_COMPAT) to build this code. Testing with LLVM=1 would help
> with that since the build system handles cross compile automatically in
> that case.

So far, I have mainly tested with tinyconfig, defconfig, allmodconfig, 
and the configs from 
https://github.com/gregkh/gregkh-linux/tree/master/stable/configs.
Additionally, I have now tested some randconfig builds. Still, there 
will most likely be edge cases that we will only discover over time. 
However, while the tool is designed to exit with a non-zero status code 
when unknown commands are encountered, it still produces a valid SBOM 
based on the information it was able to collect. So, despite missing 
command parser errors like these, the tool remains usable.
There is also the --do-not-fail-on-unknown-build-command option to log 
missing command parser errors as warnings and exit with a zero status 
code. I have disabled this by default, though, to make people more 
likely to report any missing command parser issues they encounter.

> > modules as root nodes, the script 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 script only supports x86 and arm64 architectures.
>
> This does not appear to be codified anywhere? I can run the sbom target
> when targeting ARCH=arm for example, resulting in:
>
>    | [ERROR] File "/src/scripts/sbom/sbom/cmd_graph/savedcmd_parser/savedcmd_parser.py", line 33, in log_error_or_warning
>    | Skipped parsing command sh /src/arch/arm/tools/syscallnr.sh /src/arch/arm/tools/syscall.tbl arch/arm/include/generated/asm/unistd-nr.h because no matching parser was found
>    | [ERROR] File "/src/scripts/sbom/sbom/cmd_graph/savedcmd_parser/savedcmd_parser.py", line 33, in log_error_or_warning
>    | Skipped parsing command ./arch/arm/vdso/vdsomunge arch/arm/vdso/vdso.so.raw arch/arm/vdso/vdso.so.dbg because no matching parser was found
>    | [WARNING] Could not infer primary purpose for /src/arch/arm/tools/mach-types
>    | [WARNING] Could not infer primary purpose for /build/arch/arm/boot/compressed/piggy_data

Yes, this is not codified in the sense that the tool does not restrict 
execution to specific architectures.
Should it?
As stated above, the tool is designed to collect as much of the 
dependency graph as possible. For other architectures, it behaves the 
same way, i.e., a valid SBOM is produced, but the missing parser errors 
indicate that the SBOM is not complete. I think this behavior is more 
useful than denying execution for other architectures entirely, but we 
could change that if you think otherwise.

> Sashiko points out a number of things as well:
>
>    https://sashiko.dev/#/patchset/20260410212255.9883-1-luis.augenstein@xxxxxxxxxxx

Cool, thanks. I didn't know this exists.
I worked through the comments and will provide according changes in v6 
of the patch series soon.

Best,
Luis

--
Luis Augenstein * luis.augenstein@xxxxxxxxxxx * +4915225275761
TNG Technology Consulting GmbH, Beta-Str. 13, 85774 Unterföhring
Geschäftsführer: Henrik Klagges, Dr. Robert Dahlke, Thomas Endres
Aufsichtsratsvorsitzender: Moritz Prinz
Sitz: Unterföhring * Amtsgericht München * HRB 135082

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature