NixOS on Giovanni Bassi

NixOS: Installation Guide with RAID 1, encryption, and TPM unlock (part 7 - Mitigating the OS swap attack)

giggio@giggio.net (Giovanni Bassi) — Mon, 01 Jun 2026 11:00:00 -0300

There is still a loophole where one could obtain the LUKS volume encryption key using another operating system. Let’s fix that.

This is the seventh post in the series:

Preparing the virtual machine and partitioning the disks
Disko, LUKS, and btrfs
Installing the OS
Enabling Secure Boot
Unlocking the disk with TPM
Mitigating the volume swap attack
Mitigating the OS-switch attack (this post)

If you are only using your own keys in Secure Boot, this post doesn’t apply to your scenario. If you are also using Microsoft’s keys, you need to implement this mitigation.

The Problem

So far, we have been linking disk decryption to PCR 7 (and PCR 15 for system loading, as described in the last post). As seen in previous posts, PCR 7 depends exclusively on the Secure Boot state. This means that, regardless of which operating system is loaded, PCR 7 will have the same values.

If you also trust third-party keys (such as Microsoft’s or another manufacturer’s, like Canonical’s) in Secure Boot, there is still an attack surface that allows booting another system signed by those authorities. Therefore, it’s necessary to bind the protection to something beyond just PCR 7.

With the operating system loaded and PCR 7 in the correct configuration, it’s possible to obtain the LUKS volume header data and decrypt it using the TPM to get the LUKS master key, and then decrypt the volume. This could even be done using a Live CD with a correctly signed boot loader.

Naively sealing the LUKS key with the NixOS boot loader

Sealing the volume key only with PCR 7 is risky, so let’s also use another PCR that is closely tied to our operating system. PCR 4 measures the boot loader and additional drivers — the boot loader/PE binary code executed in the boot path. This means only an operating system that loads using the NixOS .efi files we are using would be able to retrieve the LUKS key via the TPM.

Since these .efi files are generated on-demand for our specific NixOS configuration and signed with Lanzaboote using our private keys, this prevents another OS from decrypting the LUKS key. For instance, if you load Ubuntu, the boot loader will be Ubuntu’s, with different .efi files, and therefore the content extended into PCR 4 will also be different. Because PCR 4 measures the EFI/PE binary actually executed at boot, a different boot path produces a different measurement and cannot reuse the same TPM token.

This would be simple if the boot loader didn’t change every time the Kernel, initrd, or any boot configuration is updated, which ends up changing PCR 4. If that weren’t the case, we could simply run:

# remove previous token from disk 1
sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/disk/by-label/NIXLUKS1
# enroll new token using PCR 4 and PCR 7 on disk 1
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=4+7 /dev/disk/by-label/NIXLUKS1
# do the same for disk 2...

Note: The commands above can be combined into one, which will wipe and enroll in a single operation.

This will only work until the next time the boot loader files (the .efi files) are changed. On the first boot after such a change, the volume will no longer decrypt automatically, it will ask for the password, and you would need to run the commands above again. If that’s acceptable to you, you don’t even need to read the rest of the post, but I can tell you there is a better and equally secure way to solve this.

Sealing the LUKS key with the NixOS boot loader using a PCR policy

Important: Before starting, verify that your virtual machine is configured to use only one of the disks as a boot disk. I noticed that if both disks are marked as boot disks, PCR 4 is not correctly evaluated and the policy is not created. In the virtual machine settings, you can see this in the “Boot Options” menu. This might be a quirk of Virtual Machine Manager (and virsh), the Firmware used, or something related to Secure Boot and TPM protocols. The problem doesn’t occur on my physical machine, only on the virtual one.

The secret to solving this problem is a system that can predict the values that will be in the PCR and create an appropriate policy, and that is exactly what systemd-pcrlock does. While the process can be done manually, Lanzaboote recently implemented TPM measurement alongside Secure Boot integration, using systemd-pcrlock. At the time of writing, this hasn’t made it into a release yet, meaning it might contain bugs. By the time you read this, the functionality may have stabilized.

To enable it, simply add this to your configuration:

boot.lanzaboote = {
 enable = true;
 pkiBundle = "/var/lib/sbctl";
 configurationLimit = 8;
 measuredBoot = {
 enable = true;
 pcrs = [ 4 7 ];
 };
};

Finally, you need to perform a nixos-rebuild, but use boot instead of switch:

sudo nixos-rebuild boot

This will prepare the configuration, but it will only be used on the next boot. This is important to ensure that the boot loader files are correctly signed, in addition to preparing the PCR 7 files.

Note: systemd-pcrlock has several subcommands that allow you to “lock” a specific PCR. “Locking,” as used here, means inspecting the events of each PCR and generating .pcrlock files in the /var/lib/pcrlock.d directory. For example, systemd-pcrlock lock-firmware-code generates the file /var/lib/pcrlock.d/250-firmware-code-early.pcrlock.d/generated.pcrlock with PCR 0 and 2 measurements. Lanzaboote uses this system when you enable PCR 7 by running systemd-pcrlock lock-secureboot-authority and systemd-pcrlock lock-secureboot-policy. This is done by creating two oneshot systemd services: systemd-pcrlock-secureboot-authority and systemd-pcrlock-secureboot-policy.

Reboot the system. The LUKS key is still tied only to PCR 7, and the disks will be decrypted automatically. After the reboot, the policy file will have been created. You can verify if both PCRs are present in the file by running:

$ jq '.pcrValues.[].pcr' /var/lib/systemd/pcrlock.json
4
7

If this is correct, you can now remove the token from the disk headers that was tied only to PCR 7 and create a new one using the policy via the generated file:

# remove previous token and enroll new token using the policy on disk 1
sudo systemd-cryptenroll --tpm2-device=auto --wipe-slot=tpm2 --tpm2-pcrlock=/var/lib/systemd/pcrlock.json /dev/disk/by-label/NIXLUKS1
# remove previous token and enroll new token using the policy on disk 2
sudo systemd-cryptenroll --tpm2-device=auto --wipe-slot=tpm2 --tpm2-pcrlock=/var/lib/systemd/pcrlock.json /dev/disk/by-label/NIXLUKS2

With this, you can reboot again. The disk should continue to unlock automatically, but this time it is using the policy file, and therefore PCRs 4 and 7.

The functionality is now complete. Whenever the boot loader files are updated, the policy will also be updated, and the disk will be decrypted automatically without requiring any manual interaction. In the following sections, I will dive deeper into what is happening.

Inspecting TPM events

You can check TPM events by running sudo systemd-pcrlock log, or just sudo systemd-pcrlock. Unfortunately, the command doesn’t allow showing events for a specific PCR, so you can do it using JSON and jq. To see only PCR 4 events, run:

sudo systemd-pcrlock log --json=short 2>/dev/null | jq '[.log[] | select(.pcr == 4)]'

To see the components registered in systemd-pcrlock, use the list-components command:

$ sudo systemd-pcrlock list-components
ID VARIANTS
240-secureboot-policy /var/lib/pcrlock.d/240-secureboot-policy.pcrlock.d/generated.pcrlock
350-action-efi-application /nix/store/f4s218swc4kw35apcqg9al8d7s287x7y-pcrlock.d/350-action-efi-application.pcrlock
400-secureboot-separator /nix/store/f4s218swc4kw35apcqg9al8d7s287x7y-pcrlock.d/400-secureboot-separator.pcrlock.d/300-0x00000000.pcrlock
500-separator /nix/store/f4s218swc4kw35apcqg9al8d7s287x7y-pcrlock.d/500-separator.pcrlock.d/300-0x00000000.pcrlock
620-secureboot-authority /var/lib/pcrlock.d/620-secureboot-authority.pcrlock.d/generated.pcrlock
630-bootloader /var/lib/pcrlock.d/630-bootloader.pcrlock.d/current.pcrlock
635-lanzaboote /var/lib/pcrlock.d/635-lanzaboote.pcrlock.d/7.pcrlock

These components are used to predict the values of each PCR. They are what “lock” the TPM. The idea is that systemd-pcrlock lock-* commands check TPM events and generate these components, along with Lanzaboote generating the PCR 4 (boot loader) ones at every nixos-rebuild.

Finally, you can check the measurements being used by running systemd-pcrlock predict:

$ sudo systemd-pcrlock predict --pcr=4,7
Event log record 0 (PCR 0, "Raw: 2\0008\000\000\000") not matching any component.
Event log record 9 (PCR 1, "Raw: ACPI DATA") not matching any component.
Event log record 13 (PCR 2, "Raw: \030\377\004\000") not matching any component.
Event log record 27 (PCR 5, "GPT: disk 8118a150-5781-4514-94f0-517c327f4ca7") not matching any component.
Event log record 40 (PCR 9, "Linux: kernel command line") not matching any component.
Event log record 31 (PCR 11, "String: .linux") not matching any component.
Event log record 39 (PCR 12, "String: Global credentials initrd") not matching any component.
Event log record 44 (PCR 15, "cryptsetup:crypt_disk1:5a2876f5-9220-4040-8b56-7bc226c9d649") not matching any component.
3 combinations of components.
PCR 4 (boot-loader-code) matches event log and fully consists of recognized measurements. Including in set of PCRs.
PCR 7 (secure-boot-policy) matches event log and fully consists of recognized measurements. Including in set of PCRs.
PCRs in protection mask: 4 (boot-loader-code), 7 (secure-boot-policy)
Results for PCR 4 (boot-loader-code):
 sha256: 19d6c3ffa28c30062e84d8e90a357a6319ce921dfa15ee6618a5f9c38a5e9890
 sha256: 58d68b2aa60262d9831fdd1b8b0f50fd30610162bf3ae7f19d4722e21ba24277
 sha256: 480319eadf7ad52de18d44758204505cf34a4def787c762e1da3024a69b2ec8e
Results for PCR 7 (secure-boot-policy):
 sha256: cc1dc9cbd11e3ad0a695744ab152362d388e2e97f165117e3e45b8248f4a5078

The initial lines show event records that were not recognized. Since predict only generates predictions for PCRs whose component coverage is complete, those PCRs are excluded from this specific policy. If we wanted to use them, some could have components created by running systemd-pcrlock lock-* commands, while others would need manual component creation.

Lastly, let’s compare the PCR 7 logs used in the fifth post. The only difference is the inclusion of the component field (which “locks” the PCR), highlighted below:

sudo systemd-pcrlock log --json=short 2>/dev/null | jq '[.log[] | select(.pcr == 7)]'

[
 {
 "pcr": 7,
 "pcrname": "secure-boot-policy",
 "event": "efi-variable-driver-config",
 "match": true,
 "sha256": "9f75b6823bff6af1024a4e2036719cdd548d3cbc2bf1de8e7ef4d0ed01f94bf9",
 "phase": "F",
 "component": "240-secureboot-policy",
 "description": "Variable: dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f"
 },
 {
 "pcr": 7,
 "pcrname": "secure-boot-policy",
 "event": "efi-variable-authority",
 "match": true,
 "sha256": "f35567246a92b2fcdd2901e4ad2febdfd80173f25527c5a73033bf100a8eb980",
 "phase": "F",
 "component": "620-secureboot-authority",
 "description": "Authority: db-d719b2cb-3d3a-4596-a3bc-dad00e67656f"
 }
]

Evaluating the LUKS header token

We can also compare the LUKS header, which was updated when we ran systemd-cryptenroll with the --wipe-slot argument and then --tpm2-pcrlock. In the fifth post, the policy wasn’t used, so the tpm-pcrs field (a list) had the value 7, and now it’s empty. The tpm2-pcr-bank field is no longer used, and the tpm2_pcrlock_nv field now has a hash:

sudo cryptsetup luksDump --dump-json-metadata /dev/disk/by-label/NIXLUKS1 | jq -r '.tokens."0"'

{
 "type": "systemd-tpm2",
 "keyslots": ["1"],
 "tpm2-blob": "<a base64 value>",
 "tpm2-pcrs": [],
 "tpm2-policy-hash": "<a hash>",
 "tpm2_pcrlock": true,
 "tpm2_srk": "<another base64 value>",
 "tpm2_pcrlock_nv": "<yet another base64 value>"
}

This last field, ending in _nv, is especially important. It points to a non-volatile area of the TPM, which is not erased when the computer turns off. The pcrlock policy data is stored there, and if the TPM is cleared, it forces the recreation of the policy (more on this below).

Removing the TPM policy

If you ever remove the NixOS TPM measurement settings (boot.lanzaboote.measuredBoot), you will need to remove the policy manually. It is registered in the aforementioned policy file, but also in the TPM’s non-volatile memory. This should be automated by Lanzaboote (I opened an issue), but from what I’ve seen, it isn’t yet. After running nixos-rebuild switch, run:

# remove the policy from the TPM's non-volatile memory and also the files:
# /var/lib/systemd/pcrlock.json and
# /boot/loader/credentials/pcrlock.nixos.cred
sudo systemd-pcrlock remove-policy

Don’t forget to remove the TPM keyslot from the LUKS volume headers:

sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/disk/by-label/NIXLUKS1
sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/disk/by-label/NIXLUKS2

Dealing with a cleared/wiped TPM

If the TPM’s non-volatile memory is wiped, the reference to the TPM policy registered in the LUKS volume header will become outdated, pointing to a record that no longer exists. This will force us to re-enroll the policy into the LUKS header. You can test this safely by clearing the TPM directly from Linux. Run the following commands and reboot:

nix-shell -p tpm2-tools
sudo tpm2 clear
exit

As a result, the operation to decrypt the disk using the TPM during boot will fail, and you will need to decrypt using your password. To re-enable automatic TPM decryption, you first need to remove the policy from the disk (the /var/lib/systemd/pcrlock.json and /boot/loader/credentials/pcrlock.nixos.cred files—explained in the previous section), run nixos-rebuild boot, and reboot to recreate the wiped policy. Then, redo the LUKS header with the systemd-cryptenroll --wipe-slot and systemd-cryptenroll --tpm2-pcrlock commands:

sudo systemd-pcrlock remove-policy
sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/disk/by-label/NIXLUKS1
sudo systemd-cryptenroll --wipe-slot=tpm2 /dev/disk/by-label/NIXLUKS2
sudo nixos-rebuild boot
# reboot, enter LUKS password
jq '.pcrValues.[].pcr' /var/lib/systemd/pcrlock.json # validate that the result is: 4 7
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrlock=/var/lib/systemd/pcrlock.json /dev/disk/by-label/NIXLUKS1
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrlock=/var/lib/systemd/pcrlock.json /dev/disk/by-label/NIXLUKS2

Reboot once more, and you should no longer be prompted for a password.

You’ve already seen these commands in this article, so I won’t detail them further.

Conclusion

With this, your operating system is now protected, and you have the convenience of a system that starts without constantly asking for a decryption password. Better yet, since everything was done using NixOS, the configuration is ready to be reused: if it worked once, it will work forever.

The series was supposed to end here, but since I wrote this post, a few days have passed and I’ve used everything I wrote here to migrate my own machine from Ubuntu to NixOS. I learned a lot and have a few more things to share, so the series will have at least one more post.

If you’ve followed along this far, ran a proof of concept with the examples, or have ideas or criticisms, leave a comment so I know!

NixOS: Installation Guide with RAID 1, encryption, and TPM Unlock (part 6 - Mitigating the volume swap attack)

giggio@giggio.net (Giovanni Bassi) — Tue, 26 May 2026 10:00:00 -0300

The NixOS disk is encrypted, but a careful LUKS volume swap attack can still be used to obtain the encryption master key.

In this post, I show how to mitigate it!

This is the sixth post in the series:

Preparing the virtual machine and partitioning the disks
Disko, LUKS, and btrfs
Installing the OS
Enabling Secure Boot
Unlocking the disk with TPM
Mitigating the volume swap attack (this post)

As I said in the previous post, this kind of attack would not be carried out by an average person. The computer shop technician who is repairing your laptop probably will not be able to read your LUKS encrypted disk and with the key sealed with the help of PCR 7. But someone who knows what they are doing will find the weakness. This post and the next one are for those who want to be fully protected, both from the technician at the shop around the corner and from a hostile government or corporate agent. By the end of these two posts, the attacks described here will be mitigated, significantly increasing security (keeping in mind that it is always prudent to consider other attack surfaces outside these scenarios).

The problem

The attack was described by Oddlama, and it basically consists of removing the disk from the original computer, creating a fake encrypted partition with the same identification data as the original partition, and then using that to obtain the key. He even describes how to do this against NixOS.

This is possible because the UKI (Unified Kernel Image — the binary loaded by UEFI that contains the kernel and the initrd) is not encrypted — if it were, UEFI would not be able to load it. The LUKS volume header is also not encrypted, since it must be read by the system in initrd so that the LUKS volume can be decrypted. It is possible to inspect what will be loaded during boot and replace the LUKS volume with another one carefully prepared to steal the master key from the original LUKS volume.

I will not go into more detail because the explanation is long. You can read Oddlama’s post; it is quite interesting. The important point is that this attack is only possible because the UKI does not validate the identity of the LUKS volume, which allows it to be replaced.

Closing the breach

To solve the problem, we just need to start validating the decrypted volume before proceeding, something that is not being done yet and will be addressed using PCR 15 (system-identity). In the previous post, I showed how to list the hashes of all PCRs with systemd-analyze pcrs. Notice that PCR 15 was zeroed out, meaning it had not been extended. systemd can start writing to it by simply enabling tpm2-measure-pcr=yes for systemd-cryptsetup during the boot process.

To start writing to PCR 15 in the NixOS way, we need a Nix configuration. Fortunately, Oddlama himself provided the solution, pointing to a Forgejo repository by PatrickDaG, with the file ensure-pcr.nix, which has already been adapted in the repository cloned into /etc/nixos, and which makes it possible to read this PCR through a NixOS module.

I incorporated this module into my solution, which made it very easy to apply. The example commit is f690b88, described as “Enable PCR15”, but we do not need to check it out; it is enough to update the configuration in /etc/nixos/configuration.nix (it is already in the code, just remove the comment):

systemIdentity = {
 enable = true;
};

Then apply it:

nixos-rebuild switch

Restart the virtual machine, and after the reboot, confirm that the value of PCR 15 is present (the value below is just an example — replaced by a sequence from 0 to 9):

$ systemd-analyze pcrs 15
NR NAME SHA256
15 system-identity 0123456789012345678901234567890123456789012345678901234567890123

That is the hash of the system identity (derived from the activated LUKS volume key); it is what will ensure that the unlocked volume is the expected one, reducing the volume swap attack.

The value found must be copied into the pcr15 field in the configuration. For example, using the fictitious sequence above from 0 to 9:

systemIdentity = {
 enable = true;
 pcr15 = "0123456789012345678901234567890123456789012345678901234567890123";
};

Change this value, reboot once more, and everything should continue working.

How this solution prevents volume swapping

The explanation is in the Nix module defined in the file ensure-pcr.nix.

It creates a systemd service that starts extending PCR 15 when systemIdentity.enable is enabled, running:

systemd-cryptsetup attach crypt_disk1 /dev/disk/by-partlabel/NIXLUKS1 - 'tpm2-device=auto,tpm2-measure-pcr=yes,discard';

And when the hash of PCR 15 has been defined in systemIdentity.pcr15, it creates a check-pcrs service that runs in initrd and, if it fails, prevents boot from continuing. This service is very simple: it just compares the hash stored in the configuration with the value found in PCR 15:

if [[ $(systemd-analyze pcrs 15 --json=short | jq -r ".[0].sha256") != "${config.systemIdentity.pcr15}" ]] ; then
 echo "PCR 15 check failed"
 exit 1
else
 echo "PCR 15 check succeed"
fi

As this service is required by sysroot.mount, if check-pcrs fails the root disk cannot be mounted and the entire boot fails, entering emergency mode.

What if the boot fails?

If the value of PCR 15 changes for any reason, the boot will fail and enter emergency mode. In that case, you will need to log in with the emergency password configured in initrd and run:

systemctl disable check-pcrs
systemctl default

Note: see the boot.initrd.systemd.emergencyAccess attribute in configuration.nix, that is what defines the emergency initrd password (using a hash of the password). To create the password as test, run (replace the salt, xyz, and the password):

openssl passwd -6 -salt xyz test

Tip: I recommend that you test this by changing the configuration value to the wrong hash, running switch, and confirming that the boot failed. Then test the commands above: you will need to provide the initrd emergency password, disable the check-pcrs service, and continue the boot. In the worst-case scenario, if you cannot do that, you can choose the previous configuration from the boot menu. After logging in again, set the PCR 15 value in the configuration back to the correct one, run a new switch and reboot, making sure that boot works again without issues.

Is it secure?

Again: not yet.

The attack described by Oddlama no longer works, but there is still another one: since we only bind the disk encryption to PCRs 7 and 15, it is still possible to replace the operating system with another one and use the TPM to decrypt the disk. We will solve that in the next post.

NixOS: Installation Guide with RAID 1, encryption, and TPM Unlock (part 5 - unlocking the disk with TPM)

giggio@giggio.net (Giovanni Bassi) — Mon, 18 May 2026 11:00:00 -0300

At last, we are going to automatically decrypt the NixOS disk using the TPM!

This is the fifth post in the series:

Preparing the virtual machine and partitioning the disks
Disko, LUKS, and btrfs
Installing the OS
Enabling Secure Boot
Unlocking the disk with TPM (this post)

Up to now, every boot has required the LUKS password to decrypt the disk. But if the machine’s integrity has not been compromised, there is no problem in doing this automatically. But how?

Now it is time to orchestrate everything we have put together so far, connecting LUKS, Secure Boot, and the TPM.

Why this is safe

Assuming the machine has not been compromised, when the operating system comes up, the only safe way to access it is with valid credentials — assuming the system has no exploitable vulnerability. That means logging in through the console, SSH, the graphical interface, or a serial connection. In practice, that means that without a login password there is no access to the computer, and no privilege is gained.

Everything works based on this principle: an uncompromised and intact system protects itself, and if it is compromised (firmware modification, disk removal, etc), encryption protects the data.

Understanding the TPM

The TPM (Trusted Platform Module) is a dedicated processor that stores, in an inviolable way, measurements taken of the hardware and software running on the computer. These measurements are stored in PCRs (Platform Configuration Registers), whose values can be extended, but never set directly. Every value sent to the TPM extends the previous value and produces a new one. If we were to model this as a formula, it would be something like this:

PCR = HASH(PCR || new_measurement)

In other words, the PCR hash is used together with the new measured value to create the new hash.

You can see the hashes of each PCR on your running TPM (fictitious values):

$ systemd-analyze pcrs
NR NAME SHA256
 0 platform-code 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef
 1 platform-config 123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0
 2 external-code 23456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01
 3 external-config 3456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012
 4 boot-loader-code 456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123
 5 boot-loader-config 56789abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234
 6 host-platform 6789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345
 7 secure-boot-policy 789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456
 8 - 89abcdef0123456789abcdef0123456789abcdef0123456789abcdef01234567
 9 kernel-initrd 9abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345678
10 ima abcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789
11 kernel-boot 0000000000000000000000000000000000000000000000000000000000000000
12 kernel-config 0000000000000000000000000000000000000000000000000000000000000000
13 sysexts 0000000000000000000000000000000000000000000000000000000000000000
14 shim-policy bcdef0123456789abcdef0123456789abcdef0123456789abcdef0123456789a
15 system-identity 0000000000000000000000000000000000000000000000000000000000000000
16 debug 0000000000000000000000000000000000000000000000000000000000000000
17 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
18 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
19 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
20 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
21 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
22 - ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
23 application-support 0000000000000000000000000000000000000000000000000000000000000000

Each PCR is independent and is extended freely, without depending on the others. On compatible TPMs there are 24 PCRs; the UAPI (Linux Userspace API Group) in its specifications considers 0–7 to be firmware and 8–15 to be the range available to the operating system, although the systemd ecosystem also uses specific PCRs for additional measurements, and PCRs 16–23 are also usable.

When the computer powers on, all PCRs start out with no value. The firmware then begins extending the PCRs. For example, PCR 0 depends on the software running in the firmware — what we normally call the BIOS. When you “update the BIOS”, PCR 0 changes. PCR 1 may change if you replace a hardware component. PCR 4 is tied to the operating system; it measures the boot loader and additional drivers. And so on.

PCR 7 depends on the Secure Boot state. Its values are commonly extended using the keys enrolled in Secure Boot, as well as the Secure Boot Authority. It is this PCR that we will use to unlock the disk, at this moment.

I will come back to PCRs in the next posts, but it is important to understand what they are for. If you decide to use what I am proposing in these posts, this knowledge may be useful if you run into trouble.

You can see all the events that led to PCR extensions by running sudo systemd-pcrlock log. Using jq, you can show only the events that led to PCR 7:

sudo /run/current-system/systemd/lib/systemd/systemd-pcrlock log --json=short 2>/dev/null | jq '[.log[] | select(.pcr == 7)]'

The result, simplified so it does not get too long, is this:

[
 {
 "pcr": 7,
 "pcrname": "secure-boot-policy",
 "event": "efi-variable-driver-config",
 "match": true,
 "sha256": "9f75b6823bff6af1024a4e2036719cdd548d3cbc2bf1de8e7ef4d0ed01f94bf9",
 "phase": "F",
 "component": null,
 "description": "Variable: dbx-d719b2cb-3d3a-4596-a3bc-dad00e67656f"
 },
 {
 "pcr": 7,
 "pcrname": "secure-boot-policy",
 "event": "efi-variable-authority",
 "match": true,
 "sha256": "f35567246a92b2fcdd2901e4ad2febdfd80173f25527c5a73033bf100a8eb980",
 "phase": "F",
 "component": null,
 "description": "Authority: db-d719b2cb-3d3a-4596-a3bc-dad00e67656f"
 }
]

Note that the hash value, stored in the sha256 field, changes with each event. When the TPM receives a request to decrypt a value, its state must match exactly what was used when the value was encrypted (this is done through TPM policies). That means a value encrypted early in the boot process may no longer be decryptable at the end of the boot process, if the PCR has been extended again. This is especially useful for this very reason: allowing a value to be accessible only at a specific point in the boot sequence, such as during initrd startup (PCR 11 has measurements that make this possible).

Systemd documents how it uses PCRs, and since nowadays there is practically no Linux without systemd, it is worth understanding. This document will be useful later, when we look more closely at PCR 15 (system identity).

Unlocking the disk during boot

Only one command is needed to make everything happen. In our case, since we have two disks and two partitions, we run the command once for each of them (you will need to enter your LUKS password for the process to complete):

sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/disk/by-label/NIXLUKS1
sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/disk/by-label/NIXLUKS2

When this command runs, the volume master key is obtained using your password. It is then encrypted (sealed) using the TPM, and this sealed value is stored in the LUKS volume header. In this case, only PCR 7 is being used to seal the value, meaning only the Secure Boot state. That means if the Secure Boot state changes (if it is reset, or if a new key is removed or added), the TPM’s PCR 7 state will also change, and the disk will no longer be decrypted during boot. In this post, the goal is to tie automatic disk decryption to the Secure Boot state, and that is what we have done.

You can see the details stored in the LUKS volume header by running the following command after systemd-cryptenroll has been executed:

sudo cryptsetup luksDump /dev/disk/by-label/NIXLUKS1

Notice the Tokens field, with the first one being systemd-tpm2, with a Keyslot:

Tokens:
 0: systemd-tpm2
 Keyslot: 1

To see more details about the sealed value, run:

sudo cryptsetup luksDump --dump-json-metadata /dev/disk/by-label/NIXLUKS1 | jq -r '.tokens."0"'

The result will look something like this:

{
 "type": "systemd-tpm2",
 "keyslots": ["1"],
 "tpm2-blob": "<a base64 value>",
 "tpm2-pcrs": [7],
 "tpm2-pcr-bank": "sha256",
 "tpm2-policy-hash": "<a hash>",
 "tpm2_srk": "<another base64 value>",
}

The tpm2-blob contains the value encrypted by the TPM (plus metadata). Using the tools from the tpm2-tools package and root access, you could recover the master password from this value. That is not a security problem: the system is already running and the disk is already decrypted. The purpose of TPM protection is not to protect a healthy running system from its administrator, but to protect against integrity violations that happen before, during, and after boot.

With just these two commands, the TPM will start unlocking both LUKS volumes. Reboot to confirm that it no longer asks for the password. If it does, inspect the boot logs with sudo journalctl --boot.

Is it secure?

Not yet.

There are two vulnerabilities, and I will address them in the next posts. Neither is trivial, but someone who understands how all of this works could gain access to the data in a short amount of time. None of the work done so far will be lost; we will build on the current solution. The good news is that both issues are easy to fix.

That said, it is fair assume that most people, including technicians who are not systems penetration experts, would no longer be able to read the disk of a computer encrypted this way. In other words, sending a laptop for repair with this configuration would probably not present a risk. But that is still not good enough.

In the next post we will start closing the gaps.

NixOS: Installation Guide with RAID 1, encryption, and TPM Unlock (part 4 - Secure Boot)

giggio@giggio.net (Giovanni Bassi) — Thu, 14 May 2026 11:00:00 -0300

In the fourth post of our series, we are going to configure Secure Boot to ensure that only trusted operating systems can be executed.

This is the fourth post of the series:

Preparing the virtual machine and partitioning the disks
Disko, LUKS, and btrfs
Installing the OS
Enabling Secure Boot (this post)

Secure Boot is a fundamental component for tightening the security, especially when using the TPM to automatically decrypt the disk. I will explain what it is, what it’s for, and how to implement it in NixOS using Lanzaboote.

Understanding Secure Boot

Secure Boot is a protocol that is part of the UEFI (Unified Extensible Firmware Interface). When enabled, it verifies if the operating system’s bootloader has a valid digital signature recognized by the keys registered in the motherboard’s firmware.

This prevents boot-level malware (rootkits) or unauthorized operating systems from loading. Additionally, the TPM uses the Secure Boot state as one of the metrics to decide whether or not to release the disk encryption keys.

There are three main ways to manage Secure Boot keys:

Factory default keys: Usually the Microsoft keys that come with almost every computer;
Custom keys (User Mode): You remove the Microsoft keys and install only your own;
Hybrid Mode: You keep the Microsoft keys (for dual-booting with Windows) and add your own.

If you don’t intend to run Windows, the second option is the most restrictive and secure. If you need dual boot, the third is mandatory. It’s worth noting that NixOS does not have a bootloader signed by Microsoft (unlike Ubuntu or Fedora), so we always need to generate our own keys.

And why Microsoft keys, specifically? Because they were the first company to push Secure Boot as mandatory, and they hold the largest share of the PC market. There is quite a bit of controversy regarding this.

The important thing for our setup is knowing that once you define how Secure Boot will be used, it cannot be changed without breaking the automatic decryption process (which will be done with the help of the TPM). In our case, we will use the third option (mixing Microsoft keys with our own). If Secure Boot is turned off on the machine or a new platform key is loaded, the TPM will refuse to decrypt the disk. I’ll explain this in future posts, so for now, what matters is enabling Secure Boot.

Putting the Firmware into Setup Mode

In the first post, we cleared the keys in the VM’s boot menu to enter Setup Mode. This is essential: for us to write our keys via software, the firmware must be “open” to new signatures.

Confirm the status by running:

$ sudo bootctl status
...
Secure Boot: disabled (setup)
...

If disabled (setup) appears, we are ready to proceed.

Generating Keys with sbctl

We will use sbctl to create and register our keys. Since it isn’t installed by default, let’s use nix-shell:

nix-shell -p sbctl

Note: In NixOS, you can bring any application into your terminal’s context using nix-shell. With this, the sbctl command becomes available in a subshell — to exit, just run exit.

To generate the keys, we will run the create-keys subcommand:

sudo sbctl create-keys

The keys will be generated in /var/lib/sbctl/. You can see the structure with the tree command:

$ tree /var/lib/sbctl/
/var/lib/sbctl/
├── GUID
└── keys
 ├── db
 │   ├── db.key
 │   └── db.pem
 ├── KEK
 │   ├── KEK.key
 │   └── KEK.pem
 └── PK
 ├── PK.key
 └── PK.pem

Install the keys into the machine’s firmware with enroll-keys. This will use the keys we created earlier with sbctl. With the --microsoft argument, Microsoft’s platform keys will also be installed:

sudo sbctl enroll-keys --microsoft

Verify that Secure Boot has been re-enabled with:

sudo bootctl status

It should show Secure Boot: enabled (user). It might not show as enabled yet until the next boot, showing up as Secure Boot: disabled, but without setup. But don’t reboot just yet!

Signing the Boot with Lanzaboote

At this point, if you restart the machine, NixOS will no longer boot, as the NixOS bootloader is not yet signed with the Secure Boot keys we created in the previous step. That’s where Lanzaboote comes in. It automates the signing of NixOS generations. It replaces the default systemd-boot manager with one that handles the keys generated by sbctl. Once enabled, whenever a new bootloader is created in the /boot directory, it will be signed with the keys located in /var/lib/sbctl.

To enable Lanzaboote and then sign the files, first go to the configuration directory that was copied in previous posts to /etc/nixos, and check out the correct commit. Be careful not to forget the git checkout, or it won’t work:

cd /etc/nixos
# ensuring the current user owns the files:
sudo chown -R giggio:users .
# checkout with the message "Enable lanzaboote":
git checkout dab0fd4

The change in your configuration.nix disables the native systemd-boot and activates lanzaboote, pointing to the keys directory:

 boot.loader.systemd-boot.enable = false;
 boot.lanzaboote = {
 enable = true;
 pkiBundle = "/var/lib/sbctl";
 };

The Lanzaboote configuration was already present; it was just disabled. And with it enabled, systemd-boot can be disabled. Note also that the keys directory, defined in the pkiBundle attribute, is already correctly pointed to /var/lib/sbctl.

That’s all; now just install the new configurations, which take effect immediately and will also be effective on the next boot:

sudo nixos-rebuild switch

Validating the Signature

To ensure Lanzaboote did its job and signed the .efi binaries, run:

$ sudo sbctl verify
Verifying file database and EFI images in /boot...
✓ /boot/EFI/BOOT/BOOTX64.EFI is signed
✓ /boot/EFI/Linux/nixos-generation-1-xxx.efi is signed
✓ /boot/EFI/Linux/nixos-generation-2-yyy.efi is signed
✗ /boot/EFI/nixos/kernel-7.0-zzz.efi is not signed
✓ /boot/EFI/systemd/systemd-bootx64.efi is signed

Note about the Kernel: It is normal to see an ✗ on the isolated kernel file. What matters are the files inside /boot/EFI/ and the boot managers. Lanzaboote creates a Unified Kernel Image (UKI), which bundles the kernel and the initrd into a single signed executable that the UEFI can run directly.

Now you can reboot. If everything went well, the system will come up normally and bootctl status will confirm: Secure Boot: enabled (user).

The machine still asks for the password to decrypt the disk. This is expected, as we haven’t yet implemented the structure for automatic decryption with the TPM.

Troubleshooting Secure Boot

If something goes wrong and the VM won’t start, you can reset the NVRAM (the VM’s “BIOS”). On your host, turn off the VM and run:

# on the host:
virsh start <vm_name> --reset-nvram

This will start the virtual machine normally, but with all the firmware boot settings lost, including Secure Boot settings.

The following commands will re-apply the boot settings to the firmware’s non-volatile memory and the disk:

# on the vm:

# registering platform keys in the firmware again:
sudo sbctl enroll-keys --microsoft
# installing the boot menu option:
sudo bootctl install
# re-signing the UKIs:
sudo nixos-rebuild switch

Why run switch again: When running bootctl install, the files /boot/EFI/systemd/systemd-bootx64.efi and /boot/EFI/BOOT/BOOTX64.EFI will not be signed, so it is necessary to run switch so that these two files become signed again.

Declarative Approach

Lanzaboote allows generating platform keys automatically via Nix config:

boot.lanzaboote = {
 autoGenerateKeys.enable = true;
 autoEnrollKeys = {
 enable = true;
 autoReboot = true;
 };
};

This is described in more detail in the docs on automatic provisioning.

While practical for testing, I don’t recommend using this in production systems. The ideal approach is to generate keys manually (as I demonstrated here) and store them securely somewhere. A good option is to use sops-nix, keeping the keys encrypted within the repository itself. The inconvenience would be during application, where you would always need the keys or devices to decrypt the sops secrets at every nixos-rebuild.

Next Up: Using TPM to Decrypt the Disk

Secure Boot is active. The disk is encrypted. But we still have to type the LUKS password at every boot.

If someone tries to start another operating system, it will need to be signed with your platform key or Microsoft’s. You can make the system more secure by removing the --microsoft option from the enroll-keys command and not allowing any other operating system.

In the next post, we will configure the TPM (Trusted Platform Module) so that it “measures” the Secure Boot state and releases the encryption key automatically if the system hasn’t been tampered with. Maximum security with convenience.

See you then!

NixOS: Installation Guide with RAID 1, encryption, and TPM Unlock (part 3 - Installing the OS)

giggio@giggio.net (Giovanni Bassi) — Mon, 11 May 2026 11:00:00 -0300

I’m continuing my journey of setting up a NixOS machine with secure and redundant storage. In this post, we’re going to perform the actual OS installation!

This is the third post in the series:

Preparing the virtual machine and partitioning the disks
Disko, LUKS, and btrfs
Installing NixOS (this post)

At this point, we have a virtual machine with formatted disks and the file system configured and mounted, ready to receive the NixOS binaries.

Why aren’t we using disko-install?

The Disko project includes a tool called disko-install that allows you to format partitions and install NixOS in a single step. The tool is excellent and even allows for disk parameterization via the command line.

However, a bug prevents its use when the machine’s RAM is smaller than the size of the system being created. Until this is resolved, we will follow the process in two stages: disk preparation (previous post) and the manual installation of the operating system (this post).

But… if that bug is ever fixed, the command would look like this:

sudo nix --experimental-features "nix-command flakes" run 'github:nix-community/disko/latest#disko-install' -- \
 --flake ~/nixos#nixos3 --disk disk1 /dev/vda --disk disk2 /dev/vdb

Installing the operating system

We are starting from the final state of the previous post, with the system mounted at /mnt. If you restarted the virtual machine, just run the following command to mount them again without needing to reformat everything:

sudo nix --experimental-features "nix-command flakes" run github:nix-community/disko/latest -- \
 --mode mount ~/nixos/disko.nix

With everything mounted, we start the NixOS installation by pointing to our flake:

sudo nixos-install --root /mnt --no-root-passwd --flake ~/nixos#nixos3

This command will take a few minutes. NixOS will download and build the entire system from scratch within the /mnt directory.

Configuration Persistence

To manage your system in the future (using nixos-rebuild), we need to move our configuration files into the new system by copying the repository to your /etc/nixos directory, which is mounted at /mnt/etc/nixos:

sudo cp -R ~/nixos /mnt/etc/nixos

Setting the User Password

Although I left a default password in the settings (luks) to make the lab easier, let’s define the password manually. We will use nixos-enter, which creates a chroot environment in the new system:

sudo nixos-enter --root /mnt -c "passwd giggio"

Note: nixos-enter is extremely useful for maintenance. It allows you to “enter” the installed system even before the first boot to fix configurations or reset passwords.

NixOS is installed! At this stage, we have partitioned and encrypted disks with a password entered during boot, the btrfs file system is formatted, and the operating system is installed. Everything should work; shut down the VM, remove the ISO from your settings, and start the VM again.

First Access and SSH

After booting, log in with the user giggio and the password defined via passwd in the previous step.

To access via SSH from your host machine, remember to clear the old key (from the installation environment) from your known_hosts file (created during the first access to the VM):

ssh-keygen -R <ip>

Now, connect with the new user:

ssh giggio@<ip>

What do we have so far?

If you’ve never used NixOS, now is the time to experiment. In practice, it’s a modern Linux with GNOME. You’ll see that it runs with GNOME 49 (with 50 about to be integrated into nixpkgs), and it’s on the latest Kernel version - currently version 7.0.0.

The system already features RAID 1 via btrfs and LUKS encryption. However, you’ll notice that it still asks for the encryption password manually at every boot.

In the next post, we’ll dive deep into Secure Boot, so I’ll stop here to keep the next one from getting too long. It’s coming soon! See you then!

NixOS: Installation Guide with RAID 1, encryption, and TPM unlock (part 2 - Disko, LUKS, and btrfs)

giggio@giggio.net (Giovanni Bassi) — Wed, 06 May 2026 11:00:00 -0300

In this post I keep on building a NixOS setup with secure storage, now going deeper into Disko, LUKS, and btrfs.

This is the second post in the series. Read the first one.

In the previous post I showed how to create the virtual machine and partition the disks using Disko. The main command was:

sudo nix --experimental-features "nix-command flakes" run github:nix-community/disko/latest -- \
 --mode destroy,format,mount ~/nixos/disko.nix

Although the file disko.nix is part of a flake (a versioned Nix configuration), in this case I ran only the file on its own with nix run.

It is also possible to run only the mount step, after the disk has already been partitioned and formatted, with --mode mount.

What Disko is

Disko is a project that brings Nix a declarative way to partition and format disks. In Nix, everything is done declaratively, except disk partitioning and formatting. Disko solves that. Partitioning and formatting disks is done only at the start of an installation, and that is exactly where the project is useful.

In addition, Disko provides a NixOS module that lets you use what was declared to define NixOS file systems, which are normally declared in the file hardware-configuration.nix. I will talk more about that at the end.

Disko can also be used in the installation process imperatively, through the command line. That is what I did when installing my servers.

Configuring the disk and its first partition

I am working with two disks. The second disk is where all the file system declarations live, so I will focus on it. The first disk ends up being a bit simpler, since it will be mirrored from the first one (I will talk about that below, in the RAID section).

At the beginning I declare the disk, the device I am referring to (/dev/vdb — that is, the second virtual disk), and the first partition, which will be the EFI system partition, or ESP (EFI System Partition):

{
 disko.devices = {
 disk = {
 # disk1 omitted
 disk2 = {
 type = "disk";
 device = "/dev/vdb";
 content = {
 type = "gpt";
 partitions = {
 ESP = {
 size = "1G";
 type = "EF00";
 label = "EFI2";
 content = {
 type = "filesystem";
 extraArgs = [ "-n" "EFI2" ];
 format = "vfat";
 mountpoint = "/boot";
 mountOptions = [ "umask=0077" ];
 };
 };
 # crypt_disk2 partition omitted
 };
 };
 };
 };
 };
}

Note that the mount options are included, and are used both by Disko’s mount command and by the Disko module when defining file systems.

In this case, an ESP partition needs to have type EF00 and be formatted as vfat. I also set the label of the partition to EFI2, and the file system label to the same value (with -n EFI, an argument passed to mkfs.vfat).

This part will generate something roughly like these commands:

parted /dev/vdb mklabel gpt
parted /dev/vdb mkpart primary 1MiB 1025MiB
parted /dev/vdb set 1 esp on
mkfs.fat -F 32 -n EFI2 /dev/vdb1
# and, for mount:
mount /dev/disk/by-label/EFI2 /boot

Second partition: LUKS + btrfs

Next, I need to create the Linux partition, which I want to be encrypted. The encryption will be handled by LUKS, so the type is defined as luks (in the ESP it was defined as filesystem). That means the command used to set up the partition will be cryptsetup luksFormat, and it is what receives the partition label parameter --label NIXLUKS2:

{
 disko.devices = {
 disk = {
 disk2 = {
 content = {
 partitions = {
 # ESP partition omitted
 crypt_disk2 = {
 size = "100%";
 label = "NIXLUKS2";
 content = {
 type = "luks";
 name = "crypt_disk2";
 extraFormatArgs = [ "--label" "NIXLUKS2" ];
 passwordFile = "${./luks-password.txt}";
 settings = { allowDiscards = true; };
 content = { }; # btrfs details omitted
 }; # other curly braces omitted

On a real NixOS system the password coming from the luks-password.txt file would be encrypted. I usually use sops-nix for that.

That previous part will generate something roughly like these commands:

parted /dev/vdb mkpart primary 1025MiB 100%
cryptsetup --label=NIXLUKS2 luksFormat --type luks2 /dev/vdb2
# and, for mount:
cryptsetup open /dev/vdb2 crypt_disk2

Note: The password is entered interactively in the commands above.

Then, in the content part, we define what goes inside the LUKS encrypted volume, in this case, a btrfs file system.

# beginning omitted
partitions = {
 # ESP partition omitted
 crypt_disk2 = {
 content = {
 # LUKS details omitted
 content = {
 type = "btrfs";
 extraArgs = [ "--label" "NIXOS" "-d" "raid1" "-m" "raid1" "/dev/mapper/crypt_disk1" ];
 subvolumes = {
 "/@" = { mountpoint = "/"; };
 "/@home" = { mountpoint = "/home"; };
 "/@root" = { mountpoint = "/root"; };
 "/@nix" = { mountpoint = "/nix"; };
 };
 };
 };
 };
};

This part will generate something roughly like these commands:

cryptsetup open /dev/vdb2 crypt_disk2
mkfs.btrfs --label NIXOS -d raid1 -m raid1 /dev/mapper/crypt_disk1 /dev/mapper/crypt_disk2
mkdir -p /mnt
mount /dev/mapper/crypt_disk2 /mnt
btrfs subvolume create /mnt/@
btrfs subvolume create /mnt/@home
btrfs subvolume create /mnt/@root
btrfs subvolume create /mnt/@nix
umount /mnt
# and, for mount:
mount -o subvol=@ /dev/mapper/crypt_disk2 /
mkdir /mnt/{home,nix,root,boot}
mount -o subvol=@home /dev/mapper/crypt_disk2 /home
mount -o subvol=@nix /dev/mapper/crypt_disk2 /nix
mount -o subvol=@root /dev/mapper/crypt_disk2 /root

At the end of the operation, Disko will mount btrfs at /mnt. You can verify everything by running:

# list the partitions and file systems
lsblk -f
# list the btrfs subvolumes
sudo btrfs subvolume list /mnt

RAID 1 on btrfs

Notice that I passed the parameters -d raid1 -m raid1 /dev/mapper/crypt_disk1, which means btrfs will be running in RAID 1 for both metadata and data, and in parity with the first disk, which has also already been configured for encryption with LUKS. The reason for defining everything on the second disk is because Disko operates in the order defined, so when disk 1 is being prepared disk 2 still has not been partitioned.

In RAID 1, everything written to one disk is immediately copied (mirrored) to the other disks. In this case, we have a RAID 1 with two disks, controlled directly by the btrfs file system. With Linux, it is very common to do this with mdadm, but in this case mdadm is unnecessary because btrfs has native RAID support.

You can check the RAID status by running:

btrfs device stats /mnt

Subvolumes on btrfs

I defined several btrfs subvolumes. They are useful because they let us manage them independently. For example, we can save everything written to a volume using snapshots, as well as define several settings that on other file systems are available only for partitions, such as quotas, for example. They can also be nested, inheriting the settings and actions performed within the hierarchy.

Subvolumes can also be mounted wherever we want, and that is exactly what we did, for example by mounting /home from the @home volume.

On an already prepared system, this is the list of subvolumes:

$ sudo btrfs subvolume list /
ID 256 gen 1103 top level 5 path @
ID 257 gen 923 top level 5 path @home
ID 258 gen 923 top level 5 path @nix
ID 259 gen 695 top level 5 path @root
ID 260 gen 19 top level 256 path srv
ID 261 gen 19 top level 256 path var/lib/portables
ID 262 gen 19 top level 256 path var/lib/machines
ID 263 gen 1080 top level 256 path tmp
ID 264 gen 1080 top level 256 path var/tmp

The root volume is always 5, which is why the four subvolumes created point to it as the parent subvolume.

It is still possible to create subvolumes with btrfs subvolume create and make snapshots with btrfs subvolume snapshot.

Using Disko as a module

As I mentioned at the start of the post, Disko lets you use it as a module that declares file systems, without needing to declare them in the hardware-configuration.nix file.

To use it, just add disko.nixosModules.disko to the system modules, along with your Disko configuration file, which in this example is disko.nix, the same one that was used on its own to create the file system. It looks like this:

{
 inputs = {
 nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
 disko = {
 url = "github:nix-community/disko/latest";
 inputs.nixpkgs.follows = "nixpkgs";
 };
 };
 outputs =
 { self, nixpkgs, disko, ... }@inputs:
 {
 nixosConfigurations = {
 nixos = nixpkgs.lib.nixosSystem {
 system = "x86_64-linux";
 modules = [
 ./configuration.nix
 ./disko.nix
 disko.nixosModules.disko
 ];
 };
 };
 };
}

Note that my hardware-configuration.nix file does not declare any file systems. See NixOS docs about file systems for how this is normally declared, and, because I used Disko, I did not need to do it.

If I had to do it manually, it would be more or less like this:

{
 fileSystems = {
 "/" = {
 device = "/dev/mapper/crypt_disk1";
 fsType = "btrfs";
 options = [ "subvol=@" ];
 };
 "/home" = {
 device = "/dev/mapper/crypt_disk1";
 fsType = "btrfs";
 options = [ "subvol=@home" ];
 };
 "/nix" = {
 device = "/dev/mapper/crypt_disk1";
 fsType = "btrfs";
 options = [ "subvol=@nix" ];
 };
 "/root" = {
 device = "/dev/mapper/crypt_disk1";
 fsType = "btrfs";
 options = [ "subvol=@root" ];
 };
 "/boot" = {
 device = "/dev/disk/by-label/EFI1";
 fsType = "vfat";
 options = [ "fmask=0022" "dmask=0022" ];
 };
 };
}

And that only after manually partitioning the main disks with LUKS and formatting them with btrfs.

It becomes obvious how much Disko simplifies the whole process: we use its definitions to configure the disks during installation, and later to bring up the operating system itself.

Conclusion

With a disk and file system declaration that is later used to configure it, it is possible to prepare all the storage for a future Linux operating system using just one command line.

Instead of having to keep commands in documentation or build a shell script to prepare everything, we have it all versioned in executable files.

In the next post I will show how to finally install NixOS on the file system that was mounted. In the following ones I will demonstrate how to use TPM to obtain an encryption key that will be used to unlock LUKS without human interaction, directly at boot.

NixOS: Installation Guide with RAID 1, encryption, and TPM unlock (part 1)

giggio@giggio.net (Giovanni Bassi) — Tue, 28 Apr 2026 16:34:00 -0300

It is time to migrate from Ubuntu to NixOS!

For a long time, I have been using Nix on Ubuntu through Home Manager, and I have been automating my dotfiles more and more, steadily removing my custom setup and using Nix instead. Recently, I adopted the new System Manager project, whose goal is to bring system-level configuration to operating systems other than NixOS, where it was previously only available.

After quite a while on that journey, and after already migrating my home servers, it is time to move to NixOS and leave Ubuntu behind.

I want to live on the edge of what is new and configure my Linux exactly the way I want, and NixOS will let me do that. I have also come to really like the way it keeps configuration in versioned file systems that I can control in detail.

This post will show how to meet what I consider the bare minimum for security: I am going to create a NixOS system with an encrypted disk, mirrored with RAID 1, using the most modern file system available right now (btrfs), and use the TPM to decrypt the system without human interaction.

Already know NixOS, TPM, btrfs, and the rest, and just want the code? It is free and available in a repository on my Codeberg. The README explains what is going on, but I will go into more detail here on the blog, explaining the concepts in more depth. This will be a series of posts, where I intend to explain each piece.

The plan is to do something like this:

Creating the VM and the initial partitions (this post)
More information about Disko, LUKS and btrfs
Installing NixOS
Preparing Secure Boot
Using the TPM to decrypt the disks
Mitigating the volume-swapping attack
Mitigating the OS-swapping attack
Review and conclusions

I am sure the plan will fall apart, but it gives you an idea of what I intend to cover.

In this first part, we will prepare the VM and the initial partitions.

Preparing the virtual machine

I am on Ubuntu 24, using Virtual Machine Manager 5.1, installed through NixOS. Adapt this to your own OS setup.

Download the NixOS ISO. I used the graphical ISO, but I imagine the minimal image should work just fine too.

I chose to create the disks ahead of time with qemu-img, because it creates disks that do not consume all the reserved space right away; they grow as needed (sparse files). I noticed that when creating the disks through the VMM UI, it creates them with the full size by default, unless you go through the custom storage option, where there is a checkbox for “Allocate entire volume now”. In any case, I prefer the command line, so I will leave it here for reference. In my case, I will keep the VM files under /mnt/data/vms/vmm, so adapt that to whatever directory you prefer.

cd /mnt/data/vms/vmm
qemu-img create -f qcow2 nixos1-1.qcow2 200G
qemu-img create -f qcow2 nixos1-2.qcow2 200G

Copy the downloaded .iso into that same directory.

Create the virtual machine with those two disks and with the NixOS ISO. Configure the TPM for version 2. Enable the boot menu. Configure the network as NAT. If you want to see my configuration, it is available in nixos.xml.

Delete all Secure Boot keys and disable Secure Boot in the VM, because the installer does not have a signed .efi file and will not boot with Secure Boot enabled.

To do that: when the VM starts, press ESC to enter the boot menu. Then choose “Device Manager” and “Secure Boot Configuration”. Select “Reset Secure Boot Keys” and confirm. That will disable Secure Boot as well. Go back to the main menu and choose “Reset”, which will restart the boot process. It is possible that during this process it will eject the virtual installation CD (.iso); add it back in the VM settings and restart it.

Starting the installation

Choose one of the installation options. I went with Gnome and the latest Kernel, but I imagine it will make little difference; all we need is a shell. When the installer opens, close it and open a terminal.

From that point on, you can continue from that terminal.

Tip: I preferred to connect via SSH, since that makes it easier to copy and paste commands into the terminal. To do that, create a password with passwd. Find the VM IP with ip a and connect to it from the host with ssh nixos@<ip>.

Declarative partitioning with Disko

First, check the current partition status with lsblk -f.

I am using Disko to create the partitions and file systems.

Clone the repository into ~/nixos: https://codeberg.org/giggio/nixos_raid_btrfs_luks_tpm

git clone https://codeberg.org/giggio/nixos_raid_btrfs_luks_tpm.git ~/nixos
cd ~/nixos
git checkout 397fb28 # checkout the commit with message "Updated config"
# create the partitions
sudo nix --experimental-features "nix-command flakes" run github:nix-community/disko/latest -- --mode destroy,format,mount ~/nixos/disko.nix
# check the results
lsblk -f
sudo fdisk -l /dev/vd{a,b}
# or
sudo parted /dev/vda print all

See the file used by Disko: disko.nix. Note that the password is luks, and it comes from the file luks-password.txt.

In the next post, I will explain in more detail what Disko did. For now, I can say that it already created two partitions on each disk: one partition for EFI (ESP) and another for Linux, which will be encrypted using LUKS, and will internally use btrfs, with subvolumes already created. I will explain all of that later.

For now, enjoy figuring out how Disko managed to do all that with just one file. That is the beauty of NixOS: no endless command typing in the terminal, everything is versioned and declarative.

See you in the next post.