Using FIDO2 automatically generates a temporary password for setting up LUKS
which is not available on subsequent runs of the script causing the format
script to crash with `password: unbound variable`.
`bcachefs-tools`: `v1.33.1` cannot read the superblock from a mounted
device. The kernel returns EBUSY whenever
the filesystem is already mounted, so every `bcachefs show-super
/dev/vd*` assertion in this test now fails on the booted system.
`boot.initrd.preDeviceCommands` only runs in the script-based stage 1
and is gated on `!config.boot.initrd.systemd.enable`. Tests that
enable systemd initrd therefore never get `/tmp/secret.key` staged,
and disko's encrypted-filesystem mount hooks fail to find the
configured `passwordFile`.
The nixpkgs test driver was refactored: `driver.machines` is now a
computed property that returns a fresh sorted list combining
`driver.machines_qemu` and `driver.machines_nspawn`. Appending to the
property therefore mutates only the temporary returned list, so the
machines created via `create_test_machine` are no longer registered
with the driver.
This introduces what has been described in
https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html.
That is: support for FIDO2 and recovery passphrases and their boot
mechanism.
Testing is hard right now because of canokey-qemu being broken and U2F
is not a valid replacement for FIDO2…
I tried to keep as much as possible the previous behavior and make it
possible to mix FIDO2 and normal passphrases or key files without any
problem.
PIV support is out of scope for this change but can easily be added.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* FIDO2 token enrollment for LUKS-encrypted root with optional automatic
recovery passphrase and new configuration options to control enrollment
behavior.
* **Examples**
* Added an example configuration demonstrating a FIDO2-protected disk
layout (ESP + encrypted root) with FIDO2 enrollment enabled.
* **Tests**
* Added automated test coverage for the FIDO2/LUKS workflow and a
test-mode option to simulate a hardware FIDO2 device.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
This introduces what has been described in
https://0pointer.net/blog/unlocking-luks2-volumes-with-tpm2-fido2-pkcs11-security-hardware-on-systemd-248.html.
That is: support for FIDO2 and recovery passphrases and their boot
mechanism.
Testing is hard right now because of canokey-qemu being broken and U2F
is not a valid replacement for FIDO2…
I tried to keep as much as possible the previous behavior and make it
possible to mix FIDO2 and normal passphrases or key files without any
problem.
PIV support is out of scope for this change but can easily be added.
Signed-off-by: Raito Bezarius <masterancpp@gmail.com>
Previously, the `disk-deactivate` script stopped mdadm arrays before
wiping the underlying physical disks. This caused filesystems with
backup superblocks (like BTRFS at 64 MiB and 256 GiB offsets) to
survive the wipe, as the backups were striped across the physical
disks and missed by `wipefs` on the raw block devices.
When the array was reassembled during reprovisioning, the filesystem
superblocks realigned. `disko` would detect the old filesystem via
`blkid` and silently skip the `mkfs` step, leaving stale data intact.
This commit adds a `wipefs --all` command against the assembled RAID
device *before* stopping it, ensuring all filesystem signatures and
backup superblocks are cleanly destroyed.
Use the `fsBefore` function from NixOS to sort the file-systems.
The function originates from `nixpkgs/nixos/lib/utils.nix`, but the file
is a lambda that requires more arguments than we have available.
Use the `fsBefore` function from NixOS to sort the file-systems.
The function originates from `nixpkgs/nixos/lib/utils.nix`, but the file
is a lambda that requires more arguments than we have available.
The device of the bind mounts is incorrectly taken verbatim while making
the image. The root hierarchy is mounted at `config.rootMountDir`
(`/mnt` by default) during the process, and this commit prepends that
path to the `device` in these cases.
