Damn Vulnerable UEFI(github.com)
github.com
Damn Vulnerable UEFI
https://github.com/hacking-support/DVUEFI
44 comments
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.
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.
> 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?
It doesn't need to do this at all. Just make the flash accessible to the OS and have the OS do it. Machines without an OS can be booted into a live image. Put a write-protect jumper on the system board if you like.
> 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?
You give the OS access to the flash and then document what the bits do so the OS knows what to change.
> 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?
Limit the firmware UI to extremely basic settings like "restore factory defaults" and "choose boot device", none of which need a mouse. Boot an OS to do anything more complicated.
> UEFI is terrible. Baseband firmwares are terrible. Security processor firmwares are terrible. AMT is terrible. Okay, but we still need them.
The reason these are all terrible is that they're supplied by the OEM. Delete all of them and replace them with hardware documentation that allows anyone to write their own. Ship the machine with an open source reference implementation that most people will never have to change unless it's terrible, in which case the 0.1% of the users that care will fix it and you can incorporate the fix into the reference implementation.
It doesn't need to do this at all. Just make the flash accessible to the OS and have the OS do it. Machines without an OS can be booted into a live image. Put a write-protect jumper on the system board if you like.
> 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?
You give the OS access to the flash and then document what the bits do so the OS knows what to change.
> 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?
Limit the firmware UI to extremely basic settings like "restore factory defaults" and "choose boot device", none of which need a mouse. Boot an OS to do anything more complicated.
> UEFI is terrible. Baseband firmwares are terrible. Security processor firmwares are terrible. AMT is terrible. Okay, but we still need them.
The reason these are all terrible is that they're supplied by the OEM. Delete all of them and replace them with hardware documentation that allows anyone to write their own. Ship the machine with an open source reference implementation that most people will never have to change unless it's terrible, in which case the 0.1% of the users that care will fix it and you can incorporate the fix into the reference implementation.
> none of which need a mouse
Heh, I'm having flashbacks to a time repairing a computer where the BIOS/UEFI simply wouldn't work work with the regular keyboard, even though the regular OS supported it just fine.
So I had to go dig up a PS/2 one just to change settings.
Heh, I'm having flashbacks to a time repairing a computer where the BIOS/UEFI simply wouldn't work work with the regular keyboard, even though the regular OS supported it just fine.
So I had to go dig up a PS/2 one just to change settings.
Absolutely this.
Not sure which article that complained about EFI mentioned that PNG parser was vulnerable... and... there's no reason for EFI to have a PNG parser really. It's a fancy stuff that could've been totally avoided. And yet, here we go...
Not sure which article that complained about EFI mentioned that PNG parser was vulnerable... and... there's no reason for EFI to have a PNG parser really. It's a fancy stuff that could've been totally avoided. And yet, here we go...
And it is an optional thing you don't need to have or use, but some people like graphical logos or even animated logos so there you go...
> It doesn't need to do this at all. Just make the flash accessible to the OS and have the OS do it.
I fear this would lead to vendors only implementing proprietary, Windows-only, firmware update software. UEFI-based updates and "UEFI capsules" are better than a Windows-only world, even if UEFI is not necessarily the best thing ever.
I fear this would lead to vendors only implementing proprietary, Windows-only, firmware update software. UEFI-based updates and "UEFI capsules" are better than a Windows-only world, even if UEFI is not necessarily the best thing ever.
And when you don't have an OS because you need to update the flash first?
The flash updater IS the OS.
You don't need to update the flash to boot an OS capable of updating the flash. The firmware it comes with can do that and if you've irrecoverably installed broken firmware then you've bricked your machine regardless.
No, we don't need them. Look at the OpenWRT ecosystem and the routers it runs on. Those cheap plastic routers come with pretty dumb bootloaders and it works.
Its just the x86 platform that is shite.
Its just the x86 platform that is shite.
However each OpenWRT router also has its own custom bootloader AFAIK. This is why you need different images for different devices, and can't create a single image for everything. UEFI on the other hand you just build one image and it works everywhere.
> UEFI on the other hand you just build one image and it works everywhere.
Thats the theory. Practice looks like that: https://lore.kernel.org/linux-efi/20200907170021.GA2284449@r...
If Vendors couldn't get the BIOS consistently right in the 80ies, why would they get UEFI consistently right now?
Thats the theory. Practice looks like that: https://lore.kernel.org/linux-efi/20200907170021.GA2284449@r...
If Vendors couldn't get the BIOS consistently right in the 80ies, why would they get UEFI consistently right now?
Yes, UEFI is messy, not saying you will never have issues. But on the other hand, in OpenWRT you literally need to build an image for each device, something that you (almost) never have to do with UEFI or BIOS. Or when was the last time you had to build a specific image for a x86_64 laptop? If this happened to you, I am curious, this would probably make a nice blog post.
By the way, I am not saying that UEFI is not complicated, but there is probably a middle ground between "we need to build a specific image for this device because its bootloader is dumb" and "we have a f* operational system as a bootloader that works everywhere but is full of holes".
By the way, I am not saying that UEFI is not complicated, but there is probably a middle ground between "we need to build a specific image for this device because its bootloader is dumb" and "we have a f* operational system as a bootloader that works everywhere but is full of holes".
> Or when was the last time you had to build a specific image for a x86_64 laptop?
iwlwifi firmware blobs..
iwlwifi firmware blobs..
That's partly because nesrly nobody, including Linux vendors, actually pushes or checks for parameters being passed from BootVar to executable. Just like barely anyone apparently supports BootVar hotkeys.
Nobody uses it so nobody actually bothers with it, and even Linux defsulted to storing the params in files or kernel itself because good luck finding out you can put them in BootVar at all.
It's still miles better than it was with BIOS, or even Unix workstations (including OpenFirmware ones) with their "emergency releases" of updated OS just to make it boot on new gear
Nobody uses it so nobody actually bothers with it, and even Linux defsulted to storing the params in files or kernel itself because good luck finding out you can put them in BootVar at all.
It's still miles better than it was with BIOS, or even Unix workstations (including OpenFirmware ones) with their "emergency releases" of updated OS just to make it boot on new gear
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.
- 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?
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?
TL;DR UEFI builds an open platform even if the actual code is closed, while "simple" alternatives make closed platforms with open source code.
Raw coreboot/uboot like approaches give you open source but closed platform - the simplicity means you need considerable resources to do something else than the original maker wanted to do with it.
UEFI (and before it, Microsoft attempts at semi-standardizing PC low level interfaces, effort on ACPI, etc) are an effort to provide an open platform no matter the opennes of code, availability of deep dive docs of individual computer models, and handling the fact that computers arez in fact, complex.
If you want a general purpose computer that explicitly targets the idea that it's owner can just plug in CD/USB/netboot a windows/Linux/BSD installer media, without waiting for new release just to have a bootable kernel on s new machine, there's s lot of inherent complexity. Especially if you want to be able to boot a version from before release of the board you're using without significant loss of functionality (something that devicetree cannot do without special explicit work from physical device vendor, but is handled by ACPI through bytecode and _OSI checks for supported capability levels from OS).
Especially if you also want to make it extensible and reduce cost in integrating parts from different vendors (aka why UEFI with hardcoded CSM boot started taking over by 2005).
It's much easier not just to integrate a third party driver for example for network chip when the driver will use well defined interfaces instead of hooking into "boot BASIC from ROM" interrupt, especially when the driver can then expose it's configuration in standard format that will work no matter if you have monitor and mouse connected or just serial port. Petitboot is not the answer - it's way worse when you have to custom rebuild system firmware to add drivers (possibly removing other drivers to make space) because you want to netboot from a network card from different vendor, or just because the hardware is still good but the NIC is younger. Much easier to just grab driver from OpRom or worst case drop it in standardised firmware-accessible partition.
Did I mention how much easier handling booting with UEFI is compared to unholy mess of most other systems? Yes, even GRUB on x86, which by default doesn't write standard compliant boot code so if you dual boot and use certain software packages you end up with nonbootable system. Or how many Linux installers and guides make partitions that only boot because of bug-compatibility in many BIOSes. Not to mention messing with bootsectors Vs "if you drop a compatible filesystem with a file named this way* it will be used for booting".
If I want to play around with booting a late 1960s design where you need to patch binaries if you change something in hardware, I can boot a PDP-10 emulator instead. I push for using UEFI properly because I have work to do and goals to achieve other than tinkering with booting, no matter how much I like tinkering in general
Raw coreboot/uboot like approaches give you open source but closed platform - the simplicity means you need considerable resources to do something else than the original maker wanted to do with it.
UEFI (and before it, Microsoft attempts at semi-standardizing PC low level interfaces, effort on ACPI, etc) are an effort to provide an open platform no matter the opennes of code, availability of deep dive docs of individual computer models, and handling the fact that computers arez in fact, complex.
If you want a general purpose computer that explicitly targets the idea that it's owner can just plug in CD/USB/netboot a windows/Linux/BSD installer media, without waiting for new release just to have a bootable kernel on s new machine, there's s lot of inherent complexity. Especially if you want to be able to boot a version from before release of the board you're using without significant loss of functionality (something that devicetree cannot do without special explicit work from physical device vendor, but is handled by ACPI through bytecode and _OSI checks for supported capability levels from OS).
Especially if you also want to make it extensible and reduce cost in integrating parts from different vendors (aka why UEFI with hardcoded CSM boot started taking over by 2005).
It's much easier not just to integrate a third party driver for example for network chip when the driver will use well defined interfaces instead of hooking into "boot BASIC from ROM" interrupt, especially when the driver can then expose it's configuration in standard format that will work no matter if you have monitor and mouse connected or just serial port. Petitboot is not the answer - it's way worse when you have to custom rebuild system firmware to add drivers (possibly removing other drivers to make space) because you want to netboot from a network card from different vendor, or just because the hardware is still good but the NIC is younger. Much easier to just grab driver from OpRom or worst case drop it in standardised firmware-accessible partition.
Did I mention how much easier handling booting with UEFI is compared to unholy mess of most other systems? Yes, even GRUB on x86, which by default doesn't write standard compliant boot code so if you dual boot and use certain software packages you end up with nonbootable system. Or how many Linux installers and guides make partitions that only boot because of bug-compatibility in many BIOSes. Not to mention messing with bootsectors Vs "if you drop a compatible filesystem with a file named this way* it will be used for booting".
If I want to play around with booting a late 1960s design where you need to patch binaries if you change something in hardware, I can boot a PDP-10 emulator instead. I push for using UEFI properly because I have work to do and goals to achieve other than tinkering with booting, no matter how much I like tinkering in general
> Did I mention how much easier handling booting with UEFI is compared to unholy mess of most other systems?
Yeah. Like linux entries getting ignored, no eay to debug what went wrong (if an EFI executable fails, you're on your own). A shell which is undocumented. With BIOS i didn't spent hours trying to boot a linux kernel.
Yeah. Like linux entries getting ignored, no eay to debug what went wrong (if an EFI executable fails, you're on your own). A shell which is undocumented. With BIOS i didn't spent hours trying to boot a linux kernel.
Unless you encountered a BIOS that actually followed the spec instead of blindly loaded a sector and hoped for the best, and learnt that your typical linux install programs made malformed MBR that does not mark the drive as bootable so BIOS actually should skip it when booting.
Or when grub suddenly stops working on a dual boot system, and after you fix it another part on the non linux system fails, and if you fix that grub fails (and fails in all cases hard enough you need to boot from something else). After some time you either ended up dropping either grub or $some_important_software - poor you if the latter is something you make money to sustain yourself. All because, surprise, you're not supposed to write bootloader code into cylinder 0 outside of first sector, and various signature systems used in licensing use the no-mans-land of cylinder 0 to scribble signatures.
BIOS offered even less debug tools than (U)EFI, so dunno what you're talking about. UEFI shell is documented, if not as well as it could be, and even has built-in help. That you can, worst case, boot it (or any other tools) from simple fat32 formatted pendrive that can be created with a file manager instead of rawdogging the hard disk is just a bonus.
The cases with Linux entries being ignored were plain bugs by specific manufacturers, bugs that also hit windows (because the vendors in question worried that them not checking properly would backfire, and instead of checking the firmware properly hardcoded few tested bootvar names).
And the ignored entries could be resolved by using standard fallback bootloader paths, or renaming linux entries to same as ones that work.
Or when grub suddenly stops working on a dual boot system, and after you fix it another part on the non linux system fails, and if you fix that grub fails (and fails in all cases hard enough you need to boot from something else). After some time you either ended up dropping either grub or $some_important_software - poor you if the latter is something you make money to sustain yourself. All because, surprise, you're not supposed to write bootloader code into cylinder 0 outside of first sector, and various signature systems used in licensing use the no-mans-land of cylinder 0 to scribble signatures.
BIOS offered even less debug tools than (U)EFI, so dunno what you're talking about. UEFI shell is documented, if not as well as it could be, and even has built-in help. That you can, worst case, boot it (or any other tools) from simple fat32 formatted pendrive that can be created with a file manager instead of rawdogging the hard disk is just a bonus.
The cases with Linux entries being ignored were plain bugs by specific manufacturers, bugs that also hit windows (because the vendors in question worried that them not checking properly would backfire, and instead of checking the firmware properly hardcoded few tested bootvar names).
And the ignored entries could be resolved by using standard fallback bootloader paths, or renaming linux entries to same as ones that work.
> That you can, worst case, boot it (or any other tools) from simple fat32 formatted pendrive that can be created with a file manager instead of rawdogging the hard disk is just a bonus.
There was a wonderful, brief period of time where most systems were UEFI out of the box, and the largest file on a Windows ISO was under 4 GiB.
You could literally drag+drop the contents of the ISO to a FAT32 thumb drive and install Windows with it. You didn't have to erase it first. You didn't need a special app or the command line to pull it off. It just worked.
The WIM files are too big now. At least Rufus is a pretty good utility.
There was a wonderful, brief period of time where most systems were UEFI out of the box, and the largest file on a Windows ISO was under 4 GiB.
You could literally drag+drop the contents of the ISO to a FAT32 thumb drive and install Windows with it. You didn't have to erase it first. You didn't need a special app or the command line to pull it off. It just worked.
The WIM files are too big now. At least Rufus is a pretty good utility.
It sounds like what you want is Coreboot?
Which it seems like AMD is interested in from the slides in [1]
[1]: https://community.amd.com/t5/business/empowering-the-industr...
Which it seems like AMD is interested in from the slides in [1]
[1]: https://community.amd.com/t5/business/empowering-the-industr...
> 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.
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.
It not being a backdoor and NSA stealing UEFI keys from MS aren't exclusive.
To the point that it's Microsoft who mandated a deviation from UEFI SecureBoot spec that enables owners to replace root of trust keys (Platform Key) in UEFI systems if the vendors wants that "designed for windows" sticker.
To the point that it's Microsoft who mandated a deviation from UEFI SecureBoot spec that enables owners to replace root of trust keys (Platform Key) in UEFI systems if the vendors wants that "designed for windows" sticker.
Microsoft only mandated that for the "designed for windows" sticker, while simultaneously mandating that their arm laptops went hard in the opposite direction. https://news.ycombinator.com/item?id=3458679
That was during MS early flirting with ARM based devices running normal windows kernel.
The "setup your own PK without vendor or even Microsoft keys" is part of Microsoft's offering for some big dollar clients in Enterprise, which is why it's included in certification these days.
And I mean using your own keys, not running without SecureBoot, which was the topic linked in the 2012 discussion.
The "setup your own PK without vendor or even Microsoft keys" is part of Microsoft's offering for some big dollar clients in Enterprise, which is why it's included in certification these days.
And I mean using your own keys, not running without SecureBoot, which was the topic linked in the 2012 discussion.
I think you're intentionally obscuring the difference between:
(1) A system locked by Microsoft, who benevolently allows some users to achieve freedom by setting up new Platform Keys.
If the big dollar clients demand standardization and openness, then it might curtail the typical Microsoft antitrust shenanigans.
(2) A system that is owned by the purchaser, who may choose to deploy Microsoft or other security solutions, and then remove them, at will.
We already have (2), so any attempt to subvert it is by definition untrustworthy.
Item (1) is what is called "trustworthy computing," and Microsoft still openly celebrates it [1].
Item (2) is what is being obscured.
[1] https://www.microsoft.com/en-us/security/blog/2022/01/21/cel...
(1) A system locked by Microsoft, who benevolently allows some users to achieve freedom by setting up new Platform Keys.
If the big dollar clients demand standardization and openness, then it might curtail the typical Microsoft antitrust shenanigans.
(2) A system that is owned by the purchaser, who may choose to deploy Microsoft or other security solutions, and then remove them, at will.
We already have (2), so any attempt to subvert it is by definition untrustworthy.
Item (1) is what is called "trustworthy computing," and Microsoft still openly celebrates it [1].
Item (2) is what is being obscured.
[1] https://www.microsoft.com/en-us/security/blog/2022/01/21/cel...
I think you are intentionally obscuring the difference between "no standard solution for cryptographic check of what you're booting" and "solution that provides that which one of the vendors pushed to make switchable in ways that keep it open for others as well, even if only because it makes business sense for them as well"
Trustworthy computing, even in Microsoft way, involves owner deciding what's running and being able to verify that. Funnily enough Microsoft's "solution" here involves removing Microsoft keys and owner signing specific binaries they allow to run.
We don't have yours (2) because of various gaps you could drive an American freight train through. The options that exists are all even more closed down than SecureBoot (which is just one leg of Trustworthy Computing).
N.B. the main subversive component in all of this, and tellingly implemented because stakeholders of "trustworthy computing" actually care about owner control, is protected media path, foisted by MPAA and streaming industry through closed blobs in Intel ME and AMD PSP
Trustworthy computing, even in Microsoft way, involves owner deciding what's running and being able to verify that. Funnily enough Microsoft's "solution" here involves removing Microsoft keys and owner signing specific binaries they allow to run.
We don't have yours (2) because of various gaps you could drive an American freight train through. The options that exists are all even more closed down than SecureBoot (which is just one leg of Trustworthy Computing).
N.B. the main subversive component in all of this, and tellingly implemented because stakeholders of "trustworthy computing" actually care about owner control, is protected media path, foisted by MPAA and streaming industry through closed blobs in Intel ME and AMD PSP
Fear not, Microsoft has an ongoing Rust implementation, and then everything will be sorted out. /s
https://techcommunity.microsoft.com/t5/surface-it-pro-blog/r...
https://techcommunity.microsoft.com/t5/surface-it-pro-blog/r...
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
Be careful what you wish for, as the overwhelming purpose of discovered exploits will be to give freedom to the rightful owners of devices.
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.
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.
The nice thing about UEFI is that the build-in "UI framework" means you can get UI from oproms this way as well.
It also means you can bypass the mouse driven monstrosities from at least Dell by booting with console on serial port (for example through IPMI) - and all the same options are available, in vt-100 compatible form.
What relief after finding a server where the base bios was fine, but the intel raid card had its own SVGA+PS/2 mouse requiring setup interface... The mad scramble for a mouse to add to crash cart...
It also means you can bypass the mouse driven monstrosities from at least Dell by booting with console on serial port (for example through IPMI) - and all the same options are available, in vt-100 compatible form.
What relief after finding a server where the base bios was fine, but the intel raid card had its own SVGA+PS/2 mouse requiring setup interface... The mad scramble for a mouse to add to crash cart...
> 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?
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?
>I'm curious about that - why isn't there more competition
Because like most consumer PC parts, it's a race to the bottom low margin low wage business, usually offshored to Asia, that's only remotely profitable for the top 2-3 players who captured the market and optimized the costs, processes, development and supply chain to the max.
Why would anyone else want to enter such a market to compete for even lower profits?
Because like most consumer PC parts, it's a race to the bottom low margin low wage business, usually offshored to Asia, that's only remotely profitable for the top 2-3 players who captured the market and optimized the costs, processes, development and supply chain to the max.
Why would anyone else want to enter such a market to compete for even lower profits?
Most, if not all, consumer motherboard manufacturers are Asian themselves (Taiwan)
Sure, but must major BIOS manufacturers, Award, Phoenix, AMI are American AFAIK.
Don't forget the co-inventor of EFI (along with Intel), Insyde...
AMI sure is, says it right in the name, lol
I had a chuckle when I saw "Challenge 1: Singing Binaries" [0]
[0] https://github.com/hacking-support/DVUEFI/tree/main/docs/2-s...
[0] https://github.com/hacking-support/DVUEFI/tree/main/docs/2-s...
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.