Hi,
for <https://bugzilla.redhat.com/show_bug.cgi?id=1658126>, I'll soon
post four short patch sets in response to this email (I'm sending this
email basically as a common cover letter for those sets, for better
threading).
The main difference (for libguestfs & co) between LUKS-on-LVM and
LVM-on-LUKS is that in the latter, the names of the decrypted LUKS block
devices don't matter. However we name the decrypted devices via
inspect_do_decrypt() -> make_mapname() in
"common/options/decrypt.c" is
irrelevant, as LVM will scan for PVs on all block devices, regardless of
their names. The resultant LVs (hosting the filesystems) are what
"/etc/fstab" refers to, and we can deal with those names -- the VG and
LV names -- well, because (a) there is an "lvs" command (and API) for
enumeration (see "lv_canonical" in "daemon/lvm_utils.ml",
and
lv_canonical() in "daemon/lvm.c" -- see also commit c37c8e770d664),
and
(b) the VG and LV names are stored in the LVM metadata, so libguestfs
doesn't have to "invent" names.
This is not the case with LUKS-on-LVM. The names of the decrypted LUKS
devices is relevant, as they directly host filesystems, and
"/etc/fstab"
likely refers to them. Furthermore, there is no enumeration / scanning
inside the guest, only a file called "/etc/crypttab". Unfortunately,
the
root filesystem containing "/etc/crypttab" tends to exist on a LUKS
device as well, so we can't consult it for determining the decrypted
device names when we're about to decrypt those same devices in
inspect_do_decrypt(). (This circular dependency is circumvented during
normal guest boot by having a plaintext initrd containing a copy of
"/etc/crypttab", and LUKS-related parameters on the a kernel command
line in the bootloader config.)
In fact, since at least RHEL6, when the user selects either LVM-on-LUKS
or LUKS-on-LVM in Anaconda, the installer never asks for LUKS device
names (while it does let the user set VG and LV names). Instead, for a
given LUKS header containing UUID <UUID>, the decrypted block device
will automatically be named /dev/mapper/luks-<UUID>. (Anaconda sets up
"/etc/crypttab" and "/etc/fstab" like that.)
The patches I'm about to post follow the same logic -- I don't attempt
intricate UUID-based (re)mappings through "/etc/crypttab", in
"check_fstab_entry" -> "resolve_fstab_device", in
"daemon/inspect_fs_unix_fstab.ml".
(Assume that "/etc/fstab" refers to "/dev/mapper/hunter2" as
a plaintext
block device to mount.
Assume that "/etc/crypttab" associates the "hunter2" device
name with a
block device containing a LUKS header with UUID
28372dec-afca-412a-a089-736437fd03af. (For us to realize this, we'd need
to parse "/etc/crypttab" with Augeas in the first place.)
Then we'd have to recall, by UUID, that we had mapped that particular
LUKS device as "/dev/mapper/crypt<WHATEVER>" in
inspect_do_decrypt().
Then either close and reopen the LUKS device as "hunter2" (there is no
rename operation!), which could get messy as the dependent filesystem
would be in use, or replace "hunter2" with
"crypt<WHATEVER>" in both
"/etc/fstab" and "/etc/crypttab".)
Instead, accept the "/dev/mapper/luks-<UUID>" naming scheme as
the
standard one. Thus, inspect_do_decrypt() will name the decrypted block
device "/dev/mapper/luks-<UUID>" at once (rather than
"/dev/mapper/crypt<WHATEVER>"). And that name is expected to
match the
references in "/etc/fstab" and "/etc/crypttab".
I've tested this with RHEL-6 and RHEL-7 guests successfully (using
"guestfish -i", "virt-inspector", and virt-v2v). Example
"lsblk"
outputs, with "lsblk" executed in the converted domains:
RHEL6:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 1024M 0 rom
vda 252:0 0 20G 0 disk
??vda1 252:1 0 500M 0 part /boot
??vda2 252:2 0 19.5G 0 part
??vg_rhel6luks-root (dm-0) 253:0 0 14.7G 0 lvm
? ??luks-0d619854-ccd5-43b1-8883-991fec5ef713 (dm-2)
253:2 0 14.7G 0 crypt /
??vg_rhel6luks-swap (dm-1) 253:1 0 4.9G 0 lvm
??luks-4e9e7a6f-a68c-42fd-92b4-8f4f2579a389 (dm-3)
253:3 0 4.9G 0 crypt [SWAP]
RHEL7:
NAME MAJ:MIN RM SIZE RO TYPE
MOUNTPOINT
vda 252:0 0 20G 0 disk
??vda1 252:1 0 1G 0 part /boot
??vda2 252:2 0 19G 0 part
??rhel_rhel7luks-root 253:0 0 10G 0 lvm
? ??luks-74558d73-1ef3-4327-878b-f11b266a20fc 253:3 0 10G 0 crypt /
??rhel_rhel7luks-swap 253:1 0 3.9G 0 lvm
? ??luks-621270fd-6758-4001-8335-492cf5e32a45 253:2 0 3.9G 0 crypt [SWAP]
??rhel_rhel7luks-home 253:4 0 5.1G 0 lvm
??luks-0433f315-afd7-41a0-bd94-3f742114035c 253:5 0 5.1G 0 crypt /home
Thanks,
Laszlo
Laszlo Ersek
2022-Feb-23 16:19 UTC
[Libguestfs] [libguestfs-common PATCH 0/2] options: decrypt LUKS-on-LV devices
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1658126 Laszlo Ersek (2): options: extract & refactor decryption of mountables (partitions) options: decrypt LUKS-on-LV devices options/decrypt.c | 132 +++++++++++++++++++++++++++++----------------- 1 file changed, 83 insertions(+), 49 deletions(-) base-commit: 41126802097f0a864cab8679ae8672b45914d54b -- 2.19.1.3.g30247aa5d201
Laszlo Ersek
2022-Feb-23 16:21 UTC
[Libguestfs] [libguestfs PATCH 0/3] tests: add LUKS-on-LVM test
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1658126
Laszlo Ersek (3):
tests: rename "luks" to "lvm-on-luks"
tests: add LUKS-on-LVM test
TODO: remove "Better support for encrypted devices"
.gitignore
| 3 +-
TODO
| 10 --
test-data/phony-guests/Makefile.am
| 15 ++-
test-data/phony-guests/guests.xml.in
| 22 ++++-
test-data/phony-guests/make-fedora-img.pl
| 62 +++++++++++-
tests/Makefile.am
| 6 +-
tests/luks/test-key-option-inspect-luks-on-lvm.sh
| 103 ++++++++++++++++++++
tests/luks/{test-key-option-inspect.sh =>
test-key-option-inspect-lvm-on-luks.sh} | 4 +-
8 files changed, 200 insertions(+), 25 deletions(-)
create mode 100755 tests/luks/test-key-option-inspect-luks-on-lvm.sh
rename tests/luks/{test-key-option-inspect.sh =>
test-key-option-inspect-lvm-on-luks.sh} (94%)
--
2.19.1.3.g30247aa5d201
Laszlo Ersek
2022-Feb-23 16:22 UTC
[Libguestfs] [guestfs-tools PATCH 0/3] inspector: add LUKS-on-LVM test
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1658126
Laszlo Ersek (2):
inspector: rename "luks" to "lvm-on-luks"
inspector: add LUKS-on-LVM test
Richard W.M. Jones (1):
test-data: Replace deprecated luks_open with cryptsetup_open.
.gitignore
| 3 +-
inspector/Makefile.am
| 11 ++--
inspector/{expected-fedora-luks.img.xml =>
expected-fedora-lvm-on-luks.img.xml} | 0
inspector/{expected-fedora.img.xml => expected-fedora-luks-on-lvm.img.xml}
| 6 +-
inspector/{test-virt-inspector-luks.sh =>
test-virt-inspector-luks-on-lvm.sh} | 15 +++--
inspector/{test-virt-inspector-luks.sh =>
test-virt-inspector-lvm-on-luks.sh} | 2 +-
test-data/phony-guests/Makefile.am
| 15 +++--
test-data/phony-guests/guests.xml.in
| 22 ++++++-
test-data/phony-guests/make-fedora-img.pl
| 64 ++++++++++++++++++--
9 files changed, 113 insertions(+), 25 deletions(-)
copy inspector/{expected-fedora.img.xml =>
expected-fedora-luks-on-lvm.img.xml} (98%)
copy inspector/{test-virt-inspector-luks.sh =>
test-virt-inspector-luks-on-lvm.sh} (73%)
rename inspector/{expected-fedora-luks.img.xml =>
expected-fedora-lvm-on-luks.img.xml} (100%)
rename inspector/{test-virt-inspector-luks.sh =>
test-virt-inspector-lvm-on-luks.sh} (96%)
--
2.19.1.3.g30247aa5d201
Laszlo Ersek
2022-Feb-23 16:23 UTC
[Libguestfs] [v2v PATCH] convert_linux: include the "xts" module in the initrd
The conversion may change the CPU model of the domain, which in turn can
lead to the disappearance of various CPU flags/features, such as "aes"
(the AES-NI instruction set).
In RHEL7, the hw-accelerated AES module "aesni_intel" does not depend
on
the "xts" module, whereas the built-in, non-accelerated AES module
does
depend on the (external) "xts" module.
As a result of the conversion, the target domain may therefore become
dependent on the "xts" module, for decrypting LUKS block devices that
employ the "aes-xts-plain64" cipher (which is the default LUKS cipher
nowadays). When dracut runs in the appliance (in my case:
dracut-055-6.fc35.x86_64), it does not seem to notice this dependency.
Thus we need to explicitly include "xts" in the rebuilt initrd, if the
original kernel provides that module.
https://bugzilla.redhat.com/show_bug.cgi?id=1658126
Signed-off-by: Laszlo Ersek <lersek at redhat.com>
---
convert/convert_linux.ml | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/convert/convert_linux.ml b/convert/convert_linux.ml
index 45ce069ad9bf..116d9e06f792 100644
--- a/convert/convert_linux.ml
+++ b/convert/convert_linux.ml
@@ -595,6 +595,7 @@ let convert (g : G.guestfs) source inspect
keep_serial_console _ | None -> ()
| Some initrd ->
(* Enable the basic virtio modules in the kernel. *)
+ (* Also forcibly include the "xts" module; see RHBZ#1658126. *)
let modules let modules (* The order of modules here
is deliberately the same as the
@@ -605,7 +606,7 @@ let convert (g : G.guestfs) source inspect
keep_serial_console _ *)
List.filter (fun m -> List.mem m kernel.ki_modules)
[ "virtio"; "virtio_ring";
"virtio_blk";
- "virtio_scsi"; "virtio_net";
"virtio_pci" ] in
+ "virtio_scsi"; "virtio_net";
"virtio_pci"; "xts" ] in
if modules <> [] then modules
else
(* Fallback copied from old virt-v2v. XXX Why not "ide"?
*)
--
2.19.1.3.g30247aa5d201