Introduction

The LVFS is a secure web service that can be used by OEMs and ODMs to upload redistributable firmware archives for deployment onto Linux systems. This service should only be used to distribute files that are flashed onto non-volatile memory. There is no charge to vendors for the hosting or distribution of content.

The LVFS runs on a dedicated virtual private server and uses a public CDN for metadata. Every month there are over ~50 million files being downloaded from ~10 million clients. There are currently 239 devices supported on the LVFS with 634 available firmware versions. Clients such as fwupd download metadata about available updates and will offer the firmware update to end users on supported hardware.

Do I have to contribute any code?

No, unless you're using a custom update protocol that fwupd does not already support. In this case you can either write a new plugin with a free license, or provide specifications to the fwupd developers. Most hardware can be updated using the existing UEFI UpdateCapsule or DFU code in fwupd.

Upload Firmware

Once you have requested an account on the LVFS and have legal permission to redistribute the firmware, you can log in and upload files using the admin console. Files can be uploaded privately for testing and optionally embargoed until a specific date.

All firmware is uploaded as a cabinet archive, which matches the Microsoft Update requirements. Along with the firmware binary, the LVFS expects the archive to contain at least one .metainfo.xml file that describes the target device and firmware. You can create a cabinet archives using makecab.exe on Windows and gcab on Linux.

It is recommended you name the archive with the vendor, device and version number, e.g. hughski-colorhug-als-1.2.3.cab and is suggested that the files inside the cab file have the same basename, for example:

    hughski-colorhug-als-1.2.3.cab
     |- firmware.bin
     \- firmware.metainfo.xml

Why does the LVFS project sign the archive?

The upload process repacks the uploaded archive into a new cabinet file and signs the firmware image using a detached GPG or PKCS#7 signature so client tools can be sure the firmware actually originated from the LVFS. Any existing Windows Update signatures are also copied into the new archive although are not used on Linux. The signed archive is prefixed with the hash of the uploaded file to avoid clashes with other uploaded files and to make the download location non-predictable.

Working with ODMs

There are some OEMs where the ODM will be the entity responsible for uploading the firmware to the LVFS. The per-device QA can either be done by the OEM or the ODM as required.

The LVFS administrator can mark other vendors as affiliates of other vendors. This gives the ODM permission to upload firmware that is owned by the OEM on the LVFS, and would appear in the OEM embargoed metadata. The ODM can update the description and delete the firmware, but the OEM QA team is responsible for moving the firmware to testing or stable.

The ODM vendor account also doesn't have to appear in the search results or the vendor list, allowing it to remain hidden to all users except the OEM.

This also means if an ODM builds firmware for two different OEMs, they also have to specify which vendor should own the firmware at upload time. The ODM is able to manage their user accounts directly, either using local accounts with passwords, or using an OAuth provider.