1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.RC

  • Bug#1103906: qemu-efi-aarch64: Secure Boot regression for some arm64 VM

    From Mathias Gibbens@21:1/5 to dann frazier on Sat Apr 26 01:40:01 2025
    On Wed, 2025-04-23 at 22:01 -0600, dann frazier wrote:
    Please see NEWS.Debian:
    https://salsa.debian.org/qemu-team/edk2/-/blob/08d4411d458eefc4df5d48acce4f995d4ae6087d/debian/qemu-efi-aarch64.NEWS

    Thanks for pointing that out; since the NEWS entry is specific to
    arm64 it hadn't popped up as something important to me when that update
    came through on my various amd64 systems.

    Would it be possible to roll this back for the trixie release, then
    re-enable it early in forky development? The set of affected VM images
    is unknown, and since they're older most likely it wouldn't be feasible
    to backport whatever changes are needed to fix their bootloaders. The alternative is trying to update all the software launching VMs to
    automagically detect and then modify the qemu arguments. That seems
    like a fragile approach and unlikely to complete before the hard freeze
    starts.

    If this change remains, I expect a lot of people will be caught by
    surprise when they update to trixie, which will result in a long tail
    of bugs and the need for individuals to manually apply configuration
    changes to fix their VMs. Reverting the change and applying it early in
    forky would give a full development cycle to absorb the change, and
    then by release bookworm VMs would be oldoldstable.

    For some broader context, I did a quick search to see how other distros/packagers are handling this. Ubuntu hasn't yet pulled in the
    updated src:edk2 with the removal. As best as I can tell, Fedora
    appears to have that workaround still enabled[0]. Lastly, the Zabbly-
    provided packaging of Incus also carries that patch[1].

    Mathias

    [0] -- https://src.fedoraproject.org/rpms/edk2/blob/rawhide/f/edk2-build.fedora#_58
    [1] -- https://github.com/zabbly/incus/blob/daily/patches/edk2-0005-Revert-ArmVirtPkg-make-EFI_LOADER_DATA-non-executabl.patch

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEE1Bp60H32xfynSJ8cKe7i1uz0QvkFAmgMGmAACgkQKe7i1uz0 QvmNtQ//SYzxmjk5FfHZ85xiH+ZCzM3MWChQ/P3nXjc3nX3OhmelSK/Vq0zjJ8wA ASYntu9v/6SeobgNvq3nTSGSIrw8kq7U/LkQVPwOWhpUKezqN1dh0NTDLHHx04RH hvbRpiVQOkU2ZnZdCzC4B6iTmFPRBkGmWeXdJar6cMP3qifunOIDq9xjSNTV58bD dcoS1QSEBfLfWCA6eYrwsBj1bDPCZ5alXYQfmQkrZcmPXEnYXoBAuxZIZyjk9lGn Tq4VE/M7eCFKbV7UuHV8SeHaRZCr9hVEMz5sf8XMT/pC8Bz6Q9E9UKfaoCnuuyYd xbE7IprsWT8qpvsuK9juyQ0f5Eurac2dVFDZ7YLJCcq/pPSGtiJv6o5p2ovF8ZiP LMPyNK80o4zbp5TtRED3HRTsohvxg+i5sdXDjp0hp3Ng1f4BY02xrdDVmxxLVhzL w7r8IsPHrECOe05AcL8lHhSe2NkHTzFQp9tZmWg2MK+C3BLGquB0bakyplcuX9dG 3YezUFbyMb9jlQy1HP6Om+7Snrc3JtW9zQrOmvdgASFJtTmnI6skVL8i6OJ1sdrD /S/VqlkkP26t4dboGCTVB1g8Jw8d+lbZevIB/D1uVZPHQAD7WUncf1iDMQo5ruSf s/BJH1PLQcVlQAlupVpqUrltlSzdLMELdqr9d7P+W0Bjx0of7qY=
    =Xydf
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From dann frazier@21:1/5 to Mathias Gibbens on Mon May 12 06:40:01 2025
    Apologies for my delay in responding.

    On Fri, Apr 25, 2025 at 11:27:28PM +0000, Mathias Gibbens wrote:
    Thanks for pointing that out; since the NEWS entry is specific to
    arm64 it hadn't popped up as something important to me when that update
    came through on my various amd64 systems.

    I linked to that file because this bug is about arm64, but the
    equivalent content also exists for ovmf/x86:

    https://salsa.debian.org/qemu-team/edk2/-/blob/08d4411d458eefc4df5d48acce4f995d4ae6087d/debian/ovmf.NEWS#L1

    Would it be possible to roll this back for the trixie release, then re-enable it early in forky development? The set of affected VM images
    is unknown, and since they're older most likely it wouldn't be feasible
    to backport whatever changes are needed to fix their bootloaders. The alternative is trying to update all the software launching VMs to automagically detect and then modify the qemu arguments. That seems
    like a fragile approach and unlikely to complete before the hard freeze starts.

    I don't love that this would leave Debian as a less-secure host
    operating system by-default for a full release cycle. And I don't love
    that we've already delayed this a full release cycle for arm64:
    https://salsa.debian.org/qemu-team/edk2/-/commit/a0be41b75c989351b55211c7521ef1309e4e51fe

    But I do understand that switching the default this late in the release
    doesn't provide reasonable time for vm managers to adjust, so I agree that waiting to switch the default util forky opens for devel is the
    practical thing to do.

    I do want to make it easy and upgrade-safe for trixie users to opt-in
    to NX-safe bootloaders though. So, unless someone has better ideas,
    I'll prepare an upload that:
    - uninstalls the MemAttrProtocol for all existing images
    - adds new "strict" variants that retain the MemAttrProtocol
    - updates README.Debian and NEWS to recommend the strict variants
    for compatible operating systems (it'd be nice to have a wiki
    that documents know compatible/incompatible versions)

    And, once trixie has shipped, I'll restore MemAttrProtocol for the
    secboot images, with the strict image files becoming compat symlinks.

    -dann

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)