Richard Hughes has two new blog posts, one with an update to LVFS, and one on how it parses firmware ‘blobs’:
[…]Specifically, firmware is now being checked for expired Authenticode certificates which expired more than 3 years before the upload date of the firmware. The LVFS is also looking for test signing certificates that really should not exist in production firmware. All existing firmware on the LVFS is being tested, and the test backlog should be complete by this afternoon. All test failures are currently waivable.[…]
The Linux Foundation welcomes the Linux Vendor Firmware Service (LVFS) as a new project. LVFS is a secure website that allows hardware vendors to upload firmware updates. It’s used by all major Linux distributions to provide metadata for clients, such as fwupdmgr, GNOME Software and KDE Discover. To learn more about the project’s history and goals, we talked with Richard Hughes, upstream maintainer of LVFS and Principal Software Engineer at Red Hat.[…]
System Firmware and Device Firmware Updates using Unified Extensible Firmware Interface (UEFI) Capsules
Firmware is responsible for low-level platform initialization, establishing root-of-trust, and loading the operating system (OS). Signed UEFI Capsules define an OS-agnostic process for verified firmware updates, utilizing the root-of-trust established by firmware. The open source FmpDevicePkg in TianoCore provides a simple method to update system firmware images and device firmware images using UEFI Capsules and the Firmware Management Protocol (FMP). This session describes the EFI Development Kit II (EDK II) capsule implementation, implementing FMP using FmpDevicePkg, creating Signed UEFI Capsules using open source tools, and an update workflow based on the Linux Vendor Firmware Service (fwupd.org).
There’s been a few blog posts from the LVFS project and the System76 team regarding firmware updates.
The latest article is from FOSSpost.org by M.Hanny Sabbagh, which focuses on privacy issues of LVFS, from the last System76 article. While privacy issues are important, don’t forget that firmware update privacy issues exist with ALL other OSes, and LVFS team mentions transition to Linux Foundation for hosting. Most firmware updates come from OEM, so each will have their own CDN/privacy/security issues. I’m hoping the LVFS project gets picked up by the Qubes/TAILS/Subgraph/GNUHardenedLinux or some other privacy/security-centric distro, and can integrate with latest security and privacy techniques, making it Tor-friendly, etc.
See threads here and comments in fosspost.org blog post, and in Twitter feed:
Re: https://firmwaresecurity.com/2018/05/10/dont-buy-system76-hardware-and-expect-to-get-firmware-updates-from-the-lvfs/ this is the Sytem76 side of the story:
The Future of Firmware
LVFS and UpdateCapsule might be okay for companies mostly focused on a proprietary future (Logitech, Dell, etc.). UpdateCapsule is not the technique companies will use in a future of open source firmware—the future we’re working toward. Liberating firmware is going to be a long and challenging process. Much like Free Software has replaced proprietary software over time, we must chip away at the proprietary firmware pieces within the hardware supply chain. Manufacturing is the first step. This year we’ll manufacture open source desktop designs in our Denver plant. The CAD will be free to download, change, and produce. There will be a separate, open source electrical design and open source firmware daughter board to control functions within the desktop. On a mainboard there is the BIOS chip and one or more embedded controllers that manage fans, keyboard, LEDs, hotkeys and other critical functions. It’s all proprietary. Our strategy is to move this functionality from the proprietary mainboard to the open source daughter board. Then anyone can create a PCB with basic computer functionality, understand how it works, and improve upon the work. One could have this PCB made at Osh Park, install it in their desktop, tune it, and replace a bunch of proprietary firmware instantly. We’ll grow from there. Slowly we’ll chip away at more and more of the mainboard functions until what’s left is Intel and AMD bits. Then there’s the challenge of convincing them to go open. There’s room for cautious optimism.[…]
Who is working to fix (unify) Linux firmware solutions? UEFI Forum? Linux Foundation? I don’t see a single OEM (eg, System76) driving any such standardization. … 😦
This is a good example of how vendors have vendor-centric tools. Windows Update supports updating firmware, but most Windows OEMs don’t use it. LVFS supports updating firmware on Linux, but most Linux OEMs don’t use it. Sad for users. It seems a bit worse now that UEFI supposedly has a common interface to update firmware, there’s still a problem with UEFI firmware updates. 😦
tl;dr: Don’t buy System76 hardware and expect to get firmware updates from the LVFS
1) Linux Vendor Firmware Service launches
In a Phoronix article today, Michael Larabel describes the new Linux Vendor Firmware Service (LVFS) has been announced.
“This site provides a place for hardware vendors to submit packaged firmware updates, typically .cab files. This fire-and-forget service allows vendors to submit firmware updates without generating and hosting AppStream metadata themselves.”
2) Intel on Linux firmware updates
Brian Richardson posted a blog yesterday, with information on Linux fwupdate, UEFI Capsule (firmware updates), UEFI 2.5 ESRT, and the Fedora firmware update mechanism.