On 01/12/2016 11:56 AM, Daniel P. Berrange wrote: > Add a generic framework for support different block encryption > formats. Upon instantiating a QCryptoBlock object, it will read > the encryption header and extract the encryption keys. It is > then possible to call methods to encrypt/decrypt data buffers. > > There is also a mode whereby it will create/initialize a new > encryption header on a previously unformatted volume. > > The initial framework comes with support for the legacy QCow > AES based encryption. This enables code in the QCow driver to > be consolidated later. > > Signed-off-by: Daniel P. Berrange <berra...@redhat.com> > ---
> +++ b/qapi/crypto.json
> @@ -94,3 +94,68 @@
> { 'enum': 'QCryptoIVGenAlgorithm',
> 'prefix': 'QCRYPTO_IVGEN_ALG',
> 'data': ['plain', 'plain64', 'essiv']}
> +
> +##
> +# QCryptoBlockFormat:
> +#
> +# The supported full disk encryption formats
> +#
> +# @qcowaes: QCow/QCow2 built-in AES-CBC encryption. Do not use
> +#
Well, the only reason to use it would be to read data off an old
insecurely-encrypted qcow2 file; so maybe it should read "Do not use on
new files"
> +# Since: 2.6
> +##
> +{ 'enum': 'QCryptoBlockFormat',
> +# 'prefix': 'QCRYPTO_BLOCK_FORMAT',
> + 'data': ['qcowaes']}
Would 'qcow-aes' be any easier to read?
> +
> +##
> +# QCryptoBlockOptionsBase:
> +#
> +# The common options that apply to all full disk
> +# encryption formats
> +#
> +# @format: the encryption format
> +#
> +# Since: 2.6
> +##
> +{ 'struct': 'QCryptoBlockOptionsBase',
> + 'data': { 'format': 'QCryptoBlockFormat' }}
My pending series to add anonymous flat union base types can simplify
this a bit; I've added it to my list of cleanups that are awaiting merge
of my code.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
