Unless you like writing everything (display drivers, disk drivers, filesystem drivers, network stacks...) twice. Which is where these bugs come from...
You'd need to either have drivers in the kernel for everything, with no common fallback ("the ARM approach"), or have standards at the hardware/HW firmware level. Having a firmware-level abstraction layer that papers over this for fallback may not be the best idea, but it works without too much politicking.
I would like to be able to ensure that only boot loaders signed with my private key can be executed. Secure Boot serves that purpose well, can I do that with your approach?
Likewise, demand and use cases for network boot exist, otherwise it wouldn't be here. Same goes for every other feature most users would consider bloat.
Yes of course you can. Just run `signify -V` in userspace under the pre-kexec() kernel to check the signature on the post-kexec() kernel/initrd.
You can network boot too; just run `busybox udhcpc`.
I think you misread my comment. I never described signature-checking or network boot as bloat. I said it was stupid to have to implement these things twice (once in mainline Linux and then all over again in kooky UEFI-land with its bizzarre API, ABI, and wacky rules).
I still think it is stupid to do that, because it is. We have working, high-quality, battle-tested implementations of all this stuff. Use them.
I think Oxide's computers don't use UEFI, but I don't know what they replaced it with. Since they are a Rust shop, maybe something written in Rust, but if not it would also be interesting to know and to know the reasons why.
They have a custom bootloader https://github.com/oxidecomputer/phbl that runs without AGESA or any of the normal stack of stuff. From their podcast it sounds like it was quite a bit of work to get it working.
It works for them because they own the complete hardware stack, and boot only their hypervisor which is also something they control.
TL;DR you can make it simple if you close the platform (this is not the same as open source Vs closed source) - open platforms end up developing complex interfaces so thatthey are actually open to end owners.
So here we have security vulnerabilities in an open source UEFI implementation, resulting in a thread about how UEFI is too complex. So your solution... is to use the actual Linux kernel plus some glue code as your boot firmware? I love Linux, but it is neither simple nor free of security vulnerabilities; what exactly does this buy us?
Edit: On reading another reply, I see your argument for having fewer implementations; that's not nothing, but it only really helps if everything is on Linux, which isn't going to help most desktops (and I hope we can agree that NT in firmware is not better) or the rest of the world that isn't on Linux (say, the BSDs).
I don't say UEFI is no over complicated, over engineered mess but I worked on embedded systems for a while and I'd say it's no sunshine there either. Booting a modern OS on modern hardware involves a lot of essential complexity you cannot get away from.
I disagree. UEFI makes my life, as an end user, so much easier. The amount of times I've needed to buy a different flash drive because the BIOS of a particular motherboard didn't like the way my existing flash drives smelled has gone down to 0. The thing even supports filesystems _not_ formatted by a tool written for Windows 95 that arranges the FAT partition in _just_ the right way to get it recognised.
Previously, we had motherboards do the same stuff, except now they called into ROM memory on the network card, and ran a bunch of non-standard, proprietary code to render the fancy graphics and do online updating. I don't believe for a second that things were easier before UEFI standardised it all, they were just hidden from plain view better.
It helps that unlike with BIOS, the modern tooling doesn't have huge amounts of "we never read the spec but it booted on my machine" that was prevalent even with grub2.
TL;DR a BIOS doesn't have to boot a drive if there's no primary partition marked "active", no matter whether your boot code uses that or not.
It's arguably less complicated than late stage BIOSes were, and I'm not including UEFI Class 1 systems (what many systems people thought still had BIOS actually were)
It just is that complicated to bring up all the pieces of hardware in a timely manner and with the right configuration. Not to mention if you want to let user configure things. Just look at say DRAM init: https://www.systemverilog.io/design/ddr4-initialization-and-... Of course you're gonna give that hard task to a memory controller, but then you have to initialise that. This goes on for all the subsystems, with complex interactions and features, all of which need handling.
It's not a single microcontroller you're powering on, even if it were, those too require a bunch of initialisation code to function properly.
DRAM init as little to do with UEFI or BIOS and Intel probably ships x86 components for more exotic or even allow custom bootloaders. At least at a time they did. I don't know the current situation but when I played with all of that, I saw one of their "Memory Reference Code" in particular the parts in charge of calibration of the memory controller timing, and that was a quite short piece of x86 assembly completely independent from the UEFI architecture insanities. Well because it was written in assembly it had an obvious bug, but that's another story.
I agree, but Rust would've still had several of these vulnerabilities. The integer underflow would've passed in release mode (though you could argue that anything running this low level should spare the extra CPU cycles for checked arithmetic), the infinite loops hanging the system, and the predictable TCP sequence numbers.
I'm not sure about the weak pseudo-RNG, because I would expect an existing crate to get imported for that use case, but the same RNG could also be implemented just as badly in Rust.
As for the buffer overflow vulnerabilities: I completely agree. These are the most dangerous vulnerabilities and I doubt they would've made it past the compiler had they been written in Rust.
