The coreboot firmware has just received a new patch adding Software Bill of Materials (SBoM). The SBoM concept has been mainly driven by Richard Hughes and has been derived from an executive order that has been issued last year by the US president. If you are more interested on the background of SBoM, Richard wrote a nice summary here.
Summarized, SBoM should provide a way to have a manifest of which parts have been built by whom and from where. The Bill of Materials(BoM) is a common term for hardware developers. It lists exactly what raw materials, sub-assemblies and parts including the quantities of each needed to actually manufacture the product. However, for software this is non-existent. On an operating system level one can sometimes choose on what should go on the disk and what not - for firmware this is not true. Firmware just ships with the hardware you bought - thus you have to live with it (There are exceptions - but in general..)
SBoM is “who built what from where”
SBoM is here to change this and provides a list of used software parts that have been put together. Firmware consists of multiple parts, often lumped together as one binary. Even coreboot, as an open-source firmware projects, has to consume multiple closed-source binaries in order to work properly. Now the end user has an easy way to scroll through the SBoM and check in more detail what really is inside this binary blob called firmware.
How it works
Okay, let's look into more detail how this works in coreboot. Let's jump to the TL;DR first:
coreboot pulls in SBOM templates, modifies those that they fit for needs, and stich them into the image.
With the patchset that adds SBOM, we added three things to coreboot:
- First of a set of SBOM templates,
- Tooling that converts these SBOM templates into binary format,
- Extend the coreboot build system to do all of this automatically while building coreboot.
SBOM Templates
We generated quite some templates for different parts within coreboot. First of all to give everyone a better kickstart in case they want to look at the SBOM files, and probably want to generate them on their own. So let's check how the process looks like if we enable SBOM in coreboot.
First of all, the provided patchset adds a new Kconfig to the General Setup menu.
Once enabled, this will generate SBOM files for multiple other components like the Intel Management Engine, or all coreboot payloads like SeaBIOS. Every component gets it's own SBOM file - and can be enabled or disabled separately. For the Intel Management Engine, it looks like this:
If enabled, coreboot takes the provided templates in src/sbom and builds coSWID files out of this. To generate these files, we developed our own tooling called goSWID. The code can be found here, but it will also be checked into coreboot together with the patchset.
Within the build log from coreboot, we do see that we have our own sbom CBFS section now.
Details about what the SBOM CBFS section contains, can be printed by the goswid tooling.
The tooling prints in JSON format what the sbom CBFS section contains. It gives you a list of all SBOM files, as shown here for the coreboot SBOM file. Overall the coreboot integration is already quite good - we will improve the experience over time now, however for us it was important to land the change first - and then keep working on the UX.
If you have any comments on these changes, feel free to drop us an e-mail.
