On Thu, 12 Mar 2020 at 03:11, Francois Ozog <[email protected]> wrote: > > Le mer. 11 mars 2020 à 22:22, Heinrich Schuchardt <[email protected]> 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 < > > [email protected]> > > >> 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: > > >> 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? > > > > > > 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?variant=33890452626 > > > > 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-Specification-rev13-160330final.pdf > > > > 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 > > > [email protected] > > > https://lists.linaro.org/mailman/listinfo/boot-architecture > > > > > > > -- > 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 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
