FIDO_ERR_RX with multiple entries using same FIDO2 token

[bjacquin]

systemd version the issue has been seen with

systemd 248 (248)

Used distribution

Gentoo

Linux kernel version used (uname -a)

Linux lady-voodoo.local 5.12.9-stable #1 SMP 2021-06-07T21:43:26+01:00 x86_64 11th Gen Intel(R) Core(TM) i5-1135G7 @ 2.40GHz GenuineIntel GNU/Linux

CPU architecture issue was seen on

x86_64

Unexpected behaviour you saw

When multiple partitions are encrypted with cryptsetup with a single FIDO2 token, it does appear systemd is trying to perform cryptographic operation at the same time, leading to error like the following:

$ cat /etc/crypttab
lv-home UUID=681f3095-8955-444f-8543-8a3f7508a3e4 - luks,fido2-device=auto
lv-data UUID=3d527330-917c-4e07-adad-a89ae3391f1a - luks,fido2-device=auto

$ sudo systemd-cryptenroll /dev/vg-data/cr-data
SLOT TYPE
   0 password
   1 fido2
$ sudo systemd-cryptenroll /dev/vg-data/cr-home
SLOT TYPE
   0 password
   1 fido2

Jun 07 21:56:44 lady-voodoo.local systemd[1]: Starting Cryptography Setup for lv-data...
Jun 07 21:56:44 lady-voodoo.local systemd[1]: Starting Cryptography Setup for lv-home...
Jun 07 21:56:44 lady-voodoo.local systemd-cryptsetup[322]: WARNING: Locking directory /run/cryptsetup is missing!
Jun 07 21:56:44 lady-voodoo.local systemd-cryptsetup[322]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/disk/by-uuid/3d527330-917c-4e07-adad-a89ae3391f1a.
Jun 07 21:56:44 lady-voodoo.local systemd-cryptsetup[322]: Automatically discovered security FIDO2 token unlocks volume.
Jun 07 21:56:44 lady-voodoo.local systemd-cryptsetup[323]: Set cipher aes, mode xts-plain64, key size 256 bits for device /dev/disk/by-uuid/681f3095-8955-444f-8543-8a3f7508a3e4.
Jun 07 21:56:44 lady-voodoo.local systemd-cryptsetup[323]: Automatically discovered security FIDO2 token unlocks volume.
Jun 07 21:56:44 lady-voodoo.local systemd[1]: Finished LVM2 PV scan on device 259:4.
Jun 07 21:56:45 lady-voodoo.local systemd-cryptsetup[323]: Failed to open FIDO2 device /dev/hidraw0: FIDO_ERR_RX
Jun 07 21:56:45 lady-voodoo.local systemd[1]: systemd-cryptsetup@lv\x2dhome.service: Main process exited, code=exited, status=1/FAILURE
Jun 07 21:56:45 lady-voodoo.local systemd[1]: systemd-cryptsetup@lv\x2dhome.service: Failed with result 'exit-code'.
Jun 07 21:56:45 lady-voodoo.local systemd[1]: Failed to start Cryptography Setup for lv-home.
..

It does appear /run/cryptsetup is missing at this stage, however /usr/lib/tmpfiles.d/cryptsetup.conf does exist with the following content:

d /run/cryptsetup 0700 root root -

When this happen, the boot switch to emergency mode without systemd performing fallback requested to passphrase.

This specific issue does not appear with a single entry in /etc/crypttab.

[poettering]

hmm @martelletto what is the right approach for us here? what's the strategy for two different processes concurrently accessing a fido2 device via libfido2? ideally for the use in the systemd-cryptsetup logic we'd have a blocking form of fido_dev_open() that blocks (maybe with a time-out) until the caller is the sole user of the device. Then we could serialize access here.

Internally, this could be implemented via BSD file locks: the device fd that libfido2 opens internally supports BSD flock() on Linux (all fds do on linux). So when opening every participant could just lock the fd before use. The lock is automatically released by the kernel once the device i closed. (note that only BSD file locks work like this, POSIX locks do not, don't bother with them).

An alternative would be if libfido2 would somehow allow us to access the internal fd ourselves. If so we could do the BSD flock() stuff from our code instead of libfido2. That said it probably makes sense to have it in libfido2 itself, since this is advisory locking only and by putting it into libfido2 we can make sure any user of libfido2 will follow the lock protocol, not just systemd-cryptsetup.

Anyway, what's your take on the synchronization story?

[martelletto]

@poettering The spec leaves enough room for multiplexing to happen at the device level if supported, which is why libfido2 does not enforce any synchronization of its own. The reality on the ground is a bit different, though: multiplexing is unlikely to be supported by the device, and even if it were supported, it is questionable whether it is a good idea in the first place. Therefore, implementing the synchronization in libfido2 makes sense IMHO. I will add it to libfido2's 1.8.0 roadmap. Thank you!

[poettering]

@martelletto excellent! thanks! Let's wait for this to be solved in libfido2 for us then.

[poettering]

(@bjacquin btw, ignore the /run/cryptsetup thing, it's a red herring, libcrytpsetup 1e7521c0564936fdbf098ce448e91e0ba25bffae downgraded the message since it doesn't really matter.)

[poettering]

Given that Yubico/libfido2#350 was merged into libfido2 I guess we can close this here.