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.
