Re: [RFC 0/8] Support generic Luks encryption

[Daniel P . Berrangé]

On Tue, Dec 05, 2023 at 09:51:21AM +0800, Yong Huang wrote:
> Let me make a conclusion about our discussion, if i
> misunderstand something,
> point that out please:
> 
> 1. To achieve the generic encryption,  extending the pre-existing LUKS QEMU
>    block driver is suggested in practice.

yes

> 
> 2. Introducing a optional field called "header-file" that store the LUKS
> header
>    independently, and once "header-file" was specified, we should use it to
>    encrypt/decrypt the blockdev node referenced by the "file" field.

Yes.

> 
> The blockdev tree is like:
>          virtio-blk/vhost-user-blk...(frontend device)
>                        ^
>                         |
>                     LUKS
>              /                     \
>          file               header-file
>          /                             \
> data protocol node    LUKS header protocol node


That is one possible blockdev tree, but there are many possible
variations.

> 3. The usage of the generic LUKS is like:
> 
> Take the qcow2 as an example:
> 
> 1. add a protocol blockdev node of data disk
> $ virsh qemu-monitor-command vm '{"execute":"blockdev-add",
>   "arguments":{"node-name": "libvirt-1-storage", "driver": "file",
>   "filename": "/path/to/test_disk.qcow2"}}'
> 
> 2. add a protocol blockdev node of Luks header as above.
> $ virsh qemu-monitor-command vm '{"execute":"blockdev-add",
>   "arguments":{"node-name": "libvirt-2-storage", "driver": "file",
>   "filename": "/path/to/cipher.gluks" }}'
> 
> 3. add the secret for decrypting the cipher stored in Gluks header as
>    above
> $ virsh qemu-monitor-command vm '{"execute":"object-add",
>   "arguments":{"qom-type": "secret", "id":
>   "libvirt-2-storage-secret0", "data": "abc123"}}'
> 
> 4. add the qcow2-drived blockdev format node:
> $ virsh qemu-monitor-command vm '{"execute":"blockdev-add",
>   "arguments":{"node-name": "libvirt-1-format", "driver": "qcow2",
>   "file": "libvirt-1-storage"}}'
> 
> 5. add the luks-drived blockdev to connect the qcow2 disk with Luks
>    header by specifying the field "header-file"
> $ virsh qemu-monitor-command vm '{"execute":"blockdev-add",
>   "arguments":{"node-name": "libvirt-2-format", "driver": "luks",
>   "file": "libvirt-1-format", "header-file": "libvirt-2-storage",
>   "key-secret": "libvirt-2-format-secret0"}}'
> 
> 6. add the device finally
> $ virsh qemu-monitor-command vm '{"execute":"device_add",
>   "arguments": {"num-queues": "1", "driver": "virtio-blk-pci", "scsi":
>   "off", "drive": "libvirt-2-format", "id": "virtio-disk2"}}'

Yes, that looks like a valid sequence of steps.

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 :|