Understanding the current state of UEFI
Nov. 3rd, 2011 01:47 pm
mjg59
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.
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.
Stale story
Date: 2011-11-03 07:35 pm (UTC)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.
Re: Stale story
Date: 2011-11-03 09:08 pm (UTC)Ohhhkaaayyy...then why were you bragging about just that the day after you made that post?
http://imgur.com/RnB1t
(screenshot of: https://plus.google.com/u/0/115750270177636397262#115750270177636397262/posts )
Yeah, but no, but yeah, but....?
Just stay down, buddy. Just stay down.
You're embarrassing yourself and the LoCo you lead.
Re: Stale story
Date: 2011-11-03 09:14 pm (UTC)Re: Stale story
Date: 2011-11-03 09:46 pm (UTC)http://www.youtube.com/watch?v=kA3WxjplKzo
HCL?
Date: 2011-11-03 09:32 pm (UTC)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?
Re: HCL?
Date: 2011-11-03 10:36 pm (UTC)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 hats
http://antitrust.slated.org/www.iowaconsumercase.org/011607/3000/PX03020.pdf
Re: HCL?
Date: 2011-11-04 05:46 am (UTC)A buggy firmware that misreports its state is not something microsoft wants anymore than we do. Or put another way, a buggy firmware is the exact opposite of what microsoft was trying to do.
Re: HCL?
Date: 2011-11-09 08:10 am (UTC)As a note to readers
Date: 2011-11-04 11:07 pm (UTC)LGA 1155, UEFI and me
Date: 2011-11-05 03:39 pm (UTC)How are the UEFI implementation on a typical ATX LGA 1155 motherboard by the likes of Asus or Asrock?
Simplicity is often a virtue.
Date: 2011-11-08 07:00 pm (UTC)"Complexity is the enemy of reliability" - Alan Robertson, HA Linux Project founder.
Have you been reading any of the recent scientific papers on cascading failure in tightly linked, highly complex infrastructure?
Re: Simplicity is often a virtue.
Date: 2011-11-08 07:07 pm (UTC)Re: Simplicity is often a virtue.
Date: 2011-11-08 08:35 pm (UTC)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.