#
44e69ea5 |
|
15-Aug-2023 |
Nayna Jain <nayna@linux.ibm.com> |
integrity: PowerVM support for loading third party code signing keys On secure boot enabled PowerVM LPAR, third party code signing keys are needed during early boot to verify signed third party modules. These third party keys are stored in moduledb object in the Platform KeyStore (PKS). Load third party code signing keys onto .secondary_trusted_keys keyring. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-and-tested-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
#
4cb1ed94 |
|
15-Aug-2023 |
Nayna Jain <nayna@linux.ibm.com> |
integrity: check whether imputed trust is enabled trust_moklist() is specific to UEFI enabled systems. Other platforms rely only on the Kconfig. Define a generic wrapper named imputed_trust_enabled(). Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
#
a3af7188 |
|
15-Aug-2023 |
Nayna Jain <nayna@linux.ibm.com> |
integrity: PowerVM support for loading CA keys on machine keyring Keys that derive their trust from an entity such as a security officer, administrator, system owner, or machine owner are said to have "imputed trust". CA keys with imputed trust can be loaded onto the machine keyring. The mechanism for loading these keys onto the machine keyring is platform dependent. Load keys stored in the variable trustedcadb onto the .machine keyring on PowerVM platform. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Reviewed-and-tested-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
#
141e5239 |
|
12-Jul-2021 |
Mickaël Salaün <mic@linux.microsoft.com> |
certs: Factor out the blacklist hash creation Factor out the blacklist hash creation with the get_raw_hash() helper. This also centralize the "tbs" and "bin" prefixes and make them private, which help to manage them consistently. Cc: David Howells <dhowells@redhat.com> Cc: David S. Miller <davem@davemloft.net> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Eric Snowberg <eric.snowberg@oracle.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Mickaël Salaün <mic@linux.microsoft.com> Link: https://lore.kernel.org/r/20210712170313.884724-5-mic@digikod.net Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
#
048ae41b |
|
21-Apr-2022 |
Stefan Berger <stefanb@linux.ibm.com> |
integrity: Fix sparse warnings in keyring_handler Fix the following sparse warnings: CHECK security/integrity/platform_certs/keyring_handler.c security/integrity/platform_certs/keyring_handler.c:76:16: warning: Using plain integer as NULL pointer security/integrity/platform_certs/keyring_handler.c:91:16: warning: Using plain integer as NULL pointer security/integrity/platform_certs/keyring_handler.c:106:16: warning: Using plain integer as NULL pointer Signed-off-by: Stefan Berger <stefanb@linux.ibm.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
|
#
3d6ae1a5 |
|
25-Jan-2022 |
Eric Snowberg <eric.snowberg@oracle.com> |
integrity: Only use machine keyring when uefi_check_trust_mok_keys is true 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 <eric.snowberg@oracle.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
#
45fcd5e5 |
|
25-Jan-2022 |
Eric Snowberg <eric.snowberg@oracle.com> |
integrity: add new keyring handler for mok keys 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 <eric.snowberg@oracle.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
#
e561752c |
|
25-Jan-2022 |
Eric Snowberg <eric.snowberg@oracle.com> |
integrity: Fix warning about missing prototypes 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 <lkp@intel.com> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
|
#
56c58126 |
|
22-Jan-2021 |
Eric Snowberg <eric.snowberg@oracle.com> |
certs: Add EFI_CERT_X509_GUID support for dbx entries 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 <eric.snowberg@oracle.com> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> cc: Randy Dunlap <rdunlap@infradead.org> cc: Mickaël Salaün <mic@digikod.net> cc: Arnd Bergmann <arnd@kernel.org> 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]
|
#
ad723674 |
|
10-Nov-2019 |
Nayna Jain <nayna@linux.ibm.com> |
x86/efi: move common keyring handler functions to new file The handlers to add the keys to the .platform keyring and blacklisted hashes to the .blacklist keyring is common for both the uefi and powerpc mechanisms of loading the keys/hashes from the firmware. This patch moves the common code from load_uefi.c to keyring_handler.c Signed-off-by: Nayna Jain <nayna@linux.ibm.com> Acked-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Eric Richter <erichte@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/1573441836-3632-4-git-send-email-nayna@linux.ibm.com
|