Software Bill of Materials

[Richard Hughes]

Hi all,

A Software Bill of Materials (aka SBoM) is something you’ve all
probably heard of. In May last year the US president issued an
executive order titled Improving the Nation’s Cybersecurity[1] in
which it outlines the way that critical software used by various
branches of the government should be more traceable and secure. One of
the key pieces of information captured in a SBoM is “who built what
from where”. This concept breaks down for firmware, where lots of
different entities build each subsection in different ways, usually
due to commercial and technical constraints.

I've been thinking this about the SBoM problem from a firmware point
of view, but in a "BMC image" it's often lumped together as one thing,
but in reality a single BMC image might contain a BSP/FSP, microcode
blob, an EC, a root filesystem and a lot more. Even something as
seemingly-monolithic as a USB controller might contain a HAL from the
silicon vendor, an ISV-supplied bootloader and an ODM-provided runtime
firmware all built together.

I’ve been spending the last few months putting all the pieces together
to make a firmware SBoM not just possible, but super easy for ISVs,
OEMs, ODMs and IBVs to generate. This is so that vendors can make some
plans on how to be in compliance with any future requirement from the
US government, rather than reacting reactively. I was asked today if
I'd considered "the BMC blob" and the answer until just now was "no"
-- apologies if I'm coming across like a 800-pound gorilla but I
figured I'd get some discussion started.

For UEFI firmware, one of the problems is how to embed the software ID
(also known as SWID) metadata into each EFI binary. This is solved by
putting coSWID metadata (a DTMF specification[2]) into a new COFF
section called “SBOM”. This allows us to automatically capture at
build time some data, for instance the tree hash, and the files that
were used to build the binary, etc. This isn't so relevant for BCMs,
although some things like file hashes and tree hashes for the rootfs
probably are. The uSWID readme[3] explains how to do this manually.

The second problem is how to include SWID metadata for the blobs we
either don’t build, or we can’t modify in any way, e.g. the BSP/FSP or
microcode. For this there’s an “external” version of the same coSWID
metadata which has a simple header we can find in the firmware image.
This can either be included in the blob header, or just included as a
file alongside the binary deliverable. The vendor can either use the
[pip install] uswid command line (more examples in the uSWID readme)
or more helpfully there’s also a web-generator[4] on the LVFS that can
spit out the tiny coSWID blob with the correct header ready to be
included anywhere in the binary image.

Open source firmware like coreboot is also in the same boat of course,
but here we have more flexibility in how to generate and include the
SWID metadata in the image. Some vendors are planning to work on this
really soon, so we can have feature parity for free firmware like
coreboot – even when non-free blobs are included into the image so
that it can actually work on real hardware. For firmware like NVME
drives, NAS adaptors and the like the uSWID+coSWID blob can be
included anywhere in the image – even in the
0xFF,0xFF,0xFF,0xFF,0xFF,0xFF “spare” space left at the end of the
update image.

This means the firmware blob will soon have the metadata from the IBV,
ODM and OEM all sprinkled around the update binary. The LVFS now
decompresses all the shards of the firmware, and does all the usual
checks. At this point we also look for coSWID metadata in the EFI
binaries and also uSWID+coSWID metadata for the non-free microcode or
SATA blobs. From this we can save any of the detected SWID metadata to
the database, and make it available as a SBoM HTML page[5] and also
.zip archive[6] containing the raw SWID XML data. We're also planning
a standalone tool which is more useful for the BMC firmware that's not
ever going to be uploaded to the LVFS.

If you do think it's helpful to add uSWID metadata to the BMC image
please let me know; I think this makes just as much sense for firmware
that sits on a USB hub as it does your system firmware. Comments
welcome. Thanks!

Richard

[1] https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
[2] https://datatracker.ietf.org/doc/draft-ietf-sacm-coswid/
[3] https://github.com/hughsie/python-uswid
[4] https://fwupd.org/lvfs/uswid
[5] https://fwupd.org/lvfs/components/12400/swid
[6] https://fwupd.org/lvfs/components/12400/swid/archive