[Lvfs-announce] Firmware Software Bill of Materials

Hi all,

A Software Bill of Materials (aka SBoM) is something you=E2=80=99ve probabl=
y
heard of, and they=E2=80=99ll hopefully start to become more and more
important as time goes on. In May last year the US president issued an
executive order titled Improving the Nation=E2=80=99s 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 =E2=80=9Cwho built what
from where=E2=80=9D. This concept breaks down for firmware, where lots of
different entities build each subsection in different ways, usually
due to commercial and technical constraints.

Firmware is often lumped together as one thing, but in reality a
single firmware image might contain a FSP from Intel, several updated
CPU microcode blobs for a few different CPUs, a CSME management
engine, an embedded controller update, a UEFI system firmware a lot
more. The system firmware is then made up of different file volumes,
each with a few dozen EFI PEI binaries for initial system start-up and
then a couple of hundred DXE binaries for things like pre-boot
networking and things like fingerprint authentication. Even something
as seemingly-monolithic as touchpad firmware might contain a HAL from
the silicon vendor, an ISV-supplied bootloader and an ODM-provided
runtime firmware all built together.

I=E2=80=99ve been spending the last few months putting all the pieces toget=
her
to make a firmware SBoM not just possible, but super easy for ISVs,
OEMs, ODMs and IBVs to generate. This is so that you as vendors can
make some plans on how to be in compliance with any future requirement
from the US government, rather than reacting reactively next year.

For UEFI firmware, one of the first problems to solve 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 =E2=80=9CSBOM=E2=80=9D. This allows us to au=
tomatically
capture at build time some data, for instance the tree hash, and the
files that were used to build the binary, etc. In the next few months
you will be able to drop a top-level vendor.ini file in your EDK2
checkout with the correct vendor data (legal name, home page etc.) and
then you can just build the tree and get everything inserted in this
new PE section automatically. This gets us half way there. The uSWID
readme[3] explains how to do this manually too, for people not using
either the EDK2 build-system or a variant of it.

The second problem is how to include SWID metadata for the blobs we
either don=E2=80=99t build, or we can=E2=80=99t modify in any way, e.g. the=
 FSP or
microcode. For this there=E2=80=99s an =E2=80=9Cexternal=E2=80=9D version o=
f the same coSWID
metadata which has a simple header we can find in the firmware image.
This can either be included in the file volume itself, 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=E2=80=99s 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 =E2=80=93 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 =E2=80=93 even in the
0xFF,0xFF,0xFF,0xFF,0xFF,0xFF =E2=80=9Cspare=E2=80=9D space left at the end=
 of the
update image. I would suggest vendors not shipping UEFI updates to
start talking about this with their internal developer teams now, and
the ones shipping UEFI firmware to start talking to their ODM about
their plan on how to ship a SBoM.

This means the firmware uploaded to the LVFS 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/SATA/touchpad 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.

The vendor also gets the all important =E2=80=9Cgreen tick=E2=80=9D which m=
eans the
customer buying the hardware knows that it=E2=80=99s complying with the fut=
ure
requirements. Of course, we can=E2=80=99t check if the uploader has include=
d
all the SWID metadata for all the built content, or included all the
SWID components for all of the nonfree chunks, but it=E2=80=99s good enough=
 as
a first pass. The next logical thing would be to make a rule saying
that the SWID green tick disappears if we detected CPU microcode, but
also didn=E2=80=99t detect any microcode SWID metadata, etc.

I think I=E2=80=99ve got agreement-in-principle from most of the major
stakeholders, and I=E2=80=99ll be hopefully presenting this work in a few
months time. This means we=E2=80=99re in a position to actually provide SBo=
M
for all firmware when the next EO revision is announced.

If you do want to add uSWID metadata to your firmware please let me
know how I can help, even if it=E2=80=99s not available on the LVFS yet; I
think this makes just as much sense for firmware that sits on a USB
hub as it does your system firmware. Comments welcome, but please use
the https://lists.linuxfoundation.org/mailman/listinfo/lvfs-general
mailing list for discussion rather than replying to me personally if
at all possible. Thanks!

Richard

[1] https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/1=
2/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