Bootstrapping computers is "hard" and there's a huge disincentive to breaking compatibility with operating systems' installation/bootstrapping.
I'm not sure if EFI/UEFI are ideal, but it strikes me as a net win.
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.
That's just architecture astronauts with too much exposure to COM designing a firmware API.
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.
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)
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.