The TPM spec is a monster and I understand the urge to throw it out and create something simpler. It's also true that you're trusting proprietary firmware in the TPM to be correct. Errors and bugs in the spec are also near impossible to fix. So the idea of "just run whatever code you want" has appeal. And the reference tpm2_tools and software stack is a hot mess of C code that should definitely not be written in C at this point.

A device brewed on a RISC-V SOC in an FPGA is probably very hard to secure against hardware attacks. It's fun (in the sense that FPGAs are "fun") and it's definitely a worthy pursuit to have an open hardware + firmware device replace proprietary TPMs. But getting hardware security right is just as important here. A TPM-replacement is not useful if I can solder a JTAG connection to it and read out the memory.

Rewrapping keys when there's a firmware/code update is a real weakness here. There's probably a solid solution, like being able to provide a compound/asymmetric CDI to wrap between versions. Like "generate an ECDH key pair for the next hash". It would be a pain if every client application had to implement this themselves. The other hot use case for TPMs is boot chain attestation, where hashes of UEFI firmware, boot loaders, and kernel images are appended to create a verifiable hash. The device attests to the hash being authentic.

One major weakness of TPM 2.0 is that it's monolithic for the whole system. If you're running VMs or even just multiple processes in the OS, it's not really easy to use across domains. So lightweight code swapping would be pretty cool.

Interesting stuff nonetheless.