Add the "header" option for the LUKS format. This field would be
used to identify the blockdev's position where a detachable LUKS
header is stored.
In addition, introduce header field in struct BlockCrypto
Signed-off-by: Hyman Huang <yong.huang@smartx.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <5b99f60c7317092a563d7ca3fb4b414197015eb2.1701879996.git.yong.huang@smartx.com>
---
block/crypto.c | 1 +
qapi/block-core.json | 6 +++++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/block/crypto.c b/block/crypto.c
index 921933a5e5..f82b13d32b 100644
--- a/block/crypto.c
+++ b/block/crypto.c
@@ -39,6 +39,7 @@ typedef struct BlockCrypto BlockCrypto;
struct BlockCrypto {
QCryptoBlock *block;
bool updating_keys;
+ BdrvChild *header; /* Reference to the detached LUKS header */
};
diff --git a/qapi/block-core.json b/qapi/block-core.json
index ca390c5700..10be08d08f 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 header. (since 9.0)
+#
# Since: 2.9
##
{ 'struct': 'BlockdevOptionsLUKS',
'base': 'BlockdevOptionsGenericFormat',
- 'data': { '*key-secret': 'str' } }
+ 'data': { '*key-secret': 'str',
+ '*header': 'BlockdevRef'} }
##
# @BlockdevOptionsGenericCOWFormat:
--
2.39.1
Hyman Huang <yong.huang@smartx.com> writes:
> Add the "header" option for the LUKS format. This field would be
> used to identify the blockdev's position where a detachable LUKS
> header is stored.
>
> In addition, introduce header field in struct BlockCrypto
>
> Signed-off-by: Hyman Huang <yong.huang@smartx.com>
> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> Message-Id: <5b99f60c7317092a563d7ca3fb4b414197015eb2.1701879996.git.yong.huang@smartx.com>
> ---
> block/crypto.c | 1 +
> qapi/block-core.json | 6 +++++-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/block/crypto.c b/block/crypto.c
> index 921933a5e5..f82b13d32b 100644
> --- a/block/crypto.c
> +++ b/block/crypto.c
> @@ -39,6 +39,7 @@ typedef struct BlockCrypto BlockCrypto;
> struct BlockCrypto {
> QCryptoBlock *block;
> bool updating_keys;
> + BdrvChild *header; /* Reference to the detached LUKS header */
> };
>
>
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index ca390c5700..10be08d08f 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 header. (since 9.0)
This will come out like
"header": "BlockdevRef" (optional)
optional reference to the location of a blockdev storing a detached
LUKS header. (since 9.0)
in the manual. Scratch "optional".
Moreover, a BlockdevRef is a "Reference to a block device" (quote from
its doc comment), not a "reference to the location of a blockdev".
Better simplify to something like "block device holding a detached LUKS
header".
But that's just phrasing. The contents could perhaps use improvement,
too. Let's start with this question: what's a detachable LUKS header,
and why would anybody want to use it?
> +#
> # Since: 2.9
> ##
> { 'struct': 'BlockdevOptionsLUKS',
> 'base': 'BlockdevOptionsGenericFormat',
> - 'data': { '*key-secret': 'str' } }
> + 'data': { '*key-secret': 'str',
> + '*header': 'BlockdevRef'} }
>
> ##
> # @BlockdevOptionsGenericCOWFormat:
On Thu, Jan 11, 2024 at 03:35:10PM +0100, Markus Armbruster wrote:
> Hyman Huang <yong.huang@smartx.com> writes:
>
> > Add the "header" option for the LUKS format. This field would be
> > used to identify the blockdev's position where a detachable LUKS
> > header is stored.
> >
> > In addition, introduce header field in struct BlockCrypto
> >
> > Signed-off-by: Hyman Huang <yong.huang@smartx.com>
> > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> > Message-Id: <5b99f60c7317092a563d7ca3fb4b414197015eb2.1701879996.git.yong.huang@smartx.com>
> > ---
> > block/crypto.c | 1 +
> > qapi/block-core.json | 6 +++++-
> > 2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/block/crypto.c b/block/crypto.c
> > index 921933a5e5..f82b13d32b 100644
> > --- a/block/crypto.c
> > +++ b/block/crypto.c
> > @@ -39,6 +39,7 @@ typedef struct BlockCrypto BlockCrypto;
> > struct BlockCrypto {
> > QCryptoBlock *block;
> > bool updating_keys;
> > + BdrvChild *header; /* Reference to the detached LUKS header */
> > };
> >
> >
> > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > index ca390c5700..10be08d08f 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 header. (since 9.0)
>
> This will come out like
>
> "header": "BlockdevRef" (optional)
> optional reference to the location of a blockdev storing a detached
> LUKS header. (since 9.0)
>
> in the manual. Scratch "optional".
>
> Moreover, a BlockdevRef is a "Reference to a block device" (quote from
> its doc comment), not a "reference to the location of a blockdev".
> Better simplify to something like "block device holding a detached LUKS
> header".
>
> But that's just phrasing. The contents could perhaps use improvement,
> too. Let's start with this question: what's a detachable LUKS header,
> and why would anybody want to use it?
Normally a LUKS volume has a layout:
disk: | header | key material | disk payload data |
With a detached LUKS header, you need 2 disks so getting
disk1: | header | key material |
disk2: | disk payload data |
There are a variety of reasons to do this
* Secrecy - the disk2 cannot be identified as containing LUKS volume
since there's no header
* Control - if access to the disk1 is restricted, then even if someone
has access to disk2 they can't unlock it. Might be useful
if you have disks on NFS but want to restrict which host
can launch a VM instance from it, by dynamically providing
access to the header to a designated host
* Flexibility - your application data volume may be a given size and
it is inconvenient to resize it to add encryption.
You can store the LUKS header separately and use
the existing storage volume for payload
* Recovery - corruption of a bit in the header may make the entire
payload inaccessible. It might be convenient to take
backups of the header. If your primary disk header
becomes corrupt, you can unlock the data still by
pointing to the backup detached header.
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 :|
On Thu, Jan 11, 2024 at 10:58 PM Daniel P. Berrangé <berrange@redhat.com>
wrote:
> On Thu, Jan 11, 2024 at 03:35:10PM +0100, Markus Armbruster wrote:
> > Hyman Huang <yong.huang@smartx.com> writes:
> >
> > > Add the "header" option for the LUKS format. This field would be
> > > used to identify the blockdev's position where a detachable LUKS
> > > header is stored.
> > >
> > > In addition, introduce header field in struct BlockCrypto
> > >
> > > Signed-off-by: Hyman Huang <yong.huang@smartx.com>
> > > Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
> > > Message-Id: <
> 5b99f60c7317092a563d7ca3fb4b414197015eb2.1701879996.git.yong.huang@smartx.com
> >
> > > ---
> > > block/crypto.c | 1 +
> > > qapi/block-core.json | 6 +++++-
> > > 2 files changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/block/crypto.c b/block/crypto.c
> > > index 921933a5e5..f82b13d32b 100644
> > > --- a/block/crypto.c
> > > +++ b/block/crypto.c
> > > @@ -39,6 +39,7 @@ typedef struct BlockCrypto BlockCrypto;
> > > struct BlockCrypto {
> > > QCryptoBlock *block;
> > > bool updating_keys;
> > > + BdrvChild *header; /* Reference to the detached LUKS header */
> > > };
> > >
> > >
> > > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > > index ca390c5700..10be08d08f 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 header. (since 9.0)
> >
> > This will come out like
> >
> > "header": "BlockdevRef" (optional)
> > optional reference to the location of a blockdev storing a
> detached
> > LUKS header. (since 9.0)
> >
> > in the manual. Scratch "optional".
> >
> > Moreover, a BlockdevRef is a "Reference to a block device" (quote from
> > its doc comment), not a "reference to the location of a blockdev".
> > Better simplify to something like "block device holding a detached LUKS
> > header".
> >
> > But that's just phrasing. The contents could perhaps use improvement,
> > too. Let's start with this question: what's a detachable LUKS header,
> > and why would anybody want to use it?
>
> Normally a LUKS volume has a layout:
>
> disk: | header | key material | disk payload data |
>
> With a detached LUKS header, you need 2 disks so getting
>
> disk1: | header | key material |
> disk2: | disk payload data |
>
> There are a variety of reasons to do this
>
> * Secrecy - the disk2 cannot be identified as containing LUKS volume
> since there's no header
>
> * Control - if access to the disk1 is restricted, then even if someone
> has access to disk2 they can't unlock it. Might be useful
> if you have disks on NFS but want to restrict which host
> can launch a VM instance from it, by dynamically providing
> access to the header to a designated host
>
> * Flexibility - your application data volume may be a given size and
> it is inconvenient to resize it to add encryption.
> You can store the LUKS header separately and use
> the existing storage volume for payload
>
> * Recovery - corruption of a bit in the header may make the entire
> payload inaccessible. It might be convenient to take
> backups of the header. If your primary disk header
> becomes corrupt, you can unlock the data still by
> pointing to the backup detached header.
>
Thank you, Daniel, for the incisive summary. IMHO, the reason listed
above could be added to the document directly :) .
>
> 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 :|
>
>
--
Best regards
© 2016 - 2024 Red Hat, Inc.