The previous strategy is to locate the first available PXE_BASE_CODE
protocol and to fetch the second stage image from it, and this may
cause shim to fetch the wrong second stage image, i.e. grub.efi.
Consider the machine with the following boot order:
1. PXE Boot
2. Hard Drive
Assume that the EFI image, e.g. bootx64.efi, in the PXE server is
broken, then "PXE Boot" will fail and fallback to "Hard Drive". While
shim.efi in "Hard Drive" is loaded, it will find the PXE protocol is
available and fetch grub.efi from the PXE server, not grub.efi in the
disk.
This commit checks the DeviceHandle from Loaded Image. If the device
supports PXE, then shim fetches grub.efi with the PXE protocol. Otherwise,
shim loads grub.efi from the disk.
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
Right now we always look for e.g. "\grubx64.efi", which is completely
wrong. This makes it look for the path shim was loaded from and modify
that to end in a sanitized version of our default loader name.
Resolves: rhbz#1032583
Signed-off-by: Peter Jones <pjones@redhat.com>
This gets rid of a lot of type casting that we don't need, and helps
reduce warnings when I switch a bunch of gnu-efi stuff to taking const
arguments.
Signed-off-by: Peter Jones <pjones@redhat.com>
The maximum length of a string representation of an ipv6 address is 39
characters (8 groups of 4 hex chars, with 7 colons in between). So don't
allocate more room than this - and more importantly, don't blindly accept
strings from the server that are longer than our buffer...
A wrong pointer was being passed to EFI_PXE_BASE_CODE_TFTP_READ_FILE,
preventing us from getting the file size back from the tftp call, ensuring
that we don't have enough information to properly secureboot-validate the
retrieved image.
