After digging into this today, I'm thinking that I may not be using OVMF_CODE.secboot.fd as intended. While I initially assumed that specifying OVMF_CODE.secboot.fd would give you a system with Secure Boot *active* - it actually just gives you a system where Secure Boot *could* be activated, if the end user enrolls various keys and turns on SB manually in UEFI.
I think the use case I was after is what the "ms" variant, which should provide "hands-free" Secure Boot. But I think that has been broken for some time. For one, we never added the necessarily /usr/share/firmware/qemu JSON blob to support it. For another, until recently, OVMF_CODE.ms.fd was just a symlink to OVMF_CODE.fd. While OVMF_CODE.fd supports Secure Boot functionality, it isn't actually secure because it does not enforce SMM support from QEMU. In fact, we removed OVMF_CODE.ms.fd recently because its purpose was not clear (bug 1864535). I think we should look into restoring the OVMF_CODE.ms.fd link in ovmf, pointed at OVMF_CODE.secboot.fd. We should also add a new /usr/share/qemu/firmware .json file, and update the docs in the ovmf package to clarify the situation. If that does the trick, there may not be any reason to make code changes to libvirt at all, except possibly to backport d/p/ubuntu/ovmf_paths.patch to bionic. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1864532 Title: Incorrect nvram template for secboot firmware To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/edk2/+bug/1864532/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
