On Thu, 14 Mar 2019 at 16:55, Guilhem Moulin <guil...@debian.org> wrote: > > > For example many IoT and Pi devices have 1GB of ram in total, and thus > > would OOM kill when trying to luksOpen. > > Is that something you experienced? I just deployed a fresh a Debian sid > VM with 2vCPUs, 1GiB RAM a default encryption stack (LVM2 on top of > LUKS/dm-crypt). Works just fine :-) The actual memory cost is about > half of the physical memory. > > Works equally fine on a VM with 512MiB RAM. There the memory cost is > set to ~250MiB. >
Nice. > > Please consider reducing the default memory requirement of the argon2i > > in luks2 by default, or switching to pbkdf2 for LUKS2 as well. > > I think diverging from upstream (and other distros) with respect to > default algorithms requires careful consideration. And in that case, > compared to PBKDF2 Argon2 has interesting properties (such as resistance > to GPU cracking) which would be a shame not to benefit from out of the > box. > > > I think it is unfortunate to not support default encryption on 1GB big > > devices and VMs. > > AFAICT it does. What I guess doesn't is if the machine's resources are > significantly reduced between luksFormat/luksAddKey and luksOpen. > I guess that is the reason here. Majority of IoT / pi / etc devices might prepare rootfs / SDcard / golden image / etc on a bigger developer machine, prior to flashing it onto SDcard to then deploy on the target device. So the solution there is to run the benchmark on the device, once, record parameters and use those when creating the golden image for memory, threads and possibly iterations too? I.e. I think I managed to use printf test | sudo cryptsetup luksFormat --debug --key-file=- --pbkdf-memory=505372 --pbkdf-parallel=2 --pbkdf-force-iterations=4 /dev/nbd0 To create an "easy" encrypted filesystem with matching algo parameters for a "small" device, on my "big" desktop. > OTOH parallel unlocking might be an issue indeed, especially if the > devices are unlocked in an unattended fashion (for instance via key > files). That said on my 1GiB VM I could reliably boot with > > $ cat /etc/crypttab > root_crypt /dev/vda4 none luks > swap_crypt /dev/vda2 /etc/keys/swap.key luks,swap > home_crypt /dev/vda3 /etc/keys/home.key luks > > (root_crypt being unlocked an initramfs stage, the other two later by > systemd) and > > $ cat /etc/fstab > /dev/vda1 /boot ext2 defaults 0 2 > /dev/mapper/swap_crypt none swap sw 0 0 > /dev/mapper/root_crypt / ext4 defaults 0 1 > /dev/mapper/home_crypt /home ext4 defaults 0 2 > > However the OOM killer does trigger when I add a third volume. I guess > the boot process is racy and might, or might not, abort depending on > what's being started at the same time. But I'd argue that setup is far > from a typical installation, and the same goes for low-memory devices > with plenty of encrypted disks attached. (Moreover Debian's default > initramfs implementation comes from initramfs-tools, where unlocking is > sequential. So root-device encryption is out of the picture.) > > Having a separate encrypted /home partition (unlocked by systemd) > doesn't seem to cause any problem when formatted with the default > parameters, which I understood is what this bug report is about. > I guess dracut with systemd in the initrd might be affected worse, than initramfs-tools. I wonder if I should open a bug report in systemd, to potentially execute luks2 unlock with some locking / sequentially. Similarly, I shall probably back out hardcoding of --pbkdf pbkdf out of s390-tools zkey. I guess this bug should be tagged wontfixing and lowered priority to normal, or something. -- Regards, Dimitri.