Linux OEMs: support is a Linux firmware update service, roughly like Windows Update, but for Linux.

It is nice to have a central place for firmware updates, so you don’t have to rely on the tools from a single OEM. Right now, most OEMs force you to use their firmware upedate tools. Windows OEMs mostly don’t bother to use Windows Update. And it looks like that problem is not OS-centric: Linux OEMs mostly don’t bother to use fwupd. However, many Linux vendors are not helping customers with firmware updates, look at second half of this page for all the vendors that suck:

It looks like Purism is heading toward supporting fwupd:

I am suprised that System76 is going their own route and not supporting fwupd, they claimed they were going to support it, but they’ve gone their own direction, sad.

Before you buy a system from a Linux OEM, ask them if they support fwupd for firmware updates. If they do not, ask them when they are going to support it.

fwupd and Linux Vendor Firmware Service

I haven’t been covering LVFS and fwupd much. Luckily, Michael Larabel of has been doing a good job. Richard Hughes has built a Firmware Update for GNOME-based Linux systems. Excerpting from some of Richard’s posts, including his asking for help getting word out to vendors to support it:

fwupd is a simple daemon to allow session software to update device firmware on your local machine. It’s designed for desktops, but this project is also usable on phones, tablets and on headless servers. You can either use a GUI software manager like GNOME Software to view and apply updates, the command-line tool or the system D-Bus interface directly.

I’ve spent the last couple of months talking with various Red Hat partners and other OpenHardware vendors that produce firmware updates. These include most of the laptop vendors that you know and love, along with a few more companies making very specialized hardware. We’ve now got a process, fwupd, that is capable of taking the packaged update and applying it to the hardware using various forms of upload mechanism. We’ve got a specification, AppStream, which is used to describe the updates and provide metadata for what firmware updates are available to be installed. What we were missing was to “close the circle” and provide a web service for small and medium size vendors to use to upload new firmware and make it available to Linux users. Microsoft already provides such a thing for vendors to use, and it’s part of the Microsoft Update service. From the vendors I’ve talked to, the majority don’t want to run any tools on their firmware to generate metadata. Most of them don’t even want to commit to hosting the metadata or firmware files in the same place forever, and with a couple of exceptions actually like the Microsoft Update model. I’ve created a simple web service that’s being called Linux Vendor Firmware Service (perhaps not the final name). You can see the site in action here, although it’s not terribly useful or exciting if you’re not a hardware vendor. If you are vendor that produces firmware and want an access key for the beta site, please let me know. All firmware uploaded will be transferred to the final site, although I’m still waiting to hear back from Red Hat legal about a longer version of the redistribution agreement.

Over the last couple of months I’ve been emailing various tech companies trying to get hold of the right people to implement this. So far the reaction from companies has been enthusiastic and apathetic in equal measures. I’ve had a few vendors testing the process, but I can’t share those names just yet as most companies have been testing with unreleased hardware. This is where you come in. On your Linux computer right now, think about what hardware you own that works in Linux that you know has user-flashable firmware? What about your BIOS, your mouse, or your USB3 hub? Your network card, your RAID card, or your video card? Things I want you to do:

* Find the vendor on the internet, and either raise a support case or send an email. Try and find a technical contact, not just some sales or marketing person
* Tell the vendor that you would like firmware updates when using Linux, and that you’re not able to update the firmware booting to Windows or OS-X
* Tell the vendor that you’re more likely to buy from them again if firmware updates work on Linux
* Inform the vendor about the LVFS project :

At all times I need you to be polite and courteous, after all we’re asking the vendor to spend time (money) on doing something extra for a small fraction of their userbase. Ignoring one email from me is easy, but getting tens or hundreds of support tickets about the same issue is a great way to get an issue escalated up to the people that can actually make changes. So please, spend 15 minutes opening a support ticket or sending an email to a vendor now.

If you know of any vendors, please try to help Richard out with his above request. I hope Richard has contacts at the USB and UEFI trade groups, to directly get word out to their member-vendors.

Preparing for Android firmware updates

Kris Carlon of AndroidPIT has written an article for end-users to help them prepare for a system update for their Android phones. Not bad advice to give to your non-technical friends:

On UEFI-based systems, like Intel-based Android-IA systems, I’d add:

  • save your ROM with before the update, and again after the update, booting LUV-live and using CHIPSEC.

For ARM-based systems, I wish that ARM had both AArch32 and AArch64 ports of CHIPSEC. Linaro may be porting CHIPSEC to AArch64 as part of LUV. But Linaro seems more focused on AArch64 these days, so AArch32 systems may not have security tools. For x86, there’re extensive bibliographies by LegbaCore and other security researchers on x86 BIOS/UEFI vulnerabilities, but I’ve hard a hard time finding a similar list of ARM vulnerabilities. I presume that’s because most are hidden behind iOS/Android-centric vulnerability, and other ARM-based embedded devices, with the various ARM vendor variations. If there was security data for ARM users to watch for, then the community could help ARM/Linaro with the CHIPSEC ports.

Hacking Team had other bootkits

Vlad Tsyrklevich wrote an excellent aritcle on the 0-day market via analyzing the Wikileak’ed Hacking Team emails:

Most have already read about the UEFI malware that it used, including this Intel ATR analysis:

Beyond this UEFI malware, Vlad’s analysis of the Wikileaks email revealed at least 2 other firmware exploits that Hacker Team appeared to have been using:

08/19/13,  ASUS BIOS device driver LPE, Firefox RCE added

02/24/14, “Apple iOS Remote Forced Access-Point Association”/“Apple iOS Remote Forced Firmware Update Avoidance” no longer available, OpenPAM (used on BSDs) LPE added

See Vlad’s blog for pointers to other email articles on these two entries.

I wish there was a list of former 0-days, at least the firmware subset… I also wish there was a safe place to download the “” and “Z5WE1X64.fd” files listed in the Intel ATR blog.

Apple Mac Mini EFI firmware update 1.8

As reported by Apple Support, and mentioned by Apple Insider and 9to5Mac news sites, Apple just released a firmware update for Mac Mini hardware for some models.

“This update is recommended for Mac mini (late 2012) models. This update addresses an issue that may prevent a USB keyboard from being recognized after the system wakes from sleep.”

I don’t know specifics of this release, and what security implications this has.

More Information:

Rasberry Pi firmware revised to use Linux 4.0

As reported by Michael Larabel in Phoronix, the Raspberry Pi firmware has been changed, it now uses the Linux 4.0 kernel.

As Michael says, “For this low-cost ARM single board computers, the newer kernel is beneficial for new features, file-system improvements, and new device support like when it comes to USB peripherals and adapters.”

More information:

UEFI 2.5 ESRT in Linux 4.2

One new feature in UEFI 2.5 is the ESRT (EFI System Resource Table). As reported in Phoronix, ESRT supports has been added to the Linux kernel, and it appears that it’ll be in Linux 4.2. Quoting Peter Jones’ ESRT patch to sysfs on the linux-efi list, describing ESRT:

“The EFI System Resource Table (ESRT) provides a read-only catalog of system components for which the system accepts firmware upgrades via UEFI’s “Capsule Update” feature.  This module allows userland utilities to evaluate what firmware updates can be applied to this system, and potentially arrange for those updates to occur. The ESRT is described as part of the UEFI specification, in version 2.5 which should be available from in early 2015.  If you’re a member of the UEFI Forum, information about its addition to the standard is available as UEFI Mantis 1090. For some hardware platforms, additional restrictions may be found at , and additional documentation may be found at .”

Peter’s patch adds sysfs files for the EFI System Resource Table (ESRT) under /sys/firmware/efi/esrt and for each EFI System Resource Entry under entries/ as a subdir. See the UEFI 2.5 specification for more details on ESRT.

More Information:

PC Advisor article on BIOS Updating for Windows users

Jim Martin wrote an article in PC Advisor earlier this week:

“How to update your BIOS: get the latest features and fixes for your PC and laptop.”

The article is a beginner’s introduction to how to update your BIOS, for Windows users. If you’re new to updating your BIOS, you might benefit from reading this!

More Information:


Fedora proposal for UEFI 2.5 Capsule Update support

As reported on Fedora devel-announce and on Softpedia, a proposal for Red Hat’s Fedora has been added to support UEFI Capuse Updates via UEFI 2.5’s ESRT.

“This adds the ability to perform updates of system firmware, as well as some peripheral firmware, on machines supporting the UEFI Capsule Update mechanism and UEFI 2.5’s “ESRT” feature. Right now this is generic support—the number of machines for which we actually have firmware updates available is very small, as the underlying technology is quite new—and it doesn’t include any actual delivery mechanism for such firmware images. But if they’re put at the right place for fwupd to notice them, and the system supports the right features, they’ll show up as updates in gnome-software.”

It will very be interesting to see how different distributions expose firmware updates to users.

More Information:


VZ on network usage of UEFI 2.5

Vincent Zimmer of Intel recently gave a presentation on use of UEFI 2.5 and Cloud-related issues. The talk was given at the Open Compute Project, and recently reprised at the Spring UEFI Forum event. The focus is UEFI-centric use of network booting, and firmware updates. This is a useful presentation to help understand one way UEFI uses it’s network stack.

More information: