On Fri, Oct 09, 2020 at 11:12:35 -0600, Simon Glass wrote:
From an EBBR point of view I would expect it to be an implementation decision. For some use cases key enrolment makes sense, for others not so much.
In the PC space, Microsoft required that vendors include a means for users to change the keys that are trusted as part of some certification programme. However AFAIK that rule does not apply to Arm even in the cases where that certification programme is relevant.
So UEFI is a standard, in that it describes APIs. But so is the C library or ACPI, or C for that matter. I think there is another level missing here.
My point is not that systems are too constrained to use UEFI. It's more that there isn't a lot of point, for many systems. It seems to just add complexity, although it makes things simpler for Linux, I imagine. Some of the points made in this thread seem to be about removing arch-specific code from U-Boot and putting it in an EFI application, but to what end?
The valuable piece of a boot standard IMO would be to describe behaviour, how various features are configured (e.g. verified boot, adding kernels/devicetree/initrd, boot selection, key management, recovery) and how to test it.
Reading your responses, if I understand things correctly, EBBR is just a short doc that suggests using EFI protocols to boot Linux. It doesn't specify what any of the pieces should be, how they should interact, even less what their behaviour should be. I'd like to see a boot standard specify:
- what U-Boot (or some other bootloader) does and the environment it
provides (EBBR seems to have some of this)
- what any of the 'glue' pieces between U-Boot and linux are allowed
to do, their inputs and outputs (this means grub, etc.)
- how linux controls what boots, key management, etc.
Without this it is just 'please use EFI', so far as I can see. Is that the intent or is it just that it is in the early stages?
That is the intent. EBBR is actively operating system- and intended to be architecture agnostic, which adds some of the complexity you dislike.
If you are looking for a Linux-centric way of getting a fully-vertically-integrated OS up and running with a minimum of code, then that is arguably closer to the artist formerly known as LBBR: https://developer.arm.com/architectures/system-architectures/arm-systemready... although that probably carries other baggage you are also not interested in. And quite possibly does *not* add the bits you want.
I'm not saying what you're asking for wouldn't be useful, but that I don't think EBBR is the answer.
Regards,
Leif