How to enable SecureBoot

I read that with 23.05 it is possible to enable SecureBoot. I know that there is a boot.json, where do I enable this? I just use plain nixos, as described in the installation on the nixos manual

As far as I understand, that change is only one step towards supporting secure boot in NixOS. For now you have to use this, which I guess will be upstreamed into nixpkgs at some point.

There is no date planned? It would be nice to just have a single option I hvae to set to enable it

The readme on github says that the optimistic plan is to have it in nixpkgs as a beta by 23.11.

Correct: I have been starting upstreaming stuff in nixpkgs. We do not really have any blockers except me not having enough time and focusing on other things.

We could ship a feature preview in unstable soon, I imagine.

5 Likes

Thank you @RaitoBezarius , It’ll be great to test it in Unstable.

Are you talking about DeterminateSystems/bootspec-secureboot? Or about Lanzaboote?

I am a Lanzaboote developer, bootspec-secureboot is one of the early attempts done by DeterminateSystems, it can be used if you know exactly what you are doing.

1 Like

Upstreaming PR is there: https://github.com/NixOS/nixpkgs/pull/231951 but there are some non-trivial challenges left to solve with respect to cross compiling to UEFI successfully.

1 Like

Thank you for your work @RaitoBezarius , much appreciated.

I have experience importing custom certificate into UEFI and then manually signing /lib/modules/xxx/build/scripts/sign-file sha512 cert.priv ZFS DKMS modules on Debian. So I’m happy to help you to test Lanzaboote.

Is there a reason you require systemd-boot? I prefer Grub so I can have similar config across all my UEFI / BIOS systems…

You’re welcome!

ZFS + SecureBoot on NixOS via lanzaboote works already out of the box because we don’t enable module signing in the kernel because it breaks reproducibility of the kernel. This is an open problem to achieve this in a smart way (i.e. reuse the SecureBoot PKI or something) and we won’t tackle this soon because we want to streamline the experience without module signing first.

Module signing will happens when we may offer “default” NixOS images with SecureBoot.

I will put it in a polite way but GRUB is a very problematic bootloader which I advise you strongly to not use it anymore. Anyone is free to support GRUB usecases in nixpkgs and NixOS and lanzaboote but I have yet to see people show up for the work except from people who also wants to avoid GRUB, like me.

systemd-boot is the blessed bootloader for now, U-Boot will have a backend support too and finally one of our community member is working on a potential GRUB replacement in Rust, but this is probably going to take a while before it can be used.

I may release in the future a mechanism to have legacy systems work like UEFI systems via an UEFI compatibility layer using U-Boot, but this is a very experimental project at the time.

3 Likes

So many interesting projects / things happening.

What is the best way to monitor your progress and other boot projects? Do you Tweet / Blog / anything else about it?

I wonder if it would be possible to sign them on the fly (in memory) before modprobe using a user generated cert file. That means modules can be stored in cache.nixos.org without the signature / any modification and NixOS users would have only two non-reproducible sets of files: cert and initrd.

You can follow me on GitHub, I may post updates here: Raito Bezarius (@raito@nixos.paris) - NixOS Paris server when I feel like it and I do some blog posts on things I like in my website, but no guarantees :slight_smile:.

I am not sure I understand the usefulness of that proposal, if you sign before modprobe using a user generated cert file, what is the value of that signature?

1 Like

Yeah, you’re right. This would satisfy Secure Boot but wouldn’t increase the boot chain on trust.

Did you evaluate rEFInd?

It is a boot manager, that support varios different bootloader, including systemd-boot.

I say this since you mention ‘backend support’ for U-Boot and a self written Rust loader.

An unified frontend for the different solutions could be lovely.

Particulary since its really pretty and more easy to navigate through by newbies.

I know, slightly offtopic.
And still, it could effect the decision making.

Yes, I evaluated it, but rEFInd support can be added by anyone who care about it. I don’t think it’s useful in the same way as the two others (embedded/SBC systems and server/workstation systems).

1 Like