Re: [Qemu-devel] vNVRAM / blobstore design

["Michael S. Tsirkin" <mst@redhat.com>]

On Fri, Mar 29, 2013 at 01:33:01PM -0400, Kenneth Goldman wrote:
> > 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?

You want to protect against someone who is able to
manipulate some bits in the file (content) but not others (hash)?
What's the attack you are trying to protect against here?

I'm guessing the only result of extra checksums would be
unbootable guests when qemu manages to corrupt the checksum
without any help from attackers ...

-- 
MST