On Tue, May 19, 2020 at 05:51:41PM +0100, Grant Likely wrote: > On 12/03/2020 04:58, Sumit Garg wrote: > > 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. > > I think there is a distinction to be made between useful platforms for > development where most of the functionality required for secure boot > should be usable, and actual secure platforms that have the needed > hardware characteristics. > > EBBR should account for RPi and similar because it is a very convenient > development platform, but there are very few security requirements that > can be guaranteed. > > What do you think of a security addendum or checklist that goes > alongside EBBR to detail what is required to make the platform actually > secure? EBBR proper can specify the functional interfaces, but security > certification is outside EBBR scope.
I like the addendum approach. I'm also happy for conditional dependancies on the security features to become part of the requirements: if platform provides XXX then it must implement YYY. It is only mandatory requirements that are hard to met on common dev boards that are a problem for me. Daniel. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
