Re: [Qemu-devel] vNVRAM / blobstore design

[Stefan Berger]

On 03/28/2013 01:27 PM, Anthony Liguori wrote:
> Stefan Berger <address@hidden> writes:
>
> > On 03/27/2013 03:12 PM, Stefan Berger wrote:
> > > On 03/27/2013 02:27 PM, Anthony Liguori wrote:
> > > > Stefan Berger <address@hidden> writes:
> > > >
> > > > > On 03/27/2013 01:14 PM, Anthony Liguori wrote:
> > > > > > Stefan Berger <address@hidden> 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?

Firmware inside the hardware may zero out the memory or format it upon 
first run and set a flag indicating that the memory is now in valid 
state -- is that too far fetched ? I don't know what it would do in 
subsequent steps, whether it would add some sort of integrity check to 
the blobs or not or even maintain some form of journal to recover from 
disasters -- it may depend on the quality of the device. Hardware also 
knows that the chip will unlikely be taken apart and the firmware, when 
it sees garbage in memory, may refuse to start up or automatically 
format the device.

   Stefan

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