UEFI is a pretty terrible firmware and a huge mess. HP ported it for RISC-V but they seem to have lost interest.
The open source firmware people like are however doing a lot, coreboot, u-boot, linuxboot and so on. There are discussions ongoing about how to design the low level interfaces.
I don't see how you can say a specification is a mess. Particularly since it (and openfirmware) tend to implement far more of what is required to boot a "generic" OS than any of the firmware projects you mention. Projects that are all mostly linux bootloaders. Further, there is an open source mostly complete UEFI (tianocore) implementation. Some people dislike tianocore for mostly religious reasons (it has 2 character tabs, and an odd build system), but those reasons actually have nothing to do with base UEFI.
Finally, UEFI as the OS interface is actually being embraced by u-boot and coreboot as the standard OS loader. Thats because they have realized that the services provided by UEFI actually do solve many of the problem users of uboot/etc systems experience. For one, it standardizes the update process for the actual firmware, as well as providing services/controls for managing the OS boot process following update/etc. It also has interfaces for plug in cards (PCIe option roms) and many other features that turn out to be critical to building a generic computing device.
> I don't see how you can say a specification is a mess.
A specification can absolutly be a mess. Over-complicated for what is needed 90% of the time and in the other cases its also not optimal.
> Further, there is an open source mostly complete UEFI (tianocore) implementation.
Tinocore is not really complete for what you actually need and most venders are so far down stream that the advantages of real open source don't apply.
> Thats because they have realized that the services provided by UEFI actually do solve many of the problem users of uboot/etc systems experience.
I understand that. But there is a reason why Facebook, Google and other providers move away from UEFI.
> For one, it standardizes the update process for the actual firmware, as well as providing services/controls for managing the OS boot process following update/etc. It also has interfaces for plug in cards (PCIe option roms) and many other features that turn out to be critical to building a generic computing device.
The way the update process is implemented is incredibly sub-optimal and I have heard people from Intel agree that it is so.
The problem is that it creates and unnecessary parallel universe that is far more insecure, far harder to understand and with way worse tooling.
Google and facebook are about the opposite of who you should be listening to for advice on general purpose systems. Their machines are basically embedded servers, and exist in a very strict environment with lots of engineering oversight. Its almost the exact definition of a mono-culture. And google is the mother of android, the very definition of huge mess. You need look no further than the handsets being abandoned after a year because its basically impossible to actually maintain without having a staff of dozens of engineers just to keep a platform working.
UEFI, is a specification designed to allow a machine to boot and be managed by a multitude of OS's. That means, yes it may be a bit over complicated in places but those over-complications tend to serve a purpose (or did). I don't think anyone imagines that UEFI is perfect, its not, but tossing out uboot or whatever as an alternative is extremely myopic, as uboot doesn't really even provide enough firmware services for linux in its current state much less windows, or some future OS not yet thought off. That is the point with UEFI, to attempt to fill the gaps in what is possible with a given platform without creating a wild west of incompatible formats and hacky solutions for every platform (which is the current state of uboot/DT despite nearly a decade of work).
> Google and facebook are about the opposite of who you should be listening to for advice on general purpose systems. Their machines are basically embedded servers, and exist in a very strict environment with lots of engineering oversight.
They have so many servers and different configuration needs that they need to boot their servers reliably, security, with integrity and they need to boot a wide variety of different systems.
> UEFI, is
You didn't seem to watch any of the sources that I provided. I'm not making an argument for uboot. The systems that I recommend as better the UEFI can do everything UEFI can do and actually do much more and are much more flexible, not to mention far more secure.
> That is the point with UEFI, to attempt to fill the gaps in what is possible with a given platform without creating a wild west of incompatible formats and hacky solutions for every platform (which is the current state of uboot/DT despite nearly a decade of work).
You don't seem to know how actually UEFI works on servers. Each vender uses tons of old unsecure bloated firmware full of different drivers that are very badly maintained and don't get security updates. UEFI is at the point where for a commercial server there are more lines of code then the linux OS you are booting into. Its a total security nightmare and a horrible situation in terms of open source as most of these things are closed source. The UEFI core might be open source but even that is not actually used and tracked upstream, vendors all use their own forks.
UEFI is complete separated layer that is its own OS, reinventing the wheel putting a totally insecure ring under your OS.
I think your conflating UEFI, with the entire firmware stack. Anyway, there is a bit of LOL here. UEFI DXE/EFI drivers don't have a security model, once they are trusted they have free reign (similar to how a linux module can mostly to anything it wants). But... they don't tend to run under the OS, outside of the very thin UEFI runtime services. Most of UEFI is tossed/overwritten when exit boot services are called. Plus, they are effectively running in the context of the OS kernel which provides the security guarantees. AKA there is nothing gained by finding a bug in the RTC or if someone manage to break the signing chain and provide a bogus firmware update because the exploit happens outside of UEFI itself and doesn't provide more functionality then they already have.
Now, that said, you have various ME/BMC processors scattered about, and those are the ones that have frequently been exploited to great advantage. The real chuckle here is that most of the BMC's are running uboot (or similar) firmware/OS stacks which don't tend to be upgraded for the very reasons I pointed out earlier. So yes, your BMC gets owned over the network, and it manages to own the OS running on the main processors because it can inject things into the address space during any part of the boot/runtime. But that isn't a UEFI failing, its a failing of the BMC vendors who don't have a clean way to audit/control the code being built into the images. If you look at OpenBMC its a yocto based system. Which means like android the vendors are on the hook for assuring their system works, and having ongoing development control of the upstream tree's. That all works about as well for BMC's as it does for android.
The open source firmware people like are however doing a lot, coreboot, u-boot, linuxboot and so on. There are discussions ongoing about how to design the low level interfaces.