Software Bill of Materials

[Patrick Williams]

On Thu, Mar 17, 2022 at 04:26:08PM +0000, Richard Hughes wrote:
> Hi all,

Hello Richard,

Thanks for pointing this topic out to us.  I'm not sure we've done a lot of
thinking on it and there appears to be a good amount to digest.

> 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 believe most of our BMC images actually are much simpler than you've laid out
here.  Typically it really is just the BMC code and images for any other devices
are updated independently.  For the BMC that means u-boot, kernel, rootfs.

> 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.

Do you know if there has been any effort put into this at a Yocto level?
bitbake already has all the source code used to build our image and all the
metadata about how it was built.  It seems like they could add the SBoM to their
build process, if you wanted it on each package in the rootfs.  

Alternatively, would something as simple as the git-commit of the Yocto
metadata used to build the image be sufficient for a SBoM?  The Yocto metadata
itself contains hashes (or git-commits) of the source for each package
bitbake built.  I don't know how far down into the onion you're expected to peel
for whatever these SBoM hashes are.

> 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.

Depending on which pieces we need to have covered by coSWID it seems like this
could likely be put in a "free area" of the BMC image as well.

> 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!

I'm not really sure where to go from here.  It seems like, since we've built
everything on top of Yocto, having someone go write a bbclass that creates
whatever coSWID data you want from existing information the bitbake recipes
already have would be the start.

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20220317/94c87a71/attachment.sig>