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

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 of uncertainty about the UEFI Secure Boot/Linux situation). [1] - [link]

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]

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 provided in the official UEFI sample implementation, and most can be arguably called worse then an average BIOS interface. However, you have to acknowledge the capability is there. 5. It added a framework for kernel verification (unlike what some people think, it only verifies the UEFI firmware and the kernel/boot loader it loads directly). The direction that Microsoft is taking it is quite unfortunate, but it's actually a good feature. 6. It has a limited capability as a boot loader, allowing multiple operating systems to be started directly. These are all features that aren't present in the BIOS, that UEFI has fixed. Unfortunately the current implementation has many bugs, and many features are arguably implemented badly. However is was created to fix real problems, and has been undeniably succe

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] [this video]