Re: [Qemu-devel] vNVRAM / blobstore design

[Stefan Berger]

On 03/28/2013 01:39 PM, Michael S. Tsirkin wrote:
> On Thu, Mar 28, 2013 at 12:27:45PM -0500, 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:
> > > > > 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.

What do we do with the following error cases:

- provided storage is too small to fit blobs into
- user skipped over using the external tool, storage is not formatted
- provided storage contains unknown / corrupted data
- encryption / decryption key is missing (yes, we want blob encryption!)
- encryption / decryption key is wrong and decrypted data therefore are 
corrupted

Starting a device and providing it with corrupted data or data that 
could not be properly decrypted becomes ambiguous. We can do better and 
determine these error cases without starting up the device and having 
the user guess what may be wrong : wrong key versus corrupted data. 
Corrupted data is hopeless while a wrong key can  be fixed.

My suggestion would be to have a layer inside of QEMU that handles these 
error cases and QEMU would not start up unless these errors get 
resolved. I think there is probably not much concern regarding the 
separation of core vTPM functionality and this layer, but more how big 
this layer becomes, what all it provides in terms of services and one 
step further then whether it should not be a generic layer that can be 
used by other devices as well.

Some additional HMP/QMP commands to query for the above error conditions 
can be implemented and depending on how severe they are another HMP/QMP 
command can be implemented to resolve some of these error condition, 
i.e., provide another AES key or go through the step of formatting etc. 
If a block device is not big enough it may require the user to use 
qemu-img again and start over.

Thanks.

   Stefan