LVFS makes Linux firmware updates easier

The Linux Vendor Firmware Service serves as a link between hardware vendors who release updates and end users who need to install them.
505 readers like this
505 readers like this
Open lightbulbs.

Opensource.com

Traditionally, updating a BIOS or a network card's firmware in Linux meant booting into Microsoft Windows or preparing a MS-DOS floppy disk and hoping everything would work correctly after the update. Periodically searching a vendor website for updates is a manual and error-prone task and not something we should ask users to do. A firmware update service makes it simpler for end users to implement hardware updates.

A firmware update service requires two things:

  • vendors to provide information to the service about updates available for specific hardware, and
  • a mechanism to deploy the firmware onto the hardware.

The Linux Vendor Firmware Service (LVFS) is a secure web service that allows hardware vendors to upload firmware updates. The metadata and files provided by LVFS are used by all major Linux distributions to provide metadata for clients such as fwupdmgr and GNOME software. There is also no charge to vendors for LVFS to host or distribute content (although donations are welcome from both OEMs and users).

For end users, fwupd is a simple daemon built for Linux to allow session software to update device firmware on a local machine. It's designed for desktops, but also usable on phones and headless servers. To view and apply updates, users can use a GUI software manager like  GNOME software, the command-line tool, or the system D-Bus interface.

How LVFS started

A lot of hardware already supports user-upgradeable flash firmware. This is a great thing for vendors, as they can ship hardware and deploy updates when bugs are identified and fixed. By splitting the available flash memory, with a bootloader in one section and an application firmware in another, the latter can be upgraded without disassembly or expensive programmers.

LVFS emerged from my experience designing ColorHug, an open hardware colorimeter that allows Linux users to calibrate their display. Since the project started, we've shipped more than a dozen updates for three different devices. Like with most open hardware devices, to upgrade the firmware I shipped project-specific tools in a tarball, pulling a custom metadata file over HTTP from my hosting provider. There was a checksum for the binary firmware, but no private/public signing. Most users just flashed the firmware using the command line, using a statically linked program, as root.

About the same time, Red Hat wanted me to help make more hardware "just work." Some of this involved adding kernel drivers, some of it was fixing GNOME to support new hardware, and some of it was updating firmware on devices. Upgrading laptop firmware in Linux was often a bad experience, and I wondered whether I could produce shared infrastructure that mega-companies and open hardware nano-vendors could use—both to apply the firmware itself and to distribute the metadata and firmware files in a shared, secure way. This is how LVFS came to be.

How fwupd works

The fwupd daemon supports the usual Design Firmware Upgrade (DFU) and Unified Extensible Firmware Interface (UEFI) standards, and also quite a few vendor-specific update protocols. If a project can be updated using dfu-util, dfu-programmer, flashrom, or fwupdate, there's a good chance it'll just work with fwupd, with no additional code required. If the update protocol is vendor-specific (like Logitech uses), we can write a small plugin for the daemon to upgrade the hardware. Currently, LVFS supports about 10 different upgrade mechanisms, and fwupd is shipped with every modern Linux distribution.

LVFS allows vendors of any size to create an account for free and upload re-distributable firmware with standard metadata. The CAB container format was chosen to allow existing files to be re-signed using the Microsoft Update tools. The firmware is signed using GNU Privacy Guard (GPG), and the shared metadata file is updated with SHA256 hashes of the firmware. The new files are then uploaded to a SSL-enabled content-delivery network and can exist in private, embargoed, testing, or stable states.

LVFS now supports more than 70 different devices, and every month more than 165,000 devices are updated by fwupd using the firmware on LVFS. Additionally, the list of available firmware is downloaded nearly 100-million times each month. Since we started this project, at least 600,000 items of hardware (but probably many more) have been updated with new firmware.

We have strong backing from quite a few large vendors, with a few others testing the service and working on legal approval to upload binary files. I'd love to see more hardware on LVFS, with more of the custom flashing protocols supported in the fwupd daemon.

Hardware is difficult enough to produce without having to design a secure upgrade mechanism that will work on every Linux distribution. If you would like to use LVFS to distribute firmware, please contact me. If you'd like to develop a fwupd plugin, you can email the mailing list or start reading the documentation. If you know of hardware that supports user-upgradeable firmware, please ask the maker about including LVFS support.

Tags
Richard has over 10 years of experience developing open source software.

9 Comments

I agree. Unfortunatelly it is broken in F27. It looks like incorrectly inserted path... /boot/efi/EFI/EFI//boot/efi/EFI/... ???

Scheduling… [ - ]UEFI firmware update failed: {error #0} /builddir/build/BUILD/fwupdate-9/linux/libfwup.c:1193 get_fd_and_media_path(): open of /boot/efi/EFI/EFI//boot/efi/EFI/fedora/fw/fw/fwupdate-K0LvwD.cap failed: No such file or directory

Great! I will wait. Second thing is, that dmidecode tells me it is 2.3.1 already, but fwupdmgr thinks it is still 2.2.1

BIOS Information
Vendor: Dell Inc.
Version: 2.3.1

vs.
XPS 13 9360 System Firmware
Version: 0.2.2.1
VersionLowest: 0.2.2.1

I also wait for TB16 firmware update. This dock is not best Dell product.

Thank you for all your hardwork!!!
I can not imagine how much complicate and time consuming it is.

In reply to by Richard Hughes

Dell have chosen to specify the version number in fwupd as aa.bb.cc.dd rather than the slightly-more-normal aa.bb.ccdd -- fwupd supports this, but it seems dmidecode doesn't.

In reply to by Creep

I have HP Pavilion 15 ab252ur (V2H26EA), for which HP claims that FW update is only supported when Win10 is the sole system installed. I installed Ubuntu 16.04 as first system on it, then Win10 as second one (both in UEFI mode with Secure Boot disabled), and after that I was unable to update FW from within Win10. Do I have a chance to update FW from within Ubuntu using this software and repository?

HP have not included this model on the LVFS yet, but once they do there's no reason why it shouldn't work.

In reply to by Wladimir Mutel (not verified)

It's a great idea to push this off to manufacturers who should all be working much harder to ensure their users can use the devices they buy. I'd imagine the largest problem will be that manufacturers pull firmware as a planned obsolescence drive (kinda like how iPhones get slower just before a release of new iPhones).

Many of our vendors have expressed a need for native tools on FreeBSD to update firmware. So I'm wondering if this might be a path forward although it seems this is mostly focused on Linux desktops at the moment.

Although it's indeed focused on Linux, I don't think there's actually any Linux-specific code in fwupd. I've not tried to get fwupd installed on FreeBSD but I think it should be possible if the required dependency versions are in place. Some of the optional plugins are Linux specific (e.g. the UEFI UpdateCapsule one) but you can just compile that out.

In reply to by Scott Lamons

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.