EFI and Linux: the future is here, and it's awful - Matthew Garrett

What people said

forgottenpass · 2013-11 · Recommendation

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 [VIDEO]

Read the original HN comment ↗

pserwylo · 2012-11 · Recommendation

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] - [VIDEO] (Keep in mind this was in January, when there was still a lot of uncertainty about the UEFI Secure Boot/Linux situation). [1] - [LINK]

Read the original HN comment ↗

sedachv · 2017-07 · Reference

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 "security" functionality is an unworkable side-effect that provides a convenient fiction to accomplish that goal. [1] [LINK] [2] [VIDEO]

Read the original HN comment ↗