Verified Commit 44e59c48 authored by Sherif Nagy's avatar Sherif Nagy
Browse files

cherry-pick git format-patch 15.4..9f973e4e95b1136b8c98051dbbdb1773072cc998

parent 617f384a
From 822d07ad4f07ef66fe447a130e1027c88d02a394 Mon Sep 17 00:00:00 2001
From: Adam Williamson <awilliam@redhat.com>
Date: Thu, 8 Apr 2021 22:39:02 -0700
Subject: [PATCH 1/7] Fix handling of ignore_db and user_insecure_mode
In 65be350308783a8ef537246c8ad0545b4e6ad069, import_mok_state() is split
up into a function that manages the whole mok state, and one that
handles the state machine for an individual state variable.
Unfortunately, the code that initializes the global ignore_db and
user_insecure_mode was copied from import_mok_state() into the new
import_one_mok_state() function, and thus re-initializes that state each
time it processes a MoK state variable, before even assessing if that
variable is set. As a result, we never honor either flag, and the
machine owner cannot disable trusting the system firmware's db/dbx
databases or disable validation altogether.
This patch removes the extra re-initialization, allowing those variables
to be set properly.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
---
mok.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/mok.c b/mok.c
index 5ad9072..9e37d6a 100644
--- a/mok.c
+++ b/mok.c
@@ -888,9 +888,6 @@ EFI_STATUS import_one_mok_state(struct mok_state_variable *v,
EFI_STATUS ret = EFI_SUCCESS;
EFI_STATUS efi_status;
- user_insecure_mode = 0;
- ignore_db = 0;
-
UINT32 attrs = 0;
BOOLEAN delete = FALSE;
--
2.32.0
From f4a1ca3a22c5270f6c5f4764e4f69fce958d9db6 Mon Sep 17 00:00:00 2001
From: Sherif Nagy <sherif@rockylinux.org>
Date: Mon, 19 Jul 2021 15:51:13 +0100
Subject: [PATCH 2/2] cherry-pick git format-patch
15.4..9f973e4e95b1136b8c98051dbbdb1773072cc998
---
SPECS/shim-unsigned-x64.spec | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/SPECS/shim-unsigned-x64.spec b/SPECS/shim-unsigned-x64.spec
index 4696adc..33a1a48 100644
--- a/SPECS/shim-unsigned-x64.spec
+++ b/SPECS/shim-unsigned-x64.spec
@@ -36,7 +36,13 @@ Source100: shim-find-debuginfo.sh
Source90000: sbat.rocky.csv
Source90001: rocky-root-ca.der
-Patch0001: 0001-Fix-a-broken-file-header-on-ia32.patch
+Patch0001: 0001-Fix-handling-of-ignore_db-and-user_insecure_mode.patch
+Patch0002: 0002-shim-15.4-branch-update-.gitmodules-to-point-at-shim.patch
+Patch0003: 0003-Fix-a-broken-file-header-on-ia32.patch
+Patch0004: 0004-mok-allocate-MOK-config-table-as-BootServicesData.patch
+Patch0005: 0005-Don-t-call-QueryVariableInfo-on-EFI-1.10-machines.patch
+Patch0006: 0006-Post-process-our-PE-to-be-sure.patch
+Patch0007: 0007-Relax-the-check-for-import_mok_state.patch
BuildRequires: gcc make
BuildRequires: elfutils-libelf-devel
--
2.32.0
From a0f701501f73a0aabd1ef8d568183d05611b0a52 Mon Sep 17 00:00:00 2001
From: Peter Jones <pjones@redhat.com>
Date: Wed, 31 Mar 2021 09:44:53 -0400
Subject: [PATCH 2/7] shim-15.4 branch: update .gitmodules to point at
shim-15.4 in gnu-efi
This is purely superficial, as the commit points at the shim-15.4 branch
already, but some people have found it confusing.
This fixes issue #356.
Signed-off-by: Peter Jones <pjones@redhat.com>
---
.gitmodules | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/.gitmodules b/.gitmodules
index 2ad8bb8..8fc92a7 100644
--- a/.gitmodules
+++ b/.gitmodules
@@ -1,4 +1,4 @@
[submodule "gnu-efi"]
path = gnu-efi
url = https://github.com/rhboot/gnu-efi.git
- branch = shim-15.3
+ branch = shim-15.4
--
2.32.0
From 5b3ca0d2f7b5f425ba1a14db8ce98b8d95a2f89f Mon Sep 17 00:00:00 2001
From: Peter Jones <pjones@redhat.com>
Date: Wed, 31 Mar 2021 14:54:52 -0400
Subject: [PATCH 3/7] Fix a broken file header on ia32
Commit c6281c6a195edee61185 needs to have included a ". = ALIGN(4096)"
directive before .reloc, but fails to do so.
As a result, binutils, which does not care about the actual binary
format's constraints in any way, does not enforce the section alignment,
and it will not load.
Signed-off-by: Peter Jones <pjones@redhat.com>
---
elf_ia32_efi.lds | 1 +
1 file changed, 1 insertion(+)
diff --git a/elf_ia32_efi.lds b/elf_ia32_efi.lds
index 742e0a4..497a3a1 100644
--- a/elf_ia32_efi.lds
+++ b/elf_ia32_efi.lds
@@ -15,6 +15,7 @@ SECTIONS
*(.gnu.linkonce.t.*)
_etext = .;
}
+ . = ALIGN(4096);
.reloc :
{
*(.reloc)
--
2.32.0
From 4068fd42c891ea6ebdec056f461babc6e4048844 Mon Sep 17 00:00:00 2001
From: Gary Lin <glin@suse.com>
Date: Thu, 8 Apr 2021 16:23:03 +0800
Subject: [PATCH 4/7] mok: allocate MOK config table as BootServicesData
Linux kernel is picky when reserving the memory for x86 and it only
expects BootServicesData:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/x86/platform/efi/quirks.c?h=v5.11#n254
Otherwise, the following error would show during system boot:
Apr 07 12:31:56.743925 localhost kernel: efi: Failed to lookup EFI memory descriptor for 0x000000003dcf8000
Although BootServicesData would be reclaimed after ExitBootService(),
linux kernel reserves MOK config table when it detects the existence of
the table, so it's fine to allocate the table as BootServicesData.
Signed-off-by: Gary Lin <glin@suse.com>
---
mok.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mok.c b/mok.c
index 9e37d6a..9b8fc2b 100644
--- a/mok.c
+++ b/mok.c
@@ -999,7 +999,7 @@ EFI_STATUS import_mok_state(EFI_HANDLE image_handle)
npages = ALIGN_VALUE(config_sz, PAGE_SIZE) >> EFI_PAGE_SHIFT;
config_table = NULL;
efi_status = gBS->AllocatePages(AllocateAnyPages,
- EfiRuntimeServicesData,
+ EfiBootServicesData,
npages,
(EFI_PHYSICAL_ADDRESS *)&config_table);
if (EFI_ERROR(efi_status) || !config_table) {
--
2.32.0
From 493bd940e5c6e28e673034687de7adef9529efff Mon Sep 17 00:00:00 2001
From: Peter Jones <pjones@redhat.com>
Date: Sat, 10 Apr 2021 16:05:23 -0400
Subject: [PATCH 5/7] Don't call QueryVariableInfo() on EFI 1.10 machines
The EFI 1.10 spec (and presumably earlier revisions as well) didn't have
RT->QueryVariableInfo(), and on Chris Murphy's MacBookPro8,2 , that
memory appears to be initialized randomly.
This patch changes it to not call RT->QueryVariableInfo() if the
EFI_RUNTIME_SERVICES table's major revision is less than two, and
assumes our maximum variable size is 1024 in that case.
Signed-off-by: Peter Jones <pjones@redhat.com>
---
mok.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/mok.c b/mok.c
index 9b8fc2b..beac0ff 100644
--- a/mok.c
+++ b/mok.c
@@ -261,6 +261,9 @@ static const uint8_t null_sha256[32] = { 0, };
typedef UINTN SIZE_T;
+#define EFI_MAJOR_VERSION(tablep) ((UINT16)((((tablep)->Hdr.Revision) >> 16) & 0xfffful))
+#define EFI_MINOR_VERSION(tablep) ((UINT16)(((tablep)->Hdr.Revision) & 0xfffful))
+
static EFI_STATUS
get_max_var_sz(UINT32 attrs, SIZE_T *max_var_szp)
{
@@ -270,11 +273,21 @@ get_max_var_sz(UINT32 attrs, SIZE_T *max_var_szp)
uint64_t max_var_sz = 0;
*max_var_szp = 0;
- efi_status = gRT->QueryVariableInfo(attrs, &max_storage_sz,
- &remaining_sz, &max_var_sz);
- if (EFI_ERROR(efi_status)) {
- perror(L"Could not get variable storage info: %r\n", efi_status);
- return efi_status;
+ if (EFI_MAJOR_VERSION(gRT) < 2) {
+ dprint(L"EFI %d.%d; no RT->QueryVariableInfo(). Using 1024!\n",
+ EFI_MAJOR_VERSION(gRT), EFI_MINOR_VERSION(gRT));
+ max_var_sz = remaining_sz = max_storage_sz = 1024;
+ efi_status = EFI_SUCCESS;
+ } else {
+ dprint(L"calling RT->QueryVariableInfo() at 0x%lx\n",
+ gRT->QueryVariableInfo);
+ efi_status = gRT->QueryVariableInfo(attrs, &max_storage_sz,
+ &remaining_sz, &max_var_sz);
+ if (EFI_ERROR(efi_status)) {
+ perror(L"Could not get variable storage info: %r\n",
+ efi_status);
+ return efi_status;
+ }
}
/*
--
2.32.0
This diff is collapsed.
From 9f973e4e95b1136b8c98051dbbdb1773072cc998 Mon Sep 17 00:00:00 2001
From: Gary Lin <glin@suse.com>
Date: Tue, 11 May 2021 10:41:43 +0800
Subject: [PATCH 7/7] Relax the check for import_mok_state()
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
An openSUSE user reported(*) that shim 15.4 failed to boot the system
with the following message:
"Could not create MokListXRT: Out of Resources"
In the beginning, I thought it's caused by the growing size of
vendor-dbx. However, we found the following messages after set
SHIM_VERBOSE:
max_var_sz:8000 remaining_sz:85EC max_storage_sz:9000
SetVariable(“MokListXRT”, ... varsz=0x1404) = Out of Resources
Even though the firmware claimed the remaining storage size is 0x85EC
and the maximum variable size is 0x8000, it still rejected MokListXRT
with size 0x1404. It seems that the return values from QueryVariableInfo()
are not reliable. Since this firmware didn't really support Secure Boot,
the variable mirroring is not so critical, so we can just accept the
failure of import_mok_state() and continue boot.
(*) https://bugzilla.suse.com/show_bug.cgi?id=1185261
Signed-off-by: Gary Lin <glin@suse.com>
---
shim.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/shim.c b/shim.c
index c5cfbb8..40e4894 100644
--- a/shim.c
+++ b/shim.c
@@ -1973,10 +1973,13 @@ efi_main (EFI_HANDLE passed_image_handle, EFI_SYSTEM_TABLE *passed_systab)
* boot-services-only state variables are what we think they are.
*/
efi_status = import_mok_state(image_handle);
- if (!secure_mode() && efi_status == EFI_INVALID_PARAMETER) {
+ if (!secure_mode() &&
+ (efi_status == EFI_INVALID_PARAMETER ||
+ efi_status == EFI_OUT_OF_RESOURCES)) {
/*
* Make copy failures fatal only if secure_mode is enabled, or
- * the error was anything else than EFI_INVALID_PARAMETER.
+ * the error was anything else than EFI_INVALID_PARAMETER or
+ * EFI_OUT_OF_RESOURCES.
* There are non-secureboot firmware implementations that don't
* reserve enough EFI variable memory to fit the variable.
*/
--
2.32.0
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment