Bug#1139741: grub 2.06 (bookworm) fails to boot with a page fault under strict UEFI NX (PcdDxeNxMemoryProtectionPolicy=0x7FD5)

[Steve McIntyre]

Control: tags -1 +wontfix

On Fri, Jun 12, 2026 at 06:19:11PM +0800, Bing Liu wrote:
>
>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?

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.

-- 
Steve McIntyre, Cambridge, UK.                                steve at einval.com
  Getting a SCSI chain working is perfectly simple if you remember that there
  must be exactly three terminations: one on one end of the cable, one on the
  far end, and the goat, terminated over the SCSI chain with a silver-handled
  knife whilst burning *black* candles. --- Anthony DeBoer