Re: [Qemu-devel] vNVRAM / blobstore design

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

On Thu, Mar 28, 2013 at 12:11:22PM -0400, Stefan Berger wrote:
> On 03/27/2013 03:12 PM, Stefan Berger wrote:
> >On 03/27/2013 02:27 PM, Anthony Liguori wrote:
> >>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >>
> >>>On 03/27/2013 01:14 PM, Anthony Liguori wrote:
> >>>>Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> >>>>
> >>>>What I struggle with is that we're calling this a "blobstore".  Using
> >>>>BER to store "blobs" seems kind of pointless especially when we're
> >>>>talking about exactly three blobs.
> >>>>
> >>>>I suspect real hardware does something like, flash is N
> >>>>bytes, blob 1 is
> >>>>a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is
> >>>>(N - X - Y)
> >>>>bytes.
> >>>>
> >>>>Do we really need to do anything more than that?
> >>>I typically call it NVRAM, but earlier discussions seemed to prefer
> >>>'blobstore'.
> >>>
> >>>Using BER is the 2nd design of the NVRAM/blobstore. The 1st one didn't
> >>>use any visitors but used a directory in the first sector pointing to
> >>>the actual blobs in other sectors of the block device. The organization
> >>>of the directory and assignment of the blobs to their sectors, aka 'the
> >>>layout of the data' in the disk image, was handled by the
> >>>NVRAM/blobstore implementation.
> >>Okay, the short response is:
> >>
> >>Just make the TPM have a DRIVE property, drop all notion of
> >>NVRAM/blobstore, and used fixed offsets into the BlockDriverState for
> >>each blob.
> >
> >Fine by me. I don't see the need for visitors. I guess sharing of
> >the persistent storage between different types of devices is not a
> >goal here so that a layer that hides the layout and the blobs'
> >position within the storage would be necessary. Also fine by me
> >for as long as we don't come back to this discussion.
> 
> 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.
> 
> 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.
> 
>    Regards,
>       Stefan
> 
> 

It was precisely this addition of more and more metadata
that made me suggest a format like BER. But of course
a file per field will do too: following what Anthony suggested you would
put the checksum in a separate file?

-- 
MST