mirror of
https://git.proxmox.com/git/efi-boot-shim
synced 2025-07-27 06:55:53 +00:00
a7249a65af
Currently when we process base relocations, we get the correct Data Directory pointer from the headers (context->RelocDir), and that header has been copied into our pristine allocated image when we copied up to SizeOfHeaders. But the data it points to has not been mirrored in to the new image, so it is whatever data AllocPool() gave us. This patch changes relocate_coff() to refer to the base relocation table from the image we loaded from disk, but apply the fixups to the new copy. I have no idea how x86_64 worked without this, but I can't make aarch64 work without it. I also don't know how Ard or Leif have seen aarch64 work. Maybe they haven't? Leif indicated on irc that they may have only tested shim with simple "hello world" applications from gnu-efi; they are certainly much less complex than grub.efi, and are generated through a different linking process. My only theory is that we're getting recycled data there pretty reliably that just makes us /not/ process any relocations, but since our ImageBase is 0, and I don't think we ever load grub with 0 as its base virtual address, that doesn't follow. I'm open to any other ideas anybody has. I do know that on x86_64 (and presumably aarch64 as well), we don't actually start seeing *symptoms* of this bug until the first chunk[0] of |
||
|---|---|---|
| Cryptlib | ||
| include | ||
| lib | ||
| .gitignore | ||
| cert.S | ||
| COPYRIGHT | ||
| crypt_blowfish.c | ||
| crypt_blowfish.h | ||
| elf_aarch64_efi.lds | ||
| elf_arm_efi.lds | ||
| elf_ia32_efi.lds | ||
| elf_ia64_efi.lds | ||
| elf_x86_64_efi.lds | ||
| fallback.c | ||
| make-certs | ||
| Makefile | ||
| MokManager.c | ||
| MokVars.txt | ||
| netboot.c | ||
| netboot.h | ||
| PasswordCrypt.c | ||
| PasswordCrypt.h | ||
| README | ||
| replacements.c | ||
| replacements.h | ||
| shim.c | ||
| shim.h | ||
| testplan.txt | ||
| TODO | ||
| ucs2.h | ||
| version.c.in | ||
| version.h | ||
shim is a trivial EFI application that, when run, attempts to open and execute another application. It will initially attempt to do this via the standard EFI LoadImage() and StartImage() calls. If these fail (because secure boot is enabled and the binary is not signed with an appropriate key, for instance) it will then validate the binary against a built-in certificate. If this succeeds and if the binary or signing key are not blacklisted then shim will relocate and execute the binary. shim will also install a protocol which permits the second-stage bootloader to perform similar binary validation. This protocol has a GUID as described in the shim.h header file and provides a single entry point. On 64-bit systems this entry point expects to be called with SysV ABI rather than MSABI, and so calls to it should not be wrapped. To use shim, simply place a DER-encoded public certificate in a file such as pub.cer and build with "make VENDOR_CERT_FILE=pub.cer".