Matthew Garrett ([personal profile] mjg59) wrote,
@ 2011-11-03 01:47 pm UTC
Entry tags:advogato, fedora
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.

(Read 13 comments) - (Post a new comment)
(Flat) (Top-level comments only)

HCL?


(Anonymous)
2011-11-03 09:32 pm UTC (link)
"Over time we'll find those bugs and fix them"

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?

(Reply to this)  (Thread) 


Re: HCL?


[identity profile] https://www.google.com/accounts/o8/id?id=AItOawkaVflVmnuDeXb2JNmEAK0RrZqFTHtylYs
2011-11-03 10:36 pm UTC (link)
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 hats
http://antitrust.slated.org/www.iowaconsumercase.org/011607/3000/PX03020.pdf

(Reply to this)  (Thread from start)  (Parent)  (Thread) 


Re: HCL?


(Anonymous)
2011-11-04 05:46 am UTC (link)
Your link shows Bill complaining that microsoft was bringing consistency to the hardware world that us nasty freeloaders were going to benefit from.

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.

(Reply to this)  (Thread from start)  (Parent) 


Re: HCL?


(Anonymous)
2011-11-09 08:10 am UTC (link)
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.

(Reply to this)  (Thread from start)  (Parent) 


(Read 13 comments) - (Post a new comment)
(Flat) (Top-level comments only)