Software Bill of Materials

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

Re: Software Bill of Materials

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 5438 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Software Bill of Materials

[Richard Hughes]

On Thu, 17 Mar 2022 at 22:21, Patrick Williams <patrick@stwcx.xyz> wrote:
> there appears to be a good amount to digest.

Yes, agreed!

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

Ahh, no binary BSP/FSP does make things a lot easier.

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

Not bitbake, but there are people doing the same kind of thing in the
EDK2 tree, i.e. generating the SWID metadata at build time
automatically with a "vendor.ini" file in the toplevel to provide
entity details.

> Alternatively, would something as simple as the git-commit of the Yocto
> metadata used to build the image be sufficient for a SBoM?

It's some of the metadata we need, but it's not the "who built" part
-- which is the most important bit from a SBoM point of view.

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

That's a valid question. I'm guessing less granularity is fine -- as
it's not like your kernel was built by a different legal entity to the
openbmc binaries -- it's all done at the same time.

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

Agree. I'll take this discussion to the Yocto mailing list, and then I
guess OpenBMC gets this "for free" too. Many thanks for the speedy
reply, it's most appreciated.

Richard.

Re: Software Bill of Materials

[Brad Bishop]

On Thu, Mar 17, 2022 at 05:20:50PM -0500, Patrick Williams wrote:
>On Thu, Mar 17, 2022 at 04:26:08PM +0000, Richard Hughes wrote:

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

I think many general purpose offerings do this in the way Richard 
describes.  Can we include that world-view in the disucssion too?

brad

Re: Software Bill of Materials

[Richard Hughes]

On Fri, 18 Mar 2022 at 13:39, Brad Bishop <bradleyb@fuzziesquirrel.com> wrote:
> I think many general purpose offerings do this in the way Richard
> describes.  Can we include that world-view in the disucssion too?

I think it's all going to be a hybrid solution anyway, e.g. some
auto-generated, some generated with some additional input and some
just curated. I wrote a bit more about the bigger picture
https://blogs.gnome.org/hughsie/2022/03/10/firmware-software-bill-of-materials/
if that helps.

Richard

Re: Software Bill of Materials

[Joseph Reynolds]

On 3/17/22 5:20 PM, Patrick Williams wrote:
> 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.

...snip...

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

I asked Yocto a while back.  They referred me to the license.bbclass.  
You can configure it to produce a list of recipes used, along with 
version and license.
I also use the archiver.bbclass to get the source code needed for 
license compliance and for source code scans.

-Joseph