On 3/11/20 12:10 PM, Daniel Thompson wrote:
On Tue, Mar 10, 2020 at 06:34:35PM +0100, Francois Ozog wrote:
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:
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:
- industrial (manufacturing, automotive, robotics, medical...) components
- telecom edge
- 96boards
- developer desktop
- 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?
I would like it to be possible for dev boards and SoMs whose SoCs do not have a built-in root of trust to have some basic level of EBBR compliance.
I don't like to optics of saying "this standard cannot possibly apply to a Raspberry Pi"[1]. Taking the RPi Zero or CM3 as examples[2], I can't see any value added by secure boot since the root-of-trust would have to start on the same media as the operating system anyway.
There is a TPMv2 module available for Raspberries.
https://buyzero.de/products/letstrust-hardware-tpm-trusted-platform-module?v...
Would we be able to use this as root of trust?
Would we recommend the EFI TPM2 Protocol to be implemented in the EBBR as a possible source of trust? Daniel Kiper, one of the maintainers of GRUB, expressed interest in this feature.
https://trustedcomputinggroup.org/wp-content/uploads/EFI-Protocol-Specificat...
Best regards
Heinrich
Daniel.
[1] I'd also worried about some of the open-market Arm SoMs as well, but since 96Boards has skin in the game there I've adopted a less partisan example above.
[2] There are problems with RPi4 too but they are different (and hopefully less severe).
boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture