File 0022-Add-secureboot-support-on-efi-chainloader.patch of Package grub2
From cc8caea2e9f777b8995cf8631b59be3fd1d361e5 Mon Sep 17 00:00:00 2001
From: Raymund Will <rw@suse.com>
Date: Mon, 8 Jul 2019 11:55:18 +0200
Subject: [PATCH 22/28] Add secureboot support on efi chainloader
Expand the chainloader to be able to verify the image by means of shim
lock protocol. The PE/COFF image is loaded and relocated by the
chainloader instead of calling LoadImage and StartImage UEFI boot
Service as they require positive verification result from keys enrolled
in KEK or DB. The shim will use MOK in addition to firmware enrolled
keys to verify the image.
The chainloader module could be used to load other UEFI bootloaders,
such as xen.efi, and could be signed by any of MOK, KEK or DB.
Based on https://build.opensuse.org/package/view_file/openSUSE:Factory/grub2/grub2-secureboot-chainloader.patch
Signed-off-by: Peter Jones <pjones@redhat.com>
Also:
commit cd7a8984d4fda905877b5bfe466339100156b3bc
Author: Raymund Will <rw@suse.com>
Date: Fri Apr 10 01:45:02 2015 -0400
Use device part of chainloader target, if present.
Otherwise chainloading is restricted to '$root', which might not even
be readable by EFI!
v1. use grub_file_get_device_name() to get device name
Signed-off-by: Michael Chang <mchang@suse.com>
Signed-off-by: Peter Jones <pjones@redhat.com>
Also:
commit 0872a2310a0eeac4ecfe9e1b49dd2d72ab373039
Author: Peter Jones <pjones@redhat.com>
Date: Fri Jun 10 14:06:15 2016 -0400
Rework even more of efi chainload so non-sb cases work right.
This ensures that if shim protocol is not loaded, or is loaded but shim
is disabled, we will fall back to a correct load method for the efi
chain loader.
Here's what I tested with this version:
results expected actual
------------------------------------------------------------
sb + enabled + shim + fedora success success
sb + enabled + shim + win success success
sb + enabled + grub + fedora fail fail
sb + enabled + grub + win fail fail
sb + mokdisabled + shim + fedora success success
sb + mokdisabled + shim + win success success
sb + mokdisabled + grub + fedora fail fail
sb + mokdisabled + grub + win fail fail
sb disabled + shim + fedora success success*
sb disabled + shim + win success success*
sb disabled + grub + fedora success success
sb disabled + grub + win success success
nosb + shim + fedora success success*
nosb + shim + win success success*
nosb + grub + fedora success success
nosb + grub + win success success
* for some reason shim protocol is being installed in these cases, and I
can't see why, but I think it may be this firmware build returning an
erroneous value. But this effectively falls back to the mokdisabled
behavior, which works correctly, and the presence of the "grub" (i.e.
no shim) tests effectively tests the desired behavior here.
Resolves: rhbz#1344512
Signed-off-by: Peter Jones <pjones@redhat.com>
Also:
commit ff7b1cb7f69487870211aeb69ff4f54470fbcb58
Author: Laszlo Ersek <lersek@redhat.com>
Date: Mon Nov 21 15:34:00 2016 +0100
efi/chainloader: fix wrong sanity check in relocate_coff()
In relocate_coff(), the relocation entries are parsed from the original
image (not the section-wise copied image). The original image is
pointed-to by the "orig" pointer. The current check
(void *)reloc_end < data
compares the addresses of independent memory allocations. "data" is a typo
here, it should be "orig".
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1347291
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Bogdan Costescu <bcostescu@gmail.com>
Tested-by: Juan Orti <j.orti.alcaine@gmail.com>
Also:
commit ab4ba9997ad4832449e54d930fa2aac6a160d0e9
Author: Laszlo Ersek <lersek@redhat.com>
Date: Wed Nov 23 06:27:09 2016 +0100
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 <lersek@redhat.com>
Also:
commit cc06f149fbd2d8c1da1e83173d21629ba97e0d92
Author: Raymund Will <rw@suse.com>
chainloader: Define machine types for RISC-V
The commit "Add secureboot support on efi chainloader" didn't add machine
types for RISC-V, so this patch adds them.
Note, that grub-core/loader/riscv/linux.c is skipped because Linux is not
supported yet. This patch might need a new revision once that's the case.
Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com>
---
include/grub/efi/pe32.h | 52 +++++++++++++++++++++++++++++++++++++----
1 file changed, 47 insertions(+), 5 deletions(-)
diff --git a/include/grub/efi/pe32.h b/include/grub/efi/pe32.h
index 7a05c0ff8..48261b68e 100644
--- a/include/grub/efi/pe32.h
+++ b/include/grub/efi/pe32.h
@@ -261,7 +261,11 @@ struct grub_pe64_optional_header
struct grub_pe32_section_table
{
char name[8];
- grub_uint32_t virtual_size;
+ union
+ {
+ grub_uint32_t physical_address;
+ grub_uint32_t virtual_size;
+ };
grub_uint32_t virtual_address;
grub_uint32_t raw_data_size;
grub_uint32_t raw_data_offset;
@@ -272,12 +276,18 @@ struct grub_pe32_section_table
grub_uint32_t characteristics;
};
+#define GRUB_PE32_SCN_TYPE_NO_PAD 0x00000008
#define GRUB_PE32_SCN_CNT_CODE 0x00000020
#define GRUB_PE32_SCN_CNT_INITIALIZED_DATA 0x00000040
-#define GRUB_PE32_SCN_MEM_DISCARDABLE 0x02000000
-#define GRUB_PE32_SCN_MEM_EXECUTE 0x20000000
-#define GRUB_PE32_SCN_MEM_READ 0x40000000
-#define GRUB_PE32_SCN_MEM_WRITE 0x80000000
+#define GRUB_PE32_SCN_CNT_UNINITIALIZED_DATA 0x00000080
+#define GRUB_PE32_SCN_LNK_OTHER 0x00000100
+#define GRUB_PE32_SCN_LNK_INFO 0x00000200
+#define GRUB_PE32_SCN_LNK_REMOVE 0x00000800
+#define GRUB_PE32_SCN_LNK_COMDAT 0x00001000
+#define GRUB_PE32_SCN_GPREL 0x00008000
+#define GRUB_PE32_SCN_MEM_16BIT 0x00020000
+#define GRUB_PE32_SCN_MEM_LOCKED 0x00040000
+#define GRUB_PE32_SCN_MEM_PRELOAD 0x00080000
#define GRUB_PE32_SCN_ALIGN_1BYTES 0x00100000
#define GRUB_PE32_SCN_ALIGN_2BYTES 0x00200000
@@ -286,10 +296,28 @@ struct grub_pe32_section_table
#define GRUB_PE32_SCN_ALIGN_16BYTES 0x00500000
#define GRUB_PE32_SCN_ALIGN_32BYTES 0x00600000
#define GRUB_PE32_SCN_ALIGN_64BYTES 0x00700000
+#define GRUB_PE32_SCN_ALIGN_128BYTES 0x00800000
+#define GRUB_PE32_SCN_ALIGN_256BYTES 0x00900000
+#define GRUB_PE32_SCN_ALIGN_512BYTES 0x00A00000
+#define GRUB_PE32_SCN_ALIGN_1024BYTES 0x00B00000
+#define GRUB_PE32_SCN_ALIGN_2048BYTES 0x00C00000
+#define GRUB_PE32_SCN_ALIGN_4096BYTES 0x00D00000
+#define GRUB_PE32_SCN_ALIGN_8192BYTES 0x00E00000
#define GRUB_PE32_SCN_ALIGN_SHIFT 20
#define GRUB_PE32_SCN_ALIGN_MASK 7
+#define GRUB_PE32_SCN_LNK_NRELOC_OVFL 0x01000000
+#define GRUB_PE32_SCN_MEM_DISCARDABLE 0x02000000
+#define GRUB_PE32_SCN_MEM_NOT_CACHED 0x04000000
+#define GRUB_PE32_SCN_MEM_NOT_PAGED 0x08000000
+#define GRUB_PE32_SCN_MEM_SHARED 0x10000000
+#define GRUB_PE32_SCN_MEM_EXECUTE 0x20000000
+#define GRUB_PE32_SCN_MEM_READ 0x40000000
+#define GRUB_PE32_SCN_MEM_WRITE 0x80000000
+
+
+
#define GRUB_PE32_SIGNATURE_SIZE 4
#define GRUB_PE32_SIGNATURE "PE\0\0"
@@ -310,6 +338,20 @@ struct grub_pe_image_header
#endif
};
+struct grub_pe32_header_32
+{
+ char signature[GRUB_PE32_SIGNATURE_SIZE];
+ struct grub_pe32_coff_header coff_header;
+ struct grub_pe32_optional_header optional_header;
+};
+
+struct grub_pe32_header_64
+{
+ char signature[GRUB_PE32_SIGNATURE_SIZE];
+ struct grub_pe32_coff_header coff_header;
+ struct grub_pe64_optional_header optional_header;
+};
+
struct grub_pe32_fixup_block
{
grub_uint32_t page_rva;
--
2.42.0
