coreboot

Patrick Rudolph wrote:

tested with coreboot 717c0505b1063da72db9aba2f1f0e1ef6dee60da
Works:

• uefipayload_2511
  Broken:
• uefipayload_2608

Seems to hang in payload. Since there's no RS232 serial available, only EHCI debug works, it's not clear why it hangs.

HEAD of current edk2 branch (1f9ab463057c53883245d0ce5dfe07201efb1efe) or latest tag (26.09.2, afe0e87d25d5ac57191aa7c5211c83d1c13d198f)?

Leah is using 26.09.2 for libreboot currently, and says it works fine on her x220.

Patrick Rudolph wrote in #note-4:

Attached a log.
After loading GRUB it jumps to a memory location where no code resides and then causes a pagefault due to invalid x86 opcodes.

this appears to be a bug with older grub versions, jumping to memory that the payload was not able to allocate instead of requesting a new range. Older edk2 branches papered over this with a fix for another issue.

That is true. It's grub2-common-2.06-118.fc38.noarch

Hi Matt, Patrick,

Sorry to jump in - I got curious, had some time and took a closer look at
Patrick's log.

I think 2608 is missing the workaround that prevents CpuDxe from publishing
the EFI Memory Attribute Protocol.

2508, 2511, and 2603 each carry your revert of the upstream change, all from
2025-02-11:

fb863e113b / 5b63f930e3 / 97f0b65a1d
Revert "UefiCpuPkg: Produce EFI memory attributes protocol"

2605 instead has the cleaner variant:

29c488003c
UefiCpuPkg/CpuDxe: Gate EFI Memory Attribute Protocol behind a PCD

2608 appears to have neither, while 2511 is Patrick's working branch.

The fault in Patrick's log is:

ExceptionData - 0000000000000003  I:0 R:0 U:0 W:1 P:1 PK:0 SS:0 SGX:0

so this is a write fault on a present page, which does not fit a jump into
unallocated memory.

Your 29c488003c applies cleanly to 2608. After rebuilding, the Memory
Attribute Protocol GUID is no longer present in CpuDxe.dll, which is
the intended behavior described in your commit message.

I have not tested this on hardware.

My best guess as to how the remaining pieces fit together is:

1. GRUB requests 0x1000000 + init_size, and that allocation fails
   (the ConvertPages line above).
2. It falls back to another address, as Fedora's kernel_alloc() does,
   and ends up somewhere around 0x189xxxxx.
3. It then calls grub_update_mem_attrs() on that buffer, which only
   has an effect when the protocol is present...
4. A later write into a page of that buffer faults.

That would explain why the fault address is outside the failed range:
RIP, CR2, and RDI all sit within roughly 370 KiB of each other, with both
write targets page-aligned, which looks like a loader writing into its own
image.

Patrick, could you try 2608 with 29c488003c applied and see whether it
works on your hardware?

Steps:

cd payloads/external/edk2/workspace/mrchromebox
git fetch origin
git checkout -B memattr-test origin/uefipayload_2608
git cherry-pick 29c488003c

Then set the payload revision to that branch. The edk2 Makefile
force-checks out EDK2_TAG_OR_REV on every build whenever the tree is clean,
so a detached cherry-pick would otherwise be discarded:

CONFIG_EDK2_TAG_OR_REV="memattr-test"

and rebuild.

Best,
Sebastian

Sebastian Müller wrote in #note-7:

I think 2608 is missing the workaround that prevents CpuDxe from publishing
the EFI Memory Attribute Protocol.

no, the Memory Attribute Protocol workaround was intentionally dropped in uefipayload_2608. It was only needed for old shim/GRUB builds that misuse the protocol, and upstream rejected the platform-level gate (https://github.com/tianocore/edk2/pull/13002). uefipayload_2511 never published the protocol, which is why it boots.

grub2 2.06-118.fc38 is from Fedora 38, which is EOL, and its shim/GRUB predate the NX/memory-attribute fixes. With the protocol present, that GRUB marks memory non-executable and then jumps into it, which matches your log. Can you update shim and GRUB to a current version (or boot a current distro's media) and retest? That's also why Leah's X220 boots fine on the edk2 26.09.2 tag.

upstream edk2 has a PR for a compatibility mode (https://github.com/tianocore/edk2/pull/12781) that will automatically remove the protocol when it loads a bootloader without NX_COMPAT. I suppose I can cherry-pick that, so old loaders like this work without a payload-specific hack. Hopefully it makes it in before the next stable tag

edit:

One thing to note with the PR above: compatibility mode only starts when DxeCore itself loads the application without NX_COMPAT. If Fedora 38 (eg) boots through a shim, the shim is the binary that gets checked, because shim usually loads GRUB with its own loader. If that shim has NX_COMPAT set and only GRUB lacks it, compatibility mode won't start and the protocol stays published. Patrick's case is only covered if his shim or GRUB is loaded directly and lacks the flag.

Thanks, that context helps - I had only looked at the branches and did not
follow the discussion. 12781 looks like the right approach to me.

I looked it up: rhboot/shim#539 first shipped in shim 15.8 (Jan 2024), so anything older
can be affected, including install media from currently supported releases
that can't be updated.

Updated GRUB to grub2-common-2.12-32.fc42.noarch, the issue still persists.

Patrick Rudolph wrote in #note-10:

Updated GRUB to grub2-common-2.12-32.fc42.noarch, the issue still persists.

I pulled the PR into uefipayload_2608 branch, give that a try. It fixed an issue with Batocera that some others had reported.

Seems to work again with fedora 44 which ships a newer version of shim.

Tested using Fedora 40
EDK2 ebad826c3a44fdd5c2441042ebc88298bac7512d is working
EDK2 1f9ab463057c53883245d0ce5dfe07201efb1efe is still broken