If we don't have writable grubenv and we're on EFI, always show the menu
If we don't have writable grubenv, recordfail doesn't work, which means our
quickboot behavior - with a timeout of 0 - leaves the user without a
reliable way to access the boot menu if they're on UEFI, because unlike
BIOS, UEFI does not support checking the state of modifier keys (i.e.
holding down shift at boot is not detectable).
Handle this corner case by always using a non-zero timeout on EFI when
save_env doesn't work.
Reuse GRUB_RECORDFAIL_TIMEOUT to avoid introducing another variable.
Patch-Name: quick-boot-lvm.patch
Signed-off-by: Steve Langasek <email address hidden>
Bug-Ubuntu: https://bugs.launchpad.net/bugs/1800722
efi/chainloader: truncate overlong relocation section
The UEFI Windows 7 boot loader ("EFI/Microsoft/Boot/bootmgfw.efi", SHA1
31b410e029bba87d2068c65a80b88882f9f8ea25) has inconsistent headers.
Compare:
> The Data Directory
> ...
> Entry 5 00000000000d9000 00000574 Base Relocation Directory [.reloc]
Versus:
> Sections:
> Idx Name Size VMA LMA File off ...
> ...
> 10 .reloc 00000e22 00000000100d9000 00000000100d9000 000a1800 ...
That is, the size reported by the RelocDir entry (0x574) is smaller than
the virtual size of the .reloc section (0xe22).
Quoting the grub2 debug log for the same:
> chainloader.c:595: reloc_dir: 0xd9000 reloc_size: 0x00000574
> chainloader.c:603: reloc_base: 0x7d208000 reloc_base_end: 0x7d208573
> ...
> chainloader.c:620: Section 10 ".reloc" at 0x7d208000..0x7d208e21
> chainloader.c:661: section is not reloc section?
> chainloader.c:663: rds: 0x00001000, vs: 00000e22
> chainloader.c:664: base: 0x7d208000 end: 0x7d208e21
> chainloader.c:666: reloc_base: 0x7d208000 reloc_base_end: 0x7d208573
> chainloader.c:671: Section characteristics are 42000040
> chainloader.c:673: Section virtual size: 00000e22
> chainloader.c:675: Section raw_data size: 00001000
> chainloader.c:678: Discarding section
After hexdumping "bootmgfw.efi" and manually walking its relocation blocks
(yes, really), I determined that the (smaller) RelocDir value is correct.
The remaining area that extends up to the .reloc section size (== 0xe22 -
0x574 == 0x8ae bytes) exists as zero padding in the file.
This zero padding shouldn't be passed to relocate_coff() for parsing. In
order to cope with it, split the handling of .reloc sections into the
following branches:
- original case (equal size): original behavior (--> relocation
attempted),
- overlong .reloc section (longer than reported by RelocDir): truncate the
section to the RelocDir size for the purposes of relocate_coff(), and
attempt relocation,
- .reloc section is too short, or other checks fail: original behavior
(--> relocation not attempted).
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1347291
Signed-off-by: Laszlo Ersek <email address hidden>
Patch-Name: linuxefi_truncate_overlong_relocs.patch
Last-Update: 2018-09-25