[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC 0/8] Support generic Luks encryption
From: |
Daniel P . Berrangé |
Subject: |
Re: [RFC 0/8] Support generic Luks encryption |
Date: |
Mon, 4 Dec 2023 16:24:11 +0000 |
User-agent: |
Mutt/2.2.10 (2023-03-25) |
On Tue, Dec 05, 2023 at 12:06:17AM +0800, Hyman Huang wrote:
> This functionality was motivated by the following to-do list seen
> in crypto documents:
> https://wiki.qemu.org/Features/Block/Crypto
>
> The last chapter says we should "separate header volume":
>
> The LUKS format has ability to store the header in a separate volume
> from the payload. We should extend the LUKS driver in QEMU to support
> this use case.
>
> As a proof-of-concept, I've created this patchset, which I've named
> the Gluks: generic luks. As their name suggests, they offer encryption
> for any format that QEMU theoretically supports.
I don't see the point in creating a new driver.
I would expect detached header support to be implemented via an
optional new 'header' field in the existing driver. ie
diff --git a/qapi/block-core.json b/qapi/block-core.json
index ca390c5700..48d1f2a974 100644
--- a/qapi/block-core.json
+++ b/qapi/block-core.json
@@ -3352,11 +3352,15 @@
# decryption key (since 2.6). Mandatory except when doing a
# metadata-only probe of the image.
#
+# @header: optional reference to the location of a blockdev
+# storing a detached LUKS heaer
+#
# Since: 2.9
##
{ 'struct': 'BlockdevOptionsLUKS',
'base': 'BlockdevOptionsGenericFormat',
- 'data': { '*key-secret': 'str' } }
+ 'data': { '*key-secret': 'str',
+ "*header-file': 'BlockdevRef'} }
##
# @BlockdevOptionsGenericCOWFormat:
@@ -4941,9 +4945,18 @@
#
# Driver specific image creation options for LUKS.
#
-# @file: Node to create the image format on
+# @file: Node to create the image format on. Mandatory
+# unless a detached header file is specified using
+# @header.
#
-# @size: Size of the virtual disk in bytes
+# @size: Size of the virtual disk in bytes. Mandatory
+# unless a detached header file is specified using
+# @header.
+#
+# @header: optional reference to the location of a blockdev
+# storing a detached LUKS heaer. The @file option is
+# is optional when this is given, unless it is desired
+# to perform pre-allocation
#
# @preallocation: Preallocation mode for the new image (since: 4.2)
# (default: off; allowed values: off, metadata, falloc, full)
@@ -4952,8 +4965,9 @@
##
{ 'struct': 'BlockdevCreateOptionsLUKS',
'base': 'QCryptoBlockCreateOptionsLUKS',
- 'data': { 'file': 'BlockdevRef',
- 'size': 'size',
+ 'data': { '*file': 'BlockdevRef',
+ '*size': 'size',
+ '*header': 'BlockdevRef'
'*preallocation': 'PreallocMode' } }
##
It ends up giving basicallly the same workflow as you outline,
without needing the new block driver
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
- [RFC 0/8] Support generic Luks encryption, Hyman Huang, 2023/12/04
- [RFC 1/8] crypto: Export util functions and structures, Hyman Huang, 2023/12/04
- [RFC 2/8] crypto: Introduce payload offset set function, Hyman Huang, 2023/12/04
- [RFC 3/8] Gluks: Add the basic framework, Hyman Huang, 2023/12/04
- [RFC 4/8] Gluks: Introduce Gluks options, Hyman Huang, 2023/12/04
- [RFC 6/8] crypto: Provide the Luks crypto driver to Gluks, Hyman Huang, 2023/12/04
- [RFC 7/8] Gluks: Implement the fundamental block layer driver hooks, Hyman Huang, 2023/12/04
- [RFC 5/8] qapi: Introduce Gluks types to qapi, Hyman Huang, 2023/12/04
- [RFC 8/8] block: Support Gluks format image creation using qemu-img, Hyman Huang, 2023/12/04
- Re: [RFC 0/8] Support generic Luks encryption,
Daniel P . Berrangé <=
- Re: [RFC 0/8] Support generic Luks encryption, Yong Huang, 2023/12/04
- Re: [RFC 0/8] Support generic Luks encryption, Yong Huang, 2023/12/04
- Re: [RFC 0/8] Support generic Luks encryption, Daniel P . Berrangé, 2023/12/04
- Re: [RFC 0/8] Support generic Luks encryption, Yong Huang, 2023/12/04
- Re: [RFC 0/8] Support generic Luks encryption, Daniel P . Berrangé, 2023/12/04
- Re: [RFC 0/8] Support generic Luks encryption, Yong Huang, 2023/12/04
- Re: [RFC 0/8] Support generic Luks encryption, Daniel P . Berrangé, 2023/12/05
- Re: [RFC 0/8] Support generic Luks encryption, Kevin Wolf, 2023/12/05