Some years ago I bought myself a new laptop, deleted the windows partition and installed Fedora on the system. Only to later realize that the system had a bug that required a BIOS update to fix and that the only tool for doing such updates was available for Windows only. And while some tools and methods have been available from a subset of vendors, BIOS updates on Linux has always been somewhat of hit and miss situation. Well luckily it seems that we will finally get a proper solution to this problem.
Peter Jones, who is Red Hat’s representative to the UEFI working group and who is working on making sure we got everything needed to support this on Linux, approached me some time ago to let me know of the latest incoming update to the UEFI standard which provides a mechanism for doing BIOS updates. Which means that any system that supports UEFI 2.5 will in theory be one where we can initiate the BIOS update from Linux. So systems supporting this version of the UEFI specs is expected to become available through the course of this year and if you are lucky your hardware vendor might even provide a BIOS update bringing UEFI 2.5 support to your existing hardware, although you would of course need to do that one BIOS update in the old way.
So with Peter’s help we got hold of some prototype hardware from our friends at Intel which already got UEFI 2.5 support. This hardware is currently in the hands of Richard Hughes. Richard will be working on incorporating the use of this functionality into GNOME Software, so that you can do any needed BIOS updates through GNOME Software along with all your other software update needs.
Peter and Richard will as part of this be working to define a specification/guideline for hardware vendors for how they can make their BIOS updates available in a manner we can consume and automatically check for updates. We will try to align ourselves with the requirements from Microsoft in this area to allow the vendors to either use the exact same package for both Windows and Linux or at least only need small changes to them. We can hopefully get this specification up on freedesktop.org for wider consumption once its done.
I am also already speaking with a couple of hardware vendors to see if we can pilot this functionality with them, to both encourage them to support UEFI 2.5 as quickly as possible and also work with them to figure out the finer details of how to make the updates available in a easily consumable fashion.
Our hope here is that you eventually can get almost any hardware and know that if you ever need a BIOS update you can just fire up Software and it will tell you what if any BIOS updates are available for your hardware, and then let you download and install them. For people running Fedora servers we have had some initial discussions about doing BIOS updates through Cockpit, in addition of course to the command line tools that Peter is writing for this.
I mentioned in an earlier blog post that one of our goals with the Fedora Workstation is to drain the swamp in terms of fixing the real issues making using a Linux desktop challenging, well this is another piece of that puzzle and I am really glad we had Peter working with the UEFI standards group to ensure the final specification was useful also for Linux users.
Anyway as soon as I got some data on concrete hardware that will support this I will make sure to let you know.
Any plans to integrate BIOS release notes into the upgrade view? Many vendors do provide such release notes.
And to implement it, it’s necessary to sign an agreement (at http://uefi.org/specifications) with the UEFI Forum that they may reject or later terminate at any time (with 30 days notice).
Does it make sense to implement some kind of BIOS integrity check in this context? I mean to readout the currently installed BIOS and compare its hash to some cryptographically secured vendor supplied hash, to identify unautorized BIOS tampering?
Such checks are part of the UEFI standard
Well, and what about Coreboot and Libreboot?
Coreboot: http://coreboot.org
Libreboot: http://libreboot.org
This work has no impact or relation to the viability of either using coreboot or libreboot. Of course the UI design done for the installer can be re-used for any kind of BIOS update.
I bet this won´t help with Intel Boot Guard or does it?
Can you bring up this topic with Intel and hardware vendors as well? Locking the BIOS to a fixed hash sum just makes Coreboot unusable on machines with Haswell or newer processeres that use Intel Boot Guard. As far as I read there is a mode of Intel Boot Guard where the hardware can just provide the checksum for checking it later in the software stack instead of enforcing it right away, maybe hardware vendor´s can offer this.
So will this be a way to integrate coreboot into machines too?
It may go without saying, but please make sure no firmware update happens without user consent. Users may want to keep their old version (for example because they are afraid the new BIOS fixes some broken antifeature and the users think the machine they bought it’s theirs, or because they spent months getting libreboot to work in the host and don’t want it erased by a vendor whim).
If they’d simply open up hardware information and/or send patches to flashrom it wouldn’t be necessary to go through specifications and silly agreements to simply flash an EEPROM. And if firmware could stick to the minimal functions it should do, then it wouldn’t need upgrading so often…