Product Certification

logo

Introduction

We want to make it easy for ODMs and OEMs to choose components that already have fwupd plugin support. This will do a few things:

  • The onus is pushed onto the IHV to maintain the plugin not the OEM, ODM or Linux distributor (e.g. Red Hat)

  • The ODM and OEM will prefer components that do not require any software development work to pass the Works With ChromeBook (WWCB) and Red Hat Enterprise Linux (RHEL) hardware certifications

  • Having a fwupd plugin will be seen as a commercial advantage for the IHV

There are two versions of the fwupd friendly firmware certification, one for devices that will only accept signed firmware (signed-payload) and another for insecure hardware that does not implement cryptographic signing (unsigned-payload). Either is fine from a fwupd plugin point-of-view, but some OEMs will have a policy that forces them to choose hardware that cannot be altered by the end user.

Note

Consumer devices end-users buy from the store are not suitable for fwupd friendly firmware, and already have device pages on the LVFS.

Requirements

To register a device for fwupd friendly firmware the original silicon vendor must have an existing LVFS vendor account, and also provide:

  • Device model, e.g. CX2098X

  • One line summary, e.g. USB3.2 Gen1 4-port hub controller

  • Link to the device page, e.g. https://www.kinet-ic.com/ktm50x0/ (optional)

  • Link to the upstream fwupd plugin that handles this device type, e.g. https://github.com/fwupd/fwupd/tree/main/plugins/synaptics-cxaudio

  • Device firmware certification level, e.g. always signed, optionally signed, or unsigned

  • Hash and signature algorithm used for firmware signing, e.g. SHA256+RSA2048, or n/a

To add a device to the certification page, please send an email to the mailing list with the required details. On meeting the requirements, the entry will be added and then the vendor is allowed use the signed or unsigned fwupd friendly firmware logo as required.

*fwupd friendly firmware*

logo for fwupd friendly firmware (always signed)

*fwupd friendly firmware*

logo for fwupd friendly firmware (optionally signed)

*fwupd friendly firmware*

logo for fwupd friendly firmware (unsigned)

Note

Vendors should not have a “generic” fwupd friendly firmware assigned to them, as a vendor may have multiple devices with different update protocols. e.g. Synaptics has cxaudio, mst, prometheus and cape protocols, each with a different fwupd plugin.

Conclusion

Vendors using the fwupd friendly firmware logo mark will make it easier for product creators to support firmware updates for Linux users. The burden of development moves earlier to the IHVs rather than later to the OEMs. OEMs can verify the fwupd friendly firmware certification and compare hardware using the public pages on the LVFS.