Does anyone have any examples of peripheral devices that can have their firmware upgraded by dropping a new firmware file onto a mounted volume? e.g. insert device, new disk appears, firmware file is copied over, then the firmware update completes?
Could anyone with a device that supports firmware upgrade using bulk storage please fill in my 2 minute questionnaire? I’m trying to create a UF2-compatible plugin to fwupd and need data to make sure it’s suitable for all vendors and devices. The current pull request is here, but I have no idea if it is suitable yet. Thanks!
I’ve just deployed some new functionality to the LVFS adding support for component
<tag>s. These are used by server vendors to identify a known-working (or commercially supported) set of firmware on the machine. This is currently opt-in for each vendor to avoid the UI clutter on the components view, and so if you’re a vendor reading this post and realize you want this feature, let me know and it’s two clicks on the admin panel.
The idea is that when provisioning the machine, we can set
/etc/fwupd/daemon.conf and then any invocation of
fwupdmgr sync-bkc will install or downgrade firmware on all compatible devices (UEFI, RAID, network adapter, & SAS HBA etc.) to make the system match a compatible set. This allows two things:
- Factory recovery where a system in the field has been upgraded
- Ensuring a consistent set of vendor-tested firmware for a specific workload
The tags are either assigned in the archive
firmware.metainfo.xml file or added post-upload on the LVFS and are then included in the public AppStream metadata. A single firmware can be marked with multiple tags, and tags can be duplicated for different firmwares. This would allow a server vendor to say “this set of firmware has been tested as a set for workload A, and this other set of firmware has been tested for workload B” which is somewhat odd for us consumer-types, but seems to be pretty normal for enterprise deployments.
As a bonus feature, updating or downgrading firmware away from the “Best Known Configuration” is allowed, but we’ll show a semi-scary warning. Using
fwupdmgr sync-bkc will undo any manual changes and bring the machine back to the BKC. Needless to say fwupd will not ship with a configured BKC.
We’ll include this somewhat-niche-but-required feature with fwupd 1.7.3 which will hopefully be released before Christmas. Questions and comments welcome.
tl;dr: if you’re using
libfwupd to download firmware, nothing changes and everything continues as before. If you’re using something like
wget that doesn’t follow redirects by default you might need to add a command line argument to download firmware from the LVFS.
Just a quick note to explain something that some people might have noticed; if you’re using fwupd >= 1.6.1 or >= 1.5.10 when you connect to the LVFS to download a firmware file you actually get redirected to the same file on the CDN. e.g. downloading
https://fwupd/download/foo.cab gets a redirect to
https://cdn.fwupd/download/foo.cab which is then streamed to the user. Why this insanity?
As some of you know, egress charges from AWS are insanely high. The Linux Foundation are the kind people that kindly pay the LVFS bill every month, and a 4 years ago that was just a few hundred dollars and that was a rounding error to them. Last year we again grew at more than 100% and the projection for next year is going to surpass even that; the average size of firmware files has gone from ~30MB to ~50MB with much, much, larger server firmware in the pipeline. We certainly can’t watch the egress bill scale linearly with the LVFS popularity, else some accountant at the Linux Foundation is going to start asking questions – especially when Fastly provides the LF a geo-replicated CDN – which we’re not using.
So why don’t we put the CDN URL in the XML metadata directly, and then avoid all this redirect complexity altogether? This time the lawyers get us, as we’re required by US law to restrict distribution of some firmware to some countries on an embargo list. It’s very complicated, and it varies by vendor, but it’s not something we can avoid. So for this reason, the LVFS does a GeoIP lookup on the client IP, and if it’s all okay we then redirect the client to the CDN-cached version. It also lets us tell the vendor how many times the firmware has been downloaded without importing the CDN logs every 24 hours – which would be even harder as we only keep them for a short time for privacy reasons.
We just purchased a 2021 KIA eNIRO to use as our family car. As typical with EVs, this has to produce a fake engine noise to avoid squashing the hard of hearing (or animals) not expecting two tons of metal to be silently moving. When we test drove a 2020 car last year, there was a physical button on the dash to turn this off, on the premise that the noise sometimes isn’t required or appropriate, but it always defaulted to “on” for every start. As the car gets faster the noise also increases in volume, until after about 30km/h fading to nothing. In reverse the same thing happens with some additional beeps. Getting our 2021 car this year, the button was no longer present and the less-than-affectionately known VESS module cannot be muted. I can guess why, someone probably turned it off and squashed something or someone and someone in the UK/US/EU government understandably freaked out. KIA also removed the wire from the wiring loom, and won’t sell the 2020 button cluster, so it’s not even like you can retrofit a new car to act like the old one.
To be super clear: I don’t have a problem with the VESS noise, but because the “speaker” is in the front bumper the solution for going backwards is “turn up the volume”. Living in London means that houses are pretty close together and me reversing into the drive at 2mph shouldn’t submit the house opposite with a noise several times louder than a huge garbage truck. The solution in the various KIA owner forums seems to be “just unplug the VESS module” but this seems at best unethical and probably borderline illegal given it’s a device with the express purpose of trying to avoid hurting someone with your 2 ton lump of metal.
Given VESS is, as you might expect, just another device on the CAN bus and people have reverse engineered the command stream so you can actually just plug the VESS module into a USB device (with a CAN converter) and play with it yourself. My idea would be to make a modchip-like device that plugs into the VESS module using the existing plug, and basically MITM the CAN messages. All messages going from VESS back to the ECU get allow-listed (even though the ECU doesn’t seem to care if the VESS goes AWOL…) and any speed measurements going forward also get passed straight through. The clever part would be to MITM the speed when the “reverse gear” command has been issued, so that the car thinks it’s going about 20km/h backwards. This makes the VESS still make the engine and beeping noise but it’s only about as loud as the VESS module when going forwards when outside the car.
Technically this is quite easy,
VESS->txrxCAN->MCU->txrxCAN->ECU and you can probably use an inexpensive Microchip reference board for a prototype. My question is more if this would:
- Be ethical
- Be legal
- Invalidate my insurance
- Invalidate the warranty of my nice new shiny car
Feedback very welcome!
I’ve just released the first release of the 1.6.x series, and since 1.5.x some internal plugin API has been changed and removed. Although we’ve tested this release on all the hardware we have regression tests for, bugs may have crept in; please report failures to the issue tracker as required.
There are several new plugins adding support for new hardware and a lot of code has been migrated to the new plugin API. The public libfwupd API also has some trivial additions, although no action is required.
This release adds the following notable features:
- Add a composite ID that is used to identify dock device components
- Add an Intel Flash Descriptor parser
- Add API to allow the device to report its own battery level
- Add API to refount why the the device is non-updatable
- Add lspcon-i2c-spi programmer support
- Add more hardware support to the pixart-rf plugin
- Add some more new category types for firmware to use
- Add support for downloading the SPI image from the Intel eSPI device
- Add support for some Analogix hardware
- Add support for writing SREC firmware
- Add the firmware-sign command to fwupdtool to allow resigning archives
- Split UEFI EFI binary into a subproject
- Use an OFD or Unix lock to prevent more than one fwupdtool process
This release fixes the following bugs:
- Actually write the bcm57xx stage1 version into the file
- Add option to disable the UEFI capsule splash screen generation
- Avoid use-after-free when specifying the VID/PID in dfu-tool
- Cancel the GDBusObjectManager operation to fix a potential crash
- Check PixArt firmware compatibility with hardware before flashing
- Do not check for native dependencies as target dependencies
- Do not use help2man to build manual pages
- Fix a crash when shutting down the daemon
- Fix build on musl
- Fix build when using BSD
- Fix /etc/os-release ID_LIKE field parsing
- Force the synaptics-rmi hardware into IEP mode as required
- Never allow D-Bus replacement when a firmware update is in operation
- Offer the user to refresh the remote after enabling
- Remove unused, unsafe and deprecated functions from libfwupdplugin
- Simplify asking the user about reviews
- Write BMP data directly without using PIL
- Write synaptics-rmi files with valid checksum data
From a Fedora point of view, I’m waiting for the fwupd-efi new package to be reviewed and approved, and then I’ll upload the new version for Rawhide only. I might put 1.6.x into Fedora 34 after a couple more minor releases, but at the moment I’m keeping it with the 1.5.x stable branch which has all the important fixes backported. There’s a lot of new code in 1.6.x which needs to settle.
Today I released fwupd 1.5.6 which the usual smattering of new features and bugfixes. These are some of the more interesting ones:
With the help of a lot of people we added support for quite a bit of new hardware. The slightly odd GD32VF103 as found in the Longan Nano is now supported, and more of the DFU ST devices with huge amounts of flash. The former should enable us to support the Pinecil device soon and the latter will be a nice vendor announcement in the future. We’ve also added support for RMI PS2 devices as found in some newer Lenovo ThinkPads, the Starlabs LabTop L4 and the new System76 Keyboard. We’ve refactored the udev and usb backends into self contained modules, allowing someone else to contribute new bluetooth peripheral functionality in the future. There are more than a dozen teams of people all working on fwupd features at the moment. Exciting times!
One problem that has been reported was that downloads from the datacenter in the US were really slow from China, specifically because the firewall was deliberately dropping packets. I assume compressed firmware looks quite a lot like a large encrypted message from a firewalls’ point of view, and thus it was only letting through ~20% of the traffic. All non-export controlled public firmware is now also mirrored onto the IPFS, and we experimentally fall back to peer-to-peer downloads where the HTTP download failed. You can prefer IPFS downloads using
fwupdmgr --ipfs update although you need to have a running
ipfs daemon on your local computer. If this works well for you, let me know and we might add support for downloading metadata in the future too.
We’ve fully integrated the fwupd CI with oss-fuzz, a popular fuzzing service from Google. Generating horribly corrupt firmware files has found a few little memory leaks, files that cause fwupd to spin in a loop and even the odd crash. It was a lot of work to build each fuzzer into a small static binary using a 16.04-based container but it was well worth all the hard work. All new PRs will run the same fuzzers checking for regressions which also means new plugins now also have to implement building new firmware (so the test payload can be a few tens of bytes, not 32kB), rather than just parsing it.
On some Lenovo hardware there’s a “useful” feature called Boot Order Lock that means whatever the OS adds as a
BootXXXX entry the old bootlist gets restored on next boot. This breaks firmware updates using
fwupdx64.efi and until we can detect BOL from a kernel interface we also check if our EFI entry has been deleted by the firmware on next boot and give the user a more helpful message than just “it failed”. Also, on some Lenovo hardware we’re limiting the number of UEFI updates to be deployed on one reboot as they appear to have slightly quirky capsule coalesce behavior. In the same vein we’re also checking the system clock is set approximately correct (as in, not set to before 2020…) so we can tell the user to check the clock on the machine rather than just failing with a obscure certificate error.
Now there are systems that can be switched to coreboot (and back to EDK2 again) we’ve polished up the “
switch-branch” feature. We’re also checking both BIOSWE and BLE before identifying systems that can be supported. We’re also including the lockdown status in uploaded UEFI reports and added SBAT metadata to the fwupd EFI binary, which will be required for future versions of shim and grub – so for distro fwupd binaries the packager will need to set meson build options like
-Defi_sbat_distro_id=. There are examples in the fwupd source tree.
I’ve just released fwupd 1.5.5 with the following new features:
Add a plugin to update PixArt RF devices; the hardware this enables we’ll announce in a few weeks hopefully
Add new hardware to use the elantp (for TouchPads) and rts54hid (for USB Hubs) plugins
Allow specifying more than one VendorID for a device, which allows ATA devices to use the OUI-assigned vendor if set
Detect the AMD TSME encryption state for HSI-4 — use
fwupdmgr security --force to help test
Detect the AMI PK test key is not installed for HSI-1 — a failure here is very serious
As usual, this release fixes quite a few bugs too:
Fix flashing a fingerprint reader that is in use; in theory the window to hit this is vanishingly small, but on some hardware we ask the user to authorise the request using the very device that we’re trying to update…
Fix several critical warnings when parsing invalid firmware, found using hongfuzz, warming my office on these cold winter days
Fix updating DFU devices that use DNLOAD_BUSY which fixes fwupd on some other future hardware support
Ignore the legacy UEFI OVMF dummy GUID so that we can test the dbx updates using qemu on older releases like RHEL
Make libfwupd more thread safe to fix a crash in gnome-software — many thanks to Philip Withnall for explaining a lot of the
GMainContext threading complexities to me
We now never show unprintable chars from invalid firmware in the logs — as a result of fuzzing insane things the logs would often be full of gobbledygook, but no longer
I’m now building 1.5.5 into Fedora 33 and Fedora 32, packages should appear soon.
Today we released fwupd 1.5.3 which has the usual smattering of fixes and enhancements you’d expect. One notable fix is that we now allow setting the
GMainContext when used for sync methods, as some people reported problems with the way we implemented the sync libfwupd methods in previous 1.5.x releases. We’re now defaulting to the default thread context allowing the app to override if required, which seems to fix a lot of problems.
We’ve also merged some support code to support PS/2 devices. This included adding the device firmware ID for
serio class hardware. In general I’m happy to help vendors with patches that affect the core parts of fwupd (e.g. things inside
./src) but plugins themselves should now either be written by the IHV or by a consulting company employed by the IHV, ODM or OEM. There are now dozens of companies adding support for new hardware all at the same time and although I’m happy to review code, I still can’t write it all :) There are lots of consulting companies to choose from now.
We’ve also added back some compatibility code that allows apps running with old shared versions of libfwupd talk to a new running fwupd daemon – which shouldn’t be possible but then Snap decided to do just that and everything exploded.
Aleksander also merged a few patches to fix firmware updates over QMI on some hardware and to validate firmware update method combinations on mobile broadband hardware.
In the last release we also switched from libsoup to curl, but accidentally broke the RHEL build as it doesn’t quite have a new enough libcurl for us to use. There is now fallback code in place for these older versions.
The last few posts I did about fwupd releases were very popular, so I’ll do the same thing again: I’ve just tagged fwupd 1.5.2 – This release changes a few things:
Add a build time flag to indicate if packages are supported – this would be set for “traditional” package builds done by the distro, and unset by things like the Fedora COPR build, the Flatpak or Snap bundles. There are too many people expecting that the daily snap or flatpak packages represent the “official fwupd” and we wanted to make it clear to people using these snapshots that we’ve done basically no QA on the snapshots.
A plugin for the Pinebook Pro laptop has been added, although it needs further work from PINE64 before it will work correctly. At the moment there’s no way of getting the touchpad version, or finding out which keyboard layout is installed so we can tag the correct firmware file. It’s nearly there and is still very useful for playing with the hardware on the PB Pro.
Components can now set the icon from the metadata from the LVFS, if supported by the fwupd plugin. This allows us to tag “generic” ESRT devices as things like EC devices, or, ahem, batteries.
I’ve been asked by a few teams, including the Red Hat Edge team, the CoreOS team and also by Google to switch from libsoup to libcurl for downloading data – as this reduces the image size by over 5MB. Even NetworkManager depends on libcurl now, and this seemed like a sensible thing to do given fwupd is now being used in so many different places.
Fall back to FAT32 internal partitions for detecting ESP, as some users were complaining that fwupd did not properly detect their ESP that didn’t have the correct partition GUID set. Although I think fixing the GUID is the right thing to do, the system firmware also falls back, and pragmatically so should we.
Fix detection of ColorHug version on older firmware versions, which was slightly embarrassing as ColorHug is one of the devices in the device regression tests, but we were not testing an old enough firmware version to detect this bug.
Fix reading BCM57XX vendor and device ids from firmware – firmware for the Talos II machine is already on the LVFS and can replace the non-free firmware there in almost all situations now.
For this release we had to improve synaptics-mst reliability when writing data, which was found occasionally when installing firmware onto a common dock model. A 200ms delay is the difference between success and failure, which although not strictly required seemed pragmatic to add.
Fix replugging the MSP430 device which was the last device that was failing a specific ODM QA. This allows us to release a ton of dock firmware on the LVFS.
Fix a deadlock seen when calling libfwupd from QT programs. This was because we were calling a sync method from threads without a context, which we’ve now added.
In 1.5.0 we switched to the async libfwupd by default, and accidentally dropped the logic to only download the remote metadata as required. Most users only need to download the tiny
.jcat file every day, and the much larger
.xml.gz is only downloaded if the signature has changed in the last 24h. Of course, it’s all hitting the CDN, but it’s not nice to waste bandwidth for no reason.
As Snap is bundling libfwupd with gnome-software now, we had to restore recognizing GPG and PKCS7 signature types. This allows a new libfwupd to talk to an old fwupd daemon which is something we’d not expected before.
We’re also now setting the SMBIOS chassis type to portable if a DeviceTree battery exists, although I’d much rather see a
ChassisType in the DT specification one day. This allows us to support HSI on platforms like the PineBook Pro, although the number of tests is still minimal without more buy-in from ARM.
We removed the HSI update and attestation suffixes; we decided they complicated the HSI specification and didn’t really fit in. Most users won’t even care and the spec is explicitly WIP so expect further changes like this in the future.
If you’re running 1.5.0 or 1.5.1 you probably want to update to this release now as it fixes a hard-to-debug hang we introduced in 1.5.0. If you’re running 1.4.x you might want to let the libcurl changes settle, although we’ve been using it without issue for more than a week on a ton of hardware here. Expect 1.5.3 in a few weeks time, assuming we’re all still alive by then. :)
Hot on the heels of 1.5.0, I’ve just tagged and uploaded fwupd 1.5.1. Most importantly, if fixes the regression we recently included for an as-yet-unnamed OEM who wants to ship dock firmware. Any day now, I promise.
Other interesting things we fixed:
- Delete unused EFI variables when deploying firmware — which frees up a lot of space if you’ve ever enabled the
- Fix duplicate probe warning for the Logitech Unifying device — which was really cosmetic, but wasting resources is never nice.
- Include the amount of NVRAM size in use in the LVFS failure report — which will might let us explain some of the dbx updates failing.
- Make bcm57xx hotplug more reliable — although uncommon to hotplug PCI devices, using an eGPU enclosure (like I do for the device tests!) this needs to work!
- Recognize authorized ThunderBolt value of 2 — which we found in the wild recently.
- Remove the duplicate parent-child data in
FuDevice — although not strictly a bugfix, duplicating this data made no sense and caused confusion.
- Use UDisks to find out if swap files and devices are encrypted — which further adds more code depending on UDisks. I’ve added a
Recommends: udisks2 in the Fedora package, but see the wiki if you’re running a minimal system.
As before, Fedora 33 and 32 updates in the usual places.