Is Unified Extensible Firmware Interface a Threat to Non-Windows Operating Systems?
When you power on a computer, a subsystem based on firmware is initially in control. This firmware initializes and tests some system hardware components, then finds, loads, and starts a boot loader. The boot loader in turn finds, loads, and starts the operating system's monolithic kernel. The operating system can directly access the hardware, so the firmware is no longer in control. A monolithic kernel may load additional drivers as needed, once it finds the media where those drivers are stored.
The IBM Personal Computer model 5150 design released in August 1981 used a BIOS or Basic Input/Output System firmware. Within a year the BIOS had been reverse engineered, allowing Columbia Data Products to release their IBM-PC compatible computer in June 1982.
Hewlett-Packard and Intel began working on more capable firmware for the Itanium systems in the mid 1990s. Version 2.1 of the Unified Extensible Firmware Interface or UEFI, a much more capable firmware system, was released in January 2007. It has support for Secure Boot, the capability to restrict the system to cryptographically signed operating systems.
Since 2010 the computer industry has been moving toward UEFI because Microsoft would not approve a platform for Windows 8 unless it supports Secure Boot. See my details on how Linux boots for far more on how UEFI works and how it differs from BIOS. The question here is: Does UEFI represent a threat to Linux by allowing Microsoft or other manufacturers to use the Secure Boot mechanism to prevent Linux from running on commonly available hardware?
Steven Sinofsky's blog entry on UEFI summarizes itself nicely. But to summarize it even further while including some criticism of Original Equipment Manufacturer (OEM) behavior:
- UEFI empowers firmware to implement a security policy.
- Secure Boot is a UEFI protocol used by Windows 8 and later, it is not a Windows feature.
- Secure Boot does not lock out non-Windows boot loaders, if those boot loaders can get the needed cryptographic keys.
- Microsoft requires that a platform support Secure Boot, but they have also required that the owner must be able to disable Secure Boot. (or at least that's the case for Intel/AMD systems, Microsoft only approves ARM based systems on which the owner cannot disable Secure Boot)
- Microsoft doesn't really control OEM firmware which could lock out non-approved boot loaders, but some OEMs may be complete tools and do that on their own.
See UEFI boot: how does that actually work, then? for a great explanation of what UEFI is and is not.
Update: At the WinHEC conference in China in March 2015, Microsoft announced that with Windows 10 the ability for the owner to disable Secure Boot will only be optional. Major distributions will use the Verisign-provided signatures, and this will likely be more of an issue with brand-name complete PCs (HP, Dell, Lenovo, etc) rather than with bare motherboards.
UEFI and OEMs
Support for UEFI and the associated GUID Partition Table or GPT has been supported for some time on a variety of operating systems.
Linux has supported UEFI since early 2000 using
elilo and, more recently, EFI versions of GRUB.
HP-UX has used UEFI on IA-64 systems since 2002.
HP OpenVMS has used UEFI on IA-64 systems since December 2003.
Apple OS X uses UEFI on Intel based hardware.
Microsoft supports UEFI since: Windows 2000 on Itanium since 2002, Windows Server 2003 on IA-64, Windows XP in IA-64, Windows Server 2008 on x86-64, and Windows Vista SP1 on x86-64.
Anti-Malware for UEFI
Kaspersky Lab released the world's first anti-malware product for UEFI in April of 2013. It can scan selected system files and memory addresses before the operating system starts to be loaded.
Booting Linux on UEFI with Secure Boot
Click here for
much more on
Linux booting with
and without UEFI
There are various methods to boot Linux with Secure Boot. Shim is a pre-compiled signed bootloader allowing the user to individually trust keys provided by distributors. The relevant philosophy here is that the point of UEFI and Secure Boot is to secure the pre-boot environment. The kernel itself secures the post-boot environment seen by the user.
Ubuntu started using Shim at version 12.10, using Canonical's key that verifies the bootloader only and allows loading unsigned kernels.
Red Hat's Fedora uses Shim, although it requires that the kernel and its modules be signed in addition to the boot loader.
The UEFI specifications do not require that the operating system kernel be signed, although Microsoft claims that their certification requirements do. By the spring of 2013 a Spanish software development group had filed a formal complaint with the European Commission, saying that Microsoft's requirements on OEM systems were obstructive and anti-competitive. Linus Torvalds filed a far less formal complaint over Red Hat's threatened caving in to Microsoft's demands. But it gets worse...
OEMs Behaving Badly
Lenovo shipped systems with firmware hard-coded to only boot "Windows Boot Manager" or "Red Hat Enterprise Linux", regardless of their secure boot settings or whether the desired operating system was a signed Linux distribution or not.
Toshiba shipped some laptops which would be bricked if you tried to install a Linux distribution with UEFI enabled.
Absolute Software's Computrace can install from BIOS without user permission. As far as Kaspersky Labs knows, there aren't EFI firmware or BIOS optional ROMs with executables for non-Windows platforms. Their full research paper has the details.