LinuxBoot and fwupd
24 views
Skip to first unread message
Richard Hughes
May 13, 2025, 5:52:05 AMMay 13
to linuxboot
Hi all,
My name is Richard Hughes and I'm the author of fwupd and the Linux Vendor Firmware Service. Philip asked me to join one of your fortnightly meetings to introduce myself and talk a bit about firmware updates and SBOM stuff, and I thought it might be useful to summarise here what we chatted about.
Most of the call was talking about SBOMs – anyone needing a good overview of the what and why can read something like https://lvfs.readthedocs.io/en/latest/sbom.html – the general consensus was that embedding the SBOM mostly made sense (it’s tiny as it compresses really well – and if the upstream project git or artifact URL goes away in the next 10 years the information is available locally), and that building it automatically in CI was a sensible thing to do. We talked about the example tooling (e.g. https://github.com/hughsie/python-uswid) and also pushing the SBOM templates upstream (e.g. https://docs.google.com/spreadsheets/d/1gKEWLxdLubOfgS1cqqY2umEX0ohYEoEy-B1i59HNVqg/edit?usp=sharing) so that upstream projects were in control of the SBOM contents. Someone asked how granular it makes sense to make the SBOM entries, as you can “combine” SBOM components into larger SBOM chunks. The consensus seemed to be to include anything in the SBOM that you might want to use as a comparison from a VEX query for a “is my system affected by a specific security bug”, so something like a compiler, crypto library and image loader library were “in” and perhaps lower level less important stuff was “out”. We all agreed it was somewhat fuzzy what should be included. Certainly adding an SBOM for uboot, oreboot etc. made a lot of sense – and also means fwupd knows what “firmware version” is currently installed.
Which brings me onto firmware updates nicely; In the call I explained that fwupd plugins just need to know the current device firmware version, and also how to copy in a new firmware blob. There’s lots more fwupd can do, but if we can provide the basics we can use the LVFS to distribute per-board or per-vendor 1st and 2nd stage bootloader updates from the LVFS either as separate deliverables, or a combined “blob”. Using the SBOM metadata for the current firmware makes sense, and combined with the DMI data (which may be completely generic) we can make an instance ID that reflects what firmware should be matched. e.g. we could have an instance ID of VENDOR_rockchip&PRODUCT_rk3588&OS_LinuxBoot which would then match up firmware on the LVFS. The firmware uploaded could then define “I support VENDOR_rockchip&PRODUCT_rk3588&OS_LinuxBoot and also VENDOR_rockchip&PRODUCT_rk9999&OS_LinuxBoot” which would get matched on either board. In the LVFS world there’s also the CHID restrictions (e.g. type “sudo fwupdtool hwids” into the console) which means you can then say “match VENDOR_rockchip&PRODUCT_rk3588&OS_LinuxBoot but *ONLY* for “ProductSku: 2023” which makes it a little easier to match firmware to the correct device subtype.
At the moment in fwupd we support updating using an MTD device, e.g. https://github.com/fwupd/fwupd/tree/main/plugins/mtd – and I think a lot of that can be used as-is. For other 2nd stage bootloaders it might be that the firmware wants to handle the update itself (say is R/O for userspace) so another plugin could be “just copy the file into the boot partition with a specific name” like we do with UEFI Capsule-On-Disk.
Richard
My name is Richard Hughes and I'm the author of fwupd and the Linux Vendor Firmware Service. Philip asked me to join one of your fortnightly meetings to introduce myself and talk a bit about firmware updates and SBOM stuff, and I thought it might be useful to summarise here what we chatted about.
Most of the call was talking about SBOMs – anyone needing a good overview of the what and why can read something like https://lvfs.readthedocs.io/en/latest/sbom.html – the general consensus was that embedding the SBOM mostly made sense (it’s tiny as it compresses really well – and if the upstream project git or artifact URL goes away in the next 10 years the information is available locally), and that building it automatically in CI was a sensible thing to do. We talked about the example tooling (e.g. https://github.com/hughsie/python-uswid) and also pushing the SBOM templates upstream (e.g. https://docs.google.com/spreadsheets/d/1gKEWLxdLubOfgS1cqqY2umEX0ohYEoEy-B1i59HNVqg/edit?usp=sharing) so that upstream projects were in control of the SBOM contents. Someone asked how granular it makes sense to make the SBOM entries, as you can “combine” SBOM components into larger SBOM chunks. The consensus seemed to be to include anything in the SBOM that you might want to use as a comparison from a VEX query for a “is my system affected by a specific security bug”, so something like a compiler, crypto library and image loader library were “in” and perhaps lower level less important stuff was “out”. We all agreed it was somewhat fuzzy what should be included. Certainly adding an SBOM for uboot, oreboot etc. made a lot of sense – and also means fwupd knows what “firmware version” is currently installed.
Which brings me onto firmware updates nicely; In the call I explained that fwupd plugins just need to know the current device firmware version, and also how to copy in a new firmware blob. There’s lots more fwupd can do, but if we can provide the basics we can use the LVFS to distribute per-board or per-vendor 1st and 2nd stage bootloader updates from the LVFS either as separate deliverables, or a combined “blob”. Using the SBOM metadata for the current firmware makes sense, and combined with the DMI data (which may be completely generic) we can make an instance ID that reflects what firmware should be matched. e.g. we could have an instance ID of VENDOR_rockchip&PRODUCT_rk3588&OS_LinuxBoot which would then match up firmware on the LVFS. The firmware uploaded could then define “I support VENDOR_rockchip&PRODUCT_rk3588&OS_LinuxBoot and also VENDOR_rockchip&PRODUCT_rk9999&OS_LinuxBoot” which would get matched on either board. In the LVFS world there’s also the CHID restrictions (e.g. type “sudo fwupdtool hwids” into the console) which means you can then say “match VENDOR_rockchip&PRODUCT_rk3588&OS_LinuxBoot but *ONLY* for “ProductSku: 2023” which makes it a little easier to match firmware to the correct device subtype.
At the moment in fwupd we support updating using an MTD device, e.g. https://github.com/fwupd/fwupd/tree/main/plugins/mtd – and I think a lot of that can be used as-is. For other 2nd stage bootloaders it might be that the firmware wants to handle the update itself (say is R/O for userspace) so another plugin could be “just copy the file into the boot partition with a specific name” like we do with UEFI Capsule-On-Disk.
We finished with the general comment that we could, and probably should, work closer together – and make the open source boot chain simply better than existing proprietary solutions. Comments welcome!
Reply all
Reply to author
Forward
0 new messages