There’s a popular Reddit going on about UEFI and Linux:
which I noticed on Matthew Garrett’s blog, which also has some good insight on the topic:
http://mjg59.dreamwidth.org/35110.html
The Reddit author is complaining to Intel and Microsoft about the bloat of UEFI compared to a minimal boot loader, and the need for Coreboot, and how Linux doesn’t need most of this bloat.
“Unfortunately this means that it’s extremely complicated and big. The firmware is now as big and complicated as a full-fledged OS.”
Actually, UEFI *is* an OS, not just a firmware/boot loader like Coreboot or BIOS. UEFI is a complex OS, with dozens of driver models. The original IBM PC had BIOS, and was useless without MS-DOS (or another OS). Modern UEFI-based systems have no need for BIOS, the UEFI driver models replace BIOS OptionROMs, and UEFI can be either an OS or a firmware loader, depending on how used. UEFI systems don’t need an additional OS — Windows, Linux, etc. — to be installed. The UEFI OS is about as useful as MS-DOS 2.0, a shell, about 80 commands, a handful (edit, hexedit) of full-screen ‘curses’-like. Tweaking the shell to run your embedded app, there’s no need for the bloat of an additional OS.
“Complicated and big is bad. This means more bugs. Some bugs are security bugs so more bugs means more security holes. Also it’s generally proprietary so you have different groups of people trying to write the same thing from scratch so they can inject their ‘secret sauce’. So now not only you have something that is big and buggy, but also has lots of different sets of unique bugs.”
“Also it allows for a lot of fancy new ways to manage your hardware independently of the OS. Which while often convenient it is also going to be full of bugs and is proprietary. Which is going to be especially bad when the UEFI stuff allows for remote configuration and will piggy back on your network interfaces and doesn’t go away completely when the real OS is loaded.”
Small is nice. Secure is also nice. Modern BIOS have to deal with NIST and NSA/IAD guidelines for secure BIOS, and how that drives some sales. ..which Microsoft uses well to get SecureBoot into most systems. Google has taken barebones Coreboot and made is much more complex, in the name of security, when adding SecureBoot-like PKI features in Chromium. Large servers are more complex w/r/t updating firmware, and have various ‘pre-OS’ apps (iLO, IPMI, etc.) all of which were designed for some business need (hopefully beyond merely to sell hardware), and IPMI is ripe with security issues. UEFI attempts to deal with this, I’m not sure how Coreboot deals with or ignores this reality.
UEFI is well-entrenched in the PC world, used by Apple and Microsoft and Intel, and Windows OEMs do whatever Microsoft says. I don’t see future with a non-UEFI solution for Intel-based Windows OEMs. An alternate route for Linux OS users may be to focus on Chrome OEMs, which use Coreboot. Or to focus on AMD systems, which also use Coreboot. Or to focus on ARM systems, which use either U-Boot or UEFI, the latter mostly for business reasons not technical reasons, AFAICT.
Linux OEMs could select Coreboot. Linux OEMs could build UEFI using Coreboot as it’s PI layer, reducing a bit of UEFI complexity with Coreboot. Linux OEMs could use UEFI properly, without MSFT CA or keys, using SecureBoot to secure Linux, without begging Microsoft for permission to secure non-Windows OSes on WindowsPCs — Intel and SuSE demonstrated this at IDF in 2013, yet I’ve not seen a single Linux consumer device made by OEMs for Linux users. Last time I talked to a Linux OEM, a few weeks ago, they liked UEFI, since SecureBoot scared their Linux-centric customers to legacy BIOS systems, and the OEM was too lazy to work with Sage Engineering to reduce the number of blobs in their code and add Coreboot support to their units. Linux OEMs are not that bright. Neither are Windows OEMs, but Microsoft tells them what to do, there is nobody telling Linux OEMs what to do. Where is the Linux Foundation, offering leadership in this area?
Firmware Security 