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