Re: [PATCH v4 5/5] conf: add luks2 encryption format

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

 



On Thu, Oct 07, 2021 at 14:21:21 -0500, Or Ozeri wrote:
> This commit extends libvirt XML configuration to support luks2 encryption format.
> This means that <encryption format="luks2" engine="librbd"> becomes valid.
> Currently librbd is the only engine that supports this new format.
> 
> Signed-off-by: Or Ozeri <oro@xxxxxxxxxx>
> ---
>  docs/formatstorageencryption.html.in             | 12 +++++++++++-
>  docs/schemas/storagecommon.rng                   |  1 +
>  src/conf/storage_encryption_conf.c               |  2 +-
>  src/conf/storage_encryption_conf.h               |  1 +
>  src/qemu/qemu_block.c                            |  5 +++++
>  src/qemu/qemu_domain.c                           |  5 ++++-
>  ...isk-network-rbd-encryption.x86_64-latest.args | 16 ++++++++++------
>  .../disk-network-rbd-encryption.xml              | 12 ++++++++++++
>  ...disk-network-rbd-encryption.x86_64-latest.xml | 13 +++++++++++++
>  9 files changed, 58 insertions(+), 9 deletions(-)
> 
> diff --git a/docs/formatstorageencryption.html.in b/docs/formatstorageencryption.html.in
> index 02ee8f8ca3..6cf1f94a9f 100644
> --- a/docs/formatstorageencryption.html.in
> +++ b/docs/formatstorageencryption.html.in

[...]

> @@ -121,6 +121,16 @@
>        </dd>
>      </dl>
>  
> +    <h3><a id="StorageEncryptionLuks2">"luks2" format</a></h3>
> +    <p>
> +      The <code>luks2</code> format is currently supported only by the
> +      <code>librbd</code> engine, and can only be applied to RBD network disks.
> +      <code>luks2</code> encrypted RBD disks can be decrypted by the domain,
> +      but creation of such disks is currently not supported through libvirt.
> +      A single
> +      <code>&lt;secret type='passphrase'...&gt;</code> element is expected.
> +    </p>

As noted before this doesn't really tell what's happening in the storage
driver, so it will need some tweaking.


> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 13869dd79b..8c2a5408da 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -1228,7 +1228,8 @@ static bool
>  qemuDomainDiskHasEncryptionSecret(virStorageSource *src)
>  {
>      if (!virStorageSourceIsEmpty(src) && src->encryption &&
> -        src->encryption->format == VIR_STORAGE_ENCRYPTION_FORMAT_LUKS &&
> +        (src->encryption->format == VIR_STORAGE_ENCRYPTION_FORMAT_LUKS ||
> +         src->encryption->format == VIR_STORAGE_ENCRYPTION_FORMAT_LUKS2) &&
>          src->encryption->nsecrets > 0)
>          return true;
>  
> @@ -4820,6 +4821,7 @@ qemuDomainValidateStorageSource(virStorageSource *src,
>                          break;
>  
>                      case VIR_STORAGE_ENCRYPTION_FORMAT_DEFAULT:
> +                    case VIR_STORAGE_ENCRYPTION_FORMAT_LUKS2:
>                      case VIR_STORAGE_ENCRYPTION_FORMAT_LAST:
>                      default:
>                          virReportEnumRangeError(virStorageEncryptionFormatType,

Same problem as in previous patch. This creates an error message which
is not really descriptive.

Again both seem to be easy enough for me to do before pushing if you are
okay with it.

Reviewed-by: Peter Krempa <pkrempa@xxxxxxxxxx>

(Note that I'm on PTO until Monday).




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux