Re: [PATCH RESEND v3 01/10] crypto: Introduce option and structure for detached LUKS header

[Yong Huang]

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