qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] vNVRAM / blobstore design


From: Kenneth Goldman
Subject: Re: [Qemu-devel] vNVRAM / blobstore design
Date: Fri, 29 Mar 2013 13:33:01 -0400

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]