Conversation

Jarkko Sakkinen

If I did not have anything else to do I would reimplement this in Rust: https://github.com/microsoft/ms-tpm-20-ref. The code quality is not great in the original and it is not particularly complicated thing to do just time consuming. Looking how bad code quality is, I wonder why e.g. #OPTEE implementation is based on it (if I got this wrong please correct, 99% sure it is).

#tpm #arm #tee
2
0
0
There's also #IBM software TPM. It might be less messy but it does not have any community so thus I've been ignoring it: https://sourceforge.net/p/ibmswtpm2/tpm2/ci/master/tree/. It is a single person project and almost no commits by anyone else. I trust more community projects.
0
0
0
@vbabka Very much indeed! Might even considering contacting the presenter. Thank you.

Rust makes no magic here but usually people who get into Rust tend to be enthusiastic about code in the first place. Both Microsoft and IBM TPM are crap code at least in my standards. It does not take long to browse either's repository and realize this. And yeah, for new user space code I think Rust is the best available choice so it is better than starting from zero with C/C++.
1
0
1
@vbabka The reason I'm contacting is that for a new implementation the best approach would be to make the state of the TPM parametrized instead of holding it inside the implementation.

So the use case would be e.g. SGX enclave:

1. Pass a state blob from untrusted OS to with the TPM command to the enclave.
2. Enclave processes the TPM command, encrypts the state blob and returns it back to the caller.

Global state in the current implementations is IMHO the biggest problem so it would be a loss to get yet another implementation with such. Stateless software TPM would be sort of universal across various TEE's.
1
0
1
@vbabka I put a comment to the Youtube video :-)
1
0
1
@jarkko yeah but don't leave it at the comment, he probably won't notice, this is best discussed at the linux-coco list maybe?
1
0
1
@vbabka OK, totally new list to me, perhaps I'll subscribe to it.
1
0
1
@vbabka Funny given that I've upstreamed the first "coco" thing in the kernel :-) Looks like a list that I should be in.
0
0
1