Hi Francois, On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog wrote: > On Tue, 10 Mar 2020 at 17:18, Grant Likely <[email protected]> wrote: > > > > Hi Francois, > > > > This is really good. EBBR regular meetings have been on hold while the > > U-Boot work progressed, but it is probably about time to start them up > > again. This is list is a great first agenda item. > > > > Comments below... > > > > On 10/03/2020 16:02, Francois Ozog wrote: > > > Hi, > > > > > > Following implementation (or work towards) of EBBR 1.0 + UEFI Secure > > > boot + UEFI update capsule we learnt a lot. > > > > > > Here are some topics that may need some clarification on the EBBR > > > specs and It looks timely to start working on EBBR evolution. > > > > > > 0.1 - EBBR goal > > > May be a reassessment on the "for what" the specification is built. > > > > > > Following all the discussions with prominent industry players, I start > > > to think that limiting the constraints to be EBBR compliant may become > > > counter productive. There will be both EBBR non compliant and EBBR > > > compliant systems. This is inevitable. But EBBR exist for a number of > > > use cases in a number of markets. The value of EBBR is consistent > > > behavior across those. > > > > > > Maximising number of EBBR compliant systems without stating use case > > > parameters ( "why" and "for what") may not be the best goal. > > > > > I would like people to think about this one before getting into the > meeting because without this we can't discuss most of the rest. > > > > Out of things to be more explicit are supported secure boot flows > > > (with/without shim+grub or direct). Some vendors require shim+grub > > > while industry players want the exact opposite: nothing but UEFI. This > > > drivers a number of requirements in terms of UEFI protocols needed > > > > Have you got a comparison of the protocols needed in each scenario? It > > has been pretty clear that both models are important, is there a large > > delta from one to the other, and it is an extra burden to support all of > > them in U-Boot (e.g., once implemented in mainline, most of the > > protocols should work for all). > > > > Supporting industrial players require EFI_LOAD_FILE2_PROTOCOL in > addition to the distro subset. > Pushed upstream. Ilias may comment about merging
This is in U-Boot already and should go in kernel 5.7. IIRC EDK2 also got a command line to register and use the protocol. The idea behind this is that we use a number of different and rather complicated ways of passing the initrd to the kernel. This is an arch-agnostic approach. The kernel efi stub allocates a memory during booting and requests the firmware for the file right before it needs to run it. Nothing authenticates the file, but on U-boot for example, the file name is a config option, thus built-in into U-Boot. In conjuction with TF-A verifying the bootloader it offers some kind of (maybe naive??) security since you can't change the file location. A user can still overwrite the initrd contents though. There's ways to verify the initrd itself on linux if that's necessary. > > But I am flexible, important we state explicitly the reference > document and we use the language constructs. [...] > > > > I - protective offsets Regards /Ilias _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
