From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40233) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1Jjk-0006KL-H8 for qemu-devel@nongnu.org; Wed, 07 Sep 2011 11:08:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1Jjf-0005vg-JQ for qemu-devel@nongnu.org; Wed, 07 Sep 2011 11:08:24 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:53579) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1Jjf-0005vP-DV for qemu-devel@nongnu.org; Wed, 07 Sep 2011 11:08:19 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p87Ei3vS003269 for ; Wed, 7 Sep 2011 10:44:03 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p87F89MC092706 for ; Wed, 7 Sep 2011 11:08:12 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p87F6ljv000501 for ; Wed, 7 Sep 2011 12:06:48 -0300 Message-ID: <4E678882.9030204@linux.vnet.ibm.com> Date: Wed, 07 Sep 2011 11:06:42 -0400 From: Stefan Berger MIME-Version: 1.0 References: <20110901173225.GH10989@redhat.com> <4E603724.7010405@linux.vnet.ibm.com> <20110904193258.GA13640@redhat.com> <4E66B304.8020605@linux.vnet.ibm.com> <20110907111857.GB9337@redhat.com> <4E676C3D.2040607@linux.vnet.ibm.com> <20110907131612.GB10510@redhat.com> <4E677824.4040603@linux.vnet.ibm.com> <20110907141051.GA11450@redhat.com> <4E677EC4.1040405@linux.vnet.ibm.com> <20110907143555.GB11645@redhat.com> In-Reply-To: <20110907143555.GB11645@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH V8 08/14] Introduce file lock for the block layer List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: chrisw@redhat.com, Anthony Liguori , anbang.ruan@cs.ox.ac.uk, qemu-devel@nongnu.org, andreas.niederl@iaik.tugraz.at, alevy@redhat.com, rrelyea@redhat.com, "Serge E. Hallyn" On 09/07/2011 10:35 AM, Michael S. Tsirkin wrote: > On Wed, Sep 07, 2011 at 10:25:08AM -0400, Stefan Berger wrote: >> On 09/07/2011 10:10 AM, Michael S. Tsirkin wrote: >>> On Wed, Sep 07, 2011 at 09:56:52AM -0400, Stefan Berger wrote: >>>> On 09/07/2011 09:16 AM, Michael S. Tsirkin wrote: >>>>> On Wed, Sep 07, 2011 at 09:06:05AM -0400, Stefan Berger wrote: >>>>>>>> First: There are two ways to encrypt the data. >>>>>>>> >>>>>>>> One comes with the QCoW2 type of image and it comes for free. Set >>>>>>>> the encryption flag when creating the QCoW2 file and one has to >>>>>>>> provide a key to access the QCoW2. I found this mode problematic for >>>>>>>> users since it required me to go through the monitor every time I >>>>>>>> started the VM. Besides that the key is provided so late that all >>>>>>>> devices are already initialized and if the wrong key was provided >>>>>>>> the only thing the TPM can do is to go into shutdown mode since >>>>>>>> there is state on the QCoW2 but it cannot be decrypted. This also >>>>>>>> became problematic when doing migrations with libvirt for example >>>>>>>> and one was to have a wrong key/password installed on the target >>>>>>>> side -- graceful termination of the migration is impossible. >>>>> OK let's go back to this for a moment. Add a load >>>>> callback, access file there. On failure, return >>>>> an error. migration fails gracefully, and >>>>> management can retry, or migrate to another node, >>>>> or whatever. >>>>> >>>>> What's the problem exactly? >>>>> >>>>> >>>> The switch-over from source to destination already happened when the >>>> key is finally passed and you just won't be able to access the QCoW2 >>>> in case the key was wrong. >>> This is exactly what happens with any kind of othe rmigration errror. >>> So fail migration, and source can get restarted if necessary. >>> >> I guess I wanted to improve on this and catch user errors. >> If we let migration fail then all you can do is try to terminate the >> VM on the destination and cold-start on the source. > No, normally if migration fails VM is not started on destination, > and it can just continue on source. > When I had tried this in conjunction with encrypted QCoW2 the switch-over already had happened and the source had died. So a wrong key on the destination was fatal. >>>> 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. >>>> >>>> Stefan >>> 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 >> QCoW2. > 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). Only then I find out that the key was wrong. I guess any other handling would require blockdev.c's invocation of monitor_read_bdrv_key_start() to be 'somehow' extended and ... do what ? loop until the correct password was entered? Stefan >> In case of a QCoW2 encrypted VM image it's different. There I guess >> the intelligence of what is good and bad data is only inside the OS. >> >> Stefan