On Tue, 19 May 2020 at 22:21, Grant Likely <[email protected]> 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?
I would be in favour of such a security addendum. IMO, "make the platform actually secure" has a bit wider scope than just secure boot. And the scope may vary depending on the threat model which may be specific to a particular use-case. So I will try to list down security features along with their requirements as follows. Please feel free to extend this list in case I missed any relevant security feature: Feature: Secure boot Platform requirements: - BootROM being the Root of Trust for Secure boot shall initiate the chain of trust via verifying the first stage boot-loader. - Provide platform binding of the root public key used for verification. Feature: Anti-rollback protection Platform requirements: - BootROM shall provide anti-rollback protection for first stage boot-loader updates. Feature: Unbrickable firmware updates Platform requirements: - BootROM shall support A/B partition scheme to load first stage boot-loader from alternate locations. Feature: Secure storage Platform requirements: - Either provide a dedicated non-volatile memory accessible to secure world only or provide a RPMB based secure storage. - Provide a Hardware Unique Key (HUK) which is accessible to the secure world only. Feature: Secure entropy source Platform requirements: - Provide a hardware entropy source which is accessible to secure world only. Feature: Memory firewalls / TZASC Platform requirements: - Provide a way to carve out DRAM so that it's accessible to the secure world only. Feature: Secure peripherals / TZPC Platform requirements: - Provide a way to partition peripherals so that secure peripherals are accessible to secure world only. -Sumit > EBBR proper can specify the functional interfaces, but security > certification is outside EBBR scope. > > g. > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
