Boot menu asks for disk encryption password even if I'm going to boot into Windows

English Install/Boot/Login
1

Hello I have two SSDs in my laptop. One of them has Windows 11.

I selected disk encryption while installing OpenSUSE Slowroll onto the other SSD.

Something that annoys me is that the OpenSUSE boot menu asks for the encryption password even if I want to boot to Windows (on my other SSD) using the Windows Bootloader.

It would be nice to be able to wait until after selecting OpenSUSE to ask for the encryption password.

Is there a way to delay asking for the disk encryption password until after the operating system is selected?

As far as I know the EFI System Partition is unencrypted so I don’t see why the password is needed just to show the boot menu.

2

grub2 configuration (where you can select Windows) is inside of /boot/grub2 which is on the encrypted Linux root filesystem.

Are you using btrfs and do you plan/need to use snapshot rollback?

2 Likes
3

Your BIOS should be providing a boot menu, which would not require the password. On my system, I can access that by hitting F12 during boot (while the manufacturer logo is showing).

1 Like
4

Your BIOS should be providing a boot menu, which would not require the password. On my system, I can access that by hitting F12 during boot (while the manufacturer logo is showing).

Yes, I know about this. Fedora has an unencrypted boot menu and when I was using Fedora it was faster to just use the grub2 boot menu to boot Windows than pressing F12.

Are you using btrfs and do you plan/need to use snapshot rollback?

I used the default options in “guided setup” which I believe is BTRFS for the operating system files and XFS for the home directory.

I would like to keep snapshot rollback.

5

Do you have TPM 2.0? If yes, you can configure grub2 to automatically unlock root volume using key secured by TPM.

6

Is this protected by a PIN? If not, wouldn’t this mean the device can be decrypted by anyone with physical access to the machine or just plain denial of service by tampering the PCR values that TPM checks? :thinking:

1 Like
7

Probably. It’s a Dell XPS 15 9530 which I bought brand new from Dell.

Won’t there still be a significant delay waiting for the decryption to occur?

8

Try and tell us.

9

Explain how one can do it.

10

Sorry, I meant tampering the components the PCR values are validated against.
For example, the boot loader, shim, UEFI, etc.

11

So it will not be unlocked automatically if boot components change. Which is exactly how it is designed to work. What is your point?

12

Does it fallback to password, I was thinking along the lines of change the boot order or reflash the UEFI and then the device is basically bricked.
But I suppose there’s a password fallback. :man_facepalming:
Though if there’s no PIN protection for the TPM, then anyone can get access to the data. :warning:

13

Yes, this is also my concern.

I prefer typing the password because I don’t trust TPM.

I would just prefer if the password prompt was after deciding I don’t want Windows, like with Fedora grub2.

14

You can certainly make /boot its own partition (without encryption) like other distros, but this would break snapper rollback. :warning:

15

Fedora defaults to using Boot Loader Specification so menu entries are is on ESP. It is possible that SUSE will support it as well. Currently you can switch to systemd-boot with sdbooutil for snapshots support. Both are still experimental in openSUSE, although YaST just merged support for systemd-boot.

1 Like
16

I wonder how access to operating system was protected in the past before full disk encryption. Your user accounts do not have passwords?

17

User passwords are a weak access barrier and not meant to protect the data, hence the need for FDE, but it defeats the whole purpose of having FDE when it auto-unlocks is all I’m saying :face_exhaling:

This should solve OP’s problem but there appears to be a lot of pending features though, some like lack of kdump makes it a no-go for me atm.

Docs:
https://en.opensuse.org/Systemd-boot

18

Whatever the solution is, I like the way Fedora lets me use the boot menu before it asks for a password.

This is OT, but can anyone tell me how to make the font larger on the password prompt? I have a 3.5k x 2160p monitor and the prompt asking for the password comes up very small. Maybe that’s a good thing Is this part of the grub2 menu? If so, can I make the font larger by editing the “grub” file.

19

Sorry, that’s no a answer for the main questions

wouldn’t this mean the device can be decrypted by anyone with physical access to the machine

I ask myself exactly the same question. Even so, for a non-beginner attacker, physical access is open door for all kinds of other corruptions, disk encryption or not, imagination is the only limit :slight_smile:
Just for the example you give “reflash the UEFI” : even password protection on the BIOS can be bypassed by manually reboot the BIOS on the motherboard.

Of course, this is not to say that we should do nothing - quite the contrary. Rather, it’s about evaluating our threat model. To me, even for a lambda user (personal device with no sensitive activity), if laptop, the disk must be encrypted, as it’s much more exposed to physical access (lack of attention in uncontrolled places, theft, …).
And … @arvidjaar

I wonder how access to operating system was protected in the past before full disk encryption.

… Precisely, I think we are talking more about democratization of encryption than its availability. In past, there was less device, no laptop, other level of threats on data, … today it’s a “basic” for anyone with the slightest concern for his or her privacy.