On Tue, 10 Mar 2020 at 18:19, Daniel Thompson <[email protected]> wrote:
> 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. > > It's all about the target use: 1) industrial (manufacturing, automotive, robotics, medical...) components 2) telecom edge 3) 96boards 4) developer desktop 5) server As I just consider 1 and 2, I have no case without secure boot... Now the dev platform can come without the secureboot active and SElinx deactivated.... In what context you think this is usefull? > Daniel. > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
