Hi, I’ve never used opensuse before but am considering installing tumbleweed because it seems that opensuse takes things like FDE and secure boot seriously/makes that stuff easier to use.
I don’t want to enable secure boot because it feels like a hassle, especially considering I have an nvidia gpu, and I’m not under any risk from an attacker gaining physical access (I’m under the assumption that secure boot only protects against physical-access based attacks, but I’m not entirely sure that that’s true).
I’ve heard that the TPM 2.0 will only release its key if the boot chain is ‘okay’, but exactly what does it measure? Would it prevent me from booting a liveISO/another OS and mounting the encrypted partition there?
If the answer to the above is ‘no’, then what is the point? If the answer is ‘yes’, does that mean I’ll have no way to fix my system (e.g. changing the root password if I’ve forgotten it) by booting from a liveISO and chrooting in?
If I follow the guide above, what does systemd-boot ‘boot’, exactly? A unified kernel image? Does it boot grub again?
Because I’m not using secure boot, which part of my system is vulnerable? The things that reside on the ESP, right?
Sorry if some of what I said is nonsense, I don’t fully understand these things.
You are mistaken. Actually, anyone having physical access can trivially bypass Secure Boot by simply disabling it. There is no single silver bullet, defense in depth still applies.
It measures what is defined in the corresponding policy (or more precisely, it will compare only the measured data that you asked for).
It depends on which data you decided to measure to allow unlocking. But this directly contradicts your previous statement that “I’m not under any risk from an attacker gaining physical access”.
LUKS container can have multiple methods to unlock it.
systemd-boot boots an UEFI binary. It may be UKI, it may be a normal kernel with EFI stub, it may be grub (although the latter probably makes little sense).
Secure Boot measures binaries that are loaded by firmware from ESP. Secure Boot mitigates some of the attacks. Measured boot mitigates other types of attacks.
Sorry for not being more direct; I was wondering if secure boot can help protect against any software based attacks (like malware).
Interesting. in the link in my original post, there’s no mention of specifying policies. Is there a default policy? Or, where do I set it?
For the liveISO part, sure, but say I’m booted into a regular OS (not live), like linux or windows. Theoretically wouldn’t there be a chance of malware gaining access to my encrypted opensuse partition (assuming, under default behaviour, that the TPM will allow that)?
Oh so I can have it so that I can decrypt it with a regular password when I need to?
I get that, but I wanted to know, what opensuse does by default (when I follow the guide linked above).
Ok so I followed the quick setup guide in a VM, but didn’t use btrfs (used ext4 instead) for the root partition, still used LVM. Apparently, the ESP is installed under /boot/efi, and the kernel and initramfs are in /boot, which means /boot is unencrypted. in /boot/efi/loader/entries, these are the contents:
title openSUSE Tumbleweed 20250502
version @6.14.4-1-default
sort-key opensuse-tumbleweed
options root=UUID=22f75838-c309-479e-8542-65502bfbd91b splash=silent quiet security=selinux selinux=1 mitigations=auto systemd.machine_id=dde88ec724364aaa9faaa087984df18b
linux /opensuse-tumbleweed/6.14.4-1-default/linux-33132300c491a998f047656a3b200c7b1edef304
initrd /opensuse-tumbleweed/6.14.4-1-default/initrd-21305a153fa6d8751e88d30d8bb11bdba91417bb
This probably means that systemd-boot is booting an efi-stub kernel.
I followed the rest of the guide, and indeed I’m not asked for my LUKS passphrase anymore. However when I ran sdbootutil enroll --method tpm2, it complained of not detecting a GPT partition table. Don’t know how to make sense of that, since fdisk says the disk is partitioned with gpt.
Secure boot only checks that the boot stack has not been altered. Something that is hard to do in Linux unless the attacker has boot access. If he does then all bets are off, he already owns your machine and has no need to fool around with the boot stack.
Hard to do in linux maybe, but I intend to dual boot windows and my main concern is a programme gaining admin privileges there and then messing with my boot stack.
Of course not. Secure Boot protects the EFI binaries that are directly loaded by firmware. it is by far not the only software based attacks possible.
When using systemd-boot with systemd-pcrlock default PCRs are 0, 1, 2, 3, 4, 5, 7, 9, 12 (I may have missed some). Without systemd-pcrlock default PCRs are 4,7,9.
Without systemd-pcrlock: FDE_SEAL_PCR_LIST in the /etc/sysconfig/fde-tools
or sdbootutil --pcr=1,2,3 ....
With systemd-pcrlock - you cannot; they are really hard coded (as long as you are using sdbootutil).
This will change at least PCR 4, so TPM should refuse to unlock the key.
Yes.
Normal kernel. There is work in progress to support UKI, I have no idea about its state.
It’s for MicroOS but works for tumbleweed too I guess. fde-tools doesn’t seem to exist on tumbleweed, but the relevant section in that page is Full re-enrollment (lost recovery key). In the last command I can just run systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=0+2+3+5+6+7+8+9 $DEV, or whatever pcrs I choose. I don’t know what is going to happen every time I update my system, however.
Could you point me to the documentation where this is mentioned? Also, why isn’t PCR 8 used? Under default settings (no PCR 8), I was able to add rw init=/bin/bash to my kernel command line before booting, and I got access to a root shell, without having to supply any passwords! Then I manually added PCR 8 using the command mentioned above and was no longer able to do that.
Not really. You need to trace systemd-pcrlock calls in sdbootutil and check systemd-pcrlock manual which PCR is used by which invocation. Which is why I mentioned “unless I have missed some”.
Because PCR 8 is used by GRUB and your question was about systemd-boot. Kernel EFI stub measures command line into PCR 9.
Sure you can, but that is not what the sdbootutil does and the result is not equivalent (i.e. the statement “the last two commands are equivalent of” will no more be true).
Using the full re-enrollment guide in the link in my previous comment, the last command to run was this: PIN=<pin> sdbootutil enroll --method=tpm2
And the output was this: /usr/bin/sdbootutil: line 620: snapper: command not found /usr/bin/sdbootutil: line 620: snapper: command not found Disk does not have GPT partition table, refusing. NVIndex policy created 🔐 Please enter current passphrase for disk /dev/vda2: •••••••• New TPM2 token enrolled as key slot 1.
And the output of fdisk /dev/vda is this:
Command (m for help): p
Disk /dev/vda: 35 GiB, 37580963840 bytes, 73400320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: B469F3E8-8C04-427F-ACA7-E837E0080C75
Device Start End Sectors Size Type
/dev/vda1 2048 2099199 2097152 1G EFI System
/dev/vda2 2099200 73400286 71301087 34G Linux LVM
The GPT header is correct. You may consider opening a bug report for this error. It actually may cause failure to unlock the LUKS key - if firmware measures GPT and systemd-pcrlock not. I do not see how this check could fail.
The functionality is working (I think), I don’t get prompted for a passphrase on boot.
However I don’t think PCR 9 is used; under default settings (that is, when I haven’t manually set any PCRs), I can edit the kernel command line and add rw init=/bin/bash
Those are the command line and initrd measurements. The first (PCR 12) is measured by systemd-boot binary, the latter two (PCR 9) - by kernel EFI stub. Try booting with custom kernel parameters and compare the final PCR values and digests in the events.