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 grant.likely@arm.com 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