Le jeu. 22 oct. 2020 à 22:16, Simon Glass sjg@chromium.org a écrit :
Hi Leif,
On Mon, 12 Oct 2020 at 06:08, Leif Lindholm leif@nuviainc.com wrote:
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.
But then it begs the question, what is EBBR for. I had assumed that we were trying to get devices to use it, if they don't want to use ACPI...but if it doesn't cover the needs, it's just an n+1 solution, as I said above.
It seems to me that we could standardise some of these things without too much trouble. By focussing on EFI (only) and not on how we can standardise all the boot flows, we might be missing the point.
Let’s take concrete examples: chromeOS and Android are defining optimized and secured way of booting a single known OS. This is some form of walled garden and well defined. UEFI main goal is to provide an open way to boot any OSes, OSes that are unknown to UEFI. It can boot MacOS, windows, Linux, FreeBSD and even my hobby OS. EBBR is not about defining a unique boot flow that every one has to conform to. EBBR ambition is to allow any OS to be booted from an embedded board. Think of those vertical solutions: all at a sudden it increases the applicability of those solutions. It brings nothing to walled gardens environments but it does not prevent them to continue evolving their own path. In other words, it is not about standardizing everything into one boot flow, it is about opening the door to an ecosystem of OSes for boards, open source or not. Now, the walled gardens have found elegant solutions to some problems. I think one driving principle for EBBR is that we should leverage all those ideas so that we maximize code reuse.
Regards, Simon _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture