On Thu, 12 Mar 2020 at 03:11, Francois Ozog francois.ozog@linaro.org wrote:
Le mer. 11 mars 2020 à 22:22, Heinrich Schuchardt xypron.glpk@gmx.de a écrit :
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?
AFAIK, TPM in itself can't act as a root of trust. It is rather a passive device which can provide you with trusted/secure services. In general a root of trust is the first piece of *non-modifiable* code that runs on a platform which is BootROM that establishes the chain of trust via verifying the first stage boot-loader which in turn continues the chain of trust to next boot stages and so on.
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.
TPMv2 is definitely a big topic. We also implemented an OPTEE one. We will
star working on measured boot next cycle (staring April) tf-a team is ready for that.
In case of measured boot too, either you need BootROM being root of trust or first stage boot-loader verified by BootROM to measure next boot stages and invoke TPM to store/update hash in PCR register. TPM doesn't do the measurements by itself.
-Sumit
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
--
François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture