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

[Simon Glass]

Hi Mark,

On Sat, 18 Sept 2021 at 05:15, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > 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.

The DT does need to be paired with U-Boot, I think. For example, if
the DT adds new devices then the pre-reloc malloc size may need to be
increased as well.

For the SPL case, we may have enough memory to init devices, but it
may not be configured that way. Typically SPL uses a small RAM size
even if it is not initing the SDRAM. SPL does not relocate.

For the non-SPL case we still need to consider pre-reloc, where boot
time could be adversely affected by initing devices that are not
needed.

So I thnk we should say that if you are using a particular U-Boot
version, you should provide U-Boot with the DT from that version too.

>
> > >  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 think we are saying the same thing. If you don't need U-Boot
features which rely on config, and you have a tail wind, then you
should be able to boot with whatever DT there is.

But I don't think we should recommend this. It is a 'fallback' case
when (for whatever reason) the U-Boot DT for that board is not
provided. You are 'on your own' and things may or may not work,
depending on memory requirements, what features are used, etc.

Note that verified boot will actually boot (without verifying) when
the U-Boot devicetree is not provided.

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

Sounds right to me.

Regards,
Simon