On Tue, Dec 5, 2023 at 12:24 AM Daniel P. Berrangé <berra...@redhat.com> wrote:
> 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 > How about the design and usage, could it be simpler? Any advice? :) As you can see below, the Gluks format block layer driver's design is quite simple. virtio-blk/vhost-user-blk...(front-end device) ^ | Gluks (format-like disk node) / \ file header (blockdev reference) / \ file file (protocol node) | | disk data Luks data > > 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
