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

[Moiz Imtiaz]

I will try to learn how to create a dtbo, and do a PR to documentation. I
ain't an embedded or kernel guru like you guys.

I have a complete security background with primarily appsec :)

But I agree that we should have some documentation because
1. It's a common reference platform
2. At the moment we don't have any public doc on how to achieve signature
validation on Pi-4.

I know it won't be a complete secure boot, but will do a PR nonetheless. :)

We can then improve the writeup, with the passage of time,if needs
required.

On Sat, 18 Sep 2021, 18:24 Moiz Imtiaz, <moizimtiaz1 at gmail.com> wrote:

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