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/ls 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 _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
