[Top][All Lists]

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

Re: [Qemu-devel] [PATCH V8 08/14] Introduce file lock for the block laye

From: Stefan Berger
Subject: Re: [Qemu-devel] [PATCH V8 08/14] Introduce file lock for the block layer
Date: Wed, 07 Sep 2011 20:31:45 -0400
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110621 Fedora/3.1.11-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.11

On 09/07/2011 02:49 PM, Michael S. Tsirkin wrote:
On Wed, Sep 07, 2011 at 12:08:22PM -0400, Stefan Berger wrote:
On 09/07/2011 11:16 AM, Michael S. Tsirkin wrote:

So it's a bug in the code then?

 From what I saw, yes. Migration is not complete until the passwords
had been entered. Though the requirement for a correct password
wasn't there before because Qemu just couldn't know which password
is correct since it doesn't know what content in a VM image is
correct -- just using the wrong key gives you content but it's of
course not understandable.
OK, we covered that on irc - the issue is that monitor
on destination is inactive until migration is complete.
Yes we need to fix that but no, it's not a tpm only
I think the TPM is the first device that needs that password before the migration switch-over happens. The reason is that the TPM emulation layer needs the password/key to read the data from the QCoW2 to be able to initialize a device BEFORE the Qemu on the source side terminates thinking that the migration went ok. Previously an OS image that was 'opened' with the wrong key/password would probably cause the OS to not be able to read the data and hopefully not destroy it by writing wrongly encrypted data into it -- QEMU wasn't able to detect whether the QCoW2 encryption key was correct or not since it has not knowledge of the organization of the data inside the image. [[You'd need some form of reference point, like a sector that when written to a hash is calculated over its data and that hash is written into a location in the image. If a wrong key is given and the sector's hash ends up being != the reference hash you could say the key is wrong.]]
Similar problems occur when you start a
VM with an encrypted QCoW2 image. The monitor will prompt you for
the password and then you start the VM and if the password was wrong
the OS just won't be able to access the image.

Why can't you verify the password?

I do verify the key/password in the TPM driver. If the driver cannot
make sense of the contents of the QCoW2 due to wrong key I simply
put the driver into failure mode. That's all I can do with encrypted
You can return error from init script which will make qemu exit.

I can return an error code when the front- and backend interfaces
are initialized, but that happens really early and the encyrption
key entered through the monitor is not available at this point.

I also don't get a notification about when the key was entered. In
case of QCoW2 encryption (and migration) I delay initialization
until very late, basically when the VM accesses the tpm tis hardware
emulation layer again (needs to be done this way I think to support
block migration where I cannot even access the block device early on
at all).
So it in the loadvm callback. This happens when guest is
stopped on source, so no need for locks.
Two bigger cases here:

1) Encryption key passed via command line:
     - Migration with shared storage: When Qemu is initializing on
the destination side I try to access the QCoW2 file. I do some basic
tests to check whether a key was needed but none was given or
whether some of the content could be read to confirm a valid key.
This is done really early on during startup of Qemu on the
destination side while or before actually the memory pages were
transferred. Graceful termination was easily possible here.
     - Migration using block migration: During initialization I only
see an empty QCoW2 file (created by libvirt). I terminate at this
point and do another initialization later on which basically comes
down to initializing upon access of the TPM TIS interface. At this
point graceful termination wasn't possible anymore. There may be a
possibility to do this in the loadvm callback, assuming block
migration at that point has already finished, which I am not quite
sure. Though along with case 2) below this would then end up in 3
different times for initialization of the emulation layer.

2) QCoW2 encryption:
     - This maps to the last case above. Also here graceful
termination wasn't possible.

As for the loadvm callback: I have a note in my code that in case of
QCoW2 encryption the key is not available, yet. So I even have to
defer initialization further. In this case Qemu on the source
machine will have terminated.

The point is to decrypt when you start running on dest.
When the monitor gets the key for the QCoW2 it would have to invoke the TPM driver code (callback) and return an error code if the key was found to be wrong and display an error message that libvirt could react to. Afaik none of the callback and error display logic is in place. Is that something we could add later as an improvement?
At that point source is stopped. On failure,
notify management and have it restart source.
On success, management can kill source qemu.


reply via email to

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