| 44e69ea5 | 15-Aug-2023 |
Nayna Jain <[email protected]> |
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 modu
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 <[email protected]> Reviewed-and-tested-by: Mimi Zohar <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Nageswara R Sastry <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
show more ...
|
| bc026676 | 15-Aug-2023 |
Nayna Jain <[email protected]> |
integrity: ignore keys failing CA restrictions on non-UEFI platform
On non-UEFI platforms, handle restrict_link_by_ca failures differently.
Certificates which do not satisfy CA restrictions on non-
integrity: ignore keys failing CA restrictions on non-UEFI platform
On non-UEFI platforms, handle restrict_link_by_ca failures differently.
Certificates which do not satisfy CA restrictions on non-UEFI platforms are ignored.
Signed-off-by: Nayna Jain <[email protected]> Reviewed-and-tested-by: Mimi Zohar <[email protected]> Acked-by: Jarkko Sakkinen <[email protected]> Tested-by: Nageswara R Sastry <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
show more ...
|
| 4b3e71e9 | 10-Feb-2023 |
Russell Currey <[email protected]> |
integrity/powerpc: Support loading keys from PLPKS
Add support for loading keys from the PLPKS on pseries machines, with the "ibm,plpks-sb-v1" format.
The object format is expected to be the same,
integrity/powerpc: Support loading keys from PLPKS
Add support for loading keys from the PLPKS on pseries machines, with the "ibm,plpks-sb-v1" format.
The object format is expected to be the same, so there shouldn't be any functional differences between objects retrieved on powernv or pseries.
Unlike on powernv, on pseries the format string isn't contained in the device tree. Use secvar_ops->format() to fetch the format string in a generic manner, rather than searching the device tree ourselves.
(The current code searches the device tree for a node compatible with "ibm,edk2-compat-v1". This patch switches to calling secvar_ops->format(), which in the case of OPAL/powernv means opal_secvar_format(), which searches the device tree for a node compatible with "ibm,secvar-backend" and checks its "format" property. These are equivalent, as skiboot creates a node with both "ibm,edk2-compat-v1" and "ibm,secvar-backend" as compatible strings.)
Signed-off-by: Russell Currey <[email protected]> Signed-off-by: Andrew Donnellan <[email protected]> Reviewed-by: Stefan Berger <[email protected]> Signed-off-by: Michael Ellerman <[email protected]> Link: https://lore.kernel.org/r/[email protected]
show more ...
|
| 3d6ae1a5 | 26-Jan-2022 |
Eric Snowberg <[email protected]> |
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 truste
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 <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
show more ...
|
| 74f5e300 | 26-Jan-2022 |
Eric Snowberg <[email protected]> |
integrity: Trust MOK keys if MokListTrustedRT found
A new Machine Owner Key (MOK) variable called MokListTrustedRT has been introduced in shim. When this UEFI variable is set, it indicates the end-u
integrity: Trust MOK keys if MokListTrustedRT found
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 <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
show more ...
|
| 45fcd5e5 | 26-Jan-2022 |
Eric Snowberg <[email protected]> |
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 mach
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 <[email protected]> Reviewed-by: Mimi Zohar <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Tested-by: Mimi Zohar <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
show more ...
|
| d1996776 | 26-Jan-2022 |
Eric Snowberg <[email protected]> |
integrity: Introduce a Linux keyring called machine
Many UEFI Linux distributions boot using shim. The UEFI shim provides what is called Machine Owner Keys (MOK). Shim uses both the UEFI Secure Boo
integrity: Introduce a Linux keyring called machine
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 <[email protected]> Tested-by: Jarkko Sakkinen <[email protected]> Tested-by: Mimi Zohar <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> Signed-off-by: Jarkko Sakkinen <[email protected]>
show more ...
|
| ebd9c2ae | 22-Jan-2021 |
Eric Snowberg <[email protected]> |
integrity: Load mokx variables into the blacklist keyring
During boot the Secure Boot Forbidden Signature Database, dbx, is loaded into the blacklist keyring. Systems booted with shim have an equiv
integrity: Load mokx variables into the blacklist keyring
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 <[email protected]> Suggested-by: James Bottomley <[email protected]> Signed-off-by: David Howells <[email protected]> Reviewed-by: Jarkko Sakkinen <[email protected]> cc: [email protected] Link: https://lore.kernel.org/r/c33c8e3839a41e9654f41cc92c7231104931b1d7.camel@HansenPartnership.com/ Link: https://lore.kernel.org/r/[email protected]/ # 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
show more ...
|
| 726bd896 | 05-Sep-2020 |
Lenny Szubowicz <[email protected]> |
integrity: Load certs from the EFI MOK config table
Because of system-specific EFI firmware limitations, EFI volatile variables may not be capable of holding the required contents of the Machine Own
integrity: Load certs from the EFI MOK config table
Because of system-specific EFI firmware limitations, EFI volatile variables may not be capable of holding the required contents of the Machine Owner Key (MOK) certificate store when the certificate list grows above some size. Therefore, an EFI boot loader may pass the MOK certs via a EFI configuration table created specifically for this purpose to avoid this firmware limitation.
An EFI configuration table is a much more primitive mechanism compared to EFI variables and is well suited for one-way passage of static information from a pre-OS environment to the kernel.
This patch adds the support to load certs from the MokListRT entry in the MOK variable configuration table, if it's present. The pre-existing support to load certs from the MokListRT EFI variable remains and is used if the EFI MOK configuration table isn't present or can't be successfully used.
Signed-off-by: Lenny Szubowicz <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
show more ...
|