Testing trusted board boot / secure boot without burning OTP, is it even possible?

[pp2]

I have a stm32mp135f board (I'm mainly interested in Linux capable SoC) and I am trying to learn something about trusted firmware a, optee, and secure boot solutions. Although the documentation is pretty decent I don't see how I could test the whole solution from bottom to up, namely how to perform the full boot with all stages being authenticated without writing anything to OTP memory. When it comes to ATF and u-boot I see some ways to stub eg. the part of the implementation to use other keys or perhaps use the debugger to stop bl2 and write a key hash into so-called shadow registers (probably, it's just my guess), however from what I understand there is no way to stub a root of trust key, which is used by the boot ROM to authenticate bl2. I can imagine that there could be eg. some configuration in (in this case) st binary header that would indicate for the boot ROM that it should use key hashes that are eg. appended to the binary instead of OTP. I would like to avoid writing anything to OTP as long as possible due to the non-reversability of these changes which in case something went wrong would brick my chip forever.

Having said that, I am ofc aware of the limited capabilities of the boot ROM code due to the very constrained environment. How would you approach this?

[Erwan SZYMANSKI]

Hello @pp2 ,
You summarize very well in fact. Indeed, once you have access to SW level, for TF-A and U-BOOT, you have some possibilities to stub OTPs and then, make your tests with "fake" key as you want, since you stubbed it right.

However, at BootROM stage, you have no other solution than burning OTPs ... We understand that this is not very convenient when the number of chip is reduced, but we cannot counter this.

Kind regards,
Erwan.