Hardening with LUKS2, Secure Boot, and TPM2

Firmware and physical security#

TPM, firmware passwords, and Secure Boot can form part of boot protection, but must be considered alongside the device’s threat model and recovery needs:

• Confirm that TPM 2.0 is enabled and accessible from both firmware and user space.
• A firmware administrator password can restrict settings changes, but cannot prevent every attack involving disassembly or hardware.
• Restrict booting from external media as needed, while retaining a way to temporarily restore those settings. Disabling USB boot should not be treated as an absolute requirement.

LUKS2 and TPM unlocking#

LUKS2 is a disk-encryption metadata format; Argon2id is a password-based key derivation function. They are not the same kind of “encryption algorithm.” Actual defaults depend on the cryptsetup version, build configuration, and existing volume.

Initramfs hooks

When using a systemd-based initramfs and systemd-cryptenroll, use the systemd and sd-encrypt approach, for example:

HOOKS=(base systemd autodetect microcode modconf kms keyboard sd-vconsole block sd-encrypt filesystems fsck)

Add any hooks required by your actual storage stack and regenerate the image. The traditional encrypt approach is not obsolete for every use; it simply does not directly provide the systemd TPM unlocking workflow described here.

TPM enrollment example

After creating a LUKS2 volume, backing up its header, and retaining a working recovery passphrase:

sudo systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+7 /dev/EXAMPLE_LUKS_PARTITION

PCR 0 relates to firmware code measurements; PCR 7 relates to Secure Boot state and trusted certificates. Fixed measurement values may change after normal firmware or key updates, so you must test the recovery process. These PCRs do not directly verify all kernel contents; a UKI can use a signed policy involving PCR 11. Unattended unlocking also carries risks from cold-boot, hardware-bus, and runtime attacks. Add a TPM PIN if your needs warrant it.

Secure Boot key management#

Deployment workflow

First confirm that the firmware can enter Setup Mode, back up the keys and recovery information for Windows or other systems, and then choose the scope of trust.

sudo sbctl create-keys
sudo sbctl enroll-keys -m
sudo sbctl sign -s /efi/EFI/Linux/arch-linux.efi
sudo sbctl sign -s /efi/EFI/systemd/systemd-bootx64.efi
sudo sbctl verify

This assumes that the ESP is mounted at /efi and that the file paths have been checked. -m adds Microsoft certificates for better compatibility, while also expanding the scope of trust. Booting may also use EFI/BOOT/BOOTX64.EFI, so check every boot path. After saving the signing paths, verify that appropriate hooks re-sign files after every kernel and bootloader update.

Runtime hardening#

Kernel parameters

Add the following as needed to the actual kernel command-line input used to generate the UKI, such as /etc/kernel/cmdline:

slab_nomerge init_on_alloc=1 init_on_free=1 vsyscall=none

These respectively restrict some slab merging, zero memory, and disable the legacy vsyscall entry point, with trade-offs in performance or compatibility with older software. The /etc/cmdline.d/security.conf path in the original notes is not a universal path read by every UKI tool.

AppArmor

sudo pacman -S apparmor
sudo systemctl enable --now apparmor.service

Also confirm that AppArmor is enabled in the current LSM list, for example by checking:

cat /sys/kernel/security/lsm
sudo aa-status

If you need to set lsm=, retain the modules currently required and their correct order, then rebuild the UKI or boot configuration and verify it. Starting the service does not mean that all applications are confined; you must load and maintain the relevant profiles. For an additional apparmor.d rule collection, review its source, current packaging, and compatibility with application versions. Do not insert unverified package names into an official-repository installation command.

Application sandboxing#

Flatpak uses mechanisms such as Bubblewrap to isolate applications; the actual protection depends on the application’s permissions. Review access granted to the filesystem, devices, session bus, and other resources. Firejail is another option for isolating traditional applications, and also requires profiles suited to the use case. Sandboxing does not replace updates, trusted sources, or least privilege.

The chain of trust#

graph TD
    A[固件设置与 TPM] --> B[Secure Boot 信任证书]
    B --> C[签名 UKI]
    C --> D[TPM 测量与解锁策略]
    D --> E[LUKS2 解锁或恢复口令]
    E --> F[运行期访问控制与沙盒]