[pkg-cryptsetup-devel] Bug#924560: Bug#924560: cryptsetup luksOpen requires 1GB of RAM in the default configuration

[Dimitri John Ledkov]

On Thu, 14 Mar 2019 at 16:55, Guilhem Moulin <guilhem at 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.