Allow toggling cryptsetup flag CRYPT_ACTIVATE_SERIALIZE_MEMORY_HARD_PBKDF for users with a lot of ram and a lot of LUKS drives with high memory keyslots

[waffshappen]

Is your feature request related to a problem? Please describe.
#14168
A flag for cryptsetup was added to reduce OOM when "hard" luks keyslots are in use which require a lot of memory by serializing the unlocking operation.

However i did not find a boottime parameter to disable passing this to cryptsetup in any way, which makes it a pain to boot my machine (12 drives, ~300MB/keyslot, 10 seconds time complexity but 48GB of available ram) and takes the boottime from the roughly expected 10-15 seconds for unlocking all my drives to roundabout 3 Minutes for that task alone.

I first went to https://gitlab.com/cryptsetup/cryptsetup/-/issues/634 but they pointed out that it is not default behaviour and as per the above PR is only passed from systemd. This was a far smoother operation before that pull (Fedora 32)

Describe the solution you'd like
The gold standard solution would be that systemd could parse the memory/time hardness of the selected keyslot and then plan to unlock drives in parallel via the cryptsetup generator to not max out the system.

However since i fully understand this is not the most common case for users to have alternatively a boot time initrd/cmdline flag to disable that flag would be much appreciated.

Describe alternatives you've considered
Alternative solutions are to lower the memory and time hardness and thus lowering the security margin, to not mount my drives on startup and not gaining automounts from fstab and unlocking by hand or to own less drives.

The systemd version you checked that didn't have the feature you are asking for
git latest and 248~rc4-3.fc34

[poettering]

last time i looked they scale the cycles, threads and memory use by what's available when enrolling the passphrase. Or did I misunderstand something there?

If that was still really the case this would mean that unless you actually enroll your volumes on not-so-beefy systems but use them on very-beefy systems then doing what you are asking for might not be a good idea, because you still can't run multiple jobs of unlocking in parallel, simply because on your system argon2 would just use so much more resources...

[waffshappen]

last time i looked they scale the cycles, threads and memory use by what's available when enrolling the passphrase. Or did I misunderstand something there?

That is indeed the case, however you can also manually scale it to your requirement with --pbkdf options.

Going by https://gitlab.com/cryptsetup/cryptsetup/-/issues/372 default is 1GB maximum, or capped at half the available memory whichever is smaller.
Given that i already lowered the memory needed to unlock my drives, default would be far "worse" (but still, my system can handle 12GB of ram usage so why not)

If that was still really the case this would mean that unless you actually enroll your volumes on not-so-beefy systems but use them on very-beefy systems then doing what you are asking for might not be a good idea, because you still can't run multiple jobs of unlocking in parallel, simply because on your system argon2 would just use so much more resources...

Even in that case a boot time flag to disable the serial unlock on systems where it can be handled in parallel (and is thus known by the user) would already be nice while defaulting to enforcing serial behaviour for memory heavy drives.

Or as https://gitlab.com/cryptsetup/cryptsetup/-/issues/634#note_540852355 suggested, a crypttab option that changes systemd behaviour for individual drives?