diff mbox series

[v5] efi: Do not import certificates from UEFI Secure Boot for T2 Macs

Message ID E9C28706-2546-40BF-B32C-66A047BE9EFB@live.com (mailing list archive)
State New, archived
Headers show
Series [v5] efi: Do not import certificates from UEFI Secure Boot for T2 Macs | expand

Commit Message

Aditya Garg April 13, 2022, 2:04 p.m. UTC
From: Aditya Garg <gargaditya08@live.com>

On Apple T2 Macs, when Linux reads the db and dbx efi variables to load
UEFI Secure Boot certificates, a page fault occurs in Apple firmware
code and EFI services are disabled with the following logs:

Call Trace:
 <TASK>
 page_fault_oops+0x4f/0x2c0
 ? search_bpf_extables+0x6b/0x80
 ? search_module_extables+0x50/0x80
 ? search_exception_tables+0x5b/0x60
 kernelmode_fixup_or_oops+0x9e/0x110
 __bad_area_nosemaphore+0x155/0x190
 bad_area_nosemaphore+0x16/0x20
 do_kern_addr_fault+0x8c/0xa0
 exc_page_fault+0xd8/0x180
 asm_exc_page_fault+0x1e/0x30
(Removed some logs from here)
 ? __efi_call+0x28/0x30
 ? switch_mm+0x20/0x30
 ? efi_call_rts+0x19a/0x8e0
 ? process_one_work+0x222/0x3f0
 ? worker_thread+0x4a/0x3d0
 ? kthread+0x17a/0x1a0
 ? process_one_work+0x3f0/0x3f0
 ? set_kthread_struct+0x40/0x40
 ? ret_from_fork+0x22/0x30
 </TASK>
---[ end trace 1f82023595a5927f ]---
efi: Froze efi_rts_wq and disabled EFI Runtime Services
integrity: Couldn't get size: 0x8000000000000015
integrity: MODSIGN: Couldn't get UEFI db list
efi: EFI Runtime Services are disabled!
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get UEFI dbx list
integrity: Couldn't get size: 0x8000000000000015
integrity: Couldn't get mokx list
integrity: Couldn't get size: 0x80000000

This also occurs when some other variables are read (see examples below,
there are many more), but only when these variables are read at an early
stage like db and dbx are to load UEFI certs.

BridgeOSBootSessionUUID-4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14
KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c

On these Macs, we skip reading the EFI variables for the UEFI certificates.
As a result without certificates, secure boot signature verification fails.
As these Macs have a non-standard implementation of secure boot that only
uses Apple's and Microsoft's keys (users can't add their own), securely
booting Linux was never supported on this hardware, so skipping it
shouldn't cause a regression.

Cc: stable@vger.kernel.org
Signed-off-by: Aditya Garg <gargaditya08@live.com>
---
v2 :- Reduce code size of the table.
v3 :- Close the brackets which were left open by mistake.
v4 :- Fix comment style issues, remove blank spaces and limit use of dmi_first_match()
v4 RESEND :- Add stable to cc
v5 :- Rewrite the description
 .../platform_certs/keyring_handler.h          |  8 ++++
 security/integrity/platform_certs/load_uefi.c | 37 +++++++++++++++++++
 2 files changed, 45 insertions(+)

Comments

Mimi Zohar April 14, 2022, 1:30 p.m. UTC | #1
On Wed, 2022-04-13 at 14:04 +0000, Aditya Garg wrote:
> From: Aditya Garg <gargaditya08@live.com>
> 
> On Apple T2 Macs, when Linux reads the db and dbx efi variables to load
> UEFI Secure Boot certificates, a page fault occurs in Apple firmware
> code and EFI services are disabled with the following logs:
> 
> Call Trace:
>  <TASK>
>  page_fault_oops+0x4f/0x2c0
>  ? search_bpf_extables+0x6b/0x80
>  ? search_module_extables+0x50/0x80
>  ? search_exception_tables+0x5b/0x60
>  kernelmode_fixup_or_oops+0x9e/0x110
>  __bad_area_nosemaphore+0x155/0x190
>  bad_area_nosemaphore+0x16/0x20
>  do_kern_addr_fault+0x8c/0xa0
>  exc_page_fault+0xd8/0x180
>  asm_exc_page_fault+0x1e/0x30
> (Removed some logs from here)
>  ? __efi_call+0x28/0x30
>  ? switch_mm+0x20/0x30
>  ? efi_call_rts+0x19a/0x8e0
>  ? process_one_work+0x222/0x3f0
>  ? worker_thread+0x4a/0x3d0
>  ? kthread+0x17a/0x1a0
>  ? process_one_work+0x3f0/0x3f0
>  ? set_kthread_struct+0x40/0x40
>  ? ret_from_fork+0x22/0x30
>  </TASK>
> ---[ end trace 1f82023595a5927f ]---
> efi: Froze efi_rts_wq and disabled EFI Runtime Services
> integrity: Couldn't get size: 0x8000000000000015
> integrity: MODSIGN: Couldn't get UEFI db list
> efi: EFI Runtime Services are disabled!
> integrity: Couldn't get size: 0x8000000000000015
> integrity: Couldn't get UEFI dbx list
> integrity: Couldn't get size: 0x8000000000000015
> integrity: Couldn't get mokx list
> integrity: Couldn't get size: 0x80000000
> 
> This also occurs when some other variables are read (see examples below,
> there are many more), but only when these variables are read at an early
> stage like db and dbx are to load UEFI certs.
> 
> BridgeOSBootSessionUUID-4d1ede05-38c7-4a6a-9cc6-4bcca8b38c14
> KEK-8be4df61-93ca-11d2-aa0d-00e098032b8c
> 
> On these Macs, we skip reading the EFI variables for the UEFI certificates.
> As a result without certificates, secure boot signature verification fails.
> As these Macs have a non-standard implementation of secure boot that only
> uses Apple's and Microsoft's keys (users can't add their own), securely
> booting Linux was never supported on this hardware, so skipping it
> shouldn't cause a regression.

Based on your explanation, there seems to be two issues - inability to
read EFI variables, "users can't add their own" keys.  Neither of which
mean "a non-standard implementation of secure boot".  Please fix the
"cause" and "affect" in the patch description and comments.

thanks,

Mimi
Aditya Garg April 15, 2022, 6:17 a.m. UTC | #2
> Based on your explanation, there seems to be two issues - inability to
> read EFI variables, "users can't add their own" keys. Neither of which
> mean "a non-standard implementation of secure boot". Please fix the
> "cause" and "affect" in the patch description and comments.

Sending a v6

Also, I guess I should just remove the secure boot bit, cause secure boot, though kinda related, doesn’t have much role here.

The “cause” is reading of specific UEFI variables, like db, dbx etc, and the “affect” being crashing of EFI Runtime Services.

The “fix”, simply prevent reading of these variables

The role of secure boot (Which I have removed in the description of v6, cause its not of much significance in regard to this patch) :-

Loading of these certificates is required to “boot securely”. By disabling loading of these certificates, we are technically preventing booting Linux “securely” on these machines. But, this shouldn’t be a matter to worry about. The reason being, Apple doesn’t allow anything other that macOS or Windows to boot if Secure Boot in turned on, on these Macs, making it impossible to boot Linux with secure boot on, unless Apple itself updates the firmware on the T2 Chip, to support Linux as well, which is highly unlikely.
> 
> thanks,
> 
> Mimi
diff mbox series

Patch

diff --git a/security/integrity/platform_certs/keyring_handler.h b/security/integrity/platform_certs/keyring_handler.h
index 284558f30..212d894a8 100644
--- a/security/integrity/platform_certs/keyring_handler.h
+++ b/security/integrity/platform_certs/keyring_handler.h
@@ -35,3 +35,11 @@  efi_element_handler_t get_handler_for_mok(const efi_guid_t *sig_type);
 efi_element_handler_t get_handler_for_dbx(const efi_guid_t *sig_type);
 
 #endif
+
+#ifndef UEFI_QUIRK_SKIP_CERT
+#define UEFI_QUIRK_SKIP_CERT(vendor, product) \
+		 .matches = { \
+			DMI_MATCH(DMI_BOARD_VENDOR, vendor), \
+			DMI_MATCH(DMI_PRODUCT_NAME, product), \
+		},
+#endif
diff --git a/security/integrity/platform_certs/load_uefi.c b/security/integrity/platform_certs/load_uefi.c
index 5f45c3c07..bbddc7c7c 100644
--- a/security/integrity/platform_certs/load_uefi.c
+++ b/security/integrity/platform_certs/load_uefi.c
@@ -3,6 +3,7 @@ 
 #include <linux/kernel.h>
 #include <linux/sched.h>
 #include <linux/cred.h>
+#include <linux/dmi.h>
 #include <linux/err.h>
 #include <linux/efi.h>
 #include <linux/slab.h>
@@ -12,6 +13,35 @@ 
 #include "../integrity.h"
 #include "keyring_handler.h"
 
+/*
+ * On T2 Macs reading the reading the db and dbx efi variables to load UEFI
+ * Secure Boot certificates causes occurrence of a page fault in Apple's
+ * firmware and a crash disabling EFI runtime services. The following quirk
+ * skips loading of these certificates.
+ *
+ * As these Macs have a non-standard implementation of secure boot that only uses
+ * Apple's and Microsoft's keys, booting Linux securely was never supported on
+ * this hardware, so these quirks shouldn't cause a regression.
+ */
+static const struct dmi_system_id uefi_skip_cert[] = {
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro15,1") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro15,2") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro15,3") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro15,4") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro16,1") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro16,2") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro16,3") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookPro16,4") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookAir8,1") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookAir8,2") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacBookAir9,1") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacMini8,1") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "MacPro7,1") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "iMac20,1") },
+	{ UEFI_QUIRK_SKIP_CERT("Apple Inc.", "iMac20,2") },
+	{ }
+};
+
 /*
  * Look to see if a UEFI variable called MokIgnoreDB exists and return true if
  * it does.
@@ -138,6 +168,13 @@  static int __init load_uefi_certs(void)
 	unsigned long dbsize = 0, dbxsize = 0, mokxsize = 0;
 	efi_status_t status;
 	int rc = 0;
+	const struct dmi_system_id *dmi_id;
+
+	dmi_id = dmi_first_match(uefi_skip_cert);
+	if (dmi_id) {
+		pr_err("Getting UEFI Secure Boot Certs is not supported on T2 Macs.\n");
+		return false;
+	}
 
 	if (!efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE))
 		return false;