Package: grub-efi-amd64 Version: 2.06-13+deb12u1 Severity: important
[Impact] After a BIOS update, the newer UEFI (edk2) firmware enables strict
NX (W^X) by default: PcdDxeNxMemoryProtectionPolicy is now 0x7FD5
(previously the legacy 0x7FD1), enforcing NX on all EFI memory types.
bookworm's grub 2.06 then fails to boot with a page fault; grub 2.12
(trixie) boots successfully. [Root cause] GRUB allocates code memory typed
as GRUB_EFI_LOADER_CODE, non-executable under strict NX. The fault occurs
when GRUB executes/jumps into that memory (during GRUB execution or at the
final jump via grub_relocator). PE section alignment + NX_COMPAT patches
are NOT sufficient; only 2.12's EFI LoadImage()/StartImage() path (already
in trixie) resolves it. [Questions] 1. Would the team consider a
stable-update of the 2.12 boot path to bookworm, or is the recommendation
to move to trixie (2.12+)? 2. Are there known regressions in 2.12/2.14's
native EFI load path (e.g. initrd via LoadFile2 on LUKS2) that affect this
decision? 3. Any timeline we can align against?

Control: tags -1 +wontfix

It's not as simple as just bumping to a new version of GRUB. You also
need the kernel to be built with NX support, plus (if in Secure Boot)
shim as well. We don't have a fully NX-capable boot chain until forky.

What system are you seeing this on? Systems should not be attempting
to enforce NX unless the binaries in the boot chain are tagged as
NX-compatible in the DllCharacteristics field in the PE header.