import grub2-2.02-142.el8

This commit is contained in:
CentOS Sources 2022-09-14 08:11:03 +00:00 committed by Stepan Oksanichenko
parent 22518a4b0a
commit d59de3d8fd
7 changed files with 416 additions and 1 deletions

View File

@ -0,0 +1,47 @@
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Peter Jones <pjones@redhat.com>
Date: Fri, 29 Jul 2022 15:56:00 -0400
Subject: [PATCH] Make debug=file show which file filters get run.
If one of the file filters breaks things, it's hard to figure out where
it has happened.
This makes grub log which filter is being run, which makes it easier to
figure out where you are in the sequence of events.
Signed-off-by: Peter Jones <pjones@redhat.com>
(cherry picked from commit d3d6518a13b5440a3be6c66b0ae47447182f2891)
(cherry picked from commit d197e70761b1383827e9008e21ee41c6c7015776)
---
grub-core/kern/file.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/grub-core/kern/file.c b/grub-core/kern/file.c
index f062fc21e7..5e1f29d0dd 100644
--- a/grub-core/kern/file.c
+++ b/grub-core/kern/file.c
@@ -30,6 +30,14 @@ void (*EXPORT_VAR (grub_grubnet_fini)) (void);
grub_file_filter_t grub_file_filters[GRUB_FILE_FILTER_MAX];
+static char *filter_names[] = {
+ [GRUB_FILE_FILTER_VERIFY] = "GRUB_FILE_FILTER_VERIFY",
+ [GRUB_FILE_FILTER_GZIO] = "GRUB_FILE_FILTER_GZIO",
+ [GRUB_FILE_FILTER_XZIO] = "GRUB_FILE_FILTER_XZIO",
+ [GRUB_FILE_FILTER_LZOPIO] = "GRUB_FILE_FILTER_LZOPIO",
+ [GRUB_FILE_FILTER_MAX] = "GRUB_FILE_FILTER_MAX"
+};
+
/* Get the device part of the filename NAME. It is enclosed by parentheses. */
char *
grub_file_get_device_name (const char *name)
@@ -121,6 +129,9 @@ grub_file_open (const char *name, enum grub_file_type type)
if (grub_file_filters[filter])
{
last_file = file;
+ if (filter < GRUB_FILE_FILTER_MAX)
+ grub_dprintf ("file", "Running %s file filter\n",
+ filter_names[filter]);
file = grub_file_filters[filter] (file, type);
if (file && file != last_file)
{

View File

@ -0,0 +1,83 @@
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Peter Jones <pjones@redhat.com>
Date: Mon, 1 Aug 2022 14:06:30 -0400
Subject: [PATCH] efi: use enumerated array positions for our allocation
choices
In our kernel allocator on EFI systems, we currently have a growing
amount of code that references the various allocation policies by
position in the array, and of course maintenance of this code scales
very poorly.
This patch changes them to be enumerated, so they're easier to refer to
farther along in the code without confusion.
Signed-off-by: Peter Jones <pjones@redhat.com>
(cherry picked from commit 6768026270cca015d7fef0ecc8a4119e9b3d3923)
(cherry picked from commit 50b2ca3274b6950393a4ffc7edde04a1a3de594e)
---
grub-core/loader/i386/efi/linux.c | 31 ++++++++++++++++++++-----------
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/grub-core/loader/i386/efi/linux.c b/grub-core/loader/i386/efi/linux.c
index d80d6ec312..23b27f6507 100644
--- a/grub-core/loader/i386/efi/linux.c
+++ b/grub-core/loader/i386/efi/linux.c
@@ -60,17 +60,26 @@ struct allocation_choice {
grub_efi_allocate_type_t alloc_type;
};
-static struct allocation_choice max_addresses[4] =
+enum {
+ KERNEL_PREF_ADDRESS,
+ KERNEL_4G_LIMIT,
+ KERNEL_NO_LIMIT,
+};
+
+static struct allocation_choice max_addresses[] =
{
/* the kernel overrides this one with pref_address and
* GRUB_EFI_ALLOCATE_ADDRESS */
- { GRUB_EFI_MAX_ALLOCATION_ADDRESS, GRUB_EFI_ALLOCATE_MAX_ADDRESS },
+ [KERNEL_PREF_ADDRESS] =
+ { GRUB_EFI_MAX_ALLOCATION_ADDRESS, GRUB_EFI_ALLOCATE_MAX_ADDRESS },
+ /* If the flag in params is set, this one gets changed to be above 4GB. */
+ [KERNEL_4G_LIMIT] =
+ { GRUB_EFI_MAX_ALLOCATION_ADDRESS, GRUB_EFI_ALLOCATE_MAX_ADDRESS },
/* this one is always below 4GB, which we still *prefer* even if the flag
* is set. */
- { GRUB_EFI_MAX_ALLOCATION_ADDRESS, GRUB_EFI_ALLOCATE_MAX_ADDRESS },
- /* If the flag in params is set, this one gets changed to be above 4GB. */
- { GRUB_EFI_MAX_ALLOCATION_ADDRESS, GRUB_EFI_ALLOCATE_MAX_ADDRESS },
- { 0, 0 }
+ [KERNEL_NO_LIMIT] =
+ { GRUB_EFI_MAX_ALLOCATION_ADDRESS, GRUB_EFI_ALLOCATE_MAX_ADDRESS },
+ { NO_MEM, 0, 0 }
};
static struct allocation_choice saved_addresses[4];
@@ -423,7 +432,7 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
if (lh->xloadflags & LINUX_XLF_CAN_BE_LOADED_ABOVE_4G)
{
grub_dprintf ("linux", "Loading kernel above 4GB is supported; enabling.\n");
- max_addresses[2].addr = GRUB_EFI_MAX_USABLE_ADDRESS;
+ max_addresses[KERNEL_NO_LIMIT].addr = GRUB_EFI_MAX_USABLE_ADDRESS;
}
else
{
@@ -495,11 +504,11 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
grub_dprintf ("linux", "lh->pref_address: %p\n", (void *)(grub_addr_t)lh->pref_address);
if (lh->pref_address < (grub_uint64_t)GRUB_EFI_MAX_ALLOCATION_ADDRESS)
{
- max_addresses[0].addr = lh->pref_address;
- max_addresses[0].alloc_type = GRUB_EFI_ALLOCATE_ADDRESS;
+ max_addresses[KERNEL_PREF_ADDRESS].addr = lh->pref_address;
+ max_addresses[KERNEL_PREF_ADDRESS].alloc_type = GRUB_EFI_ALLOCATE_ADDRESS;
}
- max_addresses[1].addr = GRUB_EFI_MAX_ALLOCATION_ADDRESS;
- max_addresses[2].addr = GRUB_EFI_MAX_ALLOCATION_ADDRESS;
+ max_addresses[KERNEL_4G_LIMIT].addr = GRUB_EFI_MAX_ALLOCATION_ADDRESS;
+ max_addresses[KERNEL_NO_LIMIT].addr = GRUB_EFI_MAX_ALLOCATION_ADDRESS;
kernel_size = lh->init_size;
kernel_mem = kernel_alloc (kernel_size, GRUB_EFI_RUNTIME_SERVICES_CODE,
N_("can't allocate kernel"));

View File

@ -0,0 +1,129 @@
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Peter Jones <pjones@redhat.com>
Date: Mon, 1 Aug 2022 14:24:39 -0400
Subject: [PATCH] efi: split allocation policy for kernel vs initrd memories.
Currently in our kernel allocator, we use the same set of choices for
all of our various kernel and initramfs allocations, though they do not
have exactly the same constraints.
This patch adds the concept of an allocation purpose, which currently
can be KERNEL_MEM or INITRD_MEM, and updates kernel_alloc() calls
appropriately, but does not change any current policy decision. It
also adds a few debug prints.
Signed-off-by: Peter Jones <pjones@redhat.com>
(cherry picked from commit 36307bed28cd838116fc4af26a30719660d62d4c)
(cherry picked from commit dc1196350b0cbe89582832f44df0fce67e0c9fb2)
---
grub-core/loader/i386/efi/linux.c | 35 +++++++++++++++++++++++++++--------
1 file changed, 27 insertions(+), 8 deletions(-)
diff --git a/grub-core/loader/i386/efi/linux.c b/grub-core/loader/i386/efi/linux.c
index 23b27f6507..09e7596064 100644
--- a/grub-core/loader/i386/efi/linux.c
+++ b/grub-core/loader/i386/efi/linux.c
@@ -55,7 +55,14 @@ struct grub_linuxefi_context {
#define BYTES_TO_PAGES(bytes) (((bytes) + 0xfff) >> 12)
+typedef enum {
+ NO_MEM,
+ KERNEL_MEM,
+ INITRD_MEM,
+} kernel_alloc_purpose_t;
+
struct allocation_choice {
+ kernel_alloc_purpose_t purpose;
grub_efi_physical_address_t addr;
grub_efi_allocate_type_t alloc_type;
};
@@ -64,6 +71,7 @@ enum {
KERNEL_PREF_ADDRESS,
KERNEL_4G_LIMIT,
KERNEL_NO_LIMIT,
+ INITRD_MAX_ADDRESS,
};
static struct allocation_choice max_addresses[] =
@@ -71,14 +79,17 @@ static struct allocation_choice max_addresses[] =
/* the kernel overrides this one with pref_address and
* GRUB_EFI_ALLOCATE_ADDRESS */
[KERNEL_PREF_ADDRESS] =
- { GRUB_EFI_MAX_ALLOCATION_ADDRESS, GRUB_EFI_ALLOCATE_MAX_ADDRESS },
+ { KERNEL_MEM, GRUB_EFI_MAX_ALLOCATION_ADDRESS, GRUB_EFI_ALLOCATE_MAX_ADDRESS },
/* If the flag in params is set, this one gets changed to be above 4GB. */
[KERNEL_4G_LIMIT] =
- { GRUB_EFI_MAX_ALLOCATION_ADDRESS, GRUB_EFI_ALLOCATE_MAX_ADDRESS },
+ { KERNEL_MEM, GRUB_EFI_MAX_ALLOCATION_ADDRESS, GRUB_EFI_ALLOCATE_MAX_ADDRESS },
/* this one is always below 4GB, which we still *prefer* even if the flag
* is set. */
[KERNEL_NO_LIMIT] =
- { GRUB_EFI_MAX_ALLOCATION_ADDRESS, GRUB_EFI_ALLOCATE_MAX_ADDRESS },
+ { KERNEL_MEM, GRUB_EFI_MAX_ALLOCATION_ADDRESS, GRUB_EFI_ALLOCATE_MAX_ADDRESS },
+ /* this is for the initrd */
+ [INITRD_MAX_ADDRESS] =
+ { INITRD_MEM, GRUB_EFI_MAX_ALLOCATION_ADDRESS, GRUB_EFI_ALLOCATE_MAX_ADDRESS },
{ NO_MEM, 0, 0 }
};
static struct allocation_choice saved_addresses[4];
@@ -95,7 +106,8 @@ kernel_free(void *addr, grub_efi_uintn_t size)
}
static void *
-kernel_alloc(grub_efi_uintn_t size,
+kernel_alloc(kernel_alloc_purpose_t purpose,
+ grub_efi_uintn_t size,
grub_efi_memory_type_t memtype,
const char * const errmsg)
{
@@ -108,6 +120,9 @@ kernel_alloc(grub_efi_uintn_t size,
grub_uint64_t max = max_addresses[i].addr;
grub_efi_uintn_t pages;
+ if (purpose != max_addresses[i].purpose)
+ continue;
+
/*
* When we're *not* loading the kernel, or >4GB allocations aren't
* supported, these entries are basically all the same, so don't re-try
@@ -262,7 +277,8 @@ grub_cmd_initrd (grub_command_t cmd, int argc, char *argv[])
}
}
- initrd_mem = kernel_alloc(size, GRUB_EFI_RUNTIME_SERVICES_DATA,
+ grub_dprintf ("linux", "Trying to allocate initrd mem\n");
+ initrd_mem = kernel_alloc(INITRD_MEM, size, GRUB_EFI_RUNTIME_SERVICES_DATA,
N_("can't allocate initrd"));
if (initrd_mem == NULL)
goto fail;
@@ -440,7 +456,8 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
}
#endif
- params = kernel_alloc (sizeof(*params), GRUB_EFI_RUNTIME_SERVICES_DATA,
+ params = kernel_alloc (KERNEL_MEM, sizeof(*params),
+ GRUB_EFI_RUNTIME_SERVICES_DATA,
"cannot allocate kernel parameters");
if (!params)
goto fail;
@@ -462,7 +479,7 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
grub_dprintf ("linux", "new lh is at %p\n", lh);
grub_dprintf ("linux", "setting up cmdline\n");
- cmdline = kernel_alloc (lh->cmdline_size + 1,
+ cmdline = kernel_alloc (KERNEL_MEM, lh->cmdline_size + 1,
GRUB_EFI_RUNTIME_SERVICES_DATA,
N_("can't allocate cmdline"));
if (!cmdline)
@@ -510,7 +527,9 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
max_addresses[KERNEL_4G_LIMIT].addr = GRUB_EFI_MAX_ALLOCATION_ADDRESS;
max_addresses[KERNEL_NO_LIMIT].addr = GRUB_EFI_MAX_ALLOCATION_ADDRESS;
kernel_size = lh->init_size;
- kernel_mem = kernel_alloc (kernel_size, GRUB_EFI_RUNTIME_SERVICES_CODE,
+ grub_dprintf ("linux", "Trying to allocate kernel mem\n");
+ kernel_mem = kernel_alloc (KERNEL_MEM, kernel_size,
+ GRUB_EFI_RUNTIME_SERVICES_CODE,
N_("can't allocate kernel"));
restore_addresses();
if (!kernel_mem)

View File

@ -0,0 +1,63 @@
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Peter Jones <pjones@redhat.com>
Date: Mon, 1 Aug 2022 13:04:43 -0400
Subject: [PATCH] efi: use EFI_LOADER_(CODE|DATA) for kernel and initrd
allocations
At some point due to an erroneous kernel warning, we switched kernel and
initramfs to being loaded in EFI_RUNTIME_SERVICES_CODE and
EFI_RUNTIME_SERVICES_DATA memory pools. This doesn't appear to be
correct according to the spec, and that kernel warning has gone away.
This patch puts them back in EFI_LOADER_CODE and EFI_LOADER_DATA
allocations, respectively.
Resolves: rhbz#2108456
Signed-off-by: Peter Jones <pjones@redhat.com>
(cherry picked from commit 35b5d5fa47bc394c76022e6595b173e68f53225e)
(cherry picked from commit 66e1c922b40957fca488435e06a2f875a219844b)
---
grub-core/loader/i386/efi/linux.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/grub-core/loader/i386/efi/linux.c b/grub-core/loader/i386/efi/linux.c
index 09e7596064..4d39023792 100644
--- a/grub-core/loader/i386/efi/linux.c
+++ b/grub-core/loader/i386/efi/linux.c
@@ -278,7 +278,7 @@ grub_cmd_initrd (grub_command_t cmd, int argc, char *argv[])
}
grub_dprintf ("linux", "Trying to allocate initrd mem\n");
- initrd_mem = kernel_alloc(INITRD_MEM, size, GRUB_EFI_RUNTIME_SERVICES_DATA,
+ initrd_mem = kernel_alloc(INITRD_MEM, size, GRUB_EFI_LOADER_DATA,
N_("can't allocate initrd"));
if (initrd_mem == NULL)
goto fail;
@@ -457,7 +457,7 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
#endif
params = kernel_alloc (KERNEL_MEM, sizeof(*params),
- GRUB_EFI_RUNTIME_SERVICES_DATA,
+ GRUB_EFI_LOADER_DATA,
"cannot allocate kernel parameters");
if (!params)
goto fail;
@@ -480,7 +480,7 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
grub_dprintf ("linux", "setting up cmdline\n");
cmdline = kernel_alloc (KERNEL_MEM, lh->cmdline_size + 1,
- GRUB_EFI_RUNTIME_SERVICES_DATA,
+ GRUB_EFI_LOADER_DATA,
N_("can't allocate cmdline"));
if (!cmdline)
goto fail;
@@ -529,7 +529,7 @@ grub_cmd_linux (grub_command_t cmd __attribute__ ((unused)),
kernel_size = lh->init_size;
grub_dprintf ("linux", "Trying to allocate kernel mem\n");
kernel_mem = kernel_alloc (KERNEL_MEM, kernel_size,
- GRUB_EFI_RUNTIME_SERVICES_CODE,
+ GRUB_EFI_LOADER_CODE,
N_("can't allocate kernel"));
restore_addresses();
if (!kernel_mem)

View File

@ -0,0 +1,72 @@
From 0000000000000000000000000000000000000000 Mon Sep 17 00:00:00 2001
From: Diego Domingos <diegodo@linux.vnet.ibm.com>
Date: Thu, 25 Aug 2022 11:37:56 -0400
Subject: [PATCH] ieee1275: implement vec5 for cas negotiation
As a legacy support, if the vector 5 is not implemented, Power
Hypervisor will consider the max CPUs as 64 instead 256 currently
supported during client-architecture-support negotiation.
This patch implements the vector 5 and set the MAX CPUs to 256 while
setting the others values to 0 (default).
Signed-off-by: Diego Domingos <diegodo@linux.vnet.ibm.com>
Signed-off-by: Robbie Harwood <rharwood@redhat.com>
(cherry picked from commit f735c65b6da8a9d4251242b37774e1a517511253)
(cherry picked from commit 1639f43b2db4ac405ac2a92e50ed4cff351c3baa)
---
grub-core/kern/ieee1275/init.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/grub-core/kern/ieee1275/init.c b/grub-core/kern/ieee1275/init.c
index 1414695cc6..37f3098c39 100644
--- a/grub-core/kern/ieee1275/init.c
+++ b/grub-core/kern/ieee1275/init.c
@@ -307,6 +307,18 @@ struct option_vector2 {
grub_uint8_t max_pft_size;
} __attribute__((packed));
+struct option_vector5 {
+ grub_uint8_t byte1;
+ grub_uint8_t byte2;
+ grub_uint8_t byte3;
+ grub_uint8_t cmo;
+ grub_uint8_t associativity;
+ grub_uint8_t bin_opts;
+ grub_uint8_t micro_checkpoint;
+ grub_uint8_t reserved0;
+ grub_uint32_t max_cpus;
+} __attribute__((packed));
+
struct pvr_entry {
grub_uint32_t mask;
grub_uint32_t entry;
@@ -325,6 +337,8 @@ struct cas_vector {
grub_uint16_t vec3;
grub_uint8_t vec4_size;
grub_uint16_t vec4;
+ grub_uint8_t vec5_size;
+ struct option_vector5 vec5;
} __attribute__((packed));
/* Call ibm,client-architecture-support to try to get more RMA.
@@ -345,7 +359,7 @@ grub_ieee1275_ibm_cas (void)
} args;
struct cas_vector vector = {
.pvr_list = { { 0x00000000, 0xffffffff } }, /* any processor */
- .num_vecs = 4 - 1,
+ .num_vecs = 5 - 1,
.vec1_size = 0,
.vec1 = 0x80, /* ignore */
.vec2_size = 1 + sizeof(struct option_vector2) - 2,
@@ -356,6 +370,10 @@ grub_ieee1275_ibm_cas (void)
.vec3 = 0x00e0, // ask for FP + VMX + DFP but don't halt if unsatisfied
.vec4_size = 2 - 1,
.vec4 = 0x0001, // set required minimum capacity % to the lowest value
+ .vec5_size = 1 + sizeof(struct option_vector5) - 2,
+ .vec5 = {
+ 0, 0, 0, 0, 0, 0, 0, 0, 256
+ }
};
INIT_IEEE1275_COMMON (&args.common, "call-method", 3, 2);

View File

@ -552,3 +552,8 @@ Patch0551: 0551-nx-set-page-permissions-for-loaded-modules.patch
Patch0552: 0552-nx-set-attrs-in-our-kernel-loaders.patch
Patch0553: 0553-nx-set-the-nx-compatible-flag-in-EFI-grub-images.patch
Patch0554: 0554-Fixup-grub_efi_get_variable-type-in-our-loaders.patch
Patch0555: 0555-Make-debug-file-show-which-file-filters-get-run.patch
Patch0556: 0556-efi-use-enumerated-array-positions-for-our-allocatio.patch
Patch0557: 0557-efi-split-allocation-policy-for-kernel-vs-initrd-mem.patch
Patch0558: 0558-efi-use-EFI_LOADER_-CODE-DATA-for-kernel-and-initrd-.patch
Patch0559: 0559-ieee1275-implement-vec5-for-cas-negotiation.patch

View File

@ -7,7 +7,7 @@
Name: grub2
Epoch: 1
Version: 2.02
Release: 138%{?dist}
Release: 142%{?dist}
Summary: Bootloader with support for Linux, Multiboot and more
Group: System Environment/Base
License: GPLv3+
@ -510,6 +510,22 @@ fi
%endif
%changelog
* Thu Sep 08 2022 Robbie Harwood <rharwood@redhat.com> - 2.06-142
- Drop the arena size changes
- Resolves: #2118896
* Thu Aug 25 2022 Robbie Harwood <rharwood@redhat.com> - 2.06-141
- Implement vec5 for cas negotiation
- Resolves: #2117914
* Wed Aug 24 2022 Robbie Harwood <rharwood@redhat.com> - 2.06-140
- Or two, because I forgot the debug patch
- Resolves: #2118896
* Thu Aug 18 2022 Robbie Harwood <rharwood@redhat.com> - 2.06-139
- Kernel allocator fixups (in one pass)
- Resolves: #2118896
* Wed Jul 20 2022 Robbie Harwood <rharwood@redhat.com> - 2.06-138
- Rotate signing keys on ppc64le
- Resolves: #2074762