> 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?