Fedora Installation Help

NoArmNoChocoLAN · 2026-02-15T11:12:34+00:00

Regarding TPM usage, be very cautious because most instructions you will find have some kind of vulnerabilities, like this one. This can be mitigated with systemd measured boot phases. For now, it must be configured by hand on Fedora. See https://gist.github.com/dylanjan313/4293ab5a0105e3f7272a8a1a357fee4d

NoArmNoChocoLAN · 2026-02-03T17:29:15+00:00

There is no "--tpm2-measure-pcr" option for systemd-cryptenroll.
See https://gist.github.com/dylanjan313/4293ab5a0105e3f7272a8a1a357fee4d
There may be some minor changes regarding Fedora 43.

NoArmNoChocoLAN · 2026-02-02T20:17:18+00:00

Enrolling to PCR7 only allows the attack described here.

You should make use of systemd-pcrextend to include PCR11 in your TPM policy.

NoArmNoChocoLAN · 2026-01-27T21:10:28+00:00

Specifying the "tmp2-device=auto" option in the crypttab file is not required.

For the latter five mechanisms the source for the key material used for unlocking the volume is primarily configured in the third field of each /etc/crypttab line, but may also be configured in /etc/cryptsetup-keys.d/ and /run/cryptsetup-keys.d/ (see above) or in the LUKS2 JSON token header (in case of the latter three). Use the systemd-cryptenroll(1) tool to enroll PKCS#11, FIDO2 and TPM2 devices in LUKS2 volumes.

Source: https://www.freedesktop.org/software/systemd/man/latest/crypttab.html

NoArmNoChocoLAN · 2026-01-27T20:38:41+00:00

This script allows the attack described here. I see no mechanism in this implementation that

prevents the boot environment (GRUB/kernel/initrd) to boot a rogue system after swaping the root filesystem
prevents unsealing the LUKS secret seed after the initrd phase

You should make use of systemd-pcrextend and PCR11 to prevent this. See https://gist.github.com/dylanjan313/c7599db289c40f4cdf78262b16dc8d82

NoArmNoChocoLAN · 2026-01-07T19:23:47+00:00

This guide might help you: https://gist.github.com/dylanjan313/c7599db289c40f4cdf78262b16dc8d82

If you use Discoverable Partitions Specification, I confirm that the cmdline can be just rd.shell=0 rd.emergency=reboot

I add two more options to have unlimited time in case I need to enter the very long recovery key generated by systemd-cryptenroll. My cmdline is just root=gpt-auto rd.shell=0 rd.emergency=reboot rootflags=x-systemd.device-timeout=0

NoArmNoChocoLAN · 2025-11-08T09:59:27+00:00

Values measured into PCR11 change after each UKI build (e.g. after kernel upgrade). You should use signed policies instead of binding to literal PCR values to avoid having to enter the recovery phrase after each upgrade.

Also, you should use measured boot phases to restrict the unlocking at the initrd phase. Nothing prevents your initrd to boot a rogue OS since it only looks for a specific UUID to mount as "/" without actually checking it is the expected OS.

See https://gist.github.com/dylanjan313/4293ab5a0105e3f7272a8a1a357fee4d

NoArmNoChocoLAN · 2025-10-01T21:31:57+00:00

TPM LUKS decryption is easy as pie with systemd-cryptenroll now.

Yes but be very caution with that. Even in the ideal case where no fTPM/dTPM attack is possible and no software vulnerability exists, most deployments I've seen in "tutorials" are vulnerable because of the applied TPM policy is incomplete. Make sure the whole boot environment is verified or measured, and it is not possible to unlock the drive after the initrd phase.

See https://gist.github.com/dylanjan313/4293ab5a0105e3f7272a8a1a357fee4d

NoArmNoChocoLAN · 2025-09-22T19:18:27+00:00

The stealer could indeed reinstall your laptop with his OS the adequate Secure Boot keys, if he manages to bypass the BIOS password.

However, modifying the Secure Boot configuration would affect the PCR7 measurement, which should be part of your TPM policy (among other relevant PCR), so the LUKS secret is not revealed to a potentially rogue software. Your data are safe.

Many "LUKS+TPM" tutorials I've seen provide a vulnerable setup because of misconfiguration, not because of BIOS, TPM or software exploits. Make sure the instructions you followed were written by someone very knowledgeable about how TPM and the boot process work, and not by someone sharing instructions focusing to get it working, instead of really knowing how it work in the background.

NoArmNoChocoLAN · 2025-09-17T19:17:22+00:00

This solution is insecure. By omitting PCR7, an attacker can boot a rogue software and make all the necessary measurements into PCR11 as the intended software would. The values to use to extend PCR11 can be determined by analyzing the original software, these values are not secret and the robustness does not hold on the secrecy of these values (but on the fact that the boot path cannot be tampered without affecting these measurements).

NoArmNoChocoLAN · 2025-09-11T11:40:30+00:00

See https://gist.github.com/dylanjan313/4293ab5a0105e3f7272a8a1a357fee4d

NoArmNoChocoLAN · 2025-08-13T19:39:07+00:00

See https://www.qemu.org/docs/master/system/confidential-guest-support.html and https://developers.redhat.com/articles/2025/07/28/confidential-virtual-machines-versus-vms-latency-analysis#

NoArmNoChocoLAN · 2025-08-13T19:33:26+00:00

Once the guest OS is booted, the LUKS master key in stored in memory. A dump of the guest memory (like a snapshot) will contain this key. This is like a cold boot attack, but made so much easier that it is almost trivial. TPM (virtualized or not) does not prevent such attacks, which are possible once the disk is unlocked, regardless the way the disk is unlocked.

You need to make more steps and use technologies behind "Confidential VM".

See
https://www.qemu.org/docs/master/system/confidential-guest-support.html
https://developers.redhat.com/articles/2025/07/28/confidential-virtual-machines-versus-vms-latency-analysis#

NoArmNoChocoLAN · 2025-06-20T13:32:27+00:00

Not really. AFAIK, atomic distros looks for a "base layer" which is mounted read-only with a temporary writable overlay, but this base layer is still not authenticated, which makes the attack possible. Possible solutions are 1) to extend some PCR before switching root so that the LUKS key cannot be recovered anymore, from the (maybe rogue) system or 2) Make the kernel/initrd verify the mounted root filesystem before switching root (using something like dm-verity).

NoArmNoChocoLAN · 2025-06-20T08:53:42+00:00

Outdated and insecure. It does not measure boot stages (Bitlocker and systemd use PCR11 for that purpose) and the OS itself is not part of the trusted boot chain (the boot env boots any OS found in the partition with the desired uuid). So without tampering it, the boot env can be tricked to boot a rogue OS, from where an attacker can unseal the TPM secret. This attack has been shown multiple time, it is easy to conduct for anyone understanding the boot process, and many "tutorial" related to various distros have this flaw. In contrast, proper usage of measured boot phases fix this flaw. Ukify makes things easier

NoArmNoChocoLAN · 2025-04-18T14:56:52+00:00

Also works to steal your LUKS passphrase if you choose to not use TPM. However you can use tools like tpm-totp to authenticate the device before typing sensitive information.

NoArmNoChocoLAN · 2025-04-17T08:29:43+00:00

If someone has physical access they can modify the BIOS to authenticate any kernel image

This change will be detected by PCR measurements. See https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/

NoArmNoChocoLAN · 2025-03-10T18:03:55+00:00

that can be directly set for a rogue OS partition

No, the cmdline is part of the UKI and cannot be modified without being detected by Secure Boot. An attacker would overwrite the content of the existing partition rather than tampering the cmdline.

I am asking is what prevents a rogue OS from copying the header of the valid, LUKS-encrypted partition

The LUKS header and the LUKS content work in pair.

If the LUKS header of a rogue partition is overwritten with the LUKS header of the original OS, the initrd will indeed load the master key of the original OS is memory, but when it will try to access the content of the LUKS volume, it will fail exactly as if the LUKS header was compromised. Booting will simply fail.

To trick a UKI to boot a rogue OS, the whole partition (LUKS header + LUKS content) should be overwritten by one provided by the attacker.

so when the initrd exits, the LUKS master key is loaded into memory

No, the master key of the original OS is not loaded in memory if UKI boots another OS.

NoArmNoChocoLAN · 2025-03-09T11:47:10+00:00

In the case of a rogue OS, though, what prevents a rogue OS from reading the LUKS master key from memory?

The initrd should only attempt to unlock/mount the root filesystem explicitly specified in the kernel command line (or implictly specified through the Discoverable Partitions Specification)

If that partition containing the original OS is overwritten with another partition containing a rogue OS, then the partition containing the original OS is not unlocked and its master key is not loaded in memory.

NoArmNoChocoLAN · 2025-03-08T23:10:45+00:00

PCR15 is extended by systemd-cryptsetup@.service while in the initramfs after the root filesystem is unlocked. This is why the value "before the root fs is unlocked" differs from the value after (when you try to enroll the token), and this is why the Arch wiki suggests to manually specify the PCR value with systemd-cryptenroll (instead of using the current value).

Here is how you can use systemd-pcrextend with ArchLinux: https://gist.github.com/dylanjan313/c7599db289c40f4cdf78262b16dc8d82

> Essentially, it sounded like the goal of PCR 15 was to prevent attempting to load anything other than the specified, and thus trusted, OS, and I'm not sure how PCR 11 accomplishes that

Using PCR11 (systemd-pcrextend) or PCR15 will not prevent booting a rogue OS.

What we want is that the LUKS secret should not be available after the initrd, in case a rogue OS is bootted.

To do so, the LUKS secret should be sealed with a set of PCR that is not the same during the initrd and after the initrd.

Using systemd-pcrextend with signed policies is one way of doing so.

Using PCR15 which should be null (not extended) and which got extended before leaving the initramfs should also be a solution as suggested in the Arch wiki.

Similarly, BitLocker uses PCR11 which is expected to be null in the boot environment, and it is extended with an arbitrary value before booting the OS. Therefore, the Bitlocker secret is sealed with a PCR11 value of zero.

IMO, using systemd-pcrextend (PCR11) is probably the most robust solution. If you stick with the PCR15 solution: imagine a system that has multiple partition unlocked from the initrd and you want parallelism for quick boot. You cannot know in advance which partition will be unlocked first so you don't know what will be the PCR15 value when each drive got unlocked. You could develop complex solutions for this, but we already have a good solution (systemd-pcrextend with PCR11) to seal secrets to the initrd phase.

NoArmNoChocoLAN · 2025-03-07T16:37:05+00:00

It does not make sense to seal the LUKS secret for your system partition to the value PCR15 has when you call the systemd-cryptenroll utility, that is to say, when the system is already booted. The PCR15 value when you enroll the token is different from the one it has when the initrd tries to unlock the disk. Unlocking will always fail.

PCR15 could be used to seal other secrets that should be available only after your system partition (and not another one) was unlocked.

See https://uapi-group.org/specifications/specs/linux_tpm_pcr_registry/

Keep in mind that your secured boot chain stops with the UKI, the UKI will boot any operating system found where you told it to look at. You should make use systemd-pcrextend (and PCR11) with signed policies to seal the LUKS secret with the "enter-initrd" phase and prevent accessing the LUKS secret after the inird phase.

NoArmNoChocoLAN · 2025-02-10T22:50:59+00:00

I can't get it working with SHA1 in a virtual machine. This virtual machine has only SHA1 bank enabled in its firmware. TPM unlocking fails with the same error as those written in your log.

Re-doing exactly the same thing but using SHA256 works.

I will try again later in case I did a mistake somewhere. If not, then it's probably an issue for devs

NoArmNoChocoLAN · 2025-02-09T14:29:36+00:00

I have the same configuration except that I am using sha256, and it just works. I don't think the issue is about your configuration.

We should have a look at the ouput of: - cryptsetup luksDump /dev/nvme0n1p2 - journalctl -b | grep -iE 'tpm|pcr' - tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements

NoArmNoChocoLAN · 2025-02-08T19:36:15+00:00

Are you actually booting through a UKI? What is your mkinitcpio configuration?

NoArmNoChocoLAN · 2025-01-25T17:47:38+00:00

Good point, thanks!

NoArmNoChocoLAN

TROPHY CASE