Hello list,

I would like to share some observations about the management of
encrypted volumes with random key (plain dm-crypt) in the Debian
installer. These observations do not apply to encrypted devices with
passhprase (LUKS).


1) partman-crypto offers to use an encrypted volume with random key as:
ext2 filesystem, swap area, EFI system partition, LVM physical volume.
The use cases for a temporary encrypted filesystem (e.g. /tmp) or swap
area are obvious. But AFAIK an EFI system partition must be an
unencrypted persistent plain partition (so that the UEFI firmware can
read it) and an LVM PV must be persistent too, so what are the use cases
for temporary encrypted EFI system partition and LVM PV ?


2) Physical volumes for encryption with random key are designated with
their block device name in the generated /etc/crypttab. Example:

sda10_crypt /dev/sda10 /dev/urandom cipher=aes-xts-plain64,size=256,swap,discard

This is fine with device-mapper devices such as LVM LVs which have
persistent names. However it is well known that some block devices such
as SCSI/ATA/USB drives (/dev/sd*) or software RAID arrays (/dev/md*) may
not be assigned the same names across boots. I have neither experience
or knowledge about SD/MMC drives, NVMe SSDs or hardware RAID arrays.
This may lead to boot failure if the device name in /etc/crypttab does
not exist or even more catastrophic consequences if the device name is
assigned to the wrong device which will be overwritten. This has
happened to me once.

For this reason IMO /etc/crypttab should use a persistent identifier
whenever possible. For instance it could use the PARTUUID for partitions
on disk labels which provide it, or a symlink in /dev/disk/by-id/ like
the grub-pc package does to record installation devices in debconf:

* grub-pc/install_devices: /dev/disk/by-id/ata-WDC_WD1200BEVE-00WZT0_WD-WXH0A89L7521-part11


3) When an encrypted volume with random key is used as an ext2
filesystem, an entry similar to the following example is added to /etc/crypttab:

sda11_crypt /dev/sda11 /dev/urandom
cipher=aes-xts-plain64,size=256,tmp,discard

and an entry similar to the following example is added to /etc/fstab:

/dev/mapper/sda11_crypt /tmp ext2 defaults

However according to the crypttab(5) manpage, the default filesystem
type for the "tmp" option is ext4, not ext2.

As expected, at boot time the encrypted volume is initialized as ext4
and fails to mount with the following error:

"EXT4-fs (dm-0): couldn't mount as ext2 due to feature incompatibilities
Failed to mount /tmp"

and init goes into emergency mode.

A possible fix is to either set "tmp=ext2" in /etc/crypttab or use the encrypted volume as ext4 (and preferably set "tmp=ext4" in /etc/crypttab
to not rely on defaults) and set type "ext4" or "auto" in /etc/fstab
instead of ext2.


4) base-installer may wrongly select an encrypted swap area with random
key as the resume device in /etc/initramfs-tools/conf.d/resume. Example:

RESUME=/dev/mapper/sda10_crypt

This results in the following files being embedded into the initramfs:

/cryptroot/crypttab:
sda10_crypt /dev/sda10 /FIXME-initramfs-rootmnt/dev/urandom cipher=aes-xts-plain64,size=256,swap,discard

/conf/conf.d/resume:
RESUME=/dev/mapper/sda10_crypt

As expected, attempt to resume from this device at boot time causes a
delay and the following error:

"Gave up waiting for suspend/resume device"

It also causes the following warning at boot time and when running update-initramfs:

"cryptsetup: WARNING: sda10_crypt: couldn't determine device type,
assuming default (plain)"
(can be fixed by adding "plain" to the options field in /etc/crypttab)

and the following warning when running update-initramfs:

"cryptsetup: WARNING: Resume target sda10_crypt uses a key file"

It seems obvious to me that an encrypted volume with random key cannot
and should not be used as a resume device. A possible fix is to exclude encrypted volumes with random key in function get_resume_partition() in /usr/lib/base-installer/library.sh, like /usr/share/initramfs-tools/hooks/resume from package
initramfs-tools-core does.

Side note: get_resume_partition() excludes ramzswap devices which seem
to be an obsolete version of zram (aka compcache). Shouldn't that be
updated ?


Any thoughts ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)