[Bug 1234010] New: Unable to unlock multiple encrypted partitions with FIDO2 Key, Systemdboot+LUKS
https://bugzilla.suse.com/show_bug.cgi?id=1234010 Bug ID: 1234010 Summary: Unable to unlock multiple encrypted partitions with FIDO2 Key, Systemdboot+LUKS Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Other Assignee: screening-team-bugs@suse.de Reporter: chris.beaudry.miller@gmail.com QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- Description: I have followed the article here https://news.opensuse.org/2024/09/20/quickstart-fde-yast2/ to configure a system using btrfs + swap, LUKS, and systemdboot with a FIDO2 key to unlock. However, I can consistently reproduce an issue where the encrypted swap will not be unlocked by the FIDO key, and in fact it seems the swap partition is being skipped somehow. A configuration with only one encrypted partition (no swap) works perfectly. output of lsblk on the system: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 465.8G 0 disk └─sda1 8:1 0 465.8G 0 part /OFFLOAD nvme0n1 259:0 0 931.5G 0 disk ├─nvme0n1p1 259:1 0 512M 0 part /boot/efi ├─nvme0n1p2 259:2 0 899.7G 0 part │ └─cr_root 254:0 0 899.7G 0 crypt /var │ /usr/local │ /srv │ /root │ /opt │ /home │ /boot/grub2/x86_64-efi │ /boot/grub2/i386-pc │ /.snapshots │ / └─nvme0n1p3 259:3 0 31.3G 0 part └─cr_swap 254:1 0 31.3G 0 crypt [SWAP] cat /etc/crypttab: # File created by sdbootutil. Comments will be removed # Add the 'x-sdbootutil.ignore' option to un-track a device cr_swap UUID=1b692ff9-23f5-4d84-86ee-51b3c3cb72c4 none fido2-device=auto cr_root UUID=06cfe12a-6aa3-45cf-b693-4a55421345ee none x-initrd.attach,fido2-device=auto Steps to Reproduce: 1. Configure system as per the above article to include LUKS encrypted root and swap with btrfs, and use systemdboot. 2. First time boot with password, and plug in and enroll FIDO2 key. Reboot 3. If disabling plymouth, add plymouth.enable=0 to the kernel options at the systemd boot screen. 4. When prompted (yubikey flashes), touch the FIDO2 key to confirm presence. Actual Results: What the application did after performing the above steps. When Plymouth is enabled, this causes a crash to emergency mode after a lengthy timeout. When Plymouth is disabled via the kernel cmdline option plymouth.enable=0, the system falls back to a password prompt for the device that fails to unlock with FIDO2. The system will successfully boot after entering the password. LOGFILES: Failed FIDO2 Boot with Plymouth Enabled, Crash to Emergency Mode: https://paste.opensuse.org/pastes/5fa0c03399fa Failed FIDO2 Boot with Plymouth Disabled, Successful Fallback to Password for Swap https://paste.opensuse.org/pastes/5bda9dfc40a2 Expected Results: What the application should have done, were the bug not present. The system should detect the FIDO2 key and prompt once for presence (or twice, if the disk encryption passwords are different for swap and root) before booting. It should not hang or crash, and always fall back to password input after a timeout. Build Date & Hardware: Tumbleweed Build: NAME="openSUSE Tumbleweed" # VERSION="20241129" ID="opensuse-tumbleweed" ID_LIKE="opensuse suse" VERSION_ID="20241129" Hardware this is the specific FIDO2 key https://support.yubico.com/hc/en-us/articles/360013647720-Security-Key-by-Yu...). -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com