Re: [Qemu-devel] blobstore disk format (was Re: Design of the blobstore)

[Stefan Berger <stefanb@linux.vnet.ibm.com>]

On 09/19/2011 03:04 PM, Michael S. Tsirkin wrote:
> On Mon, Sep 19, 2011 at 12:22:02PM -0400, Stefan Berger wrote:
>> On 09/17/2011 03:28 PM, Michael S. Tsirkin wrote:
>>> On Fri, Sep 16, 2011 at 12:46:40PM -0400, Stefan Berger wrote:
>>
>> The checksuming I think makes sense if encryption is being added so
>> decryption and testing for proper key material remains an NVRAM
>> operation rather than a device operation.
> Not sure how this addresses the question of what to do
> on checksum failure.
>
Checksum failure on an unencrypted blob would mean that the blob is 
corrupted. In case of encryption 'corrupted' would overlap with a 'badly 
decrypted' blob. In either way the startup of the device cannot happen. 
We could refuse the NVRAM key suggesting that likely this is the wrong 
key for decryption but corruption is also possible.
>>>>>>> We use a directory as a SET in a CER format.
>>>>>>> This allows generating directory online without scanning
>>>>>>> the entries beforehand.
>>>>>>>
>>>>>> I guess it is the 'unknown' for me... but what is the advantage of
>>>>>> using ASN1 for this rather than just writing out packed and
>>>>>> endianess-normalized data structures (with revision value),
>>>>> If you want an example of where this 'custom formats are easy
>>>>> so let us write one' leads to in the end,
>>>>> look no further than live migration code.
>>>>> It's a mess of hacks that does not even work across
>>>>> upstream qemu versions, leave alone across
>>>>> downstreams (different linux distros).
>>>>>
>>>> So is ASN1 the answer or does one still need to add a revision tag
>>>> to each blob putting in custom code for parsing the different
>>>> revisions of data structures (I guess) that may be extended/changed
>>>> over time?
>>>>
>>>>     Stefan
>>> We don't need revisions. We can always parse a new structure
>>> skipping optional attributes we don't recognize. In case we want to
>>> break old qemu versions intentially, we can add
>>> a mandatory attribute.
>> So you said you had some code for the handling of ASN.1. Can sketch
>> how the interaction of devices would work with mandatory and
>> optional attributes along with an API?
> So for now what I'm happy with is a low level BER parser API.
> NVRAM would implement a scheme on top of that
> and bdrv. I'll pack up what I have and post ASAP.
>
I had thought that registration of a blob could include the registration 
of something similar to the  VMStateDescription's fields array 
(VMStateField[]) that currently is not encoded as ASN.1 but seems to be 
heading that way. I am not sure what the time frame for this is but I 
guess recycling as much code as possible would be helpful. For the 
purpose of NVRAM we would have to be able to determine the size of these 
additional metadata, something that is not necessary for the case of VM 
migration/suspend. I guess using VIsitors it should be possible to 
implement this type of functionality. Also extending the metadata in the 
future with new fields will be a lot harder with NVRAM due to the 
limited space we will have reserved when the blob + metadata was written 
out the first time.

>> I'd prefer to NOT have the
>> attributes and values be a part of the NVRAM API itself but let a
>> (mandatory) library handle the serialization and deserialization of
>> these metadata when a device wants to write or read state
>> respectively. But maybe I just want to keep the NVRAM API 'too
>> simple'.
>>
>>     Stefan
> I'm fine with that. Still tpm has some device specific
> things like 'actual size' so the api will need to address that
> in some generic way.
Maybe the above mentioned registration of the VMStateField[] could help.

    Stefan