On Sat, Sep 18, 2021 at 12:26:00PM +0200, François Ozog wrote:
> Le sam. 18 sept. 2021 à 12:10, Mark Kettenis <mark.kette...@xs4all.nl> a
> écrit :
> 
> > > From: Moiz Imtiaz <moizimti...@gmail.com>
> > > Date: Sat, 18 Sep 2021 14:47:51 +0500
> > >
> > > >Nice!  If you want to write something up extending the >documentation on
> > > >how you made this work for Pi it would be much appreciated.
> > >
> > > Sure, would love to do a PR.
> > >
> > > I basically replaced the dtb that pi loads with control Dtb of uboot, but
> > > will do a PR of documentation addition in respect to pi_4, detailing
> > > everything shortly :)
> >
> > Sorry, but I don't think this is safe.  The Raspberry Pi firmware
> > makes changes to the device tree and it is unclear what requirements
> > it has in terms of names of nodes and compatible strings since the
> > firmware is closed source.  It should be fine to add stuff to the DTB
> > that came with the firmware, but replacing it altogether is probably
> > going to break things in subtle ways.  So I don't think that is
> > something we should advocate by documenting it in U-Boot.
>
> The way I see the chain of trust is: I don’t know how the GPU firmware is
> checked (or even if it is checked), The GPU firmware does not check or
> measure the booted kernel from kernel=xyz that it gets from the unverified
> config.txt which have been building a hardware description from unverified
> files from the file system.
> 
> Bottom line, trying to create a secure boot flow on RPI4 may lead into
> impression of security while it is not supported at hardware level.
> Impression of security can be worse than no security at all.

In general, there's always the questionable value of enabling some level
of "secure" boot on platforms where we don't have a root of trust
starting from the hardware, nor hardware assist later on.  But there is
some value in documenting how to enable the commodity (versus
SoC-specific) functionality on very common reference platforms.
Sometimes even more so even on platforms you can't otherwise potentially
lock yourself out of.

-- 
Tom

Attachment: signature.asc
Description: PGP signature

Reply via email to