If the boot option recorded in csv is not in a media device path, the
corresponding full device path will be referred for creating the boot
variable.
However, the current code logic always frees the full device path
(full_device_path) and the media device path (dp) separately. In order
to resolve this issue, always check whether dp equals to full_device_path
before freeing dp.
Signed-off-by: Lans Zhang <jia.zhang@windriver.com>
Since booting the entry with fallback in the stack of things that got
measured will result in all the wrong PCR values, in the cases where TPM
is present and enabled, use ->Reset() instead of loading the Boot####
variable and executing its target.
Signed-off-by: Peter Jones <pjones@redhat.com>
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>
When dir->Read() says bs=0, we shouldn't try to allocate a buffer and
read into it. On edk2 this works because there's an implicit (possibly
accidental) minimum size of one pool list entry that can be allocated,
so you wind up getting (I think) 8 bytes.
When Rob Clark tried to run this under uboot's emulated UEFI
environment, dir->Read() returned 0 and when we passed that to
AllocateZeroPool() less good things happened.
So just check for that case and exit appropriately.
Signed-off-by: Peter Jones <pjones@redhat.com>
On baytrail, we've got 32-bit firmware, 32-bit efi utilities, and 64-bit
kernel. So since most distros will want 32+64 EFI media booting a
64-bit kernel, we have to name them better on the filesystem.
Signed-off-by: Peter Jones <pjones@redhat.com>
The following commit:
commit 4aac8a1179
Author: Gary Ching-Pang Lin <glin@suse.com>
Date: Thu Mar 6 10:57:02 2014 +0800
[fallback] Fix the data size for boot option comparison
corrected the data size used for comparison, but also reduced the
allocation so it doesn't include the trailing UTF16LE '\0\0' at the
end of the string, with the result that the trailer of the buffer
containing the string is overwritten, which OVMF detects as memory
corruption.
Increase the size of the storage buffer in a few places to correct
this problem.
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Gary Ching-Pang Lin <glin@suse.com>
fallback.c: In function ‘update_boot_order’:
fallback.c:334:17: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
for (j = 0 ; j < size / sizeof (CHAR16); j++)
^
fallback.c: In function ‘add_to_boot_list’:
fallback.c:402:16: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
for (i = 0; i < s; i++) {
^
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Some UEFI implementations never care the boot options, so the
restored boot options could be just ignored and this results in
endless reboot. To avoid this situation, this commit makes
fallback.efi to load the first matched boot option even if there
is no boot option to be restored. It may not be perfect, but at
least the bootloader is loaded...
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
set_boot_order() already copies the old BootOrder to the variable,
bootorder. Besides, we can adjust BootOrder when adding the newly
generated boot option. So, we don't have to copy the old one again
in update_boot_order(). This avoid the duplicate entries in BootOrder.
Signed-off-by: Gary Ching-Pang Lin <glin@suse.com>
This adds additional bounds-checking on the section sizes. Also adds
-Wsign-compare to the Makefile and replaces some signed variables with
unsigned counteparts for robustness.
Signed-off-by: Kees Cook <kees@ubuntu.com>
Some firmwares seem to ignore our boot entries and put their fallback
entries back on top. Right now that results in a lot of boot entries
for our stuff, a la https://bugzilla.redhat.com/show_bug.cgi?id=995834 .
Instead of that happening, if we simply find existing entries that match
the entry we would create and move them to the top of the boot order,
the machine will continue to operate in failure mode (which we can't
avoid), but at least we won't create thousands of extra entries.
Signed-off-by: Peter Jones <pjones@redhat.com>
UEFI 2.x section 3.1.2 provides for "short-form device path", where the
first element specified is a "hard drive media device path", so that you
can move a disk around on different buses without invalidating your
device path. Fallback has not been using this option, though in most
cases efibootmgr has.
Note that we still keep the full device path, because LoadImage()
isn't necessarily the layer where HD() works - one some systems BDS is
responsible for resolving the full path and passes that to LoadImage()
instead. So we have to do LoadImage() with the full path.
The things we do for our tools. In this case, make the AllocatePool()
happen outside of a conditional, even though that conditional will
always bee satisfied. This way coverity won't think we're setting fi
to NULL and passing it to StrCaseCmp.
Signed-off-by: Peter Jones <pjones@redhat.com>
fh->Read expects pointer to 32-bit int, use UINTN
Change-Id: If1a728efd51a9a24dfcd8123e84bf4c0713491fe
Signed-off-by: Andrew Boie <andrew.p.boie@intel.com>
I'm told rebooting is sometimes unreliable when called here, and we'll
get bootx64.efi loaded anyway. I'll just assume that's true and try to
load the first option, since it's clearly what we'd prefer happens next.
Signed-off-by: Peter Jones <pjones@redhat.com>
If shim is invoked as \EFI\BOOT\BOOT*.EFI and a file exists named
\EFI\BOOT\FALLBACK.EFI, try it instead of our second stage. So don't
put fallback.efi on your install media in \EFI\BOOT, because that won't
do whatever it is you're hoping for, unless you're hoping not to start
the installer.
So here's the process for using this:
in /EFI/fedora/ (or whichever directory you happen to own), you put:
shim.efi
grub.efi
boot.csv - format is: shim.efi,Nice Label,cmdline arguments,comments
- filenames refer only to files in this directory, with no
leading characters such as L"./" or L"/EFI/fedora/"
- note that while this is CSV, the character encoding is
UCS-2
and if /EFI/BOOT/BOOTX64.EFI doesn't already exist, then in /EFI/BOOT:
shim.efi as BOOTX64.EFI
fallback.efi
Signed-off-by: Peter Jones <pjones@redhat.com>
