Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8 |
|
#
f0093474 |
| 10-Oct-2023 |
Jarkko Sakkinen <jarkko@kernel.org> |
KEYS: trusted: Rollback init_trusted() consistently
commit 31de287345f41bbfaec36a5c8cbdba035cf76442 upstream.
Do bind neither static calls nor trusted_key_exit() before a successful init, in order
KEYS: trusted: Rollback init_trusted() consistently
commit 31de287345f41bbfaec36a5c8cbdba035cf76442 upstream.
Do bind neither static calls nor trusted_key_exit() before a successful init, in order to maintain a consistent state. In addition, depart the init_trusted() in the case of a real error (i.e. getting back something else than -ENODEV).
Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Closes: https://lore.kernel.org/linux-integrity/CAHk-=whOPoLaWM8S8GgoOPT7a2+nMH5h3TLKtn=R_3w4R1_Uvg@mail.gmail.com/ Cc: stable@vger.kernel.org # v5.13+ Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.5.7, v6.5.6 |
|
#
01bbafc6 |
| 06-Oct-2023 |
Sumit Garg <sumit.garg@linaro.org> |
KEYS: trusted: Remove redundant static calls usage
Static calls invocations aren't well supported from module __init and __exit functions. Especially the static call from cleanup_trusted() led to a
KEYS: trusted: Remove redundant static calls usage
Static calls invocations aren't well supported from module __init and __exit functions. Especially the static call from cleanup_trusted() led to a crash on x86 kernel with CONFIG_DEBUG_VIRTUAL=y.
However, the usage of static call invocations for trusted_key_init() and trusted_key_exit() don't add any value from either a performance or security perspective. Hence switch to use indirect function calls instead.
Note here that although it will fix the current crash report, ultimately the static call infrastructure should be fixed to either support its future usage from module __init and __exit functions or not.
Reported-and-tested-by: Hyeonggon Yoo <42.hyeyoo@gmail.com> Link: https://lore.kernel.org/lkml/ZRhKq6e5nF%2F4ZIV1@fedora/#t Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40 |
|
#
e9c5048c |
| 13-May-2022 |
Ahmad Fatoum <a.fatoum@pengutronix.de> |
KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core built into many newer i.MX and QorIQ SoCs by NXP.
The CAAM
KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core built into many newer i.MX and QorIQ SoCs by NXP.
The CAAM does crypto acceleration, hardware number generation and has a blob mechanism for encapsulation/decapsulation of sensitive material.
This blob mechanism depends on a device specific random 256-bit One Time Programmable Master Key that is fused in each SoC at manufacturing time. This key is unreadable and can only be used by the CAAM for AES encryption/decryption of user data.
This makes it a suitable backend (source) for kernel trusted keys.
Previous commits generalized trusted keys to support multiple backends and added an API to access the CAAM blob mechanism. Based on these, provide the necessary glue to use the CAAM for trusted keys.
Reviewed-by: David Gstir <david@sigma-star.at> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Tim Harvey <tharvey@gateworks.com> Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com> Tested-by: Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Tested-by: John Ernberg <john.ernberg@actia.se> # iMX8QXP Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
show more ...
|
#
fcd7c269 |
| 13-May-2022 |
Ahmad Fatoum <a.fatoum@pengutronix.de> |
KEYS: trusted: allow use of kernel RNG for key material
The two existing trusted key sources don't make use of the kernel RNG, but instead let the hardware doing the sealing/unsealing also generate
KEYS: trusted: allow use of kernel RNG for key material
The two existing trusted key sources don't make use of the kernel RNG, but instead let the hardware doing the sealing/unsealing also generate the random key material. However, both users and future backends may want to place less trust into the quality of the trust source's random number generator and instead reuse the kernel entropy pool, which can be seeded from multiple entropy sources.
Make this possible by adding a new trusted.rng parameter, that will force use of the kernel RNG. In its absence, it's up to the trust source to decide, which random numbers to use, maintaining the existing behavior.
Suggested-by: Jarkko Sakkinen <jarkko@kernel.org> Acked-by: Sumit Garg <sumit.garg@linaro.org> Acked-by: Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by: David Gstir <david@sigma-star.at> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Tested-by: Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Tested-by: John Ernberg <john.ernberg@actia.se> # iMX8QXP Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
show more ...
|
#
be07858f |
| 13-May-2022 |
Ahmad Fatoum <a.fatoum@pengutronix.de> |
KEYS: trusted: allow use of TEE as backend without TCG_TPM support
With recent rework, trusted keys are no longer limited to TPM as trust source. The Kconfig symbol is unchanged however leading to a
KEYS: trusted: allow use of TEE as backend without TCG_TPM support
With recent rework, trusted keys are no longer limited to TPM as trust source. The Kconfig symbol is unchanged however leading to a few issues:
- TCG_TPM is required, even if only TEE is to be used - Enabling TCG_TPM, but excluding it from available trusted sources is not possible - TEE=m && TRUSTED_KEYS=y will lead to TEE support being silently dropped, which is not the best user experience
Remedy these issues by introducing two new boolean Kconfig symbols: TRUSTED_KEYS_TPM and TRUSTED_KEYS_TEE with the appropriate dependencies.
Any new code depending on the TPM trusted key backend in particular or symbols exported by it will now need to explicitly state that it
depends on TRUSTED_KEYS && TRUSTED_KEYS_TPM
The latter to ensure the dependency is built and the former to ensure it's reachable for module builds. There are no such users yet.
Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by: Pankaj Gupta <pankaj.gupta@nxp.com> Tested-by: Andreas Rammhold <andreas@rammhold.de> Tested-by: Tim Harvey <tharvey@gateworks.com> Tested-by: Michael Walle <michael@walle.cc> # on ls1028a (non-E and E) Tested-by: John Ernberg <john.ernberg@actia.se> # iMX8QXP Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
show more ...
|
Revision tags: v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17 |
|
#
c5d1ed84 |
| 26-Jan-2022 |
Dave Kleikamp <dave.kleikamp@oracle.com> |
KEYS: trusted: Avoid calling null function trusted_key_exit
If one loads and unloads the trusted module, trusted_key_exit can be NULL. Call it through static_call_cond() to avoid a kernel trap.
Fix
KEYS: trusted: Avoid calling null function trusted_key_exit
If one loads and unloads the trusted module, trusted_key_exit can be NULL. Call it through static_call_cond() to avoid a kernel trap.
Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Cc: Sumit Garg <sumit.garg@linaro.org> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Mimi Zohar <zohar@linux.ibm.com> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: linux-integrity@vger.kernel.org Cc: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
show more ...
|
Revision tags: v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7 |
|
#
969a2644 |
| 01-Dec-2021 |
Andreas Rammhold <andreas@rammhold.de> |
KEYS: trusted: Fix trusted key backends when building as module
Before this commit the kernel could end up with no trusted key sources even though both of the currently supported backends (TPM and T
KEYS: trusted: Fix trusted key backends when building as module
Before this commit the kernel could end up with no trusted key sources even though both of the currently supported backends (TPM and TEE) were compiled as modules. This manifested in the trusted key type not being registered at all.
When checking if a CONFIG_… preprocessor variable is defined we only test for the builtin (=y) case and not the module (=m) case. By using the IS_REACHABLE() macro we do test for both cases.
Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Andreas Rammhold <andreas@rammhold.de> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
show more ...
|
#
bfa4a733 |
| 26-Jan-2022 |
Dave Kleikamp <dave.kleikamp@oracle.com> |
KEYS: trusted: Avoid calling null function trusted_key_exit
[ Upstream commit c5d1ed846e15090bc90dfdaafc07eac066e070bb ]
If one loads and unloads the trusted module, trusted_key_exit can be NULL. C
KEYS: trusted: Avoid calling null function trusted_key_exit
[ Upstream commit c5d1ed846e15090bc90dfdaafc07eac066e070bb ]
If one loads and unloads the trusted module, trusted_key_exit can be NULL. Call it through static_call_cond() to avoid a kernel trap.
Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com> Cc: Sumit Garg <sumit.garg@linaro.org> Cc: James Bottomley <jejb@linux.ibm.com> Cc: Jarkko Sakkinen <jarkko@kernel.org> Cc: Mimi Zohar <zohar@linux.ibm.com> Cc: David Howells <dhowells@redhat.com> Cc: James Morris <jmorris@namei.org> Cc: "Serge E. Hallyn" <serge@hallyn.com> Cc: linux-integrity@vger.kernel.org Cc: keyrings@vger.kernel.org Cc: linux-security-module@vger.kernel.org Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
b0efbe7e |
| 01-Dec-2021 |
Andreas Rammhold <andreas@rammhold.de> |
KEYS: trusted: Fix trusted key backends when building as module
[ Upstream commit 969a26446bcd142faedfe8c6f41cd7668596c1fa ]
Before this commit the kernel could end up with no trusted key sources e
KEYS: trusted: Fix trusted key backends when building as module
[ Upstream commit 969a26446bcd142faedfe8c6f41cd7668596c1fa ]
Before this commit the kernel could end up with no trusted key sources even though both of the currently supported backends (TPM and TEE) were compiled as modules. This manifested in the trusted key type not being registered at all.
When checking if a CONFIG_… preprocessor variable is defined we only test for the builtin (=y) case and not the module (=m) case. By using the IS_REACHABLE() macro we do test for both cases.
Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: Andreas Rammhold <andreas@rammhold.de> Tested-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12 |
|
#
60dc5f1b |
| 21-Apr-2021 |
James Bottomley <James.Bottomley@HansenPartnership.com> |
KEYS: trusted: fix TPM trusted keys for generic framework
The generic framework patch broke the current TPM trusted keys because it doesn't correctly remove the values consumed by the generic parser
KEYS: trusted: fix TPM trusted keys for generic framework
The generic framework patch broke the current TPM trusted keys because it doesn't correctly remove the values consumed by the generic parser before passing them on to the implementation specific parser. Fix this by having the generic parser return the string minus the consumed tokens.
Additionally, there may be no tokens left for the implementation specific parser, so make it handle the NULL case correctly and finally fix a TPM 1.2 specific check for no keyhandle.
Fixes: 5d0682be3189 ("KEYS: trusted: Add generic trusted keys framework") Tested-by: Sumit Garg <sumit.garg@linaro.org> Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
show more ...
|
Revision tags: v5.10.32, v5.10.31, v5.10.30 |
|
#
aec00aa0 |
| 12-Apr-2021 |
Colin Ian King <colin.king@canonical.com> |
KEYS: trusted: Fix missing null return from kzalloc call
The kzalloc call can return null with the GFP_KERNEL flag so add a null check and exit via a new error exit label. Use the same exit error la
KEYS: trusted: Fix missing null return from kzalloc call
The kzalloc call can return null with the GFP_KERNEL flag so add a null check and exit via a new error exit label. Use the same exit error label for another error path too.
Addresses-Coverity: ("Dereference null return value") Fixes: 830027e2cb55 ("KEYS: trusted: Add generic trusted keys framework") Signed-off-by: Colin Ian King <colin.king@canonical.com> Reviewed-by: Sumit Garg <sumit.garg@linaro.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
show more ...
|
Revision tags: v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20 |
|
#
0a95ebc9 |
| 01-Mar-2021 |
Sumit Garg <sumit.garg@linaro.org> |
KEYS: trusted: Introduce TEE based Trusted Keys
Add support for TEE based trusted keys where TEE provides the functionality to seal and unseal trusted keys using hardware unique key.
Refer to Docum
KEYS: trusted: Introduce TEE based Trusted Keys
Add support for TEE based trusted keys where TEE provides the functionality to seal and unseal trusted keys using hardware unique key.
Refer to Documentation/staging/tee.rst for detailed information about TEE.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Tested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
show more ...
|
#
5d0682be |
| 01-Mar-2021 |
Sumit Garg <sumit.garg@linaro.org> |
KEYS: trusted: Add generic trusted keys framework
Current trusted keys framework is tightly coupled to use TPM device as an underlying implementation which makes it difficult for implementations lik
KEYS: trusted: Add generic trusted keys framework
Current trusted keys framework is tightly coupled to use TPM device as an underlying implementation which makes it difficult for implementations like Trusted Execution Environment (TEE) etc. to provide trusted keys support in case platform doesn't posses a TPM device.
Add a generic trusted keys framework where underlying implementations can be easily plugged in. Create struct trusted_key_ops to achieve this, which contains necessary functions of a backend.
Also, define a module parameter in order to select a particular trust source in case a platform support multiple trust sources. In case its not specified then implementation itetrates through trust sources list starting with TPM and assign the first trust source as a backend which has initiazed successfully during iteration.
Note that current implementation only supports a single trust source at runtime which is either selectable at compile time or during boot via aforementioned module parameter.
Suggested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Sumit Garg <sumit.garg@linaro.org> Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org> Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
show more ...
|