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

Moiz Imtiaz moizimtiaz1 at gmail.com
Sat Sep 18 15:24:33 CEST 2021


Tbh, the reason why I didn't do overlay is that I am not comfortable with
it. I still have to learn how to do dtbo, and that is why I didn't add a PR
to the documentation. I understand adding a dtbo is more robust and better
way.

What I replaced with was a copy of the original device tree that came with
the firmware or one can get it from pi's GitHub and using mkimage added the
public key to it.

I completely agree that achieving a complete secure boot in pi is not
possible and I have mentioned few reasons in the initial thread as well.
One reason being that the Root of Trust can't be achieved in its true way.
The pi loads from GPU and we get control at 3rd stage of the pi bootloader
from where, our U-boot comes, what happens before it, can't be verified
because the (bootloader.bin) and (start.elf) are both closed source and PI
doesn't offer any HAB either.

Secondly, relying on an unverified config.txt which theoretically speaking
can be replaced by an attacker having shell access is not a secure way. as
in PI, AFAIK, it's flat memory and there isn't any Arm trustzone or TF-A
implemented, so one would be relying completely on an unverified congif.txt
file.

Other than that, since there isn't any HAB, or efuses, the physcial attack
vector is always there. Anyone with physical access can flash the emmc or
sdcard and replace it with their own FIT (having kernel) and Control FDT or
just replace the u-boot.bin with their own u-boot.

I guess, pi wanted to reduce the cost and compensated on the security
features.


More information about the U-Boot mailing list