On Thu, Jan 11, 2024 at 10:58 PM Daniel P. Berrangé <berra...@redhat.com>
wrote:
> On Thu, Jan 11, 2024 at 03:35:10PM +0100, Markus Armbruster wrote:
> > Hyman Huang <yong.hu...@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.hu...@smartx.com>
> > > Reviewed-by: Daniel P. Berrangé <berra...@redhat.com>
> > > Message-Id: <
> 5b99f60c7317092a563d7ca3fb4b414197015eb2.1701879996.git.yong.hu...@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
