[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Markus Armbruster
Subject: Re: [Qemu-devel] The unholy encrypted image key mess
Date: Wed, 05 Mar 2014 09:43:11 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

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.


>> 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

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]