Installation medium has invalid secure boot signature

When trying to boot with the NixOS 24.11 installation medium, the BIOS of my laptop tells me that there was an “invalid signature detected” and I should “check Secure Boot Policy in Setup”. Why is this? Doesn’t the NixOS installation medium use some standard secure boot solution for Linux that can be used with the default Microsoft keys, like Shim? And what about the installed system? Will I run into the same problem with it?

Secure boot is still fairly WIP. I forget what exactly the difficulties are, but full reproducibility is hard to guarantee when you must guard a secret. NixOS will just let you 1:1 rebuild the kernel and initrd, fitting some kind of signing process in there while making it actually useful would be hard.

NixOS also doesn’t use dracut (again, reproducibility, dracut likes to do stuff on deployment) which means the whole boot solution is built by just the NixOS community, and therefore this all takes more effort than on other distros, with fewer developers to put in the work.

You can use lanzaboote for local signatures in the actually installed system though.

1 Like

Does this mean that neither the installation system nor the installed system work with secure boot?

Note that I don’t insist on using secure boot, but I don’t want to switch off secure boot in the BIOS if the problems with booting I described are actually because of some real error or security problem. Therefore, my question is: Is it necessary to switch off secure boot for starting the installation system or the installed system, or should it be possible to have secure boot switched on and my problems are because of some bug?

To my knowledge, yes. I’ve double checked the sources for the installer ISO to be safe, and there’s no shim loader in there.

The wiki is also explicit about it:

The EFI bootloader of the installation media is not signed and is not using a signed shim to boot. This means that Secure Boot will need to be disabled to boot.

But the wiki is often outdated, so I take it with a grain of salt.

We should probably add this to the manual for the avoidance of doubt. If you don’t want to take my word for it, you could double check by mounting the USB’s boot partition and looking for the shim by hand, but I’m quite certain.

And to be clear, lanzaboote can be used if you want secure boot after installation.

1 Like

So without lanzaboote you have to keep secure boot switched off after installation?

That’s correct. It’s not part of nixpkgs yet.

1 Like

The biggest issue is that you can’t just borrow another distro’s shim and use it. That shim includes specifically trusted keys and of course NixOS shouldn’t have another distro’s signing keys. So getting microsoft approval so that it works out of the box on systems with secure boot enabled by default is the long term goal. But there’s a lot of barriers to that. We have lanzaboote to do this all self-signed, but it’s not perfect. It could be used with an MS-signed shim so that it can be signed by the NixOS org. But there’s problems, for instance allowing users to customize their kernel params means using MOK addons, which lanzaboote doesn’t support yet. Then there’s the issue of verifying stage 2 without limiting users’ ability to customize their system. It’s all just a bunch of stuff that needs more work, so we’re a ways away from MS signing a NixOS-owned shim.

1 Like

I thought that Microsoft just has to sign Shim, not Shim plus some keys.

The way shim works is that a distro hardcodes their own public key into their distribution of shim, which shim uses to verify the next boot phase. Then they have to apply to MS to have their build of shim (again, with their public key hardcoded in it) signed by MS, and MS checks over their boot chain to make sure it meets the qualifications. MS reserves the right to revoke this distribution’s boot chain, including the shim, with an update to the UEFI secure boot database variable, which only they have the ability to do on these MS-secure-boot-enabled devices.

The other thing that shim does is implement Machine Owner Keys (MOKs). The way you get shim to boot something custom despite having a hardcoded key and being MS-signed is by using MOKManager to add your public key to a secure EFI variable that shim manages. Shim takes some measures to make sure the person taking this action is actually physically present at the machine, and not some remote party who bootkitted the OS. From there shim will accept things signed by your MOK, and provides a protocol that later boot phases can use to allow it too (up until UEFI Boot Services are exited).

1 Like