As far as I know, Tumbleweed is still using the Yast installer (rather than Agama), and grub2-efi is still an install time option for booting.
I’m using grub2-efi, and it is passing along the encryption password to the kernel.
I don’t think that’s right. I have Tumbleweed using “sdboot” in a VM, and both the kernel and initrd are in the EFI partition.
Just to clarify: I was being asked for two passwords overall, and not during boot.
The two passwords I was being asked for:
I interpreted the following phrase in the documentation to mean that this was unusual, whereas in fact this is standard behaviour:
A disadvantage of encrypting the root partition is that you’ll have to provide the decryption passphrase twice - once in the bootloader (Grub), and then again when your system actually boots.
This is because, to me, it was not clear what timepoint in the start-up process “your system actually boots” was referring to - immediately after the bootloader, or all the way at the user login screen.
If the initrd is in the efi partition, I take it that my current set-up is not secure?
Would you happen to know what the ideal set-up is? As in, how do I sort this out?
When you are using grub2-efi, you will be asked for the encryption password before you get to bootloader screen, and again when your system is booting to decrypt the root and home partitions (but there are ways to get around the second password by creating a key file). This password is separate from your login password, unless you chose it to be the same.
systemd-boot (unlike grub does not have a decryption module) lives in /boot/efi with the kernel and initrd which is unencrypted. So when you boot you get to the bootloader screen without the encryption password. You just enter the password once to decrypt the root and home partitions. but you still have to use your login password.
Woah, that’s a big change from grub2. 
Thanks for that! 
Not sure how I feel with the initrd and kernel sitting there unencrypted. 
So that’s why there’s a TPM integration to measure if these things have been tampered with? 
@TooManyCucumbers Please disregard my previous post. I’m just another person left clueless with the passage of time! 
Technically, your setup is secure. 
Your root and swap partitions are encrypted and are only unlocked when you give your LUKS password to sdboot. You should not follow the wiki and put your keyfile in the unencrypted intird! 
That depends.
If you have put the LUKS key in the “initrd”, then that is not secure.
TPM is supposed to monitor booting, but I’m unsure of the details of that.
Personally, I have not set up anything in TPM, and I provide the LUKS key manually on boot. I see that as sufficiently secure for my needs. You will have to decide what is sufficient for your needs.
I don’t think so. I was using Grub2 before I switched to systemd boot. There used to be an issue with grub not passing on the key on to decrypt root in the past but that was resolved from my understanding. Grub only prompted me once for the password before the bootloader screen. I was getting prompted for other endcrypted devices until I created a key file for them.
Warning: Newest GRUB version can unlock automatically the root partition! See Bug #1206710 for additional info. Besides, the auto-unlocking mechanism can be extended to the swap partition by specify the same key file path in /etc/crypttab.
https://bugzilla.opensuse.org/show_bug.cgi?id=1206710
Michael Chang 2023-01-10 02:23:39 UTC - Unlike the SDB article where that key files needs to be in the root partition and attached onto initrd, the feature requires no additional persistent storage other than your brain cells. The grub can be instructed by /etc/crypttab to handover the password users have just typed to systemd-cryptsetup on the fly to the initramfs before root file system is mounted and then gets destroyed as linux kernel relinquished the initrd memory.
My setup is
├─nvme1n1p2 259:2 0 476.5G 0 part
│ └─cr_nvme-SAMSUNG_MZVLB512HBJQ-000H1_S4GLNX2N505445-part2 254:3 0 476.4G 0 crypt
│ ├─system-root 254:4 0 70G 0 lvm /var
│ │ /tmp
│ │ /root
│ │ /usr/local
│ │ /srv
│ │ /opt
│ │ /boot/grub2/x86_64-efi
│ │ /boot/grub2/i386-pc
│ │ /.snapshots
│ │ /
│ ├─system-swap 254:5 0 2G 0 lvm [SWAP]
│ └─system-home 254:6 0 404.4G 0 lvm /home
Yours is
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
nvme0n1 259:0 0 953.9G 0 disk
├─nvme0n1p1 259:1 0 1G 0 part /boot/efi
└─nvme0n1p2 259:2 0 952.9G 0 part
└─cr_nvme-eui.01000000000000008ce38e040126dddc-part2 254:0 0 952.9G 0 crypt
├─system-root 254:1 0 937.5G 0 lvm /var
│ /usr/local
│ /srv
│ /root
│ /home
│ /opt
│ /.snapshots
│ /
└─system-swap 254:2 0 15.4G 0 lvm [SWAP]
So it looks like you do not have /boot in an encrypted root partition.
Warning: Do this only if you have an encrypted root partition that includes /boot (no separate /boot partition)! The key added to the initrd can be used to decrypt your root partition, therefore having the initrd on an unencrypted /boot partition would defeat encrypting your root partition.
And I may be wrong but there shouldn’t be any reason for you to have the key file because you are not being prompted twice to decrypt root but it is a crypt volume. You are only being prompted to enter the passphrase once to unlock it so everything should be fine if you delete /.nvme0n1p2.key from the disk entirely, consign it to the memory bin and remove it from initramfs.
@TooManyCucumbers Please disregard my previous post. I’m just another person left clueless with the passage of time!
I guess the real treasure was all the learning we did along the way. 
Thank you for the help again!
Now I just need to figure out how to re-enroll the cryptvolume with TPM2… After I unenrolled for troubleshooting, then re-enrolled, my machine had trouble with the PCR checks on boot, and I ended up having to bypass those by editing the bootloader parameters and unenrolling after startup again…
Oh well, one lesson at a time!
Ah, thank you, that helps clear things up somewhat! For some reason was struggling to figure out how everything was structured behind the scenes from the documentation alone (but I’m quite new, so maybe I wasn’t looking in the right places).
Thank you again! I really appreciate the explainer!
Yep, re /boot: as I mentioned in the footnote of the original post, I wasn’t sure if that part of the SDB page was relevant to me, as I couldn’t actually figure out where the initrd was stored for my set-up: in my /boot folder (within the encrypted volume), or in /boot/efi (mounted/sits outside this in its own unencrypted partition). But it was precisely this uncertainty that made me worried enough to post the question in the first place.
Will be keeping the solution as is, since undoing the key file enrolment process is essentially what fixed the issue.
Yea, it’s not exactly self-explanatory.
Unenrolling the key file from the device for the sake of completeness should prevent it being used even if it is still in initrd, I think.
sudo cryptsetup luksRemoveKey /dev/nvme0n1p2 /.nvme0n1p2.key
ls -l /boot might give something somewhat similar to this.
lrwxrwxrwx. 1 root root 23 May 22 01:23 vmlinuz -> vmlinuz-7.0.9-1-default
lrwxrwxrwx. 1 root root 22 May 22 01:23 initrd -> initrd-7.0.9-1-default
This is where initrd lives I guess and might be the same on your system. If so it would probably be within the encrypted volume on your system as you say and I was wrong telling you otherwise, apologies.
/boot/initrd is a broken link on my system because I moved to systemd-boot(some regret) and so there is no longer any use for it.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.