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 <stef...@linux.vnet.ibm.com> writes: > >> > >>>On 03/27/2013 01:14 PM, Anthony Liguori wrote: > >>>>Stefan Berger <stef...@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
