mirror of
https://git.proxmox.com/git/efi-boot-shim
synced 2025-08-03 10:17:46 +00:00
a8f3dc82be
Rob Clark noticed while, implementing a UEFI like backend on u-boot, that if a File Handle actually returns a meaningful device path from DevicePathFromHandle(), we wind up with a horribly wrong device path in the boot variable. He's right, normal UEFI doesn't return that, which means FileDevicePath() in our code currently does nothing at all. Instead of all that, pass in the device's handle, and it'll do what we're doing after the fact there. Here's the log from a current run: FS0:\> \efi\BOOT\BOOTX64.EFI System BootOrder not found. Initializing defaults. find_boot_options:778:Found directory named "fedora" try_boot_csv:532:Found file "\EFI\fedora\BOOT.CSV" try_boot_csv:544:File looks like: ?shim.efi,Fedora,,This is the boot entry for Fedora populate_stanza:495:CSV data: "shim.efi,Fedora,,This is the boot entry for Fedora" populate_stanza:501:filename: "shim.efi" populate_stanza:508:label: "Fedora" populate_stanza:514:arguments: "" add_to_boot_list:430:file DP: PciRoot(0)/Pci(0x1F,0x2)/Sata(0x0,0x0,0x0)/HD(Part1,Sig6584272A-D7B9-442A-B8A4-19B5EC4566F4)/\EFI\fedora\shim.efi FindSubDevicePath:78:input device path: "PciRoot(0)/Pci(0x1F,0x2)/Sata(0x0,0x0,0x0)/HD(Part1,Sig6584272A-D7B9-442A-B8A4-19B5EC4566F4)/\EFI\fedora\shim.efi" FindSubDevicePath:86:sub-path (4,1): "HD(Part1,Sig6584272A-D7B9-442A-B8A4-19B5EC4566F4)/\EFI\fedora\shim.efi" add_to_boot_list:452:04 01 2A 00 01 00 00 00 00 08 00 00 00 00 00 00 add_to_boot_list:452:00 40 06 00 00 00 00 00 2A 27 84 65 B9 D7 2A 44 add_to_boot_list:452:B8 A4 19 B5 EC 45 66 F4 02 02 04 04 2E 00 5C 00 add_to_boot_list:452:45 00 46 00 49 00 5C 00 66 00 65 00 64 00 6F 00 add_to_boot_list:452:72 00 61 00 5C 00 73 00 68 00 69 00 6D 00 2E 00 add_to_boot_list:452:65 00 66 00 69 00 00 00 7F FF 04 00 add_to_boot_list:459:device path: "HD(Part1,Sig6584272A-D7B9-442A-B8A4-19B5EC4566F4)/\EFI\fedora\shim.efi" Creating boot entry "Boot0000" with label "Fedora" for file "\EFI\fedora\shim.efi" AddOption - Boot0000, then CurrentCount = 0x00000008 update_boot_order:390:nbootorder: 7 BootOrder: 0000 0002 0001 0003 0005 0006 0004 Signed-off-by: Peter Jones <pjones@redhat.com> |
||
|---|---|---|
| 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 | ||
| hexdump.h | ||
| httpboot.c | ||
| httpboot.h | ||
| make-certs | ||
| Makefile | ||
| MokManager.c | ||
| MokVars.txt | ||
| netboot.c | ||
| netboot.h | ||
| PasswordCrypt.c | ||
| PasswordCrypt.h | ||
| README | ||
| README.fallback | ||
| replacements.c | ||
| replacements.h | ||
| shim.c | ||
| shim.h | ||
| testplan.txt | ||
| TODO | ||
| tpm.c | ||
| tpm.h | ||
| 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".