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? > > 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. > > > 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
