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

[Markus Armbruster]

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.