Server platforms definitely need UEFI or something very much like it. How else can a server boot from eg. a network card that's not directly supported by the firmware? You need something like UEFI to define a standard for option ROMs, and that standard needs a stable, backward-compatible ABI.
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's the opposite. It's tragic to have no baseline when there's an accepted very good platform that basically works that everyone else uses. It's tragic to go it alone.
Well, implementations of UEFI are all over the board because vendors have their own ideas, that leads to compatibility issues.
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.
It is increasingly rare for EDK2 (A modern, feature-rich, cross-platform firmware development environment for the UEFI and PI specifications from www.uefi.org: https://github.com/tianocore/edk2) to not be used as the basis for a secure boot load plus runtime firmware services stack).
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.
It's tragic to see these hardware vendors repeat mistakes of the past by forcing UEFI on platforms that do not need it.
Server platforms definitely need UEFI or something very much like it. How else can a server boot from eg. a network card that's not directly supported by the firmware? You need something like UEFI to define a standard for option ROMs, and that standard needs a stable, backward-compatible ABI.
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's the opposite. It's tragic to have no baseline when there's an accepted very good platform that basically works that everyone else uses. It's tragic to go it alone.
Well, implementations of UEFI are all over the board because vendors have their own ideas, that leads to compatibility issues.
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.
It is increasingly rare for EDK2 (A modern, feature-rich, cross-platform firmware development environment for the UEFI and PI specifications from www.uefi.org: https://github.com/tianocore/edk2) to not be used as the basis for a secure boot load plus runtime firmware services stack).
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.