From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Yong Huang <yong.huang@smartx.com>
Cc: qemu-devel@nongnu.org, Kevin Wolf <kwolf@redhat.com>,
Hanna Reitz <hreitz@redhat.com>, Eric Blake <eblake@redhat.com>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [RFC 0/8] Support generic Luks encryption
Date: Tue, 5 Dec 2023 11:37:16 +0000 [thread overview]
Message-ID: <ZW8LbPcGOE10hQZD@redhat.com> (raw)
In-Reply-To: <CAK9dgmbhJ+UVn3oTkjsshMOPAqdmXnywNk1jZsQ3BD+BN131fQ@mail.gmail.com>
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 :|
next prev parent reply other threads:[~2023-12-05 11:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-04 16:06 [RFC 0/8] Support generic Luks encryption Hyman Huang
2023-12-04 16:06 ` [RFC 1/8] crypto: Export util functions and structures Hyman Huang
2023-12-04 16:06 ` [RFC 2/8] crypto: Introduce payload offset set function Hyman Huang
2023-12-04 16:06 ` [RFC 3/8] Gluks: Add the basic framework Hyman Huang
2023-12-04 16:06 ` [RFC 4/8] Gluks: Introduce Gluks options Hyman Huang
2023-12-04 16:06 ` [RFC 5/8] qapi: Introduce Gluks types to qapi Hyman Huang
2023-12-04 16:06 ` [RFC 6/8] crypto: Provide the Luks crypto driver to Gluks Hyman Huang
2023-12-04 16:06 ` [RFC 7/8] Gluks: Implement the fundamental block layer driver hooks Hyman Huang
2023-12-04 16:06 ` [RFC 8/8] block: Support Gluks format image creation using qemu-img Hyman Huang
2023-12-04 16:24 ` [RFC 0/8] Support generic Luks encryption Daniel P. Berrangé
2023-12-04 16:32 ` Yong Huang
2023-12-04 16:41 ` Yong Huang
2023-12-04 16:51 ` Daniel P. Berrangé
2023-12-04 17:32 ` Yong Huang
2023-12-04 17:43 ` Daniel P. Berrangé
2023-12-05 1:51 ` Yong Huang
2023-12-05 11:37 ` Daniel P. Berrangé [this message]
2023-12-05 11:27 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZW8LbPcGOE10hQZD@redhat.com \
--to=berrange@redhat.com \
--cc=armbru@redhat.com \
--cc=eblake@redhat.com \
--cc=hreitz@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=yong.huang@smartx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).