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

Moiz Imtiaz moizimtiaz1 at gmail.com
Sun Sep 12 22:45:56 CEST 2021


Thanks a lot Tom and U-boot Team,

What I did is that I made a control FDT (with Public_key and
signature_node) and replaced the default dtb (bcm2711-rpi-4-b.dtb) in the
boot directory of rpi_4-b(the board I am using) with the Control FDT

I compiled U-boot with "Config_OF_BOARD" and thought that since the pi
second stage bootloader is gonna decide what dtb to use, how about
replacing the default with our Contro FDT and it worked :)

[image: image.png]

It's like when I will be copying u-boot.bin in the /boot directory I will
replace the default dtb with the Control FDT. If there is any concern with
the above implementation from a security perspective (i.e manually
replacing the default dtb of pi with control FDT), please let me know so
that I can improve it. I am completely open to suggestions.

I also checked by modifying the config kernel hash and it throw rejection
and didn't boot up.
[image: changing_the_hash_verfication.png]

Kudos on the awesome writeup
<https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/beaglebone_vboot.txt>
of
manual verification by modifying the hash, saved me a couple of hours of
googling :D

Also, one quick question, why do we not accept boot scripts with FIT
enabled? I really like the idea of disabling legacy image support with FIT
enabled but what is the recommended way of achieving boot scripts action
then, if we won't allow boot script for e.g loading the FIT image in memory
and then booting it up with bootm?
Currently, I am using the following in my boot script.

setenv bootargs 8250.nr_uarts=1 console=ttyS0,115200 root=/dev/mmcblk0p2
> rootwait rw;
> fatload mmc 0:1 0x20000000 image.itb;
> bootm 0x20000000;


Again, thanks a lot and appreciate your input and suggestions.

Best,
Moiz Imtiaz Khan

On Sun, Sep 12, 2021 at 8:02 PM Tom Rini <trini at konsulko.com> wrote:

> On Sun, Sep 12, 2021 at 02:58:12AM +0500, Moiz Imtiaz wrote:
>
> > Completely agreed, that a fully secure boot on pi won't be achievable
> > because the Root of Trust (ROT) cant be established from the
> BOTROM/EEPROM.
> > Plus Pi doesn't have any High Assurance Boot (HAB).  But given the
> > scenerio, whatever we can achieve i.e if we can verify the kernel, the
> > device tree, from the bootloader, (u-boot)  that would be great.
> >
> > Currently the issue with Pi4 is that , signature verification is not
> being
> > done with u-boot, so wondering if that can be made possible.
>
> Right, OK.  Yes, I think it would be possible, but you'll need to
> experiment a bit.  You'll basically want to take the signature
> information that the U-Boot docs talk about out of the created device
> tree, and put it in its own file, and then have the Pi firmware apply
> that as an "overlay", as it assembles the tree to use.  Then the regular
> mechanism U-Boot uses to use the passed in device tree should work.
>
> > >But that applies to the scenario where the public key is stored in the
> > > device tree embedded in u-boot itself as well
> >
> > Just for the sake of knowledge, Isn't this the case with all u-boot, that
> > the public key is stored in the device tree (control FDT) and is embedded
> > in the u-boot.
>
> You're in experimental territory here, yes.  The existing examples all
> are on platforms where a prior stage wouldn't be giving us a device
> tree.  U-Boot should not actually care where the device tree comes from
> so long as it is correct.
>
> I've only got a Pi 3 in my CI lab, and since it's CI I also really hate
> fiddling with it since I then end up spending more time re-setting it
> for CI.
>
> --
> Tom
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 67795 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210913/afec2e65/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: changing_the_hash_verfication.png
Type: image/png
Size: 24777 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20210913/afec2e65/attachment-0003.png>


More information about the U-Boot mailing list