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

[Markus Armbruster]

Kevin Wolf <address@hidden> writes:

> Am 28.02.2014 um 22:01 hat Markus Armbruster geschrieben:
>> Questions:
>> 
>> 1. Should we protect guests from state NEEDKEY?
>
> Yes. An image in state NEEDKEY isn't fully initialised, so we should
> make sure that it isn't used.

Consensus.

>> 2. If yes, how?
>> 
>>    Pause the guest when something enters state NEEDKEY?  I'd hate that.
>> 
>>    Fail device_add in state NEEDKEY?  Takes care of hot-plug, and
>>    cold-plug is already protected by cont.
>
> 'device_add' should refuse to accept a backend that isn't fully
> initialised, so yes, I agree.

bdrv_attach_dev() could fail then.

> '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 we probably really need
> to do is support a state where no BDS is attached to the device
> emulation (a BlockBackend might still be attached, not sure about this
> one), but the VM is still running. And then 'change' can detach the BDS,
> bring it back to the NEEDKEY state (unrealize in QOM speech?), magic
> happens and then we reattach the BDS to the guest device.

In a BlockBackend world, the device model attaches to a BlockBackend,
and the BlockBackend may have a BDS[*].  No BDS means no media.
Removing media takes away the BDS and destroys it.  Inserting media
creates a new BDS and gives it to the BlockBackend.

To avoid visible NEEDKEY, delay the giving until we reach GOTKEY.

> We'll also want to protect other parts of qemu from not fully
> initialised BDSes, e.g. block jobs or NBD servers shouldn't take such an
> BDS as their source.

Good point.  Shows that the NEEDKEY problems are more pervasive than I
thought.

What shall we do about them?

We can ship yet another release with known open deathtraps around
encrypted images, only this time with a warning against it buried in the
documentation for people not to read.

Or we can do our users a favor and kill support for encrypted images
dead (except in qemu-img, of course).  Revive when we have encryption
that actually works, both in the safety and security sense.

Opinions?


[*] Actually: root of a BDS tree (or even BDS DAG?)