Make 64-on-32 maybe work on x86_64.

This is mostly based on a patch (https://github.com/mjg59/shim/issues/30)
from https://github.com/TBOpen , which refactors our __LP64__
tests to be tests of the header magic instead.  I've simplified things
by using what we've pre-loaded into "context" and making some helper
functions so the conditionals in most of the code say what they do,
instead of how they work.

Note that we're only allowing that from in_protocol's loader - that is,
we'll let 64-bit grub load a 32-bit kernel or 32-bit grub load a 64-bit
kernel, but 32-bit shim isn't loading a 64-bit grub.

Signed-off-by: Peter Jones <pjones@redhat.com>
Validate computed hash bases/hash sizes more thoroughly.

I screwed one of these up when working on 750584c, and it's a real pain
to figure out, so that means we should be validating them.

Signed-off-by: Peter Jones <pjones@redhat.com>
Don't call AuthenticodeVerify if vendor_cert_size is 0.

Actually check the size of our vendor cert quite early, so that there's
no confusion as to what's going on.

This isn't strictly necessary, in that in all cases if vendor_cert_size
is 0, then AuthenticodeVerify -> Pkcs7Verify() -> d2i_X509() will result
in a NULL "Cert", and it will return FALSE, and we'll reject the
signature, but better to avoid all that code in the first place.  Belt
and suspenders and whatnot.

Based on a patch from https://github.com/TBOpen .

Signed-off-by: Peter Jones <pjones@redhat.com>
Fix our "in_protocol" printing.

When I merged 4bfb13d and fixed the conflicts, I managed to make the
in_protocol test exactly backwards, so that's why we don't currently see
error messages.

Signed-off-by: Peter Jones <pjones@redhat.com>
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>
Do the same for ia32...

Once again, on ia32 this time, we see:

00000120  47 84 00 00 0a 00 00 00  00 00 00 00 00 00 00 00 |G...............|

Which is where the pointer on ia32 for the Base Relocation Table should
be.  It points to 0x8447, which isn't a particularly reasonable address as
numbers go, and happens to have this data there:

00008440  6f 00 6e 00 66 00 69 00  67 00 75 00 72 00 65 00 |o.n.f.i.g.u.r.e.|
00008450  00 00 49 00 50 00 76 00  36 00 28 00 00 00 2c 00 |..I.P.v.6.(...,.|
00008460  25 00 73 00 2c 00 00 00  29 00 00 00 25 00 64 00 |%.s.,...)...%.d.|
00008470  2e 00 25 00 64 00 2e 00  25 00 64 00 2e 00 25 00 |..%.d...%.d...%.|
00008480  64 00 00 00 44 00 48 00  43 00 50 00 00 00 49 00 |d...D.H.C.P...I.|
00008490  50 00 76 00 34 00 28 00  00 00 2c 00 25 00 73 00 |P.v.4.(...,.%.s.|

And so that table is, in theory, this part:

00008447                       00  67 00 75 00 72 00 65 00 |       .g.u.r.e.|
00008450  00                                               |.               |

Which is pretty clearly not a pointer table of any kind.

So give ia32 the same treatment as x86_64, and now all arches work basically
the same.

Signed-off-by: Peter Jones <pjones@redhat.com>
Make list_keys() index variables all be signed.

We build with -Werror=signed-compare in fedora/rhel rpms, and this
showed up.

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