Re: [Qemu-devel] vNVRAM / blobstore design

[Anthony Liguori <anthony@codemonkey.ws>]

Stefan Berger <stefanb@linux.vnet.ibm.com> writes:

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

Error creating device.

> - user skipped over using the external tool, storage is not formatted
> - provided storage contains unknown / corrupted data

Garbage in, garbage out.

> - encryption / decryption key is missing (yes, we want blob encryption!)
> - encryption / decryption key is wrong and decrypted data therefore are 
> corrupted

No, encrypting the nvram is not the device's job.  A user can either use
ecryptfs or AES encryption in qcow2 if they feel this is important.

There is nothing special about the TPM's nvram compared to a normal
virtual disk image.  Any argument you would make regarding key storage
is equally applicable to a virtual disk image.  An awful lot of private
keys are stored in virtual disk images today...

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

Same applies to virtual disk images.  If someone hands a guest a garbage
disk image, the behavior will be ambiguous.  It's not a job to prevent
users from doing this.

(In fact, it may even be desirable to test these conditions)

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

You're overcomplicating things.  QEMU's role is not to prevent a user
from doing something unusual.  This isn't GNOME.

Regards,

Anthony Liguori

>
> Thanks.
>
>     Stefan