Untested buggy UEFI heads for prime-time
BIOS, the archaic firmware that sits between a computer's hardware and the operating system, is set to be replaced by the Unified Extensible Firmware Interface (UEFI). The move is intended to improve security, but a leading kernel developer says UEFI is "awful" for Linux.
Matthew Garrett
(Credit: Stilgherrian/ZDNet Australia)
Red Hat's Matthew Garrett, speaking at the Linux.conf.au 2012 (LCA) conference in Ballarat last week, also believes that Intel's UEFI reference implementation, codenamed Tiano and upon which hardware vendors' UEFI implementations will be based, is bloated and buggy.
Tiano now consists of 7061 individual files totalling around 100 megabytes of code. That's roughly 10 per cent of the size of the entire Linux kernel.
However, Tiano is only the hardware-independent part of UEFI. It contains no device drivers. If you strip out the drivers from the Linux kernel, the device-independent remainder is smaller than Tiano. Compiled UEFI code may be "several megabytes", which is larger than many Linux kernels.
"Files contain code, [and] code, as we all know, contains bugs. Always. So from this we can conclude that UEFI contains bugs. This shouldn't surprise anyone, other than the Linux kernel which obviously contains no bugs at all ever," said Garrett, to audience laughter.
Some vendors' UEFI implementations have bugs that are so bad that they won't even install Windows via UEFI, let alone Linux.
"It indicates that nobody ever tested this code at all, ever," Garrett said.
UEFI's secure boot mode also presents problems.
According to the UEFI specification, the master platform key (PK) used to sign software modules as being trusted is under the control of the platform owner, which has subsequently been clarified as meaning the hardware vendor.
As a result, there's only one PK on any system — which means problems when keys must be revoked because hackers have compromised them. A similar problem was at the heart of the RSA SecurID hack in early 2011.
It also means that Linux developers, who can't have every code change signed by the vendor's PK, must allow the kernel to load unsigned modules.
"In a secure boot environment, if you have a signed kernel that loads unsigned modules, your signed kernel is effectively a signed malware loader," Garrett said.
Microsoft's Windows operating system gets around this problem because the company has already been requiring driver signing for the past five years.
"Coincidentally, the UEFI-signing mechanism is completely identical to the Windows driver-signing mechanism — to the extent that the structure members start with 'win'," Garrett said.
So is the only solution for Linux developers to build their own motherboards and as a result become vendors so they can generate their own PKs?
No, because at least for the x86 architecture Microsoft now requires manufacturers to allow the user to disable UEFI secure boot in order to add their own keys to the system.
Garrett doesn't see this as a particularly useful solution.
"It's fine for enthusiasts. If you're happy to be going into your firmware and changing options, that's great. You'll be able to do this," he said.
But UEFI doesn't specify the format the keys have to be in, nor the naming convention or the firmware's under interface.
"A vendor could require that [the keys] be in ROT-13 Base-64 ... To get into secure boot [and disable it] you need to get into your firmware, which requires you to hit a key on your keyboard, we're not sure which," Garrett said.
"Once you've done that and got into your firmware you're then going to need to find a menu which might be called 'Security', which might be called 'Boot', which might be called 'Advanced', which might be called 'Beware of the leopard'."
And apart form that, turning off secure boot defeats one of UEFI's primary goals: making bootkit malware impossible.