From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53963) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJevr-0003EU-As for qemu-devel@nongnu.org; Thu, 14 Jan 2016 05:15:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJevp-0005pR-PD for qemu-devel@nongnu.org; Thu, 14 Jan 2016 05:15:07 -0500 Date: Thu, 14 Jan 2016 10:14:56 +0000 From: "Daniel P. Berrange" Message-ID: <20160114101456.GD910@redhat.com> References: <1452624982-19332-1-git-send-email-berrange@redhat.com> <1452624982-19332-7-git-send-email-berrange@redhat.com> <5696E113.2010103@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <5696E113.2010103@redhat.com> Subject: Re: [Qemu-devel] [PATCH v1 06/15] crypto: implement the LUKS block encryption format Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: qemu-devel@nongnu.org, qemu-block@nongnu.org On Wed, Jan 13, 2016 at 04:43:15PM -0700, Eric Blake wrote: > On 01/12/2016 11:56 AM, Daniel P. Berrange wrote: > > Provide a block encryption implementation that follows the > > LUKS/dm-crypt specification. > > > > This supports all combinations of hash, cipher algorithm, > > cipher mode and iv generator that are implemented by the > > current crypto layer. > > > > The notable missing feature is support for the 'xts' > > cipher mode, which is commonly used for disk encryption > > instead of 'cbc'. This is because it is not provided by > > either nettle or libgcrypt. A suitable implementation > > will be identified & integrated later. > > > > There is support for opening existing volumes formatted > > by dm-crypt, and for formatting new volumes. In the latter > > case it will only use key slot 0. > > > > Signed-off-by: Daniel P. Berrange > > --- > > > +++ b/qapi/crypto.json > > @@ -101,12 +101,13 @@ > > # The supported full disk encryption formats > > # > > # @qcowaes: QCow/QCow2 built-in AES-CBC encryption. Do not use > > +# @luks: LUKS encryption format. Recommended > > # > > # Since: 2.6 > > ## > > { 'enum': 'QCryptoBlockFormat', > > # 'prefix': 'QCRYPTO_BLOCK_FORMAT', > > - 'data': ['qcowaes']} > > + 'data': ['qcowaes', 'luks']} > > > > ## > > # QCryptoBlockOptionsBase: > > @@ -134,6 +135,39 @@ > > 'data': { '*key-id': 'str' }} > > > > ## > > +# QCryptoBlockOptionsLUKS: > > +# > > +# The options that apply to LUKS encryption format > > +# > > +# @key-id: the ID of a QCryptoSecret object providing the decryption key > > Is the key-id really optional? If so, missing the '#optional' tag. Yes & no. It is not optional if you actually want to open the disk and do I/O, but we want 'qemu-img info' to be able to report on data when using the BDRV_O_NO_IO flag, so we have to declare it optional to allow that to work. This is why we have an explicit check for key_id being non-NULL in the code at time of use. 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 :|