Currently weighing whether I want to set up secure boot on my lin/win dual boot UEFI setup… the arch wiki is thorough but it seems pretty darn complicated and easy to screw up. I guess the benefit is malware can’t write anything to the boot partition to be inserted during the next boot?
As an aside: a pox upon windows for only allocating 100 MB for the ESP on install. It isn’t nearly enough space if you’re dual-booting. I tried to resize it but ended up wrecking everything and had to reinstall windows.
One thing the author doesn’t mention in their post (not that they need to document all windows wonkiness, but this burned me before) is that, despite recommending installing dual-booted OSs on separate disks, and mentioning you can have as many EFI partitions as you want (according to the UEFI spec) windows very much does not like this and will probably refuse to boot if it finds more than one EFI partition (https://learn.microsoft.com/en-US/troubleshoot/windows-client/windows-security/cannot-boot-windows-on-primary-hard-disk-uefi). Despite this a lot of linux distributions will happily create a new EFI partition on whatever blank disk they’re being installed onto instead of using an existing EFI partition on a different disk. So I feel like you really have to understand UEFI if you want to get dual-booting running well. This might move lin/win dual-booting beyond the reach of non-technical users.
Currently weighing whether I want to set up secure boot on my lin/win dual boot UEFI setup… the arch wiki is thorough but it seems pretty darn complicated and easy to screw up.
That is why I wrote sbctl which is mentioned at the end of the Arch Wiki entry.
Wow, this is neat, thanks for writing this! I will certainly try it out. The only thing I’m confused by here is proper key storage. It seems like if I just have all the keys sitting around in my root filesystem then it would be easy for some linux malware to find those key files then modify the boot files and also sign them, thus obviating most of the protection granted by secure boot in the first place, right? Should the keys be stored in a TPM or derived from a U2F dongle or something?
Should the keys be stored in a TPM or derived from a U2F dongle or something?
Yes, they should. I just haven’t had the time to sit down and understand enough of the TPM libraries in Go to actually implement this properly. Same with HW tokens.
Storing these files as passord-less files on the root file system isn’t more terrible then what most guides instruct you to do, especially when you have disk encryption.
The successfully protected threat model here is that if someone steals your laptop, they can’t access those key files without a measured-good OS unlocking the FDE keys.
Secure Boot starts getting a lot more useful once you have multiple computers and you can transmit PCR measurements from one to the other.
Like in corporate IT setups or something? This sounds very interesting, do you know of some good reading on the topic? The secure boot threat model, mitigations against various stages of attacks, integrations with TPM and FDE, communicating secure boot state with other computers, etc.
I tried to resize it but ended up wrecking everything and had to reinstall windows.
Very much this. Gparted can’t resize FAT32 volumes under 250MB, but doesn’t tell you that until after it’s trashed it.
Everyone thinks they love UEFI these days. Systemd, of course, has its own special bootloader for loading the kernel from an ESP. Yeah, well, if you love it so much, put your money where your mouth is and make sure that the standard FOSS OS management tools and resize an existing ESP to make it compliant with these needs. No it is not enough to demand a new one, or destroy the current one, or support one per distro.
I have a theory (which I will shortly test) that windows does support there being multiple ESPs on the computer. Gonna make a completely new partition near the end of the drive and copy things over (including the windows boot files, which were missing in the Ubuntu-created one) then make the new ESP first in the boot order. If windows still complains I’ll change the partition type of the original ESP so it can’t even find it. But yes I can guess it would irritate people to have that residual 100 MB sitting uselessly at the start of the drive.
Hmmm. I have heard about setups with multiple ESPs, cerainly. How many and which OSes support it, I don’t know.
I first tangled with UEFI about 5-6 years ago, and while I have gradually learned a little bit more about it, I’ve also learned that it’s quite a mess and different implementations handle it with widely varying degrees of success. It is fairly apparent that it’s not well-tested especially in multi-boot scenarios.
Vendor approaches, from inside the companies concerned, also vary. Inside Red Hat they all thought it was great, the bee’s knees – but RH is big and it’s rich so it has no problem getting its bootloaders signed and verified. And RH considers that it’s basically the only Linux vendor, so as long as something works for RH, it works, the end.
SUSE, OTOH, had images on its internal installation server that required BIOS bootup. When I reported problems, they fixed it, but the fact that it persisted for maybe years says something.
Currently weighing whether I want to set up secure boot on my lin/win dual boot UEFI setup… the arch wiki is thorough but it seems pretty darn complicated and easy to screw up. I guess the benefit is malware can’t write anything to the boot partition to be inserted during the next boot?
As an aside: a pox upon windows for only allocating 100 MB for the ESP on install. It isn’t nearly enough space if you’re dual-booting. I tried to resize it but ended up wrecking everything and had to reinstall windows.
One thing the author doesn’t mention in their post (not that they need to document all windows wonkiness, but this burned me before) is that, despite recommending installing dual-booted OSs on separate disks, and mentioning you can have as many EFI partitions as you want (according to the UEFI spec) windows very much does not like this and will probably refuse to boot if it finds more than one EFI partition (https://learn.microsoft.com/en-US/troubleshoot/windows-client/windows-security/cannot-boot-windows-on-primary-hard-disk-uefi). Despite this a lot of linux distributions will happily create a new EFI partition on whatever blank disk they’re being installed onto instead of using an existing EFI partition on a different disk. So I feel like you really have to understand UEFI if you want to get dual-booting running well. This might move lin/win dual-booting beyond the reach of non-technical users.
Overall, great post.
That is why I wrote
sbctlwhich is mentioned at the end of the Arch Wiki entry.https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot#sbctl
Wow, this is neat, thanks for writing this! I will certainly try it out. The only thing I’m confused by here is proper key storage. It seems like if I just have all the keys sitting around in my root filesystem then it would be easy for some linux malware to find those key files then modify the boot files and also sign them, thus obviating most of the protection granted by secure boot in the first place, right? Should the keys be stored in a TPM or derived from a U2F dongle or something?
Yes, they should. I just haven’t had the time to sit down and understand enough of the TPM libraries in Go to actually implement this properly. Same with HW tokens.
Storing these files as passord-less files on the root file system isn’t more terrible then what most guides instruct you to do, especially when you have disk encryption.
The successfully protected threat model here is that if someone steals your laptop, they can’t access those key files without a measured-good OS unlocking the FDE keys.
Secure Boot starts getting a lot more useful once you have multiple computers and you can transmit PCR measurements from one to the other.
Like in corporate IT setups or something? This sounds very interesting, do you know of some good reading on the topic? The secure boot threat model, mitigations against various stages of attacks, integrations with TPM and FDE, communicating secure boot state with other computers, etc.
Very much this. Gparted can’t resize FAT32 volumes under 250MB, but doesn’t tell you that until after it’s trashed it.
Everyone thinks they love UEFI these days. Systemd, of course, has its own special bootloader for loading the kernel from an ESP. Yeah, well, if you love it so much, put your money where your mouth is and make sure that the standard FOSS OS management tools and resize an existing ESP to make it compliant with these needs. No it is not enough to demand a new one, or destroy the current one, or support one per distro.
I have a theory (which I will shortly test) that windows does support there being multiple ESPs on the computer. Gonna make a completely new partition near the end of the drive and copy things over (including the windows boot files, which were missing in the Ubuntu-created one) then make the new ESP first in the boot order. If windows still complains I’ll change the partition type of the original ESP so it can’t even find it. But yes I can guess it would irritate people to have that residual 100 MB sitting uselessly at the start of the drive.
Hmmm. I have heard about setups with multiple ESPs, cerainly. How many and which OSes support it, I don’t know.
I first tangled with UEFI about 5-6 years ago, and while I have gradually learned a little bit more about it, I’ve also learned that it’s quite a mess and different implementations handle it with widely varying degrees of success. It is fairly apparent that it’s not well-tested especially in multi-boot scenarios.
Vendor approaches, from inside the companies concerned, also vary. Inside Red Hat they all thought it was great, the bee’s knees – but RH is big and it’s rich so it has no problem getting its bootloaders signed and verified. And RH considers that it’s basically the only Linux vendor, so as long as something works for RH, it works, the end.
SUSE, OTOH, had images on its internal installation server that required BIOS bootup. When I reported problems, they fixed it, but the fact that it persisted for maybe years says something.
From 2014. But a good overview and still relevant.