From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47724) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMCpM-0003JJ-8j for qemu-devel@nongnu.org; Thu, 21 Jan 2016 05:50:57 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMCpL-0007ul-7o for qemu-devel@nongnu.org; Thu, 21 Jan 2016 05:50:56 -0500 Date: Thu, 21 Jan 2016 10:50:45 +0000 From: "Daniel P. Berrange" Message-ID: <20160121105045.GE19835@redhat.com> References: <1453311539-1193-1-git-send-email-berrange@redhat.com> <1453311539-1193-13-git-send-email-berrange@redhat.com> <20160121095423.GD31470@ad.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160121095423.GD31470@ad.usersys.redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 12/17] qcow2: convert QCow2 to use QCryptoBlock for encryption Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng Cc: Kevin Wolf , qemu-devel@nongnu.org, qemu-block@nongnu.org On Thu, Jan 21, 2016 at 05:54:23PM +0800, Fam Zheng wrote: > On Wed, 01/20 17:38, Daniel P. Berrange wrote: > > This converts the qcow2 driver to make use of the QCryptoBlock > > APIs for encrypting image content. As well as continued support > > for the legacy QCow2 encryption format, the appealing benefit > > is that it enables support for the LUKS format inside qcow2. > > FWIW, with today's QEMU, it's possible to stack format drivers on top of each > other. In other words, even without this patch, we can make LUKS driver > encrypt/decrypt the qcow2 payload, while keeping them completely orthogonal. Yep, that is certainly possible, and it is what is intended for using LUKS with RBD, iSCSI, & other network drivers. I think there is value in having LUKS integrated directly into qcow2 though. It means that given a qcow2 file you can 100% reliably distinguish between a file created with the intention of QEMU managing the LUKS encryption, from a file where the guest OS happens to have set up LUKS encryption in its virtual disk. If you don't have this, then given a random qcow2 file, you have to probe to see if LUKS is present or not. Given the security issues we've had in the past with raw images being turned into qcow2 images by a malicious guest writing a qcow2 header, I feel that having explicitly integration LUKS support in QCow is worthwhile as a concept. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|