Note that I am still doing final comprehensive tests, but I have done initial validation of the resulting images.

I would rather this be included by default with OVMFFull and not a standalone package. I see OVMFFull as batteries included and should definitely have secure boot support. What do you think @RaitoBezarius ?

The QEMU update looks good, but why is it part of this PR?

@alyssais The OVMFMSVars derivation uses qemu to populate the nvram image, and it hangs on 8.2.0 (but not prior versions of qemu nor on 8.2.1).

@adamcstephens I can move that if that's what the maintainers want. To be clear, OVMFFull does fully support secure boot, it just doesn't have the MS keys so you have to do your own key management.

@alyssais The OVMFMSVars derivation uses qemu to populate the nvram image, and it hangs on 8.2.0 (but not prior versions of qemu nor on 8.2.1).

Would make more sense in a separate PR IMO. There's no point holding up a simple QEMU update for the other stuff here.

Looks like #284925 is the qemu side. If that's going to move forward this time, we may want to base this PR off of it since both add the OVMF build flag. I do prefer systemManagementModeSupport as it better matches the naming of the other arguments.

Either way, yes I think this should be handled in the OVMF package directly. It can include ms.nix if that's easier, but I would prefer to not expose another top-level package.

@alyssais Rebased on #285002

@adamcstephens That other PR doesn't bump qemu versions and is mostly about NixOS support. I also think the logic of requiring SMM when secureBoot is being used is more appropriate.

Thanks a lot.

@adamcstephens OK, inlined into the main derivation.

@adamcstephens Updated flag name for SMM.

Testing confirmed: Default vars file does not have secure boot enabled, new vars file does and requires MS-signed boot.

There is still an issue with SMM when secureboot is enabled.
For some reason enabling SMM still makes it impossible to update EFI variables. The qemu 8.2.1 bump doesn't fix that.

I don't know if we should build OVMF with a builtin set of keys. I'd much rather go with an approach like: baloo@0174b95

Get the test driver (or whatever wrapper) to write the efivars storage directly, and embed a set of keys from the user if needed.

@baloo It can't be right that it's impossible to update EFI vars, since the script that generates the variables template works by launching a qemu VM and running a firmware program to update them, and my Windows VM is able to update the boot order. Where are you seeing this issue?

I don't know if we should build OVMF with a builtin set of keys.

With this change, you still get the empty variable store if you want it. You have to opt in to the default keys by using OVMF_VARS.ms.fd. Note that approximately every real world x86 secure boot implementation has these keys and most of the secure boot signing infrastructure revolves around them in some shape or form.

@baloo It can't be right that it's impossible to update EFI vars, since the script that generates the variables template works by launching a qemu VM and running a firmware program to update them, and my Windows VM is able to update the boot order. Where are you seeing this issue?

The moment secureboot is turned on, the SMM handler for qemu seems to make it impossible to update variables.
That occurs with lanzaboote test suite (when pulling changes from #284925) :

nix build 'github:baloo/lanzaboote/baloo/qemu-smm#checks.x86_64-linux.basic' -j 12 -L

@baloo You need to pass -global driver=cfi.pflash01,property=secure,value=on to qemu.

You probably should rebase on master and test this again.

Fixed

@AshleyYakeley are you able or have you tested this to ensure it meets your needs?

Yes, this works for me. I used "${packages.OVMFFull.fd}/FV/OVMF_CODE.ms.fd" and "${packages.OVMFFull.fd}/FV/OVMF_VARS.ms.fd" from shlevy's branch, and I could get past the hardware check of the Windows 11 installer.

This PR would close #288184.

Is this ready to merge?

I have no known issues on my end.

Well, if no-one has any objections...

@adamcstephens still wants to test #284874 (comment)

Thanks for your contribution. Sorry for the delay.

Since there are no objections, I'm going to merge it.

Thanks!

FYI the merge blocked channels. See PR #291544

This breaks a lot of things. Most notably it makes secure boot with aarch64 impossible because of weird defaults, an assertion and a qemu machine type that is x86 only. I'm biased to revert it.

@nikstur Can you explain the issue/show a repro? The only x86-only code here is the usage of q35 when system management mode is enabled, but SMM is an x86 feature…

@nikstur Can you test https://github.com/shlevy/nixpkgs/tree/mx-secureboot-cleanups

This breaks a lot of things.

If this is that critical, I'm happy to revert, but it would be helpful to know what and why. It's possible we can just fix and move forward instead of rolling back completely.

Maintainer of systemd-boot here. I'm surprised to find out that this PR adds a new test the the systemd-boot tests, but I was never pinged for review, and this test doesn't specify maintainers. I am not planing to maintain tests that are getting merged without my approval, so I will revert at least this part of the PR.

libvirtd.nix adds nvram options for the default .fd files (I suppose this makes them selectable in virt-manager), and with its libvirtd-config service symlinks them into a fixed path under /var/lib/libvirt so that they could be referenced by that path from xmls and remain valid between system upgrades.

Nothing is offered for these .ms. secure-boot files, even if you set your QEMU's OVMF to use OVMFFull.fd as the package.

Should we add some way, controlled from editing the virtualisation.libvirtd.qemu configuration, to ship the secure boot versions in a way usable from virt-manager nicely?