It's tragic to see these hardware vendors repeat mistakes of the past by forcing UEFI on platforms that do not need it.
AFAIK, only UEFI and ACPI fulfill that requirement currently (ok, there's Open Firmware, but that's quite esoteric) - eg. Coreboot doesn't really work well in this situation: multiple vendors, different update lifecycles and possibly closed-source binaries.
It is also a security risk, as it is essentially a huge system (compared to BIOS) under the actual OS, compromise the former and own the latter. The larger code base, the larger attack vector.
Coming back to UEFI implementations, how many of them are actually open source and do not have un-vetted code running (again under your OS)?
Yes, UEFI do have some positives but the security risk far outweighs them.
Vendor veerage from vanilla upstream edk2 does occur of course but it does so also with legacy BIOS’. There’s no getting around it in the real world with very very few exceptions.
UEFI evolved to solve standardized boot and firmware at scale and the internet as it stands today would struggle without a standard like it. RISC-V taking a different approach would be swimming against the tide backwards to irrelevance.
RISC-V has specifications on how UEFI should be implemented.
It's not just "use UEFI".
The security benefits of having something that has a robust capable platform with a good test suites feels unmatched compared. Even if you don't know the code (and most are just edk2), at least there's a pretty well defined surface, whose expectations we can test.
I'm open in principle to the idea that maybe UEFI isn't the right fit, that there's other things we should try. but if that answer is BIOS, i'm going to laugh my way out of this thread. Maybe not strictly required but man, the wild incredible janky world of weird antics required to get PXE or a add-on drive card running under bios: it was a piecemeal bodge through and through. I don't know what we see we even try to consider?