Re: [Qemu-devel] The unholy encrypted image key mess

[Markus Armbruster]

Paolo Bonzini <address@hidden> writes:

> Il 05/03/2014 11:36, Markus Armbruster ha scritto:
>> Andreas Färber <address@hidden> writes:
>>
>>> Am 05.03.2014 09:43, schrieb Markus Armbruster:
>>>> Kevin Wolf <address@hidden> writes:
>>>>
>>>>> 'change' is a bit trickier because it involves several low-level actions
>>>>> at once, and device_add is not one of them.
>>>>
>>>> The problem is that it can run while a device model is attached.
>>>
>>> What exactly is the problem here? 'change' is for floppy and CD, right?
>>> The device stays realized/connected and guest-visible during that time,
>>> and the guest should be able to live with no media while the new drive
>>> is not yet decrypted. Are we just lacking a QMP command to enter the
>>> password and complete the change while the guest is executing?
>>
>> Here's how change works (both HMP and QMP):
>>
>> 1. bdrv_close(); now we have no medium.
>>
>> 2. If a device model is attached, tell it the medium has been ejected.
>>    A device model supporting notification (anything but floppy, I guess)
>>    in turn notifies the guest.
>>
>> 3. bdrv_open(); now we again have a medium, we're in state NOKEY if the
>>    image is unencrypted, and in state NEEDKEY if it's encrypted.
>>
>> 4. Only in state NOKEY: if a device model is attached, tell it a medium
>>    has been loaded.  A device model supporting notification in turn
>>    notifies the guest.
>>
>> 5. Only in state NEEDKEY:
>>
>>    If QMP, fail the command with error DeviceEncrypted.
>>
>>    If HMP, prompt user for password.
>>
>> In QMP, the client needs to follow up with a block_passwd command.  In
>> HMP, the user neeeds to enter a password.  In both cases, time passes,
>> guest can run, and even other monitor commands can be executed, possibly
>> in other monitors.  When the password arrives:
>>
>> 7. Set the key, state is now GOTKEY.
>>
>> 8. If a device model is attached, tell it a medium has been loaded.  A
>>    device model supporting notification in turn notifies the guest.
>>
>> Shit happens for encrypted images if anything reads or writes between
>> 3. and 8.
>
> You could use bdrv_new before step 3, to open the new medium on a new
> temporary BDS.  Then before step 8 you use bdrv_swap and delete the
> temporary BDS.

If we can't get rid of state NEEDKEY entirely, then we need to hide BDSs
in this state from anything but the QMP command to set the key.

As long as we don't have BlockBackend, we need to do something like you
described to keep NEEDKEY hidden from the device model even though the
device model has a direct reference to its backing BDS.