On Tue, Mar 10, 2020 at 05:02:27PM +0100, 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.
Thanks for circulating this. I'm going to respond piecemeal (so I can join the right sub-threads) but since so many of your later comments include "Following my view in 0) I think this shall be made mandatory" let me kick off with the comment below! > 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. > > 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 We have resisted levels in EBBR until now but this might be where might have a need for them. Put another way I agree that getting explicit about mandatory features for secure boot flows is useful. However I also think that is remains valuable to define best practice for how firmware and OS interact on systems that have not implemented secure boot. Daniel. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
