Dear maintainer,

Today I upgraded a small KVM machine with a LUKS2 encrypted root and
1GiB of RAM to bookworm, and was very surprised to be confronted with an
OOM immediately upon entering my LUKS password in the initramfs prompt:

     Loading Linux 6.1.0-5-amd64 ...
     Loading initial ramdisk ...
     Please unlock disk vda5_crypt:
     [    7.982435] Out of memory: Killed process 243 (cryptsetup)
total-vm:799000kB, anon-rss:678296kB, file-rss:6440kB, shmem-rss:0kB,
UID:0 pgtables:1384kB oom_score_adj:0
     Killed
     cryptsetup: ERROR: vda5_crypt: cryptsetup failed, bad password or
options?

This machine was booting just fine before upgrading, under bullseye.

The problem appears to be perhaps related to #924560, but in this
instance, the issue causing an unbootable system post-upgrade.


Thanks,

Hi,

No, this is related to #1028250 and https://gitlab.com/cryptsetup/cryptsetup/-/issues/802#note_1287298872 .
Don't think we can do anything in src:cryptsetup for existing volumes
unfortunately.  You might need to manually lower the parameters of your
PBKDF.

Lowering the severity, because this shouldn't block the transition of -2
into bookworm (which fixes an unrelated and arguably much more severe RC
bug).  See also the d-i errata for Bookworm Alpha 2.  I'm also not
certain that #-1 is RC, after all Debian's memory requirements have
consistently increased since the start of the project, so IMHO one has
to accept that hardware might need to be dusted up on upgrade.  Compare

https://www.debian.org/releases/potato/i386/ch-hardware-req.en.html §2.3 with
https://www.debian.org/releases/bullseye/amd64/ch03s04.en.html §3.4

Either way the issue definitely needs to be mentioned in Bookworm's
release notes.

cheers

Hi Guilhem,

Guilhem Moulin <guilhem@debian.org> (2023-03-11):

Existing systems failing to boot after an upgrade doesn't seem to be
“only” important to me…
sense for a specific version to migrate…

Either the bug appeared specifically in the version it was filed against,
and it makes sense to block the migration since that's a new RC bug in
that particular version, and the RC-ness stays.

Or the bug was already there in the version currently in testing, and that
means that's not a regression, and the RC-ness stays. You only need to
record the bug as also being found in the previous version (possibly
plural) to make sure britney knows it's not a regression.

Sure, we can discuss the severity of the bug I filed. But #1032734 really
can't be “just” important.


Cheers,

Hi kibi,

I fail to see how that's different from an existing resource-constrained
system (sarge recommends for 64MiB RAM for desktop i386) being unusable
after dist-upgrading to a more recent Debian release.  Granted I haven't
tried it, but I very much doubt GNOME would still work with that little
memory :-)

Anyway, while it definitely isn't ideal (not very future proof) that the
key slots were created with a memory cost close to the whole available
memory, there is actually not that much difference in resident set size
before and after the upgrade.  The test environment is a VM with 1024M
RAM, and initialized with d-i's debian-10.12.0-amd64-netinst.iso and
“Encrypted LVM” partition scheme.  In my case the PBKDF benchmark chose
the following parameters (close to half the amount of physical memory
indeed):

	~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
		PBKDF:      argon2i
		Time cost:  4
		Memory:     504962
		Threads:    2

	## buster (cryptsetup 2:2.1.0-5+deb10u2, linux 4.19+105+deb10u18)
	~# command time cryptsetup luksOpen --test-passphrase /dev/vda5 <<<test
	1.98user 0.09system 0:01.13elapsed 182%CPU (0avgtext+0avgdata 534408maxresident)k
	566inputs+0outputs (0major+2212minor)pagefaults 0swaps

	## dist-upgrade to bullseye (cryptsetup 2:2.3.7-1+deb11u1, linux 5.10.162-1)
	~# command time cryptsetup luksOpen --test-passphrase /dev/vda5 <<<test
	1.93user 0.11system 0:01.14elapsed 179%CPU (0avgtext+0avgdata 534012maxresident)k
	566inputs+0outputs (0major+2185minor)pagefaults 0swaps

	## dist-upgrade to bookworm (cryptsetup 2:2.6.1-1, linux 6.1.12-1)
	~# command time cryptsetup luksOpen --test-passphrase /dev/vda5 <<<test
	2.05user 0.08system 0:01.17elapsed 183%CPU (0avgtext+0avgdata 512940maxresident)k
	6102inputs+0outputs (37major+1649minor)pagefaults 0swaps

So one could argue it's not a cryptsetup regression, at least not since
memory-hard KDFs are used by default (i.e. since buster).  The kernel
happens to kill cryptsetup because it's the main memory consumer at that
point (again due to unfortunate KDF parameters), but the reason why it
ran out of memory in the first place, and didn't with earlier releases,
appears to be independent from cryptsetup.

Ah cool didn't know that, thanks for the information.  Marking this as
found all the way back to buster then.  I'm indeed able to trigger the
OOM-killer on a buster system when I artificially fill the memory so the
memory cost exceeds what remains.  Furthermore I don't see what can be
done about existing keyslots, and that includes everything created since
buster.

Tagging ‘moreinfo’ then.  I can definitely see how one can reproduce
this theoretically (and possibly in the future when the kernel's memory
requirement increase high enough), and mentioned that in the upstream
bug, but I'm unable to find a reproducer after dist-upgrading bullseye
systems to bookworm (all created from d-i's debian-11.6.0-amd64-netinst.iso,
and “Encrypted LVM” partition scheme, on VMs with 1024M RAM).

Jérôme, what memory cost is the keyslot using?  (Paste the output of
`cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:`.)  Would also be
interested to see by how much the amount of memory available to
cryptsetup has changed before and after the uprade.  Please edit
/usr/share/initramfs-tools/scripts/local-top/cryptroot and add `free` at
the begining of the setup_mapping() function (patch attached).  My own
findings are as follows (again on a minimal netinst system without
changing any default).  cryptsetup isn't even close to memory
exhaustion.

	## bullseye (cryptsetup 2:2.3.7-1+deb11u1, linux 5.10.162-1)
	~# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
		PBKDF:      argon2i
		Time cost:  4
		Memory:     499892
		Threads:    2
	~# systemctl reboot
	Loading Linux 5.10.0-21-amd64 ...
	Loading initial ramdisk ...
	              total        used        free      shared  buff/cache   available
	Mem:         999776       39276      843280          52      117220      777124
	Swap:             0           0           0
	Please unlock disk vda5_crypt:
	1.90user 0.18system 0:04.19elapsed 49%CPU (0avgtext+0avgdata 525900maxresident)k
	566inputs+0outputs (0major+2400minor)pagefaults 0swaps
	cryptsetup: vda5_crypt: set up successfully

	## pin src:cryptsetup to 2:2.3.7-1+deb11u1 and dist-upgrade everything else to bookworm
	Loading Linux 6.1.0-5-amd64 ...
	Loading initial ramdisk ...
	              total        used        free      shared  buff/cache   available
	Mem:         993508       48892      748520          56      196096      683768
	Swap:             0           0           0
	Please unlock disk vda5_crypt:
	1.94user 0.21system 0:18.21elapsed 11%CPU (0avgtext+0avgdata 525592maxresident)k
	566inputs+0outputs (0major+2402minor)pagefaults 0swaps
	cryptsetup: vda5_crypt: set up successfully

	## remove the pin and finalize the dist-upgrade (cryptsetup 2:2.6.1-1, linux 6.1.12-1)
	Loading Linux 6.1.0-5-amd64 ...
	Loading initial ramdisk ...
	              total        used        free      shared  buff/cache   available
	Mem:         993508       40672      759596          52      193240      694828
	Swap:             0           0           0
	Please unlock disk vda5_crypt:
	2.04user 0.12system 0:04.57elapsed 47%CPU (0avgtext+0avgdata 507772maxresident)k
	566inputs+0outputs (0major+1382minor)pagefaults 0swaps
	cryptsetup: vda5_crypt: set up successfully

Memory cost:

----- 8< -----
# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
         PBKDF:      argon2i
         Time cost:  4
         Memory:     787907
         Threads:    1
----- >8 -----

Free memory:

----- 8< -----
Loading Linux 6.1.0-5-amd64 ...
Loading initial ramdisk ...
               total        used        free      shared  buff/cache
available
Mem:         993756       74720      725012          60      194024
660412
Swap:             0           0           0
----- >8 -----

I've also tested on another of my virtual machines that has 1GiB of RAM
and got another result, closer to what you got in your experimentation:

----- 8< -----
# cryptsetup luksDump /dev/vda5 | grep -A3 PBKDF:
         PBKDF:      argon2i
         Time cost:  6
         Memory:     499912
         Threads:    1
----- >8 -----

So, I think what's happening is that the first VM may have been created
with a different (larger) memory configuration, and was reduced at a
later point in time. I don't have absolute certainty of this, but it
would very well explain the discrepancy in memory cost.

Also, I think I agree with your assessment that in the memory usage
increase of the kernel may be involved: between the two releases,
according to your numbers it appears to have increased nearly 25% (!).
So it could also explain why it (probably very nearly) worked under
bullseye.

I there any way we could make the cryptsetup-initramfs hook aware of
this, and emit a warning if it finds that the encrypted root lacks a
keyslot with appropriate (low-enough) memory cost?


Thanks,

Control: tag -1 - moreinfo
Control: severity -1 important
Control: retitle -1 Argon2 memory cost is not future proof and might OOM on dist-upgrade on memory-constrained systems
in between) never set the memory cost to more than half the physical
memory.  So it's just not possible to end up with such a high memory
cost on a machine with only 1GiB RAM.  Memory-hard KDF parameters are
non portable and this is a feature not a bug :-)  Upon hardware change
one needs to run the benchmark again via cryptsetup-luksChangeKey(8) or
similar to tune the parameters to the new system; and downgrading
hardware needs to be done with care as folks who bootstrap images for
RPI-like boards are surely aware.

It's a coincidence that you triggered the OOM-killer only after the post
dist-upgrade reboot, you were already likely close to memory exhaustion
after reducing memory.
access to the header where this information resides, 2/ it doesn't know
beforehand which keyslot will be used, and 3/ the issue is not specific
to cryptsetup-initramfs.  There is an upstream commit on the main branch
that adds a warning to libcryptsetup, might cherry-pick that to bookworm
instead.

Anyway, lowering this to sub-RC now that it's demystified.  In your case
the root issue (KDF parameter portability) is wontfix/notabug, but I'm
hijacking this to point out that KDF parameters are not future proof.
(This is what the forwarded upstream bug points to, and what I initially
thought you might be experiencing.)  Things work fine out of the box on
minimal systems (also with <1GiB RAM), but several releases down the
road we might ship a kernel or early boot daemons requiring a lot more
memory, and the KDF *will* exhaust memory at that point.  The upstream
fix in !490 (neither in bookworm nor sid yet) improves things a bit but
really is only buying time.  Milan suggested that systems with little
RAM are probably better off using a non-memory-hard KDF.  Perhaps
upstream could be convinced to have different defaults depending on the
amount of physical memory, if not then perhaps it could be done in
partman-crypto (I personally wouldn't feel comfortable carrying such a
patch in src:cryptsetup or have defaults that are unaligned with
upstream or other distros).  Won't help with existing keyslots though.