Over the last year we've grown the LVFS ecosystem over 100%. Recently we hit 2 million firmware downloads per month for the first time. There are now over 3000 firmware files available on the LVFS, with over 100 vendors using 50 different protocols. We're clearly winning.

I wanted a chance to talk about the latest things that you can do on the LVFS and with fwupd.

• We have more vendors using HSI for real use cases
• We now have a complete Redfish implementation working with tier-1 OEM hardware.
• Signed LVFS firmware reports for hardware certification.
• Scanning EFI binaries on upload for common security problems.
• Soft requirements in the form of recommends and requires.
• A global progressbar, to be used for instance in something like ChromeOS.
• Bidirectional support for VINCE, allowing us to work effectively with CERT.
• Mirroring to IPFS for firmware updates from behind less-than-great firewalls.
• Adding support for CapsuleOnDisk and chainloading from grub, and more generally FreeBSD.

Time will be left for some questions and feedback.

Nowadays, it’s difficult to find any hardware vendor who develops all the components present in its products. Many of these components, including firmware, are outsourced to ODMs. As a result, this limits the ability of hardware vendors to have complete control over their hardware products. In addition to creating extra supply chain security risks, this also produces security gaps in the threat modeling process. Through this research, ​we wanted to raise awareness about the risks in the firmware supply chain and the complexity of fixing known vulnerabilities.

The firmware patch cycles last typically around 6-9 months (sometimes even longer) due to the complexity of the firmware supply chain and the lack of a uniform patching process. The 1-day and n-day vulnerabilities in many cases have a large impact on enterprises since the latest firmware update wasn’t installed or the device vendor had not released a patch yet. Each vendor follows their own patch cycle. Even known issues may not be patched until the next firmware update is available.

We decided to build an open-source framework to identify known vulnerabilities in the context of UEFI specifics, classify them based on their impact and detect across the firmware ecosystem with the help of the LVFS project. We will be sharing our approach as well as the tooling we have created to help industry identify the problems and get patched.

Nowadays, it’s difficult to find any hardware vendor who develops all the components present in its products. Many of these components, including firmware, are outsourced to ODMs. As a result, this limits the ability of hardware vendors to have complete control over their hardware products. In addition to creating extra supply chain security risks, this also produces security gaps in the threat modeling process. Through this research, ​we wanted to raise awareness about the risks in the firmware supply chain and the complexity of fixing known vulnerabilities.

The firmware patch cycles last typically around 6-9 months (sometimes even longer) due to the complexity of the firmware supply chain and the lack of a uniform patching process. The 1-day and n-day vulnerabilities in many cases have a large impact on enterprises since the latest firmware update wasn’t installed or the device vendor had not released a patch yet. Each vendor follows their own patch cycle. Even known issues may not be patched until the next firmware update is available.

We decided to build an open-source framework to identify known vulnerabilities in the context of UEFI specifics, classify them based on their impact and detect across the firmware ecosystem with the help of the LVFS project. We will be sharing our approach as well as the tooling we have created to help industry identify the problems and get patched.

Workshop outline:

• Why it's important to get patched in time, and why your EDR won't help you with compromised firmware?
• The uefi_r2 scanner details internals (https://github.com/binarly-io/uefi_r2)
• How semantic code annotations work to bring UEFI codentext for code analysis
• How to scale uefi_r2 scanner in enterprise infrastructure?
• Deep dive into FwHunt rules format
• What is the difference between detecting new and known issues?
• How does the FwHunt detection work on different layers PEI/DXE/SMM?
• LVFS integration of uefi_r2 and FwHunt
• How patch the industry deal with the help of LVFS?
• Future plans and upcoming updates for FwHunt technology