Today we tagged the 1.5.0 release of fwupd. Quite a bit has changed since the last release and I figured a blog post probably made sense to explain things.
From a firmware engineer point of view, the most useful is the ability to build composite images, for instance building a
firmware.dfuse file from different
B.dfu images. At the moment there are commands in
fwupdtool to convert one file format to another, but not to merge or alter them. Many firmware files are really just containers which can store multiple images, each with optional id, index and addresses. This new fwupd feature also allows us to create very small complicated container binaries for fuzzing.
This can be used by writing a `firmware.builder.xml` file like:
<?xml version="1.0" encoding="UTF-8"?> <firmware gtype="FuBcm57xxFirmware"> <version>1.2.3</version> <image> <version>4.5.6</version> <id>header</id> <idx>456</idx> <addr>0x456</addr> <filename>header.bin</filename> </image> <image> <version>7.8.9</version> <id>payload</id> <data>aGVsbG8=</data> </image> </firmware>
…and then using something like
fwupdtool firmware-convert firmware.builder.xml firmware.dfu builder dfu on the CLI.
Notably, each subclass of
FuFirmware (for instance
FuBcm57xxFirmware) can define properties it expects in the XML so it can really be quite expressive and useful.
From the developer point of view, the most interesting additions are the async API to
libfwupd and also the addition of
FwupdPlugin so we can convey enumerated system errors to the end user. This means we can finally stop the workaround of building “dummy devices” with the update error set for a generic plugin failure, e.g. efivarfs not being mounted. Expect updates to GNOME Software and GNOME Firmware to support both when all this hits Fedora stable.
From the end user point of view, we have lots of new devices supported, including:
- Goodix fingerprint sensors
- Elan Touchpads
- ChromeOS Quiche and Gingerbread
- Broadcom BCM5719 network adapter
The latter being the most interesting, as the BCM5719 has two branches of firmware; one from Broadcom and one free software re-implementation from meklort. Once both versions of firmware has been uploaded to the LVFS, the user can simply type
fwupdmgr switch-branch to switch from the proprietary firmware to the free software one, or back again. We’re hoping to use this in other places in the future, for instance EDK2 to Coreboot on platforms without BootGuard enabled.
Which brings me nicely to the Host Security ID. We’re not officially launching the HSI specification yet, as we’re waiting to hear back from various silicon vendors about how (and if) they can support the new initiative. HSI is something that might be hugely interesting to users where platform security is important and especially for people specifying and purchasing hardware for a specific purpose. Although
fwupdmgr security is now available, you‘ll need to use
--force as it’s not officially an API stable “thing” yet. If you do play with HSI, be sure to upload results to the LVFS if you can and then we’ll know if the various plugins are working as designed. I’m sure we’ll be talking more about HSI in the future…
We’ve also done some work for teams building fwupd into products we never imagined; for CoreOS the ModemManager and flashrom plugins are split off as sub-packages so that we don’t drag lots of extra deps onto the minimal image. We’ve also made PolicyKit optional at build time as it doesn’t make sense on super-embedded devices, although you’re limited to only installing signed firmware. For the server SSH-only case we’re also using
pkttyagent to request user passwords if running without GUI.
Finally, it was a ton of work testing and fixing timing bugs for composite devices found in various laptop docks, so the people waiting for those updates probably want to update to 1.5.0 too. Updates are already on the LVFS and will be available soon. You know who you are.