On 21/05/2020 07:58, Sumit Garg wrote:
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
Added as issue on github:
https://github.com/ARM-software/ebbr/issues/47
g.
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
