Comment 4 for bug 2040137

I was just subscribed to this and bug 2040139 today, so catching up..

Disabling the integrated shell only when SecureBoot mode is active is appealing. That seems like the safest mitigation for a stable update. I don't see an existing mechanism for that though.

All of the images provided by edk2 include the secureboot code - whether or not it is enforced during boot is an EFI variable setting. For ovmf, we have a separate image tagged for secureboot that requires SMM - it is documented as the recommend image for secureboot VMs, with the other image type already noted as being less secure:
  https://salsa.debian.org/qemu-team/edk2/-/blob/debian/debian/ovmf.README.Debian

Disabling the built-in shell in all images seems like a big hammer. Newer edk2 packages do provide efi-shell-* packages that contain standalone Shell.efi binaries, but it is sometimes convenient to have the shell built-in for testing things.

One option is to disable the shell in only the secureboot-tagged ovmf image, and introduce secureboot-tagged variants for the other architectures also with no integrated shell. Users would then have the non-secureboot-tagged images if they want a built-in shell. We could remove the SecureBoot code from those images to make the features of built-in Shell and the ability to enable SecureBoot mutually exclusive. But having VM firmware suddenly forget how to do SecureBoot mode after an OS update - even if it is not the firmware image we recommend for SecureBoot mode - seems like a bad experience.