From: Tom Rini <trini@konsulko.com>
To: "François Ozog" <francois.ozog@linaro.org>
Cc: Mark Kettenis <mark.kettenis@xs4all.nl>,
Moiz Imtiaz <moizimtiaz1@gmail.com>,
jehannazkhan@skyelectric.com, moiz.imtiaz@skyelectric.com,
sjg@chromium.org, u-boot@lists.denx.de
Subject: Re: Problem with U-boot | Configuration Signature not being checked while booting
Date: Mon, 20 Sep 2021 11:33:01 -0400 [thread overview]
Message-ID: <20210920153301.GZ8579@bill-the-cat> (raw)
In-Reply-To: <CAHFG_=UGbTh4QhPHr3nYnhK0UoQqwE9qs=r1sd_OdXm4JWLA_A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]
On Sat, Sep 18, 2021 at 12:26:00PM +0200, François Ozog wrote:
> Le sam. 18 sept. 2021 à 12:10, Mark Kettenis <mark.kettenis@xs4all.nl> a
> écrit :
>
> > > From: Moiz Imtiaz <moizimtiaz1@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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
next prev parent reply other threads:[~2021-09-20 15:33 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-09 20:21 Problem with U-boot | Configuration Signature not being checked while booting Moiz Imtiaz
2021-09-10 4:37 ` Simon Glass
2021-09-11 18:19 ` Moiz Imtiaz
2021-09-11 19:18 ` Mark Kettenis
2021-09-11 21:05 ` Tom Rini
2021-09-11 21:30 ` Mark Kettenis
2021-09-11 21:34 ` Tom Rini
2021-09-11 21:58 ` Moiz Imtiaz
2021-09-12 15:02 ` Tom Rini
2021-09-12 20:45 ` Moiz Imtiaz
2021-09-15 13:02 ` Tom Rini
2021-09-15 10:13 ` Simon Glass
2021-09-15 10:25 ` François Ozog
2021-09-17 16:21 ` Simon Glass
2021-09-17 17:18 ` François Ozog
2021-09-17 17:55 ` Tom Rini
2021-09-15 11:51 ` Mark Kettenis
2021-09-15 13:35 ` Tom Rini
2021-09-15 13:53 ` François Ozog
2021-09-17 16:21 ` Simon Glass
2021-09-17 17:42 ` Tom Rini
2021-09-18 9:27 ` Simon Glass
2021-09-18 13:24 ` Tom Rini
2021-09-17 16:19 ` Simon Glass
2021-09-17 17:26 ` Tom Rini
2021-09-18 9:27 ` Simon Glass
2021-09-18 9:47 ` Moiz Imtiaz
2021-09-18 10:10 ` Mark Kettenis
2021-09-18 10:26 ` François Ozog
2021-09-18 13:24 ` Moiz Imtiaz
2021-09-18 13:30 ` Moiz Imtiaz
2021-09-20 15:33 ` Tom Rini [this message]
2021-09-18 11:15 ` Mark Kettenis
2021-09-18 15:28 ` Simon Glass
2021-09-20 15:38 ` Tom Rini
2021-09-20 15:27 ` Tom Rini
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210920153301.GZ8579@bill-the-cat \
--to=trini@konsulko.com \
--cc=francois.ozog@linaro.org \
--cc=jehannazkhan@skyelectric.com \
--cc=mark.kettenis@xs4all.nl \
--cc=moiz.imtiaz@skyelectric.com \
--cc=moizimtiaz1@gmail.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox