From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56187) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1afTTG-0007we-MK for qemu-devel@nongnu.org; Mon, 14 Mar 2016 10:27:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1afTTA-00087C-LN for qemu-devel@nongnu.org; Mon, 14 Mar 2016 10:27:46 -0400 Date: Mon, 14 Mar 2016 14:27:29 +0000 From: "Daniel P. Berrange" Message-ID: <20160314142729.GD21198@redhat.com> References: <1456747261-22032-1-git-send-email-berrange@redhat.com> <1456747261-22032-14-git-send-email-berrange@redhat.com> <56E3475F.1080207@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56E3475F.1080207@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 13/26] 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: Fam Zheng , qemu-devel@nongnu.org, qemu-block@nongnu.org On Fri, Mar 11, 2016 at 03:31:59PM -0700, Eric Blake wrote: > On 02/29/2016 05:00 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. > > Stale paragraph, you implemented it earlier in the series. > > > > > 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 > > --- > > > > +static int > > +qcrypto_block_luks_open(QCryptoBlock *block, > > + QCryptoBlockOpenOptions *options, > > + QCryptoBlockReadFunc readfunc, > > + void *opaque, > > + unsigned int flags, > > + Error **errp) > > +{ > > > + /* Read the entire LUKS header, minus the key material from > > + * the underling device */ > > s/underling/underlying/ (although the typo does read rather humorously - > I now have a mental image of a LUKS overlord :) > > > > +++ b/qapi/crypto.json > > @@ -117,12 +117,13 @@ > > > ## > > # QCryptoBlockOptionsBase: > > @@ -143,7 +144,8 @@ > > # The options that apply to QCow/QCow2 AES-CBC encryption format > > # > > # @key-secret: #optional the ID of a QCryptoSecret object providing the > > -# decryption key > > +# decryption key. Mandatory except when probing image for > > +# metadata only. > > Aha - I think this hunk may belong earlier in the series... Yes, it does belong in the previous patch. > > > # > > # Since: 2.6 > > ## > > @@ -151,6 +153,45 @@ > > 'data': { '*key-secret': 'str' }} > > > > ## > > +# QCryptoBlockOptionsLUKS: > > +# > > +# The options that apply to LUKS encryption format > > +# > > +# @key-secret: #optional the ID of a QCryptoSecret object providing the > > +# decryption key > > ...Although you may want to duplicate it here. Yep, will do. 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 :|