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