From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40871) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afpa3-0005OU-AW for qemu-devel@nongnu.org; Tue, 15 Mar 2016 10:04:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afpZx-0005eF-DA for qemu-devel@nongnu.org; Tue, 15 Mar 2016 10:04:15 -0400 Date: Tue, 15 Mar 2016 14:03:55 +0000 From: "Daniel P. Berrange" Message-ID: <20160315140355.GE3168@redhat.com> References: <1456747261-22032-1-git-send-email-berrange@redhat.com> <1456747261-22032-20-git-send-email-berrange@redhat.com> <56E81537.5020005@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56E81537.5020005@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 19/26] block: add generic full disk encryption driver Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: Fam Zheng , qemu-devel@nongnu.org, qemu-block@nongnu.org On Tue, Mar 15, 2016 at 07:59:19AM -0600, Eric Blake wrote: > On 02/29/2016 05:00 AM, Daniel P. Berrange wrote: > > Add a block driver that is capable of supporting any full disk > > encryption format. This utilizes the previously added block > > encryption code, and at this time supports the LUKS format. > > > > The driver code is capable of supporting any format supported > > by the QCryptoBlock module, so it registers one block driver > > for each format. > > > > At this time, the "luks" driver is registered. New LUKS > > compatible volume can be formatted using qemu-img with > > defaults for all settings. > > Sounds a bit redundant between the 1st and 3rd paragraph; but I'm not > sure if I have any suggestions on shortening it for only a single > mention that LUKS is the first (and so far only) supported driver. > > > > > $ qemu-img create --object secret,data=123456,id=sec0 \ > > -f luks -o key-secret=sec0 demo.luks 10G > > > > Alternatively the cryptographic settings can explicitly > > set > > > > $ qemu-img create --object secret,data=123456,id=sec0 \ > > -f luks -o key-secret=sec0,cipher-alg=aes-256,\ > > cipher-mode=cbc,ivgen-alg=plain64,hash-alg=sha256 \ > > demo.luks 10G > > > > And query its size > > > > $ qemu-img info demo.img > > image: demo.img > > file format: luks > > virtual size: 10G (10737418240 bytes) > > disk size: 132K > > encrypted: yes > > > > Note that it was not neccessary to provide the password > > s/neccessary/necessary/ > > > when querying info for the volume. The password is only > > required when performing I/O on the volume > > > > All volumes created by this new 'luks' driver should be > > capable of being opened by the kernel dm-crypt driver. > > > > The only algorithms listed in the LUKS spec that are > > not currently supported by this impl are sha512 and > > ripemd160 hashes and cast6 cipher. > > > > A new I/O test is added which is used to validate the > > interoperability of the QEMU implementation of LUKS, > > with the dm-crypt/cryptsetup implementation. Due to > > the need to run cryptsetup as root, this test requires > > that the user have password-less sudo configured. > > and therefore, the test better not be run by default, but by an explicit > target. Worth spelling out what that target is? [1] Yes, for reference it is cd tests/qemu-iotests ./check -luks 146 ...and then wait a long time :-) In theory the other pre-existing I/O tests should also pass, but the current I/O test infrastructure isn't clever enough to provide the key secrets needed when creating the images. I'll be working on fixing this test suite limitation later... 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 :|