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.
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.
On Sun, 12 Sep 2021, 02:34 Tom Rini, trini@konsulko.com wrote:
On Sat, Sep 11, 2021 at 11:30:00PM +0200, Mark Kettenis wrote:
Date: Sat, 11 Sep 2021 17:05:45 -0400 From: Tom Rini trini@konsulko.com
On Sat, Sep 11, 2021 at 09:18:46PM +0200, Mark Kettenis wrote:
From: Moiz Imtiaz moizimtiaz1@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/bro...
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.
In this case, doesn't the Pi firmware pass along apply overlays and construct the device tree it's going to pass along, so in this case you would want to make an "overlay" for the Pi firmware to apply and pass along to U-Boot, that includes the required information?
yes, that might work. The overlay can be specified in the config.txt
file.
I think truly verified boot is impossible on the Pi though, as u-boot and the overlay file will need to be stored on the uSD card of the Pi. But that applies to the scenario where the public key is stored in the device tree embedded in u-boot itself as well.
Yes, a more general problem is that some platforms are really only proof-of-concept useful. If you can't start with the ROM, you're going to be limited.
-- Tom