> One thing I'd like to get clarity about is the following corner-case. A > user supplies some VM image as persistent storage for the TPM. It > contains garbage. How do we handle this case? Does the TPM then just > start writing its state into this image or do we want to have some layer
> in place that forces a user to go through the step of formatting after > that layer indicates that the data are unreadable. Besides that a > completely empty image also contains garbage from the perspective of TPM > persistent state and for that layer. A garbage persistent storage should be handled the same way a physical TPM would handle an NV failure - failure mode. It's a broken part that must be replaced with a factory fresh part. That's done by some admin tool nulling the storage. Empty (length zero or non-existent) is different from corrupt. The TPM should detect that and initialize itself to factory defaults. Those defaults are specified in the TPM specification. > My intention would (again) be to put a header in front of every blob. > That header would contain a crc32 covering that header (minus the crc32 > field itself of course) plus the blob to determine whether the blob is > garbage or not. It is similar in those terms as the 1st implementation > where we also had a directory that contained that crc32 for the > directory itself and for each blob. This is not a filesystem, I know that. I agree that an integrity value should be included. This is a security device, and layers of protection are good. I wonder about the choice of algorithm. The TPM doesn't have crc32 code but it does have SHA-1. Why not reuse code rather than add a new function?
