[Bug 1864532] Re: Incorrect nvram template for secboot firmware
Agreed, marked both tasks Won't Fix. ** Changed in: edk2 (Ubuntu Eoan) Status: Confirmed => Won't Fix ** Changed in: libvirt (Ubuntu Bionic) Status: Confirmed => Won't Fix -- 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
[Bug 1864532] Re: Incorrect nvram template for secboot firmware
Another +1 on leave it alone would be that Bionic users could (if for whatever reason they don't want/can to modify the conffile) can also consider getting the cloud archive based new version from focal along that newer ovmf packages and then fully work as in focal. For Eoan it is odd, essentially we now have: - Bionic -> Focal upgraders are fine - Bionic -> Eoan -> Focal upgraders have a change in Eoan and again one in Focal I'M glad that B-F should be smooth now. For B->E IMHO chances are high that those few affected in Eoan have fixed it somehow via local setup and the change would regresses exactly those people, while OTOH everyone else wouldn't mind either way as they are not using OVMF-secboot. I'm tempted to say both could be "won't Fix" as it seems like more pain than gain. What do you think Dann? -- 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
[Bug 1864532] Re: Incorrect nvram template for secboot firmware
One other comment about bionic - this would require a default config file change, so I believe every bionic user who has modified /etc/libvirt/qemu.conf would then get prompted about differences there. In my mind this tips the scales more towards "leave it alone". -- 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
[Bug 1864532] Re: Incorrect nvram template for secboot firmware
This is now addressed in focal, so now let's discuss what we should do for eoan/bionic. = eoan = At a high level the issue here is that cosmic/disco behaved a certain way, eoan's behavior changed, and we've now restored the cosmic/disco behavior in focal. Detail: the behavior change concerns what happens when you define a guest w/ a given fw loader and let libvirt choose a variable template. In cosmic and disco, the "secboot" loader would give you a Secure Boot-capable, but disabled, guest, and the "ms" loader would give you a Secure Boot-enabled guest w/ preloaded keys. In eoan, libvirt handed off this decision to edk2-provided descriptor files, and there the "secboot" loader started behaving like "ms" did, and the "ms" loader behavior was dropped. In focal, we've updated the descriptors to retore the cosmic/disco behavior, as that appears to be what was originally intended, and provides users with the most flexibility. So on one hand we could consider the existing eoan behavior a regression (vs. disco) and SRU a fix back. Or, we could leave eoan alone to avoid regressing anyone there, knowing that a focal upgrade will change that behavior. = bionic = Bionic is technically not impacted by this issue, as it had neither "secboot" nor "ms" ovmf images. However, we do have a class of users who are installing the focal version of ovmf in bionic to get Secure Boot guest support in an LTS. Back in bionic, the loader/variable template config was managed in libvirt config, and our default bionic config knows nothing of the "ms" flavor. We could make the lives of these users easier by (low priority) SRU'ing the "ms" config support back to libvirt in bionic, so this setup works by default. But then we risk a bionic->eoan regression unless we change eoan as well. We could also just decide that bionic users w/ focal ovmf should just modify their local config. -- 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
[Bug 1864532] Re: Incorrect nvram template for secboot firmware
This bug was fixed in the package edk2 - 0~20191122.bd85bf54-2ubuntu2 --- edk2 (0~20191122.bd85bf54-2ubuntu2) focal; urgency=medium * Bring back (and fix) the "ms" option and restore the behavior of the "secboot" option, which had changed when libvirt moved from built-in nvram configs to parsing external firmware descriptors. LP: #1864532. - Reintroduce OVMF_CODE.ms.fd symlink, but now it points to OVMF_CODE.secboot.fd instead of OVMF_CODE.fd, which enforces SMM. - Update firmware descriptor JSON files: + Update the existing secboot descriptor to use an empty variable store. This makes it Secure Boot-capable, but with Secure Boot initially disabled. Note that previously it used a store w/ keys pre-enrolled, without advertising that feature. + Add a new "ms" descriptor which has keys pre-enrolled, has Secure Boot enabled, and advertises the "enrolled-keys" feature. + Provide more details in "description" fields. - README.Debian: Improve the use-case description for each image. -- dann frazier Fri, 03 Apr 2020 07:47:19 -0600 ** Changed in: edk2 (Ubuntu) Status: In Progress => Fix Released -- 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
[Bug 1864532] Re: Incorrect nvram template for secboot firmware
** Changed in: libvirt (Ubuntu) Status: In Progress => Invalid ** Changed in: libvirt (Ubuntu Eoan) Status: Confirmed => Invalid ** Changed in: edk2 (Ubuntu Eoan) Status: New => Confirmed -- 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
[Bug 1864532] Re: Incorrect nvram template for secboot firmware
I've just uploaded the following changes to Debian: https://salsa.debian.org/qemu-team/edk2/-/commit/1698e2a07e5c8a07ff0d772d2a9377ebe577d544 https://salsa.debian.org/qemu-team/edk2/-/commit/a08b306955cfde78b39028ae8bad44922e0c8e1b https://salsa.debian.org/qemu-team/edk2/-/commit/e098d8cf95247fe32e0c2db49dbbe37f6f91b4d9 https://salsa.debian.org/qemu-team/edk2/-/commit/d8e1e32f2c30cd80a25b554fa0e36553a1a2bb1d I plan to backport those to focal to resolve this bug once Beta Freeze is lifted. -- 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
[Bug 1864532] Re: Incorrect nvram template for secboot firmware
** Changed in: edk2 (Ubuntu Bionic) Status: New => Invalid ** Changed in: edk2 (Ubuntu) Status: New => In Progress ** Changed in: edk2 (Ubuntu) Assignee: (unassigned) => dann frazier (dannf) -- 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
[Bug 1864532] Re: Incorrect nvram template for secboot firmware
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
[Bug 1864532] Re: Incorrect nvram template for secboot firmware
** Also affects: edk2 (Ubuntu) Importance: Undecided Status: New -- 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
[Bug 1864532] Re: Incorrect nvram template for secboot firmware
** Changed in: libvirt (Ubuntu Eoan) Status: New => Confirmed ** Changed in: libvirt (Ubuntu Eoan) Importance: Undecided => Low ** Changed in: libvirt (Ubuntu) Status: Confirmed => In Progress ** Changed in: libvirt (Ubuntu) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: libvirt (Ubuntu Bionic) Assignee: (unassigned) => dann frazier (dannf) ** Changed in: libvirt (Ubuntu Eoan) Assignee: (unassigned) => dann frazier (dannf) -- 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/libvirt/+bug/1864532/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1864532] Re: Incorrect nvram template for secboot firmware
** Also affects: libvirt (Ubuntu Eoan) Importance: Undecided Status: New -- 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/libvirt/+bug/1864532/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1864532] Re: Incorrect nvram template for secboot firmware
** Also affects: libvirt (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: libvirt (Ubuntu) Importance: Undecided => Low ** Changed in: libvirt (Ubuntu Bionic) Importance: Undecided => Low ** Changed in: libvirt (Ubuntu Bionic) Status: New => Confirmed -- 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/libvirt/+bug/1864532/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1864532] Re: Incorrect nvram template for secboot firmware
Status changed to 'Confirmed' because the bug affects multiple users. ** Changed in: libvirt (Ubuntu) Status: New => Confirmed -- 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/libvirt/+bug/1864532/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
