kernel/linux.git/security/integrity/platform_certs, branch v5.18.16

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

2022-06-09T08:30:41+00:00

commit 155ca952c7ca19aa32ecfb7373a32bbc2e1ec6eb upstream. 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: 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 ---[ 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 Reviewed-by: Mimi Zohar Signed-off-by: Mimi Zohar Signed-off-by: Greg Kroah-Hartman

integrity: Only use machine keyring when uefi_check_trust_mok_keys is true

2022-03-08T11:55:52+00:00

With the introduction of uefi_check_trust_mok_keys, it signifies the end- user wants to trust the machine keyring as trusted keys. If they have chosen to trust the machine keyring, load the qualifying keys into it during boot, then link it to the secondary keyring . If the user has not chosen to trust the machine keyring, it will be empty and not linked to the secondary keyring. Signed-off-by: Eric Snowberg Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

integrity: Trust MOK keys if MokListTrustedRT found

2022-03-08T11:55:52+00:00

A new Machine Owner Key (MOK) variable called MokListTrustedRT has been introduced in shim. When this UEFI variable is set, it indicates the end-user has made the decision themselves that they wish to trust MOK keys within the Linux trust boundary. It is not an error if this variable does not exist. If it does not exist, the MOK keys should not be trusted within the kernel. Signed-off-by: Eric Snowberg Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

integrity: add new keyring handler for mok keys

2022-03-08T11:55:52+00:00

Currently both Secure Boot DB and Machine Owner Keys (MOK) go through the same keyring handler (get_handler_for_db). With the addition of the new machine keyring, the end-user may choose to trust MOK keys. Introduce a new keyring handler specific for MOK keys. If MOK keys are trusted by the end-user, use the new keyring handler instead. Signed-off-by: Eric Snowberg Reviewed-by: Mimi Zohar Reviewed-by: Jarkko Sakkinen Tested-by: Mimi Zohar Signed-off-by: Jarkko Sakkinen

integrity: Introduce a Linux keyring called machine

2022-03-08T11:55:52+00:00

Many UEFI Linux distributions boot using shim. The UEFI shim provides what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure Boot DB and MOK keys to validate the next step in the boot chain. The MOK facility can be used to import user generated keys. These keys can be used to sign an end-users development kernel build. When Linux boots, both UEFI Secure Boot DB and MOK keys get loaded in the Linux .platform keyring. Define a new Linux keyring called machine. This keyring shall contain just MOK keys and not the remaining keys in the platform keyring. This new machine keyring will be used in follow on patches. Unlike keys in the platform keyring, keys contained in the machine keyring will be trusted within the kernel if the end-user has chosen to do so. Signed-off-by: Eric Snowberg Tested-by: Jarkko Sakkinen Tested-by: Mimi Zohar Reviewed-by: Jarkko Sakkinen Signed-off-by: Jarkko Sakkinen

integrity: Fix warning about missing prototypes

2022-03-08T11:55:52+00:00

make W=1 generates the following warning in keyring_handler.c security/integrity/platform_certs/keyring_handler.c:71:30: warning: no previous prototype for get_handler_for_db [-Wmissing-prototypes] __init efi_element_handler_t get_handler_for_db(const efi_guid_t *sig_type) ^~~~~~~~~~~~~~~~~~ security/integrity/platform_certs/keyring_handler.c:82:30: warning: no previous prototype for get_handler_for_dbx [-Wmissing-prototypes] __init efi_element_handler_t get_handler_for_dbx(const efi_guid_t *sig_type) ^~~~~~~~~~~~~~~~~~~ Add the missing prototypes by including keyring_handler.h. Reported-by: kernel test robot Signed-off-by: Eric Snowberg Reviewed-by: Mimi Zohar Reviewed-by: Jarkko Sakkinen Tested-by: Mimi Zohar Signed-off-by: Jarkko Sakkinen

integrity: Do not load MOK and MOKx when secure boot be disabled

2021-12-24T15:25:24+00:00

The security of Machine Owner Key (MOK) relies on secure boot. When secure boot is disabled, EFI firmware will not verify binary code. Then arbitrary efi binary code can modify MOK when rebooting. This patch prevents MOK/MOKx be loaded when secure boot be disabled. Signed-off-by: "Lee, Chun-Yi" Reviewed-by: Petr Vorel Signed-off-by: Mimi Zohar

efi: Don't use knowledge about efi_guid_t internals

2021-08-27T14:01:27+00:00

When print GUIDs supply pointer to the efi_guid_t (guid_t) type rather its internal members. Signed-off-by: Andy Shevchenko Reviewed-by: Serge Hallyn Signed-off-by: Ard Biesheuvel

integrity: Load mokx variables into the blacklist keyring

2021-03-11T16:34:48+00:00

During boot the Secure Boot Forbidden Signature Database, dbx, is loaded into the blacklist keyring. Systems booted with shim have an equivalent Forbidden Signature Database called mokx. Currently mokx is only used by shim and grub, the contents are ignored by the kernel. Add the ability to load mokx into the blacklist keyring during boot. Signed-off-by: Eric Snowberg Suggested-by: James Bottomley Signed-off-by: David Howells Reviewed-by: Jarkko Sakkinen cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/c33c8e3839a41e9654f41cc92c7231104931b1d7.camel@HansenPartnership.com/ Link: https://lore.kernel.org/r/20210122181054.32635-5-eric.snowberg@oracle.com/ # v5 Link: https://lore.kernel.org/r/161428674320.677100.12637282414018170743.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/161433313205.902181.2502803393898221637.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161529607422.163428.13530426573612578854.stgit@warthog.procyon.org.uk/ # v3

certs: Add EFI_CERT_X509_GUID support for dbx entries

2021-03-11T16:31:28+00:00

This fixes CVE-2020-26541. The Secure Boot Forbidden Signature Database, dbx, contains a list of now revoked signatures and keys previously approved to boot with UEFI Secure Boot enabled. The dbx is capable of containing any number of EFI_CERT_X509_SHA256_GUID, EFI_CERT_SHA256_GUID, and EFI_CERT_X509_GUID entries. Currently when EFI_CERT_X509_GUID are contained in the dbx, the entries are skipped. Add support for EFI_CERT_X509_GUID dbx entries. When a EFI_CERT_X509_GUID is found, it is added as an asymmetrical key to the .blacklist keyring. Anytime the .platform keyring is used, the keys in the .blacklist keyring are referenced, if a matching key is found, the key will be rejected. [DH: Made the following changes: - Added to have a config option to enable the facility. This allows a Kconfig solution to make sure that pkcs7_validate_trust() is enabled.[1][2] - Moved the functions out from the middle of the blacklist functions. - Added kerneldoc comments.] Signed-off-by: Eric Snowberg Signed-off-by: David Howells Reviewed-by: Jarkko Sakkinen cc: Randy Dunlap cc: Mickaël Salaün cc: Arnd Bergmann cc: keyrings@vger.kernel.org Link: https://lore.kernel.org/r/20200901165143.10295-1-eric.snowberg@oracle.com/ # rfc Link: https://lore.kernel.org/r/20200909172736.73003-1-eric.snowberg@oracle.com/ # v2 Link: https://lore.kernel.org/r/20200911182230.62266-1-eric.snowberg@oracle.com/ # v3 Link: https://lore.kernel.org/r/20200916004927.64276-1-eric.snowberg@oracle.com/ # v4 Link: https://lore.kernel.org/r/20210122181054.32635-2-eric.snowberg@oracle.com/ # v5 Link: https://lore.kernel.org/r/161428672051.677100.11064981943343605138.stgit@warthog.procyon.org.uk/ Link: https://lore.kernel.org/r/161433310942.902181.4901864302675874242.stgit@warthog.procyon.org.uk/ # v2 Link: https://lore.kernel.org/r/161529605075.163428.14625520893961300757.stgit@warthog.procyon.org.uk/ # v3 Link: https://lore.kernel.org/r/bc2c24e3-ed68-2521-0bf4-a1f6be4a895d@infradead.org/ [1] Link: https://lore.kernel.org/r/20210225125638.1841436-1-arnd@kernel.org/ [2]