qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 06/15] crypto: implement the LUKS block encry


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH v1 06/15] crypto: implement the LUKS block encryption format
Date: Thu, 14 Jan 2016 10:14:56 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

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 <address@hidden>
> > ---
> 
> > +++ 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 :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]