On Tue, 10 Mar 2020 at 18:19, Daniel Thompson daniel.thompson@linaro.org 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.