Generate a sane PE header on shim, fallback, and MokManager.

It turns out a7249a65 was masking a second problem - on some binaries,
when we actually don't have any base relocations at all, binutils'
"objcopy --target efi-app-x86_64" is generating a PE header with a base
relocations pointer that happily points into the middle of our text
section.  So with shim processing base relocations correctly, it refuses
to load those binaries.

For example, on one binary I just built:

00000130  00 a0 00 00 0a 00 00 00  00 00 00 00 00 00 00 00 |................|

which says there's a Base Relocation Table at 0xa000 that's 0xa bytes long.
That's here:

0000a000  58 00 29 00 00 00 00 00  48 00 44 00 28 00 50 00 |X.).....H.D.(.P.|
0000a010  61 00 72 00 74 00 25 00  64 00 2c 00 53 00 69 00 |a.r.t.%.d.,.S.i.|
0000a020  67 00 25 00 67 00 29 00  00 00 00 00 00 00 00 00 |g.%.g.).........|
0000a030  48 00 44 00 28 00 50 00  61 00 72 00 74 00 25 00 |H.D.(.P.a.r.t.%.|

So the table is:

0000a000  58 00 29 00 00 00 00 00  48 00                   |X.).....H.      |

That wouldn't be so bad, except those binaries are MokManager.efi,
fallback.efi, and shim.efi, and sometimes they're .reloc, which we're
actually trying to handle correctly now because grub builds with a real
and valid .reloc table.  So though I didn't think there was any hair
left on this yak, more shaving ensues.

With this change, instead of letting objcopy do whatever it likes, we
switch to "-O binary" and merely link in a header that's appropriate for
our binaries.  This is the same method Ard wrote for aarch64, and it
seems to work fine in either place (modulo some minor changes.)

At some point this should be merged into gnu-efi instead of carrying our
own crt0-efi-x86_64.S, but that's a less immediate problem.

I did not need this problem.

Signed-off-by: Peter Jones <pjones@redhat.com>

0 files changed, 0 insertions, 0 deletions