On Thu, Jun 23, 2016 at 13:29:05 -0400, John Ferlan wrote:
> For a luks device, allow the configuration of a specific cipher to be
> used for encrypting the volume.
>
> Signed-off-by: John Ferlan <jferlan@xxxxxxxxxx>
> ---
> docs/formatstorageencryption.html.in | 81 +++++++++++++-
> docs/schemas/storagecommon.rng | 44 +++++++-
> src/conf/domain_conf.c | 11 ++
> src/util/virstorageencryption.c | 124 +++++++++++++++++++++
> src/util/virstorageencryption.h | 13 +++
> .../qemuxml2argv-luks-disk-cipher.xml | 41 +++++++
> .../qemuxml2xmlout-luks-disk-cipher.xml | 45 ++++++++
> tests/qemuxml2xmltest.c | 1 +
> tests/storagevolxml2xmlin/vol-luks-cipher.xml | 23 ++++
> tests/storagevolxml2xmlout/vol-luks-cipher.xml | 23 ++++
> tests/storagevolxml2xmltest.c | 1 +
> 11 files changed, 401 insertions(+), 6 deletions(-)
> create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-luks-disk-cipher.xml
> create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-luks-disk-cipher.xml
> create mode 100644 tests/storagevolxml2xmlin/vol-luks-cipher.xml
> create mode 100644 tests/storagevolxml2xmlout/vol-luks-cipher.xml
>
> diff --git a/docs/formatstorageencryption.html.in b/docs/formatstorageencryption.html.in
> index 3a08192..80111e3 100644
> --- a/docs/formatstorageencryption.html.in
> +++ b/docs/formatstorageencryption.html.in
> @@ -71,6 +71,58 @@
> be used as the passphrase to decrypt the volume.
> <span class="since">Since 2.0.0</span>.
> </p>
> + <p>
> + For volume creation, it is possible to specify the encryption
> + algorithm used to encrypt the luks volume. The following two
> + optional elements may be provided for that purpose. It is hypervisor
> + dependent as to which algorithms are supported. The default algorithm
> + for QEMU is 'aes-256-cbc' using 'essiv' for initialization vector
At this point this is the default not for qemu, but for the 'DIR'
backend for the storage driver that is using qemu-img.
> + generation and 'sha256' hash algorithm for both the cipher and the
> + initialization vector generation.
> + </p>
> +
> + <dl>
> + <dt><code>cipher</code></dt>
> + <dd>This element describes the cipher algorithm to be used to either
> + encrypt or decrypt the luks volume. This element has the following
> + attributes:
> + <dl>
> + <dt><code>name</code></dt>
> + <dd>The name of the cipher algorithm used for data encryption,
> + such as 'aes', 'des', 'cast5', 'serpent', 'twofish', etc.
> + Support of the specific algorithm is hypervisor dependent.</dd>
This is storage driver implementation dependent.
> + <dt><code>size</code></dt>
> + <dd>The size of the cipher in bits, such as '256', '192', '128',
> + etc. Support of the specific size for a specific cipher is
> + hypervisor dependent.</dd>
> + <dt><code>mode</code></dt>
> + <dd>An optional cipher algorithm mode such as 'cbc', 'xts',
> + 'ecb', etc. Support of the specific cipher mode is
> + hypervisor dependent.</dd>
> + <dt><code>hash</code></dt>
> + <dd>An optional master key hash algorithm such as 'md5', 'sha1',
> + 'sha256', etc. Support of the specific hash algorithm is
> + hypervisor dependent.</dd>
> + </dl>
> + </dd>
> + <dt><code>ivgen</code></dt>
> + <dd>This optional element describes the initialization vector
> + generation algorithm used in conjunction with the
> + <code>cipher</code>. If the <code>cipher</code> is not provided,
> + then an error will be generated by the parser.
> + <dl>
> + <dt><code>name</code></dt>
> + <dd>The name of the algorithm, such as 'plain', 'plain64',
> + 'essiv', etc. Support of the specific algorithm is hypervisor
> + dependent.</dd>
> + <dt><code>hash</code></dt>
> + <dd>An optional hash algorithm such as 'md5', 'sha1', 'sha256',
> + etc. Support of the specific ivgen hash algorithm is hypervisor
> + dependent.</dd>
> + </dl>
> + </dd>
> + </dl>
> +
>
> <h2><a name="example">Examples</a></h2>
>
> @@ -84,9 +136,12 @@
> </encryption></pre>
>
> <p>
> - Here is a simple example, specifying use of the <code>luks</code> format
> - where it's assumed that a <code>secret</code> has been defined using a
> - <code>usage</code> element with a <code>id</code> of "luks_example":
> + Assuming a <a href="formatsecret.html#luksUsageType">
> + <code>luks secret</code></a> is already defined using a
> + <code>usage</code> element with an <code>id</code> of "luks_example",
s/id/name/
> + a simple example specifying use of the <code>luks</code> format
> + for either volume creation without a specific cipher being defined or
> + as part of a domain volume definition:
> </p>
> <pre>
> <encryption format='luks'>
> @@ -94,5 +149,25 @@
> </encryption>
> </pre>
>
> + <p>
> + Here is an example, specifying use of the <code>luks</code> format for
> + a specific cipher algorihm for volume creation:
> + </p>
> + <pre>
> + <volume>
> + <name>twofish.luks</name>
> + <capacity unit='G'>5</capacity>
> + <target>
> + <path>/var/lib/libvirt/images/demo.luks</path>
> + <format type='luks'/>
> + <encryption format='luks'>
> + <secret type='passphrase' usage='luks_example'/>
> + <cipher name='twofish' size='256' mode='cbc' hash='sha256'/>
> + <ivgen name='plain64' hash='sha256'/>
> + </encryption>
> + </target>
> + </volume>
> + </pre>
> +
> </body>
> </html>
[...]
> diff --git a/src/util/virstorageencryption.h b/src/util/virstorageencryption.h
> index 5e1be3b..34bba03 100644
> --- a/src/util/virstorageencryption.h
> +++ b/src/util/virstorageencryption.h
> @@ -44,6 +44,16 @@ struct _virStorageEncryptionSecret {
> virSecretLookupTypeDef seclookupdef;
> };
>
> +/* For a key type it's possible to dictate the cipher and if necessary iv */
> +typedef struct _virStorageEncryptionInfoDef virStorageEncryptionInfoDef;
> +typedef virStorageEncryptionInfoDef *virStorageEncryptionInfoDefPtr;
> +struct _virStorageEncryptionInfoDef {
> + unsigned int size;
> + char *name;
> + char *mode;
> + char *hash;
I'd either store the IV generator info here or add a different
structure. It seems weird to reuse it just because it has two fields
with same name.
> +};
> +
> typedef enum {
> /* "default" is only valid for volume creation */
> VIR_STORAGE_ENCRYPTION_FORMAT_DEFAULT = 0,
[...]
> virStorageEncryptionPtr virStorageEncryptionCopy(const virStorageEncryption *src)
> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-luks-disk-cipher.xml b/tests/qemuxml2argvdata/qemuxml2argv-luks-disk-cipher.xml
> new file mode 100644
> index 0000000..00399cf
> --- /dev/null
> +++ b/tests/qemuxml2argvdata/qemuxml2argv-luks-disk-cipher.xml
[...]
> diff --git a/tests/qemuxml2xmloutdata/qemuxml2xmlout-luks-disk-cipher.xml b/tests/qemuxml2xmloutdata/qemuxml2xmlout-luks-disk-cipher.xml
> new file mode 100644
> index 0000000..9ce15c0
> --- /dev/null
> +++ b/tests/qemuxml2xmloutdata/qemuxml2xmlout-luks-disk-cipher.xml
Again the output file is not really needed:
$ diff -u qemuxml2argvdata/qemuxml2argv-luks-disk-cipher.xml qemuxml2xmloutdata/qemuxml2xmlout-luks-disk-cipher.xml
--- qemuxml2argvdata/qemuxml2argv-luks-disk-cipher.xml 2016-06-24 15:55:42.059454563 +0200
+++ qemuxml2xmloutdata/qemuxml2xmlout-luks-disk-cipher.xml 2016-06-24 15:55:42.059454563 +0200
@@ -32,10 +32,14 @@
</encryption>
<address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
</disk>
- <controller type='usb' index='0'/>
+ <controller type='usb' index='0'>
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
+ </controller>
<controller type='pci' index='0' model='pci-root'/>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
- <memballoon model='virtio'/>
+ <memballoon model='virtio'>
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
+ </memballoon>
</devices>
</domain>
Difference to the test files added in previous patch makes this test
even less useful:
$ diff -u qemuxml2argvdata/qemuxml2argv-luks-disk-cipher.xml qemuxml2argvdata/qemuxml2argv-luks-disks.xml
$
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list