I think I've ranted about this in HN before, but UEFI is so pointlessly complex. Modern OSes don't rely on the BIOS for basically anything. When choosing the successor to the old PC BIOS we could have made something extremely minimal.
Instead UEFI goes hard in the opposite direction. It's basically a full blown operating system with all the attendant complexity and, unsurprisingly, vulnerability surface.
How do you build a BIOS successor that's not complicated, when it has to be able to reflash bios from a file on a fat32 partition on a usb stick, because all the other historical ways of reflashing bios were difficult and more fragile? How do you build a BIOS successor that's not complicated when it needs to allow an OS to alter boot settings for the next boot?
Granted, most of what goes on in a BIOS is displaying and changing variables involved in getting the system running, and maintaining those values, which just requires some sort of minimal editing interface and nv storage, but then... users appear. They want to be able to use a mouse. They want an ability to configure their raid chipset prior to boot, or netboot, and HW makers want to implement that in a way that's not some arcane raw assembly dance between BIOS and additional chip FW. What then?
I don't think the complaint is about complexity, but about code quality and architecture. This isn't the only case where an old, simpler but less capable and annoying, system has been replaced by a much more complex system that is much hated and [initially] buggy and less secure, but also more or less gets the job done better than the old way, and where average users of the new system find it easier and more productive.
If there wasn't a case where a hardware manufacturer needed a capability prior to the OS taking over, or to modify their HW settings from the OS in a portable way, it wouldn't be in UEFI, right?
Calling UEFI a full operating system seems needlessly inflammatory. It's not a linux or windows kernel. It has to do a fair amount of the basics, but so does any kernel running on a general purpose chip and interfacing with a bunch of other people's code. UEFI is terrible. Baseband firmwares are terrible. Security processor firmwares are terrible. AMT is terrible. Okay, but we still need them.
My favourite pet peeves that i love to complain about (repeatedly):
- The GPT partition scheme inherited mixed-endianness UUID from Windows 3.1. Some people argue it does not qualify as mixed-endianness, but it is the struct from Windows 3.1 and its not evident from a printed UUID whether it is the Windows format or Big Endian as the standard says.
- Default file system for EFI is FAT, which was originally made for floppies and 8.3 filenames. Everything above 32MB and 11-byte filenames is hacked on top. There were a ton of competing, incompatible implementations until the Microsoft Extensible Firmware Initiative standardized it. FAT should deserve a long list on its own.
- EFI binaries are Windows PE executables, and PE executables are starting with the MS-DOS MZ header as introduced with MS-DOS 3 (or was it 2?). The "This program cannot be run in DOS mode" header.
From an osdev perspective, EFI is hideous. Good luck implementing that stuff for your own OS.
For secureboot: On one side i hope that Microsoft gets hacked and their EFI signing key leaked, on the other side i'm confident this has already happened.
> ...we could have made something extremely minimal. Instead UEFI goes hard in the opposite direction...
My initial suspicion was that this was about preparing the ground for closed computing regardless of the surrounding hardware.
That this hasn't happened suggests it's just my imagination gone wild, it's a missed opportunity for (say) Microsoft, or the folks behind it had good intentions. Occam's Razor, I guess?
> It's basically a full blown operating system with all the attendant complexity and, unsurprisingly, vulnerability surface.
By design. The UEFI is a gigantic NSA backdoor. I've got a bridge to sell to anyone who believes the NSA doesn't own the Microsoft UEFI signing keys, for a start.
Hopefully this will spur more research and visibility and unfortunately active exploits, but that would finally put pressure on oems to secure their firmwares. Or break up the damn covert cabal that’s the 3 major bios producers
At the very least I find it comforting that whenever I need to enter the bios on one of my thinkpad I get a snappy keyboard driven interface that barely changed in 30 years.
I'll take that anyday over that slow as hell mouse driven firmware horror Dell and HP have been producing for their servers and laptops.
> Or break up the damn covert cabal that’s the 3 major bios producers
I'm curious about that - why isn't there more competition, especially when everything you need to do it without them is easily available online? Like, not just specs, all the actual code you'd need is open source and AIUI friendly to use. Frankly, why aren't most motherboards shipping with lightly-patched coreboot+edk2?
paol|1 year ago
Instead UEFI goes hard in the opposite direction. It's basically a full blown operating system with all the attendant complexity and, unsurprisingly, vulnerability surface.
harshreality|1 year ago
Granted, most of what goes on in a BIOS is displaying and changing variables involved in getting the system running, and maintaining those values, which just requires some sort of minimal editing interface and nv storage, but then... users appear. They want to be able to use a mouse. They want an ability to configure their raid chipset prior to boot, or netboot, and HW makers want to implement that in a way that's not some arcane raw assembly dance between BIOS and additional chip FW. What then?
I don't think the complaint is about complexity, but about code quality and architecture. This isn't the only case where an old, simpler but less capable and annoying, system has been replaced by a much more complex system that is much hated and [initially] buggy and less secure, but also more or less gets the job done better than the old way, and where average users of the new system find it easier and more productive.
If there wasn't a case where a hardware manufacturer needed a capability prior to the OS taking over, or to modify their HW settings from the OS in a portable way, it wouldn't be in UEFI, right?
Calling UEFI a full operating system seems needlessly inflammatory. It's not a linux or windows kernel. It has to do a fair amount of the basics, but so does any kernel running on a general purpose chip and interfacing with a bunch of other people's code. UEFI is terrible. Baseband firmwares are terrible. Security processor firmwares are terrible. AMT is terrible. Okay, but we still need them.
blueflow|1 year ago
- The GPT partition scheme inherited mixed-endianness UUID from Windows 3.1. Some people argue it does not qualify as mixed-endianness, but it is the struct from Windows 3.1 and its not evident from a printed UUID whether it is the Windows format or Big Endian as the standard says.
- Default file system for EFI is FAT, which was originally made for floppies and 8.3 filenames. Everything above 32MB and 11-byte filenames is hacked on top. There were a ton of competing, incompatible implementations until the Microsoft Extensible Firmware Initiative standardized it. FAT should deserve a long list on its own.
- EFI binaries are Windows PE executables, and PE executables are starting with the MS-DOS MZ header as introduced with MS-DOS 3 (or was it 2?). The "This program cannot be run in DOS mode" header.
From an osdev perspective, EFI is hideous. Good luck implementing that stuff for your own OS.
For secureboot: On one side i hope that Microsoft gets hacked and their EFI signing key leaked, on the other side i'm confident this has already happened.
Antip0dean|1 year ago
My initial suspicion was that this was about preparing the ground for closed computing regardless of the surrounding hardware.
That this hasn't happened suggests it's just my imagination gone wild, it's a missed opportunity for (say) Microsoft, or the folks behind it had good intentions. Occam's Razor, I guess?
i80and|1 year ago
Which it seems like AMD is interested in from the slides in [1]
[1]: https://community.amd.com/t5/business/empowering-the-industr...
TacticalCoder|1 year ago
By design. The UEFI is a gigantic NSA backdoor. I've got a bridge to sell to anyone who believes the NSA doesn't own the Microsoft UEFI signing keys, for a start.
pjmlp|1 year ago
https://techcommunity.microsoft.com/t5/surface-it-pro-blog/r...
getcrunk|1 year ago
userbinator|1 year ago
prmoustache|1 year ago
I'll take that anyday over that slow as hell mouse driven firmware horror Dell and HP have been producing for their servers and laptops.
yjftsjthsd-h|1 year ago
I'm curious about that - why isn't there more competition, especially when everything you need to do it without them is easily available online? Like, not just specs, all the actual code you'd need is open source and AIUI friendly to use. Frankly, why aren't most motherboards shipping with lightly-patched coreboot+edk2?
iam-TJ|1 year ago
[0] https://github.com/hacking-support/DVUEFI/tree/main/docs/2-s...