Series applies on top of v5.18-rc6. Would be great if this could make it
into v5.19.
v9 was here:
https://lore.kernel.org/linux-integrity/[email protected]
Changelog is beneath each individual patch. Compared to v9, only code
change is checking whether CAAM can support blobbing at init-time for
CAAM revisions < 10 (such as LS1046A) to avoid a cryptic error message
at first use.
The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
built into many newer i.MX and QorIQ SoCs by NXP.
Its blob mechanism can AES encrypt/decrypt user data using a unique
never-disclosed device-specific key.
There has been multiple discussions on how to represent this within the kernel:
The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
built into many newer i.MX and QorIQ SoCs by NXP.
Its blob mechanism can AES encrypt/decrypt user data using a unique
never-disclosed device-specific key. There has been multiple
discussions on how to represent this within the kernel:
- [RFC] crypto: caam - add red blobifier
Steffen implemented[1] a PoC sysfs driver to start a discussion on how to
best integrate the blob mechanism.
Mimi suggested that it could be used to implement trusted keys.
Trusted keys back then were a TPM-only feature.
- security/keys/secure_key: Adds the secure key support based on CAAM.
Udit Agarwal added[2] a new "secure" key type with the CAAM as backend.
The key material stays within the kernel only.
Mimi and James agreed that this needs a generic interface, not specific
to CAAM. Mimi suggested trusted keys. Jan noted that this could serve as
basis for TEE-backed keys.
- [RFC] drivers: crypto: caam: key: Add caam_tk key type
Franck added[3] a new "caam_tk" key type based on Udit's work. This time
it uses CAAM "black blobs" instead of "red blobs", so key material stays
within the CAAM and isn't exposed to kernel in plaintext.
James voiced the opinion that there should be just one user-facing generic
wrap/unwrap key type with multiple possible handlers.
David suggested trusted keys.
- Introduce TEE based Trusted Keys support
Sumit reworked[4] trusted keys to support multiple possible backends with
one chosen at boot time and added a new TEE backend along with TPM.
This now sits in Jarkko's master branch to be sent out for v5.13
This patch series builds on top of Sumit's rework to have the CAAM as yet another
trusted key backend.
The CAAM bits are based on Steffen's initial patch from 2015. His work had been
used in the field for some years now, so I preferred not to deviate too much from it.
This series has been tested with dmcrypt[5] on an i.MX6Q/DL, i.MX8M[6]
and LS1028[7].
Looking forward to your feedback.
Cheers,
Ahmad
[1]: https://lore.kernel.org/linux-crypto/[email protected]/
[2]: https://lore.kernel.org/linux-integrity/[email protected]/
[3]: https://lore.kernel.org/lkml/[email protected]/
[4]: https://lore.kernel.org/lkml/[email protected]/
[5]: https://lore.kernel.org/linux-integrity/[email protected]/
[6]: https://lore.kernel.org/linux-integrity/DU2PR04MB8630D83FE9BBC0D782C4FAF595089@DU2PR04MB8630.eurprd04.prod.outlook.com/
[7]: https://lore.kernel.org/linux-integrity/[email protected]/
---
To: Jarkko Sakkinen <[email protected]>
To: "Horia Geantă" <[email protected]>
To: Mimi Zohar <[email protected]>
To: Pankaj Gupta <[email protected]>
To: Herbert Xu <[email protected]>
To: "David S. Miller" <[email protected]>
To: James Bottomley <[email protected]>
Cc: David Howells <[email protected]>
Cc: James Morris <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Cc: Steffen Trumtrar <[email protected]>
Cc: Jan Luebbe <[email protected]>
Cc: David Gstir <[email protected]>
Cc: Eric Biggers <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Franck LENORMAND <[email protected]>
Cc: Sumit Garg <[email protected]>
Cc: Andreas Rammhold <[email protected]>
Cc: Tim Harvey <[email protected]>
Cc: Matthias Schiffer <[email protected]>
Cc: Michael Walle <[email protected]>
Cc: John Ernberg <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Ahmad Fatoum (7):
KEYS: trusted: allow use of TEE as backend without TCG_TPM support
KEYS: trusted: allow use of kernel RNG for key material
crypto: caam - determine whether CAAM supports blob encap/decap
crypto: caam - add in-kernel interface for blob generator
KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
doc: trusted-encrypted: describe new CAAM trust source
MAINTAINERS: add KEYS-TRUSTED-CAAM
.../admin-guide/kernel-parameters.txt | 11 ++
.../security/keys/trusted-encrypted.rst | 60 +++++-
MAINTAINERS | 9 +
drivers/crypto/caam/Kconfig | 3 +
drivers/crypto/caam/Makefile | 1 +
drivers/crypto/caam/blob_gen.c | 182 ++++++++++++++++++
drivers/crypto/caam/ctrl.c | 17 +-
drivers/crypto/caam/intern.h | 1 +
drivers/crypto/caam/regs.h | 4 +-
include/keys/trusted-type.h | 2 +-
include/keys/trusted_caam.h | 11 ++
include/soc/fsl/caam-blob.h | 103 ++++++++++
security/keys/Kconfig | 18 +-
security/keys/trusted-keys/Kconfig | 38 ++++
security/keys/trusted-keys/Makefile | 10 +-
security/keys/trusted-keys/trusted_caam.c | 80 ++++++++
security/keys/trusted-keys/trusted_core.c | 45 ++++-
17 files changed, 563 insertions(+), 32 deletions(-)
create mode 100644 drivers/crypto/caam/blob_gen.c
create mode 100644 include/keys/trusted_caam.h
create mode 100644 include/soc/fsl/caam-blob.h
create mode 100644 security/keys/trusted-keys/Kconfig
create mode 100644 security/keys/trusted-keys/trusted_caam.c
--
2.30.2
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 <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Reviewed-by: Pankaj Gupta <[email protected]>
Tested-by: Pankaj Gupta <[email protected]>
Tested-by: Andreas Rammhold <[email protected]>
Tested-by: Tim Harvey <[email protected]>
Tested-by: Michael Walle <[email protected]> # on ls1028a (non-E and E)
Tested-by: John Ernberg <[email protected]> # iMX8QXP
Signed-off-by: Ahmad Fatoum <[email protected]>
---
v9 -> v10:
- added Michael's and John's Tested-by
v8 -> v9:
- no changes
v7 -> v8:
- add Pankaj's Reviewed-by and Tested-by
v6 -> v7:
- s/Tested-By/Tested-by/
v5 -> v6:
- Rebased on asym_tpm removal
v4 -> v5:
- collected Jarkko's Reviewed-by
v3 -> v4:
- rebased on top of Andreas' regression fix and pulled it back
into series
v2 -> v3:
- factored this patch out as a fix for backporting
v1 -> v2:
- Move rest of TPM-related selects from TRUSTED_KEYS to
TRUSTED_KEYS_TPM (Sumit)
- Remove left-over line in Makefile (Sumit)
- added Fixes: tag
- adjust commit message to reference the regression reported
by Andreas
- have ASYMMETRIC_TPM_KEY_SUBTYPE depend on TRUSTED_KEYS_TPM,
because it references global symbols that are exported
by the trusted key TPM backend.
[1]: https://lore.kernel.org/linux-integrity/f8285eb0135ba30c9d846cf9dd395d1f5f8b1efc.1624364386.git-series.a.fatoum@pengutronix.de/
[2]: https://lore.kernel.org/linux-integrity/20210719091335.vwfebcpkf4pag3wm@wrt/T/#t
To: Jarkko Sakkinen <[email protected]>
To: James Morris <[email protected]>
To: "Serge E. Hallyn" <[email protected]>
To: James Bottomley <[email protected]>
To: Mimi Zohar <[email protected]>
To: Sumit Garg <[email protected]>
To: David Howells <[email protected]>
To: Herbert Xu <[email protected]>
To: "David S. Miller" <[email protected]>
Cc: David Gstir <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Matthias Schiffer <[email protected]>
Cc: Pankaj Gupta <[email protected]>
Cc: Michael Walle <[email protected]>
Cc: John Ernberg <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
security/keys/Kconfig | 18 ++++++--------
security/keys/trusted-keys/Kconfig | 29 +++++++++++++++++++++++
security/keys/trusted-keys/Makefile | 8 +++----
security/keys/trusted-keys/trusted_core.c | 4 ++--
4 files changed, 42 insertions(+), 17 deletions(-)
create mode 100644 security/keys/trusted-keys/Kconfig
diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index 0e30b361e1c1..abb03a1b2a5c 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -70,23 +70,19 @@ config BIG_KEYS
config TRUSTED_KEYS
tristate "TRUSTED KEYS"
- depends on KEYS && TCG_TPM
- select CRYPTO
- select CRYPTO_HMAC
- select CRYPTO_SHA1
- select CRYPTO_HASH_INFO
- select ASN1_ENCODER
- select OID_REGISTRY
- select ASN1
+ depends on KEYS
help
This option provides support for creating, sealing, and unsealing
keys in the kernel. Trusted keys are random number symmetric keys,
- generated and RSA-sealed by the TPM. The TPM only unseals the keys,
- if the boot PCRs and other criteria match. Userspace will only ever
- see encrypted blobs.
+ generated and sealed by a trust source selected at kernel boot-time.
+ Userspace will only ever see encrypted blobs.
If you are unsure as to whether this is required, answer N.
+if TRUSTED_KEYS
+source "security/keys/trusted-keys/Kconfig"
+endif
+
config ENCRYPTED_KEYS
tristate "ENCRYPTED KEYS"
depends on KEYS
diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig
new file mode 100644
index 000000000000..fc4abd581abb
--- /dev/null
+++ b/security/keys/trusted-keys/Kconfig
@@ -0,0 +1,29 @@
+config TRUSTED_KEYS_TPM
+ bool "TPM-based trusted keys"
+ depends on TCG_TPM >= TRUSTED_KEYS
+ default y
+ select CRYPTO
+ select CRYPTO_HMAC
+ select CRYPTO_SHA1
+ select CRYPTO_HASH_INFO
+ select ASN1_ENCODER
+ select OID_REGISTRY
+ select ASN1
+ help
+ Enable use of the Trusted Platform Module (TPM) as trusted key
+ backend. Trusted keys are random number symmetric keys,
+ which will be generated and RSA-sealed by the TPM.
+ The TPM only unseals the keys, if the boot PCRs and other
+ criteria match.
+
+config TRUSTED_KEYS_TEE
+ bool "TEE-based trusted keys"
+ depends on TEE >= TRUSTED_KEYS
+ default y
+ help
+ Enable use of the Trusted Execution Environment (TEE) as trusted
+ key backend.
+
+if !TRUSTED_KEYS_TPM && !TRUSTED_KEYS_TEE
+comment "No trust source selected!"
+endif
diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
index feb8b6c3cc79..2e2371eae4d5 100644
--- a/security/keys/trusted-keys/Makefile
+++ b/security/keys/trusted-keys/Makefile
@@ -5,10 +5,10 @@
obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
trusted-y += trusted_core.o
-trusted-y += trusted_tpm1.o
+trusted-$(CONFIG_TRUSTED_KEYS_TPM) += trusted_tpm1.o
$(obj)/trusted_tpm2.o: $(obj)/tpm2key.asn1.h
-trusted-y += trusted_tpm2.o
-trusted-y += tpm2key.asn1.o
+trusted-$(CONFIG_TRUSTED_KEYS_TPM) += trusted_tpm2.o
+trusted-$(CONFIG_TRUSTED_KEYS_TPM) += tpm2key.asn1.o
-trusted-$(CONFIG_TEE) += trusted_tee.o
+trusted-$(CONFIG_TRUSTED_KEYS_TEE) += trusted_tee.o
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index 9b9d3ef79cbe..7cdbd16aed30 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -27,10 +27,10 @@ module_param_named(source, trusted_key_source, charp, 0);
MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)");
static const struct trusted_key_source trusted_key_sources[] = {
-#if IS_REACHABLE(CONFIG_TCG_TPM)
+#if defined(CONFIG_TRUSTED_KEYS_TPM)
{ "tpm", &trusted_key_tpm_ops },
#endif
-#if IS_REACHABLE(CONFIG_TEE)
+#if defined(CONFIG_TRUSTED_KEYS_TEE)
{ "tee", &trusted_key_tee_ops },
#endif
};
--
2.30.2
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 <[email protected]>
Reviewed-by: Pankaj Gupta <[email protected]>
Reviewed-by: Jarkko Sakkinen <[email protected]>
Tested-by: Tim Harvey <[email protected]>
Tested-by: Matthias Schiffer <[email protected]>
Tested-by: Pankaj Gupta <[email protected]>
Tested-by: Michael Walle <[email protected]> # on ls1028a (non-E and E)
Tested-by: John Ernberg <[email protected]> # iMX8QXP
Signed-off-by: Ahmad Fatoum <[email protected]>
---
v9 -> v10:
- added Michael's and John's Tested-by
v8 -> v9:
- remove diagnostic on caam_blob_gen_init() failure as more relevant
messages are now printed by caam_blob_gen_init() itself
v7 -> v8:
- add Jarkko's Reviewed-by
v6 -> v7:
- Split off MAINTAINERS and documentation chanes into separate patches
(Jarkko)
- Use new struct caam_blob_info API (Pankaj)
v5 -> v6:
- Rename caam_trusted_key_ops to trusted_key_caam_ops for symmetry
with other trust sources (Pankaj)
- Collected Pankaj's Reviewed-by
v4 -> v5:
- Collected Reviewed-by's and Tested-by's
- Changed modifier to SECURE_KEY for compatibility with linux-imx
(Matthias)
v3 -> v4:
- Collected Acked-by's, Reviewed-by's and Tested-by
v2 -> v3:
- add MAINTAINERS entry
v1 -> v2:
- Extend trusted keys documentation for CAAM
To: Jonathan Corbet <[email protected]>
To: David Howells <[email protected]>
To: Jarkko Sakkinen <[email protected]>
To: James Bottomley <[email protected]>
To: Mimi Zohar <[email protected]>
Cc: James Morris <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Cc: "Horia Geantă" <[email protected]>
Cc: Pankaj Gupta <[email protected]>
Cc: Herbert Xu <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Eric Biggers <[email protected]>
Cc: Jan Luebbe <[email protected]>
Cc: David Gstir <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Franck LENORMAND <[email protected]>
Cc: Matthias Schiffer <[email protected]>
Cc: Sumit Garg <[email protected]>
Cc: Michael Walle <[email protected]>
Cc: John Ernberg <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
---
.../admin-guide/kernel-parameters.txt | 1 +
include/keys/trusted_caam.h | 11 +++
security/keys/trusted-keys/Kconfig | 11 ++-
security/keys/trusted-keys/Makefile | 2 +
security/keys/trusted-keys/trusted_caam.c | 80 +++++++++++++++++++
security/keys/trusted-keys/trusted_core.c | 6 +-
6 files changed, 109 insertions(+), 2 deletions(-)
create mode 100644 include/keys/trusted_caam.h
create mode 100644 security/keys/trusted-keys/trusted_caam.c
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 4deed1908a75..9afb7046ce97 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5958,6 +5958,7 @@
sources:
- "tpm"
- "tee"
+ - "caam"
If not specified then it defaults to iterating through
the trust source list starting with TPM and assigns the
first trust source as a backend which is initialized
diff --git a/include/keys/trusted_caam.h b/include/keys/trusted_caam.h
new file mode 100644
index 000000000000..73fe2f32f65e
--- /dev/null
+++ b/include/keys/trusted_caam.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2021 Pengutronix, Ahmad Fatoum <[email protected]>
+ */
+
+#ifndef __CAAM_TRUSTED_KEY_H
+#define __CAAM_TRUSTED_KEY_H
+
+extern struct trusted_key_ops trusted_key_caam_ops;
+
+#endif
diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig
index fc4abd581abb..dbfdd8536468 100644
--- a/security/keys/trusted-keys/Kconfig
+++ b/security/keys/trusted-keys/Kconfig
@@ -24,6 +24,15 @@ config TRUSTED_KEYS_TEE
Enable use of the Trusted Execution Environment (TEE) as trusted
key backend.
-if !TRUSTED_KEYS_TPM && !TRUSTED_KEYS_TEE
+config TRUSTED_KEYS_CAAM
+ bool "CAAM-based trusted keys"
+ depends on CRYPTO_DEV_FSL_CAAM_JR >= TRUSTED_KEYS
+ select CRYPTO_DEV_FSL_CAAM_BLOB_GEN
+ default y
+ help
+ Enable use of NXP's Cryptographic Accelerator and Assurance Module
+ (CAAM) as trusted key backend.
+
+if !TRUSTED_KEYS_TPM && !TRUSTED_KEYS_TEE && !TRUSTED_KEYS_CAAM
comment "No trust source selected!"
endif
diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
index 2e2371eae4d5..735aa0bc08ef 100644
--- a/security/keys/trusted-keys/Makefile
+++ b/security/keys/trusted-keys/Makefile
@@ -12,3 +12,5 @@ trusted-$(CONFIG_TRUSTED_KEYS_TPM) += trusted_tpm2.o
trusted-$(CONFIG_TRUSTED_KEYS_TPM) += tpm2key.asn1.o
trusted-$(CONFIG_TRUSTED_KEYS_TEE) += trusted_tee.o
+
+trusted-$(CONFIG_TRUSTED_KEYS_CAAM) += trusted_caam.o
diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
new file mode 100644
index 000000000000..e3415c520c0a
--- /dev/null
+++ b/security/keys/trusted-keys/trusted_caam.c
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2021 Pengutronix, Ahmad Fatoum <[email protected]>
+ */
+
+#include <keys/trusted_caam.h>
+#include <keys/trusted-type.h>
+#include <linux/build_bug.h>
+#include <linux/key-type.h>
+#include <soc/fsl/caam-blob.h>
+
+static struct caam_blob_priv *blobifier;
+
+#define KEYMOD "SECURE_KEY"
+
+static_assert(MAX_KEY_SIZE + CAAM_BLOB_OVERHEAD <= CAAM_BLOB_MAX_LEN);
+static_assert(MAX_BLOB_SIZE <= CAAM_BLOB_MAX_LEN);
+
+static int trusted_caam_seal(struct trusted_key_payload *p, char *datablob)
+{
+ int ret;
+ struct caam_blob_info info = {
+ .input = p->key, .input_len = p->key_len,
+ .output = p->blob, .output_len = MAX_BLOB_SIZE,
+ .key_mod = KEYMOD, .key_mod_len = sizeof(KEYMOD) - 1,
+ };
+
+ ret = caam_encap_blob(blobifier, &info);
+ if (ret)
+ return ret;
+
+ p->blob_len = info.output_len;
+ return 0;
+}
+
+static int trusted_caam_unseal(struct trusted_key_payload *p, char *datablob)
+{
+ int ret;
+ struct caam_blob_info info = {
+ .input = p->blob, .input_len = p->blob_len,
+ .output = p->key, .output_len = MAX_KEY_SIZE,
+ .key_mod = KEYMOD, .key_mod_len = sizeof(KEYMOD) - 1,
+ };
+
+ ret = caam_decap_blob(blobifier, &info);
+ if (ret)
+ return ret;
+
+ p->key_len = info.output_len;
+ return 0;
+}
+
+static int trusted_caam_init(void)
+{
+ int ret;
+
+ blobifier = caam_blob_gen_init();
+ if (IS_ERR(blobifier))
+ return PTR_ERR(blobifier);
+
+ ret = register_key_type(&key_type_trusted);
+ if (ret)
+ caam_blob_gen_exit(blobifier);
+
+ return ret;
+}
+
+static void trusted_caam_exit(void)
+{
+ unregister_key_type(&key_type_trusted);
+ caam_blob_gen_exit(blobifier);
+}
+
+struct trusted_key_ops trusted_key_caam_ops = {
+ .migratable = 0, /* non-migratable */
+ .init = trusted_caam_init,
+ .seal = trusted_caam_seal,
+ .unseal = trusted_caam_unseal,
+ .exit = trusted_caam_exit,
+};
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index 9235fb7d0ec9..c6fc50d67214 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -9,6 +9,7 @@
#include <keys/user-type.h>
#include <keys/trusted-type.h>
#include <keys/trusted_tee.h>
+#include <keys/trusted_caam.h>
#include <keys/trusted_tpm.h>
#include <linux/capability.h>
#include <linux/err.h>
@@ -29,7 +30,7 @@ MODULE_PARM_DESC(rng, "Select trusted key RNG");
static char *trusted_key_source;
module_param_named(source, trusted_key_source, charp, 0);
-MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)");
+MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or caam)");
static const struct trusted_key_source trusted_key_sources[] = {
#if defined(CONFIG_TRUSTED_KEYS_TPM)
@@ -38,6 +39,9 @@ static const struct trusted_key_source trusted_key_sources[] = {
#if defined(CONFIG_TRUSTED_KEYS_TEE)
{ "tee", &trusted_key_tee_ops },
#endif
+#if defined(CONFIG_TRUSTED_KEYS_CAAM)
+ { "caam", &trusted_key_caam_ops },
+#endif
};
DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
--
2.30.2
On Fri, May 13, 2022 at 04:56:58PM +0200, Ahmad Fatoum wrote:
> Series applies on top of v5.18-rc6. Would be great if this could make it
> into v5.19.
>
> v9 was here:
> https://lore.kernel.org/linux-integrity/[email protected]
>
> Changelog is beneath each individual patch. Compared to v9, only code
> change is checking whether CAAM can support blobbing at init-time for
> CAAM revisions < 10 (such as LS1046A) to avoid a cryptic error message
> at first use.
>
>
> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
> built into many newer i.MX and QorIQ SoCs by NXP.
>
> Its blob mechanism can AES encrypt/decrypt user data using a unique
> never-disclosed device-specific key.
>
> There has been multiple discussions on how to represent this within the kernel:
>
> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
> built into many newer i.MX and QorIQ SoCs by NXP.
>
> Its blob mechanism can AES encrypt/decrypt user data using a unique
> never-disclosed device-specific key. There has been multiple
> discussions on how to represent this within the kernel:
>
> - [RFC] crypto: caam - add red blobifier
> Steffen implemented[1] a PoC sysfs driver to start a discussion on how to
> best integrate the blob mechanism.
> Mimi suggested that it could be used to implement trusted keys.
> Trusted keys back then were a TPM-only feature.
>
> - security/keys/secure_key: Adds the secure key support based on CAAM.
> Udit Agarwal added[2] a new "secure" key type with the CAAM as backend.
> The key material stays within the kernel only.
> Mimi and James agreed that this needs a generic interface, not specific
> to CAAM. Mimi suggested trusted keys. Jan noted that this could serve as
> basis for TEE-backed keys.
>
> - [RFC] drivers: crypto: caam: key: Add caam_tk key type
> Franck added[3] a new "caam_tk" key type based on Udit's work. This time
> it uses CAAM "black blobs" instead of "red blobs", so key material stays
> within the CAAM and isn't exposed to kernel in plaintext.
> James voiced the opinion that there should be just one user-facing generic
> wrap/unwrap key type with multiple possible handlers.
> David suggested trusted keys.
>
> - Introduce TEE based Trusted Keys support
> Sumit reworked[4] trusted keys to support multiple possible backends with
> one chosen at boot time and added a new TEE backend along with TPM.
> This now sits in Jarkko's master branch to be sent out for v5.13
>
> This patch series builds on top of Sumit's rework to have the CAAM as yet another
> trusted key backend.
>
> The CAAM bits are based on Steffen's initial patch from 2015. His work had been
> used in the field for some years now, so I preferred not to deviate too much from it.
>
> This series has been tested with dmcrypt[5] on an i.MX6Q/DL, i.MX8M[6]
> and LS1028[7].
>
> Looking forward to your feedback.
>
> Cheers,
> Ahmad
>
> [1]: https://lore.kernel.org/linux-crypto/[email protected]/
> [2]: https://lore.kernel.org/linux-integrity/[email protected]/
> [3]: https://lore.kernel.org/lkml/[email protected]/
> [4]: https://lore.kernel.org/lkml/[email protected]/
> [5]: https://lore.kernel.org/linux-integrity/[email protected]/
> [6]: https://lore.kernel.org/linux-integrity/DU2PR04MB8630D83FE9BBC0D782C4FAF595089@DU2PR04MB8630.eurprd04.prod.outlook.com/
> [7]: https://lore.kernel.org/linux-integrity/[email protected]/
>
> ---
> To: Jarkko Sakkinen <[email protected]>
> To: "Horia Geantă" <[email protected]>
> To: Mimi Zohar <[email protected]>
> To: Pankaj Gupta <[email protected]>
> To: Herbert Xu <[email protected]>
> To: "David S. Miller" <[email protected]>
> To: James Bottomley <[email protected]>
> Cc: David Howells <[email protected]>
> Cc: James Morris <[email protected]>
> Cc: "Serge E. Hallyn" <[email protected]>
> Cc: Steffen Trumtrar <[email protected]>
> Cc: Jan Luebbe <[email protected]>
> Cc: David Gstir <[email protected]>
> Cc: Eric Biggers <[email protected]>
> Cc: Richard Weinberger <[email protected]>
> Cc: Franck LENORMAND <[email protected]>
> Cc: Sumit Garg <[email protected]>
> Cc: Andreas Rammhold <[email protected]>
> Cc: Tim Harvey <[email protected]>
> Cc: Matthias Schiffer <[email protected]>
> Cc: Michael Walle <[email protected]>
> Cc: John Ernberg <[email protected]>
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
> Cc: [email protected]
>
>
>
> Ahmad Fatoum (7):
> KEYS: trusted: allow use of TEE as backend without TCG_TPM support
> KEYS: trusted: allow use of kernel RNG for key material
> crypto: caam - determine whether CAAM supports blob encap/decap
> crypto: caam - add in-kernel interface for blob generator
> KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
> doc: trusted-encrypted: describe new CAAM trust source
> MAINTAINERS: add KEYS-TRUSTED-CAAM
>
> .../admin-guide/kernel-parameters.txt | 11 ++
> .../security/keys/trusted-encrypted.rst | 60 +++++-
> MAINTAINERS | 9 +
> drivers/crypto/caam/Kconfig | 3 +
> drivers/crypto/caam/Makefile | 1 +
> drivers/crypto/caam/blob_gen.c | 182 ++++++++++++++++++
> drivers/crypto/caam/ctrl.c | 17 +-
> drivers/crypto/caam/intern.h | 1 +
> drivers/crypto/caam/regs.h | 4 +-
> include/keys/trusted-type.h | 2 +-
> include/keys/trusted_caam.h | 11 ++
> include/soc/fsl/caam-blob.h | 103 ++++++++++
> security/keys/Kconfig | 18 +-
> security/keys/trusted-keys/Kconfig | 38 ++++
> security/keys/trusted-keys/Makefile | 10 +-
> security/keys/trusted-keys/trusted_caam.c | 80 ++++++++
> security/keys/trusted-keys/trusted_core.c | 45 ++++-
> 17 files changed, 563 insertions(+), 32 deletions(-)
> create mode 100644 drivers/crypto/caam/blob_gen.c
> create mode 100644 include/keys/trusted_caam.h
> create mode 100644 include/soc/fsl/caam-blob.h
> create mode 100644 security/keys/trusted-keys/Kconfig
> create mode 100644 security/keys/trusted-keys/trusted_caam.c
>
> --
> 2.30.2
>
I can probably pick these unless objections?
BR, Jarkko
On Tue, 2022-05-17 at 14:44 +0200, Ahmad Fatoum wrote:
> Hello Herbert,
>
> On 16.05.22 20:36, Jarkko Sakkinen wrote:
> > On Fri, May 13, 2022 at 04:56:58PM +0200, Ahmad Fatoum wrote:
> > I can probably pick these unless objections?
>
> Pankaj has given his Reviewed-by for the CAAM parts he co-maintains,
> is it ok for this to go in via Jarkko's tree?
>
> Note that applying this series on top of jarkko/linux-tpmdd.git has a
> trivial conflict when merged with herbert/cryptodev-2.6.git:
> Two independently added Kconfig options need to coexist in
> drivers/crypto/caam/Kconfig.
>
> I can resend my series rebased if needed.
>
> Cheers,
> Ahmad
>
> >
> > BR, Jarkko
> >
>
>
This came up:
https://lore.kernel.org/keyrings/[email protected]/
BR, Jarkko
On Wed, May 18, 2022 at 05:58:09PM +0300, Jarkko Sakkinen wrote:
> On Wed, May 18, 2022 at 06:36:18AM +0200, Ahmad Fatoum wrote:
> > On 18.05.22 03:08, Jarkko Sakkinen wrote:
> > > On Tue, 2022-05-17 at 14:44 +0200, Ahmad Fatoum wrote:
> > >> Hello Herbert,
> > >>
> > >> On 16.05.22 20:36, Jarkko Sakkinen wrote:
> > >>> On Fri, May 13, 2022 at 04:56:58PM +0200, Ahmad Fatoum wrote:
> > >>> I can probably pick these unless objections?
> > >>
> > >> Pankaj has given his Reviewed-by for the CAAM parts he co-maintains,
> > >> is it ok for this to go in via Jarkko's tree?
> > >>
> > >> Note that applying this series on top of jarkko/linux-tpmdd.git has a
> > >> trivial conflict when merged with herbert/cryptodev-2.6.git:
> > >> Two independently added Kconfig options need to coexist in
> > >> drivers/crypto/caam/Kconfig.
> > >>
> > >> I can resend my series rebased if needed.
> > >>
> > >> Cheers,
> > >> Ahmad
> > >>
> > >>>
> > >>> BR, Jarkko
> > >>>
> > >>
> > >>
> > >
> > > This came up:
> > >
> > > https://lore.kernel.org/keyrings/[email protected]/
> >
> > And it turned out to be a misunderstanding. Or do you think there is still anything
> > to do there?
> >
> > Thanks,
> > Ahmad
>
> Oops, you're right, sorry.
>
> Yeah, I guess I can pick these patches now.
Applied:
https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=next
BR, Jarkko