Matthew Garrett

Understanding the current state of UEFI

This story has been floating around for a week or so. The summary is that someone bought a system that has UEFI and is having trouble installing Linux on it. In itself, not a problem. But various people have either conflated this with the secure boot issue or suggested that UEFI is a fundamentally anti-Linux technology.

Right now there are no machines shipping to the public with secure boot enabled. None at all. If you're having problems installing Linux on a machine with UEFI then it's not because of secure boot. So what is actually causing the problem?

UEFI is a complicated specification, with 2.3.1A being 2214 pages long. It's a large body of code. There's a lot of subtleties. It's very easy for people to get things wrong. For example, we've seen issues where calling SetVirtualAddressMap() resulted in the firmware referencing boot services code, a clear violation of the spec on the firmware authors' part. We've also found machines that failed to boot because grub wasn't aligning its stack properly, a clear violation of the spec on our part.

Software is difficult. People make mistakes. When something mysteriously fails to work the immediate assumption should be that you've found a bug, not a conspiracy. Over time we'll find those bugs and fix them, but until then just treat UEFI boot failures like any other bug - annoying, but not malicious.

The blog post was never intended to become anything close to viral but instead was just a share on the topic. The person who shared the problem suggest I share it so that he could get helped and luckily that is so far what is resulting since he has connected with the right people through our Ubuntu Oregon LoCo mailing list.

There is no doubt that this was likely a bug although even still from the continued conversation occurring on the mailing list it seems very trivial as to whether it is a Ubuntu bug or something wrong with the UEFI firmware.

I was not bragging about that link bringing traffic but instead traffic in general... In fact the Hacker News traffic was from my post on Occupy Wall Street and a good portion of the other traffic was likely revolving traffic for Netflix on Linux searches.

There's a few days discrepancy between posts (UEFI post made on the 23rd and previous one made on the 20th) you're not accounting for and it clearly shows that the traffic stats were for the morning of the 24th. We could do this all day, but this is Matthews blog and I will now stop cluttering it. Before I go though, this is relevant:http://www.youtube.com/watch?v=kA3WxjplKzo

I don't doubt that. But will the vendors do their part and fix their bugs as well? Most vendors' track records are less than stellar to say the least. There are numerous issues with ACPI and ASPM under Linux, and occasionally I still encounter EHCI issues where the same hardware works fine under Windows (device not accepting address, etc).

Phoronix has announced plans for a hardware compatibility list, and I know that several HCLs have been published for Linux before. Do you know of any plans for a centralized body concerning UEFI Linux compatibility?

Lots of that ACPI incompatibility isn't stupidity on the behalf of the vendors is "non-aggressive" linux lock-out.

Take Toshiba for example. Most of their recent laptops have an ACPI "bug" where the fans are reported as always being on. This causes no end of overheat hell for me. I decompiled, fixed and then loaded a patched DSDT table into mine to fix this. From what I can tell Windows just ignores the current state and toggles the fans as it sees fit.

Anyway here is a link for those who haven't seen it to prove I'm not wearing tin-foil hatshttp://antitrust.slated.org/www.iowaconsumercase.org/011607/3000/PX03020.pdf

Having worked with BIOS vendors: yes, they do fix bugs when identified, quite happily even, while a BIOS remains in development. Once a BIOS gets released, though, they go into "any change might cause a regression or otherwise break something" mode, and only accept critical bugfixes.

As a note to readers - we worked rather harder on EFI compatibility in Fedora 16 and got testing on a wider range of systems than we have before, so F16 should be doing better than previous releases on EFI systems. We have quite a lot of successful test installs on EFI Macs, even, which have always been problematic in the past.

If you want to argue that UEFI is overdesigned, fragile and inherently full of bugs then I'm not going to disagree with you. On the other hand, BIOS is underdesigned, fragile and inherently full of bugs. All firmware sucks.

I'm not going to disagree with you either! I think you've very accurately described the current situation.

I'm reminded of the way that DAP was a reaction to the lame crap that was computerized directory lookup, and LDAP was a reaction to the hideous complexity of DAP. Maybe what we need is to nail down an optimally useful subset of EFI, disposing of inherently bad ideas like filesystem drivers in firmware... LUEFI p'raps? Course, that just invokes xkcd (http://xkcd.com/927/). But it worked for LDAP.

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Nebula. Member of the Linux Foundation Technical Advisory Board. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.