Problem with U-boot | Configuration Signature not being checked while booting

[Mark Kettenis]

> From: Simon Glass <sjg at chromium.org>
> Date: Sat, 18 Sep 2021 03:27:48 -0600
> 
> Hi Tom,
> 
> On Fri, 17 Sept 2021 at 11:26, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote:
> > > Hi Mark,
> > >
> > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> > > >
> > > > > From: Simon Glass <sjg at chromium.org>
> > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600
> > > >
> > > > Hi Simon,
> > > >
> > > > > Hi Mark,
> > > > >
> > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
> > > > > >
> > > > > > > From: Moiz Imtiaz <moizimtiaz1 at gmail.com>
> > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > Thanks for the reply.  I already followed the steps mentioned in
> > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt".
> > > > > > >
> > > > > > > >I wonder if rpi is not using the devicetree compiled with U-Boot, but
> > > > > > > instead one provided by the earlier-stage firmware?
> > > > > > >
> > > > > > > Not sure, but seems like this is the case. I checked and there isn't any
> > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I tried to
> > > > > > > add the dtb and other dts dtsi
> > > > > > > <https://github.com/raspberrypi/linux/tree/rpi-5.10.y/arch/arm64/boot/dts/broadcom>files
> > > > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARATE and
> > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Boot and
> > > > > > > it would just give a blank screen*. I wonder why there isn't any device
> > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supported by
> > > > > > > RPI4?
> > > > > >
> > > > > > The issue with the rpi4 is that the addresses of devices move around
> > > > > > based on the version of the Raspberry Pi firmware you're using.  And
> > > > > > possibly on the amount of memory on the board as well.  So U-Boot
> > > > > > pretty much has to use the device tree passed by the firmware since
> > > > > > the device tree in the U-Boot tree would be wrong for many
> > > > > > combinations of firmware and hardware.
> > > > > >
> > > > > > Simon, this sort of thing is exactly the reason why I think the idea
> > > > > > of having all U-Boot configuration information in a single device tree
> > > > > > with the hardware description doesn't work everywhere.
> > > > >
> > > > > >From my reading of this thread, it rather reinforces the need to
> > > > > provide a way to give U-Boot the config it needs, in the devicetree.
> > > >
> > > > As long as that configuration is optional, yes, maybe.
> > > >
> > > > > It seems that rpi is actually OK in this regard. If you think about
> > > > > it, it would be pretty hopeless if first-stage firmware assumed that
> > > > > it could provide a devicetree to whatever is next.
> > > >
> > > > Not hopeless.  If that device tree provides a hardware description
> > > > that is complete enough to boot Linux, it should be good enough to run
> > > > U-Boot.
> > >
> > > Not in general. I hope I have covered this in enormous detail in the
> > > devicetree patch. But if you don't need verified boot, SPL or some
> > > other feature that needs config, then perhaps you will get away with
> > > it.
> >
> > Wait, why does SPL _need_ it?  If something provides us with a device
> > tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a
> > smaller DT to use.
> 
> Yes, although if the filtering is not done I am not sure what SPL
> would do. In fact we don't have a way to provide two DTs (SPL, U-Boot
> proper) from a prior boot stage at present.

I still think that if there is some sort of prior stage firmware,
there typically is no need for SPL.  And if there is, DRAM is probably
set up already and there are no space constraints so using the full DT
isn't an issue.

> >  Dealing with u-boot,dm-pre-reloc could be trickier,
> > but means whatever loaded us needs to have enabled any early clocks we
> > need.  But even then, it's just going to be output related?  And some
> > "was already configured" path could be used.
> 
> My point is that ignoring U-Boot's devicetree requirements doesn't
> work in general. It may work in specific cases. It cannot work for
> verified boot of course.

And this is I think the root of the controversy.  IMHO, U-Boot should
have no "hard" devicetree requirements other than the requirement that
the device tree provides a complete enough description of the hardware
using standardized DT bindings.

That doesn't mean you can't have something like a /config node with
U-Boot specific options.  I'd say that would be a great way for prior
stage firmware to control U-Boot behaviour.

But what it does mean is that none of those options can be a "hard"
requirement in the sense that in order to have a functioning U-Boot on
a platform you absolutely have to have U-Boot specific nodes and/or
properties in your DT.

I guess what I'm saying/asking is, why can't we have some sort of
middle ground here?

If there is no prior-stage firmware to speak of and U-Boot is entirely
responsible for bootstrapping a board (the typical scenario where you
need SPL/TPL) I don't see a problem with having a control DT that
specifies everything.

If there is prior-stage firmware, and U-Boot proper is the canonical
payload for that firmware on a board, adding U-Boot specific stuff to
the DT should be no issue.  There are some obvious issues here in
keeping DT bindings in synch between the prior-stage firmware and
U-Boot in that case, so standardizing/upstreaming the U-Boot DT
bindings would be helpful in this scenario.

If U-Boot is just one of many choices for the payload having U-Boot
specific stuff in the DT may not make sense.  In that scenario you'd
just get reasonable default behaviour (and potentially no verified
boot).  But it should be possible to change the default behaviour
using the U-Boot environment variables in cases where it makes sense.

I'm not yet sure where my Apple M1 work is going to land on this
spectrum.  I think doing verified boot here is doable when using
u-boot as a payload.  Currently the m1n1 bootloader, the DTB and
U-Boot are combined into a single Mach-O binary and there is a special
procedure that requires username/password verification to "enroll"
that binary as a bootable "kernel" for Apple's bootloader.  I believe
that means that it can't be tampered with without physical access to
the machine and providing the password of the "owner" of the machine.
So embedding the public key that verifies subsequent stages (e.g. a
FIT image or an EFI binary) should work just fine.

Cheers,

Mark