The Unified Extensible Firmware Interface or UEFI is set to replace the basic input/output system (BIOS), the software that controls the hardware that is attached to the computer.

The move was intended to enhance security, but Matthew Garrett, a leading kernel developer believes that UEFI is bloated, buggy and even “awful” especially for Linux, just like what he said during the conference of Linux.conf.au 2012 at Ballarat. Codenamed Tiano, the UEFI reference implementation of Intel is where hardware vendors will base their UEFI implementations.

Tiano presently contains 7061 individual files which when summed up is a code of around 100 megabytes which is approximately 10 per cent of the entire size of the Linux kernel. Nevertheless, Tiano is still just the part of UEFI which is hardware-independent as it has no device drivers. When stripped out from the Linux kernel drivers, the remaining Linux piece which is device-independent is still smaller when compared to Tiano. Once compiled, a UEFI code could still be larger compared to many Linux kernels by “several megabytes.”

Garret told audience, “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.”

Accordingly, the UEFI implementations made by some vendors had very bad bugs that won’t even install Windows by means of UEFI, all the more Linux. “It indicates that nobody ever tested this code at all, ever,” added Garrett.

UEFI in secure boot mode also showed problems. In the UEFI specification, it is the hardware vendor or the platform owner who is in control of the master platform key (PK) which is used to sign software modules in the trusted mode. As a result, only one PK is available on any system leaving a possibility for problems once keys are revoked just like the hacking problems experienced by the RSA SecurID which happened in early 2011.

This is a bad situation for Linux developers as they have to allow kernels loading in unsigned modules as they can’t have the vendor’s PK sign every code. Garrett shared, “In a secure boot environment, if you have a signed kernel that loads unsigned modules, your signed kernel is effectively a signed malware loader.”

The operating system for Microsoft’s Windows gets around the problem as it has required signing of drivers for the past five years. Garrett mentioned, “Coincidentally, the UEFI-signing mechanism is completely identical to the Windows driver-signing mechanism — to the extent that the structure members start with ‘win’.”

Linux developers also can not result to building their own motherboards, become vendors and generate their own PKs as manufacturers are required (for the x86 Microsoft architecture) to allow users to disable UEFI secure boot so that they can add their own keys to the system which according to Garrett isn’t a particularly valuable solution saying, “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.”

UEFI however doesn’t specify which key format, naming convention or firmware interface they have to be in. Garrett shared, “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.”

“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’.”

When one turns off UEFI’s primary goals, which is secure booting, they defeat UEFI’s primary goals which is to make bootkit malware impossible.