Fedora 44 shim-x64-16.1-5 RPM ships without IMAGE_DLLCHARACTERISTICS_NX_COMPAT — intentional?

[NexusOne23]

Summary

Fedora 44's shim-x64-16.1-5 RPM ships all four shim-suite binaries (shim.efi, shimx64.efi, mmx64.efi, fbx64.efi) with OptionalHeader.DllCharacteristics = 0x0000 — IMAGE_DLLCHARACTERISTICS_NX_COMPAT not set. Upstream shim has enabled NX_COMPAT by default since 15.8 (PR #530 by @vathpela), and Fedora 16.1-5 is newer (built 2025-11-04) — yet none of its binaries carry the flag. Sister fwupd uefi_mok plugin (PR fwupd/fwupd#8554, merged March 2025) reports org.fwupd.hsi.Uefi.MemoryProtection = not-enabled for every Fedora 44 user as a result.

Filing here because @vathpela / @pjones maintain both upstream and the Fedora package — you can route this fastest to wherever it belongs (upstream change, Fedora spec change, or "intentional, won't fix" with rationale).

Reproducer (Fedora 44, any hardware)

for p in /usr/lib/efi/shim/16.1-5/EFI/fedora/shim.efi \
         /usr/lib/efi/shim/16.1-5/EFI/fedora/shimx64.efi \
         /usr/lib/efi/shim/16.1-5/EFI/fedora/mmx64.efi \
         /usr/lib/efi/shim/16.1-5/EFI/BOOT/fbx64.efi; do
    sudo python3 -c "
import struct
with open('$p', 'rb') as f: d = f.read()
pe = struct.unpack('<I', d[0x3c:0x40])[0]
dll = struct.unpack('<H', d[pe + 24 + 70:pe + 24 + 72])[0]
print(f'  NX_COMPAT: {\"SET ✓\" if dll & 0x100 else \"NOT SET ✗\"}  DllChar=0x{dll:04x}  $p')
"
done

Observed (Fedora 44, package shim-x64-16.1-5.x86_64, build 2025-11-04, packagers @pjones / @keszybz / @lsandova / @mlewando)

  NX_COMPAT: NOT SET ✗  DllChar=0x0000  /usr/lib/efi/shim/16.1-5/EFI/fedora/shim.efi
  NX_COMPAT: NOT SET ✗  DllChar=0x0000  /usr/lib/efi/shim/16.1-5/EFI/fedora/shimx64.efi
  NX_COMPAT: NOT SET ✗  DllChar=0x0000  /usr/lib/efi/shim/16.1-5/EFI/fedora/mmx64.efi
  NX_COMPAT: NOT SET ✗  DllChar=0x0000  /usr/lib/efi/shim/16.1-5/EFI/BOOT/fbx64.efi

Section alignment is correct (0x1000 = 4 KB). Deployed /boot/efi/EFI/fedora/shim*.efi are byte-identical to the RPM-shipped binaries in /usr/lib/efi/shim/16.1-5/ (verified by SHA256 571ea56b855dcf73bec6acb63c5ded44c2a191138bca0d8cfa5aa93f60f46fff for both shim.efi and shimx64.efi) — so this is the RPM build state, not deployment drift.

Counterproof (same Fedora 44 host, other vendor-built EFI binaries)

  NX_COMPAT: SET ✓      DllChar=0x0100  /boot/efi/EFI/fedora/grubx64.efi   (Fedora grub2)
  NX_COMPAT: SET ✓      DllChar=0x0100  /boot/efi/EFI/fedora/gcdx64.efi    (Fedora grub2)
  NX_COMPAT: SET ✓      DllChar=0x0100  /boot/vmlinuz-7.0.7-200.fc44.x86_64 (Fedora kernel)

So Fedora's grub2 and kernel packages get NX_COMPAT correctly, only the shim-x64 package doesn't.

Why this surfaces now

The fwupd uefi_mok plugin (PR fwupd/fwupd#8554, merged March 2025) checks shim-has-nx-compat-set as one of eight sub-attributes contributing to org.fwupd.hsi.Uefi.MemoryProtection. Before this plugin existed, the missing flag wasn't visible. After Fedora 44 shipped fwupd 2.1.x with the plugin enabled, every F44 user gets not-enabled on this attribute (contributing to HSI:1!).

Affected user reports (cross-vendor, cross-hardware, all Fedora 44):

Issue	Hardware	BIOS	CPU
fwupd/fwupd#10080	Lenovo 21L6S1HA00 / P14s G4 / P16s G2 / ASUS FA617XS	AMI	AMD Ryzen
fwupd/fwupd#10277	Framework Laptop 16	INSYDE	AMD Ryzen AI 300
(this report basis)	Lenovo ThinkPad X13 Gen 1	Lenovo	Intel i5-10310U Comet Lake

The reframe is in fwupd/fwupd#10080 issuecomment-4464964714 and fwupd/fwupd#10277 issuecomment-4464964655.

Microsoft UEFI CA signing context

Microsoft's UEFI CA memory mitigation requirements have required IMAGE_DLLCHARACTERISTICS_NX_COMPAT on submitted PE files since 2022-11-30 (MS docs). With the Microsoft Corporation UEFI CA 2011 cert expiring 2026-06-27 (per Red Hat KB-7128933 and the cert's own Not After: Jun 27 21:32:45 2026 GMT) and the new Microsoft UEFI CA 2023 cert enforcement following, this becomes more than a fwupd-cosmetic issue.

Question for maintainers

1. Is this intentional in the Fedora shim spec (e.g. compatibility workaround for some edge-case firmware that refuses NX_COMPAT-flagged binaries)? If so, would a brief comment in the spec explaining the rationale help, so distros and uefi_mok users understand the constraint?
2. If it's an unintentional regression in the Fedora shim.spec (missing POST_PROCESS_PE_FLAGS arg, missing make argument, or a patch that was dropped), is it tracked anywhere?
3. Is rhboot/shim the right place for this report, or should it be filed in Fedora bugzilla / Pagure src.fedoraproject.org/rpms/shim instead?

Happy to provide additional diagnostics, file Fedora bugzilla as a duplicate-with-cross-ref, or test a candidate fix on the Intel X13 Gen 1 system.

[Shished]

Ubuntu 26.04 ships shim binaries with both NX enabled and disabled but the file that is used during the boot has it disabled.

/usr/lib/shim$ for p in ./*.efi*; do
    sudo python3 -c "
import struct
with open('$p', 'rb') as f: d = f.read()
pe = struct.unpack('<I', d[0x3c:0x40])[0]
dll = struct.unpack('<H', d[pe + 24 + 70:pe + 24 + 72])[0]
print(f'  NX_COMPAT: {\"SET ✓\" if dll & 0x100 else \"NOT SET ✗\"}  DllChar=0x{dll:04x}  $p')
"
done
  NX_COMPAT: SET ✓  DllChar=0x0100  ./fbx64.efi
  NX_COMPAT: SET ✓  DllChar=0x0100  ./mmx64.efi
  NX_COMPAT: NOT SET ✗  DllChar=0x0000  ./shimx64.efi
  NX_COMPAT: NOT SET ✗  DllChar=0x0000  ./shimx64.efi.dualsigned
  NX_COMPAT: NOT SET ✗  DllChar=0x0000  ./shimx64.efi.signed
  NX_COMPAT: NOT SET ✗  DllChar=0x0000  ./shimx64.efi.signed.latest
  NX_COMPAT: NOT SET ✗  DllChar=0x0000  ./shimx64.efi.signed.previous
  NX_COMPAT: SET ✓  DllChar=0x0100  ./shimx64.nx.efi
  NX_COMPAT: SET ✓  DllChar=0x0100  ./shimx64.nx.efi.signed.latest

/boot/efi/EFI/ubuntu# for p in ./*.efi*; do
    sudo python3 -c "
import struct
with open('$p', 'rb') as f: d = f.read()
pe = struct.unpack('<I', d[0x3c:0x40])[0]
dll = struct.unpack('<H', d[pe + 24 + 70:pe + 24 + 72])[0]
print(f'  NX_COMPAT: {\"SET ✓\" if dll & 0x100 else \"NOT SET ✗\"}  DllChar=0x{dll:04x}  $p')
"
done
  NX_COMPAT: SET ✓  DllChar=0x0100  ./grubx64.efi
  NX_COMPAT: SET ✓  DllChar=0x0100  ./mmx64.efi
  NX_COMPAT: NOT SET ✗  DllChar=0x0000  ./shimx64.efi

[timn]

Also seeing this on a Lenovo X1 Carbon Gen 13. Drops from HSI:4 to HSI:1.

[NexusOne23]

Answering my own question — the evidence points to "intentional", so closing this as resolved.

I pulled the newest Fedora shim build from Koji to check whether the Microsoft UEFI CA 2023 re-sign (for the 2011 CA expiry) flips the flag. It does not:

Build	Signatures	shim NX_COMPAT
shim-x64-16.1-5 (F44 stable)	2011 only	0x0000 ✗
shim-x64-16.1-8 (newest in Koji)	2011 + 2023	0x0000 ✗

16.1-8 carries both Microsoft Corporation UEFI CA 2011 and Microsoft UEFI CA 2023 signer in the embedded PKCS#7, and per the changelog it's a full rebuild (16.1-8: Rebuild, after 16.1-6: x86_64: add signature from "Microsoft UEFI CA 2023 signer"). So Fedora rebuilt and re-signed shim in 2026 and deliberately kept all four suite binaries non-NX. A forgotten build flag would almost certainly have surfaced at that rebuild/re-sign.

That matches the reason distros ship a non-NX shim on purpose: setting NX_COMPAT on shim turns firmware NX enforcement on, and there is no reliable way for shim/GRUB to know whether the rest of the chain (and the firmware) is ready — so an NX shim can page-fault otherwise-bootable systems (cf. the grub-devel "unavoidable crash" discussion, and systemd/systemd#38545). Microsoft also lists IMAGE_DLLCHARACTERISTICS_NX_COMPAT as if-implemented, with explicit firmware backward-compat for non-NX modules, so a non-NX shim is not a signing violation. Ubuntu's split (ship both shimx64.efi non-NX and a separate shimx64.nx.efi, boot the non-NX one) fits the same picture.

Net: org.fwupd.hsi.Uefi.MemoryProtection = not-enabled via the shim-has-nx-compat-set leg is the expected, deliberate state for Fedora today — the conservative tail of the ecosystem-wide W^X migration, not a packaging miss.

For anyone arriving here from an HSI:1 drop: fixing the shim leg alone would not restore HSI:2 on most hardware anyway — the firmware MAT/DXE legs (stack/heap-is-executable, ro-sections-are-writable) and pre-UEFI-2.10 systems (has-memory-attribute-protocol) are independent blockers.

Thanks to everyone who added data points. Closing as resolved.