Re: [Qemu-devel] vNVRAM / blobstore design

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

On Thu, Mar 28, 2013 at 12:27:45PM -0500, Anthony Liguori wrote:
> Stefan Berger <stefanb@linux.vnet.ibm.com> writes:
> 
> > 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.
> 
> What Would Hardware Do?
> 
> If you need to provide a tool to initialize the state, then just provide
> a small tool to do that or provide device option to initialize it that
> can be used on first run or something.
> 
> Don't bother trying to add complexity with CRCs or anything like that.
> Just keep it simple.
> 
> Regards,
> 
> Anthony Liguori


External tool sounds better. Update on first use creates
nasty corner cases - use isn't a well defined thing.
So it creates nasty interactions with migration etc.

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