[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] vNVRAM / blobstore design
From: |
Anthony Liguori |
Subject: |
Re: [Qemu-devel] vNVRAM / blobstore design |
Date: |
Fri, 29 Mar 2013 10:12:05 -0500 |
User-agent: |
Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) |
Stefan Berger <address@hidden> 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 <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
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
- Re: [Qemu-devel] vNVRAM / blobstore design, (continued)
- Re: [Qemu-devel] vNVRAM / blobstore design, Stefan Berger, 2013/03/27
- Re: [Qemu-devel] vNVRAM / blobstore design, Anthony Liguori, 2013/03/27
- Re: [Qemu-devel] vNVRAM / blobstore design, Stefan Berger, 2013/03/27
- Re: [Qemu-devel] vNVRAM / blobstore design, Stefan Berger, 2013/03/28
- Re: [Qemu-devel] vNVRAM / blobstore design, Michael S. Tsirkin, 2013/03/28
- Re: [Qemu-devel] vNVRAM / blobstore design, Stefan Berger, 2013/03/28
- Re: [Qemu-devel] vNVRAM / blobstore design, Anthony Liguori, 2013/03/28
- Re: [Qemu-devel] vNVRAM / blobstore design, Stefan Berger, 2013/03/28
- Re: [Qemu-devel] vNVRAM / blobstore design, Michael S. Tsirkin, 2013/03/28
- Re: [Qemu-devel] vNVRAM / blobstore design, Stefan Berger, 2013/03/29
- Re: [Qemu-devel] vNVRAM / blobstore design,
Anthony Liguori <=
- Re: [Qemu-devel] vNVRAM / blobstore design, Kenneth Goldman, 2013/03/29
- Re: [Qemu-devel] vNVRAM / blobstore design, Michael S. Tsirkin, 2013/03/31
- Re: [Qemu-devel] vNVRAM / blobstore design, Kenneth Goldman, 2013/03/31
- Re: [Qemu-devel] vNVRAM / blobstore design, Michael S. Tsirkin, 2013/03/27
- Re: [Qemu-devel] vNVRAM / blobstore design, Kenneth Goldman, 2013/03/27