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, <moizimti...@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. >
