On Tue, 19 May 2020 at 22:21, Grant Likely <grant.lik...@arm.com> wrote:
>
> On 12/03/2020 04:58, Sumit Garg wrote:
> > On Thu, 12 Mar 2020 at 03:11, Francois Ozog <francois.o...@linaro.org> 
> > wrote:
> >>
> >> Le mer. 11 mars 2020 à 22:22, Heinrich Schuchardt <xypron.g...@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.thomp...@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:
> >>>>> 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
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture

Reply via email to