From: Aditya Garg gargaditya08@live.com
On T2 Macs, the secure boot is handled by the T2 Chip. If enabled, only macOS and Windows are allowed to boot on these machines. Moreover, loading UEFI Secure Boot certificates is not supported on these machines on Linux. An attempt to do so causes a crash 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
As a result of not being able to read or load certificates, secure boot cannot be enabled. This patch prevents querying of these UEFI variables, since these Macs seem to use a non-standard EFI hardware.
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 .../platform_certs/keyring_handler.h | 8 +++++ security/integrity/platform_certs/load_uefi.c | 35 +++++++++++++++++++ 2 files changed, 43 insertions(+)
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..c3393b2b1 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,33 @@ #include "../integrity.h" #include "keyring_handler.h"
+/* + * Apple Macs with T2 Security chip seem to be using a non standard + * implementation of Secure Boot. For Linux to run on these machines + * Secure Boot needs to be turned off, since the T2 Chip manages + * Secure Boot and doesn't allow OS other than macOS or Windows to + * boot. If turned off, an attempt to get certificates causes a crash, + * so we simply prevent doing the same. + */ +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 +166,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;
On Tue, 2022-04-12 at 16:44 +0000, Aditya Garg wrote:
From: Aditya Garg gargaditya08@live.com
On T2 Macs, the secure boot is handled by the T2 Chip. If enabled, only macOS and Windows are allowed to boot on these machines. Moreover, loading UEFI Secure Boot certificates is not supported on these machines on Linux. An attempt to do so causes a crash 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
As a result of not being able to read or load certificates, secure boot cannot be enabled. This patch prevents querying of these UEFI variables, since these Macs seem to use a non-standard EFI hardware.
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 .../platform_certs/keyring_handler.h | 8 +++++ security/integrity/platform_certs/load_uefi.c | 35 +++++++++++++++++++ 2 files changed, 43 insertions(+)
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..c3393b2b1 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,33 @@ #include "../integrity.h" #include "keyring_handler.h" +/*
- Apple Macs with T2 Security chip seem to be using a non standard
- implementation of Secure Boot. For Linux to run on these machines
- Secure Boot needs to be turned off, since the T2 Chip manages
- Secure Boot and doesn't allow OS other than macOS or Windows to
- boot. If turned off, an attempt to get certificates causes a crash,
- so we simply prevent doing the same.
- */
Both the comment here and the patch description above still needs to be improved. Perhaps something along these lines.
Secure boot on Apple Macs with a T2 Security chip cannot read either the EFI variables or the certificates stored in different db's (e.g. db, dbx, MokListXRT). Attempting to read them causes ...
Avoid reading the EFI variables or the certificates stored in different dbs. As a result, without certificates secure boot signature verification fails.
thanks,
Mimi
+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 +166,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;
Both the comment here and the patch description above still needs to be improved. Perhaps something along these lines.
Checkout v5
Secure boot on Apple Macs with a T2 Security chip cannot read either the EFI variables or the certificates stored in different db's (e.g. db, dbx, MokListXRT). Attempting to read them causes ...
Avoid reading the EFI variables or the certificates stored in different dbs. As a result, without certificates secure boot signature verification fails.
thanks,
Mimi
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(+)
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;
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
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
From: Aditya Garg gargaditya08@live.com
On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs:
[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) 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 patch skips reading these UEFI variables and thus prevents the crash.
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 v6 :- Make description more clear .../platform_certs/keyring_handler.h | 8 +++++ security/integrity/platform_certs/load_uefi.c | 33 +++++++++++++++++++ 2 files changed, 41 insertions(+)
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..1a7e7d597 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,31 @@ #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 reading these variables. + */ +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 +164,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;
On Fri, 2022-04-15 at 06:19 +0000, Aditya Garg wrote:
From: Aditya Garg gargaditya08@live.com
On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs:
[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) 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 patch skips reading these UEFI variables and thus prevents the crash.
Instead of "This patch skips reading" say "Avoid reading".
Cc: stable@vger.kernel.org Signed-off-by: Aditya Garg gargaditya08@live.com
After making these minor changes, both above and below, Reviewed-by: Mimi Zohar zohar@linux.ibm.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 v6 :- Make description more clear .../platform_certs/keyring_handler.h | 8 +++++ security/integrity/platform_certs/load_uefi.c | 33 +++++++++++++++++++ 2 files changed, 41 insertions(+)
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..1a7e7d597 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,31 @@ #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 reading these variables.
- */
+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 +164,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");
Replace "Getting" with "Reading".
thanks,
Mimi
return false;- }
if (!efi_rt_services_supported(EFI_RT_SUPPORTED_GET_VARIABLE)) return false;
After making these minor changes, both above and below, Reviewed-by: Mimi Zohar zohar@linux.ibm.com
Sending a v7
From: Aditya Garg gargaditya08@live.com
On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs:
[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) 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
So we avoid reading these UEFI variables and thus prevent the crash.
Cc: stable@vger.kernel.org Signed-off-by: Aditya Garg gargaditya08@live.com Reviewed-by: Mimi Zohar zohar@linux.ibm.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 v6 :- Make description more clear v7 :- Minor changes and add reviewed by .../platform_certs/keyring_handler.h | 8 +++++ security/integrity/platform_certs/load_uefi.c | 33 +++++++++++++++++++ 2 files changed, 41 insertions(+)
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..1a7e7d597 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,31 @@ #include "../integrity.h" #include "keyring_handler.h"
+/* + * On T2 Macs 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 reading + * these variables. + */ +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 +164,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("Reading 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;
From: Aditya Garg gargaditya08@live.com
On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs:
[Firmware Bug]: Page fault caused by firmware at PA: 0xffffb1edc0068000 WARNING: CPU: 3 PID: 104 at arch/x86/platform/efi/quirks.c:735 efi_crash_gracefully_on_page_fault+0x50/0xf0 (Removed some logs from here) 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
So we avoid reading these UEFI variables and thus prevent the crash.
Cc: stable@vger.kernel.org Signed-off-by: Aditya Garg gargaditya08@live.com Reviewed-by: Mimi Zohar zohar@linux.ibm.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 v6 :- Make description more clear v7 :- Minor changes and add reviewed by .../platform_certs/keyring_handler.h | 8 +++++ security/integrity/platform_certs/load_uefi.c | 33 +++++++++++++++++++ 2 files changed, 41 insertions(+)
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..1a7e7d597 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,31 @@ #include "../integrity.h" #include "keyring_handler.h"
+/* + * On T2 Macs 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 reading + * these variables. + */ +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 +164,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("Reading 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;
Hi Aditya,
On Fri, 2022-04-15 at 17:02 +0000, Aditya Garg wrote:
From: Aditya Garg gargaditya08@live.com
On Apple T2 Macs, when Linux attempts to read the db and dbx efi variables at early boot to load UEFI Secure Boot certificates, a page fault occurs in Apple firmware code and EFI runtime services are disabled with the following logs:
Are there directions for installing Linux on a Mac with Apple firmware code? Are you dual booting Linux and Mac, or just Linux? While in secure boot mode, without being able to read the keys to verify the kernel image signature, the signature verification should fail.
Has anyone else tested this patch?
thanks,
Mimi
Are there directions for installing Linux on a Mac with Apple firmware code?
Well, directions of installing Linux on an Intel based Mac, which includes the T2 Macs is the same as on a normal PC.
Though, in case of T2 Macs, we for now need to use customised ISOs, since some drivers and patches to support T2 Macs are yet to be upstreamed.
An example of installing Ubuntu can be read here on https://wiki.t2linux.org/distributions/ubuntu/installation/
Talking about the official ISOs, for many distros, since CONFIG_LOAD_UEFI_KEYS is not enabled in their kernel config, we can install Linux using them, but they still lack many drivers required, since they are yet to be upstreamed. So the installation doesn’t work efficiently and we have to manually install custom kernels having those patches.
In some distros like Ubuntu, they have CONFIG_LOAD_UEFI_KEYS enabled in their kernel config. In this case the crash as mentioned in the patch description occurs and EFI Runtime Services get disabled. Since installing GRUB requires access to NVRAM, the installation fails with official ISOs in this case. Thus, a custom ISO, with this patch incorporated in being used for now for users interested in Ubuntu on T2 Macs.
Are you dual booting Linux and Mac, or just Linux?
I don’t think it actually matters, though in most of the cases, we dual boot macOS and Linux, but I do have seen cases who wipe out their macOS completely. But this doesn't affect the Secure Boot policy of these machines.
While in secure boot mode, without being able to read the keys to verify the kernel image signature, the signature verification should fail.
If I enable secure boot in the BIOS settings (macOS Recovery), Apple’s firmware won't allow even the boot loader like GRUB, rEFInd to boot. It shall only allow Windows and macOS to Boot. You could see https://support.apple.com/en-in/HT208198 for more details.
Has anyone else tested this patch?
I work as a maintainer for Ubuntu for T2 Linux community and I have this patch incorporated in the kernels used for Ubuntu ISOs customised for T2 Macs, and thus have many users who have used the ISO and have a successful installation. Thus, there are many users who have tested this patch and are actually using it right now. We also need the have the NVRAM writes enabled so as to unlock the iGPU in Macs with both Intel and AMD GPU, and with this patch, we have been successfully able to unlock it,
I hope I could answer your questions
Regards Aditya
On Fri, 2022-05-13 at 18:31 +0000, Aditya Garg wrote:
Are there directions for installing Linux on a Mac with Apple firmware code?
Well, directions of installing Linux on an Intel based Mac, which includes the T2 Macs is the same as on a normal PC.
Though, in case of T2 Macs, we for now need to use customised ISOs, since some drivers and patches to support T2 Macs are yet to be upstreamed.
An example of installing Ubuntu can be read here on https://wiki.t2linux.org/distributions/ubuntu/installation/
Talking about the official ISOs, for many distros, since CONFIG_LOAD_UEFI_KEYS is not enabled in their kernel config, we can install Linux using them, but they still lack many drivers required, since they are yet to be upstreamed. So the installation doesn’t work efficiently and we have to manually install custom kernels having those patches.
In some distros like Ubuntu, they have CONFIG_LOAD_UEFI_KEYS enabled in their kernel config. In this case the crash as mentioned in the patch description occurs and EFI Runtime Services get disabled. Since installing GRUB requires access to NVRAM, the installation fails with official ISOs in this case. Thus, a custom ISO, with this patch incorporated in being used for now for users interested in Ubuntu on T2 Macs.
Are you dual booting Linux and Mac, or just Linux?
I don’t think it actually matters, though in most of the cases, we dual boot macOS and Linux, but I do have seen cases who wipe out their macOS completely. But this doesn't affect the Secure Boot policy of these machines.
While in secure boot mode, without being able to read the keys to verify the kernel image signature, the signature verification should fail.
If I enable secure boot in the BIOS settings (macOS Recovery), Apple’s firmware won't allow even the boot loader like GRUB, rEFInd to boot. It shall only allow Windows and macOS to Boot. You could see https://support.apple.com/en-in/HT208198 for more details.
Has anyone else tested this patch?
I work as a maintainer for Ubuntu for T2 Linux community and I have this patch incorporated in the kernels used for Ubuntu ISOs customised for T2 Macs, and thus have many users who have used the ISO and have a successful installation. Thus, there are many users who have tested this patch and are actually using it right now. We also need the have the NVRAM writes enabled so as to unlock the iGPU in Macs with both Intel and AMD GPU, and with this patch, we have been successfully able to unlock it,
I hope I could answer your questions
Yes, thank you. Based on the link above and https://wiki.t2linux.org/guides/kernel/, I was able boot a kernel with/without this patch.
The patch is now queued in the next-integrity-testing branch.
thanks,
Mimi
linux-stable-mirror@lists.linaro.org
-
Aditya Garg -
Mimi Zohar