Created attachment 1798120 [details]
Grub config to install the VM

Created attachment 1798122 [details]
libvirt "default" network XML to be able to UEFI+HTTP boot

Cryptsetup simply can not change defaults here. The utility does not know the use case for the keyslot and it aims to achieve highest security possible for the user by default.

cryptsetup luksAddKey action aims to use half system memory with argon2 pbkdf (or 1GiB whatever hits first). But yes, if the system is under memory pressure it leads to oom. Please mind that memory cost is core feature of memory hard pbkdf function. It serves to protect LUKS2 passphrases against parallel attack performed on systems with high parallel core count but expensive memory (GPUs).

I see following posibilities:

a) you can lower memory cost of pbkdf by adding --pbkdf-memory limit in KiB
b) you can switch to back to pbkdf2 with --pbkdf pbkdf2

this needs to be verified by clevis/tang maintainer:
c) Maybe clevis can safely switch to minimal pbkdf values since I expect new passphrase provided by clevis during luksAddKey action is in fact cryptographicly strong key (key generated with high entropy).

Is that correct Sergio?

example for c) would look like this:

cryptsetup luksAddKey cryptsetup luksAddKey --pbkdf pbkdf2 --pbkdf-force-iterations 1000 --key-file <(echo -n "${existing_key}") "$DEV"

But please bear in mind that c) is safe only if the 'new_passphrase' is generated using approved random key generator. I don't know clevis/tang internals good enough to verify that.

Systemd does something very similar when it's aware new passphrase has key generated with high entropy

(In reply to Ondrej Kozina from comment #3)

[...]

> 
> this needs to be verified by clevis/tang maintainer:
> c) Maybe clevis can safely switch to minimal pbkdf values since I expect new
> passphrase provided by clevis during luksAddKey action is in fact
> cryptographicly strong key (key generated with high entropy).
> 
> Is that correct Sergio?
> 

Yes -- the key is currently generated with pwmake and 256 bits of entropy.

> example for c) would look like this:
> 
> cryptsetup luksAddKey cryptsetup luksAddKey --pbkdf pbkdf2
> --pbkdf-force-iterations 1000 --key-file <(echo -n "${existing_key}") "$DEV"
> 

Renaud: could you check if something like this helps?

> But please bear in mind that c) is safe only if the 'new_passphrase' is
> generated using approved random key generator. I don't know clevis/tang
> internals good enough to verify that.

(In reply to Sergio Correia from comment #5)
> (In reply to Ondrej Kozina from comment #3)
> 
> [...]
> 
> > 
> > this needs to be verified by clevis/tang maintainer:
> > c) Maybe clevis can safely switch to minimal pbkdf values since I expect new
> > passphrase provided by clevis during luksAddKey action is in fact
> > cryptographicly strong key (key generated with high entropy).
> > 
> > Is that correct Sergio?
> > 
> 
> Yes -- the key is currently generated with pwmake and 256 bits of entropy.
> 
> > example for c) would look like this:
> > 
> > cryptsetup luksAddKey cryptsetup luksAddKey --pbkdf pbkdf2
> > --pbkdf-force-iterations 1000 --key-file <(echo -n "${existing_key}") "$DEV"
> > 
> 
> Renaud: could you check if something like this helps?

I had a typo in the example, use this one instead:

cryptsetup luksAddKey --pbkdf pbkdf2 --pbkdf-force-iterations 1000 --key-file <(echo -n "${existing_key}") "$DEV""

I can confirm this works fine on a 2GB system which has not much free during installation:

[anaconda root@vm-tpm84 ~]# free
              total        used        free      shared  buff/cache   available
Mem:        2005084     1087568       70380      388900      847136      364996
Swap:       4102228      723456     3378772

as per comment #7 I'm moving it clevis/tang. This change seems reasonable and it would also speed up clevis/tang based device activations with safe clevis generated LUKS2 passphrases.

I don't manage to reproduce on my 8.4 VMs anymore, but now I have some issue with the TPM, could be the reason.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (clevis bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:1857