rhboot/shim cannot directly load OpenCore.efi after recent build tooling changes

[mikebeaton]

Pre-existing GRUB2 shim (not recompiled) is failing to load recent OpenCore.efi (renamed to grubx64.efi) correctly.

A part of the code linked code within OpenCore is zero when it should be initialized (specifically - though there may be others, this is encountered first - all of the memory pointed to by the function pointers in mUefiDevicePathLibToTextTable is zero) (so - it may or may not be worth noting - this is all code which is linked only via static variable pointers to it, but not sure if this is what matters). The same pointers are working (pointing to valid code) when the same, current OpenCore.efi file is loaded 'normally' (by any BIOS, but including by OVMF). Also, chaining from the very same shim works fine with older 0.8.7 OpenCore.efi. Is this even supposed to work? It seems like it should, as presumably loads of old loaders have to sucessfully load our newly compiled OpenCore.efi.

(FYI Not that it probably matters too much, but I am attempting to use rhboot/shim before OC instead of before GRUB2 as I think it may be an easy and clean way to combine Linux MOK handling with OpenCore. Most likely as something to encourage advanced users to compile for themselves.)

[mikebeaton]

This has been tested on the shim which came with Fedora, and on a built shim from Arch https://archlinux.org/packages/community/any/shim/download/ - same result.

I believe the same issue is also occurring in own-build shim from source, though this is not thoroughly tested - I switched back to pre-built shims as I (initially) thought this issue might be a result of an error in how I built/configured own-build shim.

[mikebeaton]

In OVMF, where I have been doing most testing, 1st and 3rd options (i.e. normal ways of starting OC) work.

2nd and 4th start the images (you can see early debug o/p), but generate errors and crash OVMF early.

The named boot options above start what you would think they would start. For the shimmed versions, a copy of OC's /EFI/BOOT/BOOTx64.efi has been made, called grubx64.efi, in its directory, and a copy of /EFI/OC/OpenCore.efi has been made, called grubx64.efi, in its directory. (Worth noting, going forwards, that own-build shim can easily be configured, via its existing make options, to chain to OpenCore.efi directly, with no renaming necessary, but this is not done here.)

[mikebeaton]

And to give a little more context on exactly what I am seeing:

The error case (first screenshot) shown above is starting /EFI/OC/OpenCore.efi (renamed to grubx64.efi) directly (i.e. shim->oc, not shim->grub->oc) from shimx64.efi in the same directory. I can single step into this, once started, using lldb (I have just added a WaitForKeyPress very early to allow breaking into the code more easily, as suggested in the OC debug documentation). It gets to where it tries to print the path it is at, using the function pointers (path print functions) mentioned in the OP, and they are pointing to memory which is zero. Which it jumps to, so crashes.

The first screenshot is the error case, the second screenshot is the very same OpenCore.efi, loaded in the very same OVMF setup, but started using a boot entry which points to it directly, rather than starting it via a boot entry which points to /EFI/OC/shimx64.efi.

[mikebeaton]

FWIW IDA can load the problem OpenCore.efi fine - the function pointers in question are pointing to sane code in a .text section. Given that IDA loads it, and presumably lots of people's BIOSes are loading it, it is starting to seem as if shim is the code that is quirky... so also (assuming my whole issue isn't off, for some reason) that a PR might be needed...

[mikebeaton]

As requested, attached are EFIs showing the problem:

• Essentially any recent shimx64.efi is placed in /EFI/OC
• /EFI/OC/BOOTx64.efi is removed (to avoid starting via that unintentionally)
• /EFI/OC/OpenCore.efi is copied as /EFI/OC/grubx64.efi
• OVMF compiled as NOPT (./build.sh -a X64 -b NOOPT) and is started with ./build.sh -a X64 -b NOOPT qemu -drive format=raw,file=fat:rw:~/OPENCORE -gdb tcp::8864 -serial stdio -usb -device usb-mouse -device usb-kbd -net none (if you prefer not to start with build.sh, then the qemu launch command which this is equivalent to is shown as its first output)
• Enter OVMF boot menu and create a boot entry pointing at /EFI/OC/OpenCore.efi
• Restart OVMF, press any key at the WaitForKeyPress output (Mike...), and confirm it runs fine
• Re-enter OVMF boot menu and create a boot entry pointing at /EFI/OC/shimx64.efi (being sure to confirm this new entry is moved to first entry)
• Restart with the new boot entry; it is clear from the output that shimx64.efi has started grubx64.efi (i.e. the copy of OpenCore.efi)
• However, if you press any key at the WaitForKeyPress output (Mike...) it crashes
• Re-start and attach a debugger when at the WaitForKeyPress output
• Run to https://github.com/acidanthera/audk/blob/master/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c#L2450 (single step into https://github.com/acidanthera/OpenCorePkg/blob/master/Application/OpenCore/OpenCore.c#L336, which is called very early, just below the WaitForKeyPress) and verify that the wrong value is assigned to ToText, which is a function pointer, which therefore crashes when dereferenced and called shortly afterwards
• Start and debug the non-crashing version, and verify the correct value which should be written to ToText at the same line
• The code is the current OpenCore source compiled as NOOPT, with only the attached patch applied, to add a single WaitForKeyPress line

OPENCORE_XCODE5.zip
OPENCORE_GCC5.zip
WaitForKeyPress.patch

[ponychicken]

I think I was trying to achieve the same thing as you:
To skip the hasslesome process of creating a completely new keystore and just use the easily adminstrable mokutil.

I have signed my OpenCore files with sbsign --key MOK.priv --cert MOK.pem
This gave a warning, maybe its related to the issue:

warning: gap in section table:
    .data   : 0x00076000 - 0x00087000,
    .reloc  : 0x0008e000 - 0x00090000,
gaps in the section table may result in different checksums
warning: data remaining[564224 vs 592896]: gaps between PE/COFF sections?
Image was already signed; adding additional signature

Still I would have expected it to work if I boot into grub and select the Mac entry (it works with SB disabled), but grub displayed the error:

/EndEntire
file path: /ACPI........................../File(OpenCore.efi)/EndEntire
Error: cannot load image.

[tzugen]

There are people on reddit reporting two years ago that exactly that worked:
https://www.reddit.com/r/hackintosh/comments/p8epla/how_do_you_sign_opencore_binaries_with_secure/

[mikebeaton]

Closing this as fixed by PR from the OC team accepted into rhboot/shim.

[mikebeaton]

See also #2237.

[mikebeaton]

See also acidanthera/OpenCorePkg#484, which finishes off the project of actually using the accepted change to Shim.