EFI and Linux: the future is here, and it's awful - Matthew Garrett
Why Hacker News recommends it
Pointed to as an entertaining, informative explanation of why UEFI is troublesome, from a Linux UEFI developer.
What it is
Matthew Garrett's linux.conf.au 2012 talk covers EFI and UEFI from the Linux point of view: why the PC BIOS was bad, what EFI changes, the issues it brings, and Secure Boot.
Recommended by 2 HN commenters across 2 different months, 2012 to 2017.
What Hacker News said
Recommends pserwylo · 2012-11 · on “More in the series of bizarre UEFI bugs”
Matthew gave an awesome talk on UEFI at linux.conf.au 2012 [0]. A thoroughly entertaining and informative talk on issues including secure boot, but also other issues with UEFI. It even got voted one of the best four talks at the conference, so he did the talk again at the end of the conference. This was great because I missed it the first time. My favourite quote from the talk was: "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." [1]. [0] - [this video] (Keep in mind this was in January, when there was still a lot o
Recommends forgottenpass · 2013-11 · on “Booting to Rust”
EFI even talks FAT and there exists licensing such that you can use FAT for EFI reasons without any patent worries. I'm not saying that's a bad decision, just pointing out it is another thing that happened. I heard that fact in a linux.conf.au talk by the guy what did UEFI work for linux [0]. If you're sad to hear about the Microsoft influence, dude isn't too hot on the implementation of this new standard in general. Interesting talk though, digging up the link to post it here means I'm going to give it another watch. [0] EFI and Linux: the future is here, and it's awful - Matthew Garrett [this video]
Cites keeperofdakeys · 2013-01 · on “Booting Linux using UEFI can brick Samsung laptops”
Sorry, but the BIOS had many issues, and UEFI provided a solution to them, even if it wasn't an inherently good system. 1.The BIOS isn't portable, you can compile UEFI for any platform by porting a small base module. Everything uses this module, so the compiler will take care of the rest. 2. BIOS was a heap of 16bit assembly code, with a small memory space. It was quite hard to add any kind of complex functionality. 3. You couldn't use a boot volume greater than 2TB due to MBR. A new one wasn't added because of number 2. 4. UEFI is more like a micro kernel then a generic BIOS, and provides the functionality for vendors to write 'better' interfaces. Here the interfaces aren't actually provide
Cites dlitz · 2016-08 · on “A x64 OS #1: UEFI”
Yeah, Matthew Garrett also gave a pretty detailed talk about it Linux.conf.au 2012, which reaches a similar conclusion: [this video]
Cites sedachv · 2017-07 · on “Windows 10 will use protected folders to thwart crypto ransomware”
You can get around UEFI Secure Boot by installing an old signed bootloader with known exploits (if I understand correctly this is why the "Secure Golden Key Boot" exploit of last year[1] cannot be patched without changing public keys in the UEFI firmware). Not only that, the code that is shared by most UEFI implementations is garbage[2] with a large attack surface; exploits against the firmware is a possibility. The primary function of UEFI Secure Boot is for Microsoft to prevent other operating systems from being installed on as many systems as they can get away with (right now there is no provision that end users should be allowed to disable Secure Boot on ARM devices, for example). The "s