[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.
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?)
- Re: [Qemu-devel] The unholy encrypted image key mess, Paolo Bonzini, 2014/03/01
- Re: [Qemu-devel] The unholy encrypted image key mess, Kevin Wolf, 2014/03/03
- Re: [Qemu-devel] The unholy encrypted image key mess,
Markus Armbruster <=
- Re: [Qemu-devel] The unholy encrypted image key mess, Paolo Bonzini, 2014/03/05
- Re: [Qemu-devel] The unholy encrypted image key mess, Andreas Färber, 2014/03/05
- Re: [Qemu-devel] The unholy encrypted image key mess, Markus Armbruster, 2014/03/05
- Re: [Qemu-devel] The unholy encrypted image key mess, Paolo Bonzini, 2014/03/05
- Re: [Qemu-devel] The unholy encrypted image key mess, Markus Armbruster, 2014/03/05
Re: [Qemu-devel] The unholy encrypted image key mess, Markus Armbruster, 2014/03/05