This is what I thought when viewing my latest computer that came with an UEFI bios. That the UEFI BIOS is to large and too complex and has way to many functions to be a BIOS device, hence a perfect place to put advanced malware.
It's like an operating system before the operating system, has its own FAT32 system partition where you can store stuff.
Also after a few years your manufacturer will stop shipping uefi BIOS updates for your computer due to their interest in selling new computers and then there will be a lurking security whole laying around.
All of this is equally possible on plain old BIOS. One way that's been done in the past is to write a small hook into the SMM handler. Don't even need to drop any malware into windows, once you're in SMM mode you are running completely outside the view of the OS, with full access to everything in memory.
Without a doubt, the classic BIOS needed improvement, but we didn't need this. The situation reminds me of IPv6, which is also grossly over-engineered.
BIOS also got very large and complex, that's why there was such need for it to be replaced. In both the case of the BIOS and the case of uEFI, it is possible to protect them from tampering or not.
A lot of what you're saying is largely FUD, since all you're doing is listing off random uEFI features and waving your hands around while implying it is "bad" and we're all doomed. But you haven't pointed out a single reason why it is worse than BIOS, in fact BIOS is even more of a "black box" in many cases and thus was even more security through obscurity.
Several uEFI implementations have a checkbox that when unchecked will simply block all updates. If you uncheck that and enable a password, many of these persistent threats are stopped in their tracks. If you know of a specific alternative vector for installation, then contact the manufacturer as a matter of security.
The only reason that uEFI malware is taking off is not because uEFI is inherently more insecure, but instead because uEFI is better documented, it is easier to get reference builds, and easier for people to learn. But, again, all you've done is exchange obscurity (BIOS) for known threats (uEFI). Either way an expert monied adversary (e.g. state security services) could launch an attack.
Systems with UEFI are more likely to also support virtual machines at the CPU level which makes it much easier to transparently slip in a layer under everything else.
Computers being more complicated has nothing to do with a dynamic module loader that is designed to be able to override installed code modules with newer versions at runtime.
That's just architecture astronauts with too much exposure to COM designing a firmware API.
Fine, but that's not what I replied to. Someone said they forgot the "B" in BIOS (with uEFI), I am saying the BIOS hasn't been close to a basic in a very long time due to the complexities of x86-like systems.
The BIOS was a giant bloated mess before uEFI. uEFI's modular design is a single attempt at keeping it simplier and removing unneeded code.
> UEFI's modular design is a single attempt at keeping it simplier and removing unneeded code.
That's why with the introduction of UEFI, flash parts finally grew in size again? (not that I complain, that's quite useful to burn coreboot + Linux on them, to have a _real_ OS around to drive the boot process)
UEFI is _much_ larger than BIOS, conceptually and in terms of code size.
It's also _much_, _much_ larger than coreboot based solutions implementing the same purpose (my tests indicate that UEFI takes 6 times the LOC over coreboot for a minimized code base that provides a boot menu and the ability to load a signed Linux kernel from disk)
> That's why with the introduction of UEFI, flash parts finally grew in size again?
Assembly programs are typically smaller than ones written in C. No surprise there.
> It's also _much_, _much_ larger than coreboot based solutions implementing the same purpose (my tests indicate that UEFI takes 6 times the LOC over coreboot for a minimized code base that provides a boot menu and the ability to load a signed Linux kernel from disk)
And does 1/6th the amount of "stuff." If you drop a bunch of uEFI features, of course you won't use as much code. Is that controversial? There's a reason CoreBoot is so infrequently used, it doesn't do many things that people take for granted with uEFI.
I disabled all capabilities that weren't required for the task, then killed all source files that weren't required for the build, in both trees. I believe it was a fair comparison.
It's like an operating system before the operating system, has its own FAT32 system partition where you can store stuff.
Also after a few years your manufacturer will stop shipping uefi BIOS updates for your computer due to their interest in selling new computers and then there will be a lurking security whole laying around.