All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
@ 2021-07-21 16:48 Ahmad Fatoum
  2021-07-21 16:48 ` [PATCH 1/4] KEYS: trusted: allow users to use kernel RNG for key material Ahmad Fatoum
                   ` (5 more replies)
  0 siblings, 6 replies; 28+ messages in thread
From: Ahmad Fatoum @ 2021-07-21 16:48 UTC (permalink / raw)
  To: Jarkko Sakkinen, Horia Geantă,
	Mimi Zohar, Aymen Sghaier, Herbert Xu, David S. Miller,
	James Bottomley
  Cc: kernel, David Howells, James Morris, Serge E. Hallyn,
	Steffen Trumtrar, Udit Agarwal, Jan Luebbe, David Gstir,
	Eric Biggers, Richard Weinberger, Franck LENORMAND, Sumit Garg,
	linux-integrity, keyrings, linux-crypto, linux-kernel,
	linux-security-module

Series applies on top of
https://lore.kernel.org/linux-integrity/20210721160258.7024-1-a.fatoum@pengutronix.de/T/#u

v2 -> v3:
 - Split off first Kconfig preparation patch. It fixes a regression,
   so sent that out, so it can be applied separately (Sumit)
 - Split off second key import patch. I'll send that out separately
   as it's a development aid and not required within the CAAM series
 - add MAINTAINERS entry

v1 -> v2:
 - Added new commit to make trusted key Kconfig option independent
   of TPM and added new Kconfig file for trusted keys
 - Add new commit for importing existing key material
 - Allow users to force use of kernel RNG (Jarkko)
 - Enforce maximum keymod size (Horia)
 - Use append_seq_(in|out)_ptr_intlen instead of append_seq_(in|out)_ptr
   (Horia)
 - Make blobifier handle private to CAAM glue code file (Horia)
 - Extend trusted keys documentation for CAAM
 - Rebased and updated original cover letter:

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 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.MX6DL.

Looking forward to your feedback.

Cheers,
Ahmad

 [1]: https://lore.kernel.org/linux-crypto/1447082306-19946-2-git-send-email-s.trumtrar@pengutronix.de/
 [2]: https://lore.kernel.org/linux-integrity/20180723111432.26830-1-udit.agarwal@nxp.com/
 [3]: https://lore.kernel.org/lkml/1551456599-10603-2-git-send-email-franck.lenormand@nxp.com/
 [4]: https://lore.kernel.org/lkml/1604419306-26105-1-git-send-email-sumit.garg@linaro.org/
 [5]: https://lore.kernel.org/linux-integrity/20210122084321.24012-2-a.fatoum@pengutronix.de/

---
To: Jarkko Sakkinen <jarkko@kernel.org>
To: "Horia Geantă" <horia.geanta@nxp.com>
To: Mimi Zohar <zohar@linux.ibm.com>
To: Aymen Sghaier <aymen.sghaier@nxp.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
To: "David S. Miller" <davem@davemloft.net>
To: James Bottomley <jejb@linux.ibm.com>
Cc: David Howells <dhowells@redhat.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Cc: Udit Agarwal <udit.agarwal@nxp.com>
Cc: Jan Luebbe <j.luebbe@pengutronix.de>
Cc: David Gstir <david@sigma-star.at>
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: Franck LENORMAND <franck.lenormand@nxp.com>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: linux-integrity@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org

Ahmad Fatoum (4):
  KEYS: trusted: allow users to use kernel RNG for key material
  KEYS: trusted: allow trust sources to use kernel RNG for key material
  crypto: caam - add in-kernel interface for blob generator
  KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

 Documentation/admin-guide/kernel-parameters.txt   |   8 +-
 Documentation/security/keys/trusted-encrypted.rst |  60 +++-
 MAINTAINERS                                       |   9 +-
 drivers/crypto/caam/Kconfig                       |   3 +-
 drivers/crypto/caam/Makefile                      |   1 +-
 drivers/crypto/caam/blob_gen.c                    | 230 +++++++++++++++-
 include/keys/trusted-type.h                       |   2 +-
 include/keys/trusted_caam.h                       |  11 +-
 include/soc/fsl/caam-blob.h                       |  56 ++++-
 security/keys/trusted-keys/Kconfig                |  11 +-
 security/keys/trusted-keys/Makefile               |   2 +-
 security/keys/trusted-keys/trusted_caam.c         |  74 +++++-
 security/keys/trusted-keys/trusted_core.c         |  23 +-
 13 files changed, 477 insertions(+), 13 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/trusted_caam.c

base-commit: 97408d81ed533b953326c580ff2c3f1948b3fcee
-- 
git-series 0.9.1

^ permalink raw reply	[flat|nested] 28+ messages in thread

* [PATCH 1/4] KEYS: trusted: allow users to use kernel RNG for key material
  2021-07-21 16:48 [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
@ 2021-07-21 16:48 ` Ahmad Fatoum
  2021-07-22  6:17   ` Sumit Garg
  2021-07-21 16:48 ` [PATCH 2/4] KEYS: trusted: allow trust sources " Ahmad Fatoum
                   ` (4 subsequent siblings)
  5 siblings, 1 reply; 28+ messages in thread
From: Ahmad Fatoum @ 2021-07-21 16:48 UTC (permalink / raw)
  To: James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells
  Cc: kernel, Ahmad Fatoum, James Morris, Serge E. Hallyn,
	Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, Udit Agarwal,
	Jan Luebbe, Eric Biggers, David Gstir, Richard Weinberger,
	Franck LENORMAND, Sumit Garg, keyrings, linux-crypto,
	linux-integrity, linux-kernel, linux-security-module

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, Users may want to place
less trust into the quality of the trust source's random number
generator and instead use the kernel entropy pool, which can be
seeded from multiple entropy sources.

Make this possible by adding a new trusted.kernel_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>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: James Bottomley <jejb@linux.ibm.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: Mimi Zohar <zohar@linux.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: "Horia Geantă" <horia.geanta@nxp.com>
Cc: Aymen Sghaier <aymen.sghaier@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Udit Agarwal <udit.agarwal@nxp.com>
Cc: Jan Luebbe <j.luebbe@pengutronix.de>
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: David Gstir <david@sigma-star.at>
Cc: Richard Weinberger <richard@nod.at>
Cc: Franck LENORMAND <franck.lenormand@nxp.com>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: keyrings@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt   |  7 ++++++-
 Documentation/security/keys/trusted-encrypted.rst | 20 +++++++++-------
 security/keys/trusted-keys/trusted_core.c         | 17 +++++++++++++-
 3 files changed, 35 insertions(+), 9 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index bdb22006f713..0267ead88902 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5734,6 +5734,13 @@
 			first trust source as a backend which is initialized
 			successfully during iteration.
 
+	trusted.kernel_rng =	[KEYS]
+			Format: <bool>
+			When set to true (1), the kernel random number pool
+			is used to generate key material for trusted keys.
+			The default is to leave the RNG's choice to each
+			individual trust source.
+
 	tsc=		Disable clocksource stability checks for TSC.
 			Format: <string>
 			[x86] reliable: mark tsc clocksource as reliable, this
diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index 80d5a5af62a1..1d4b4b8f12f0 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -87,22 +87,26 @@ Key Generation
 Trusted Keys
 ------------
 
-New keys are created from random numbers generated in the trust source. They
-are encrypted/decrypted using a child key in the storage key hierarchy.
-Encryption and decryption of the child key must be protected by a strong
-access control policy within the trust source.
+New keys are created from random numbers. They are encrypted/decrypted using
+a child key in the storage key hierarchy. Encryption and decryption of the
+child key must be protected by a strong access control policy within the
+trust source. The random number generator in use differs according to the
+selected trust source:
 
-  *  TPM (hardware device) based RNG
+  *  TPM: hardware device based RNG
 
-     Strength of random numbers may vary from one device manufacturer to
-     another.
+     Keys are generated within the TPM. Strength of random numbers may vary
+     from one device manufacturer to another.
 
-  *  TEE (OP-TEE based on Arm TrustZone) based RNG
+  *  TEE: OP-TEE based on Arm TrustZone based RNG
 
      RNG is customizable as per platform needs. It can either be direct output
      from platform specific hardware RNG or a software based Fortuna CSPRNG
      which can be seeded via multiple entropy sources.
 
+Optionally, users may specify ``trusted.kernel_rng=1`` on the kernel
+command-line to override the used RNG with the kernel's random number pool.
+
 Encrypted Keys
 --------------
 
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index 8cab69e5d0da..569af9af8df0 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -16,12 +16,17 @@
 #include <linux/key-type.h>
 #include <linux/module.h>
 #include <linux/parser.h>
+#include <linux/random.h>
 #include <linux/rcupdate.h>
 #include <linux/slab.h>
 #include <linux/static_call.h>
 #include <linux/string.h>
 #include <linux/uaccess.h>
 
+static bool trusted_kernel_rng;
+module_param_named(kernel_rng, trusted_kernel_rng, bool, 0);
+MODULE_PARM_DESC(kernel_rng, "Generate key material from kernel 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)");
@@ -312,8 +317,14 @@ struct key_type key_type_trusted = {
 };
 EXPORT_SYMBOL_GPL(key_type_trusted);
 
+static int kernel_get_random(unsigned char *key, size_t key_len)
+{
+	return get_random_bytes_wait(key, key_len) ?: key_len;
+}
+
 static int __init init_trusted(void)
 {
+	int (*get_random)(unsigned char *key, size_t key_len);
 	int i, ret = 0;
 
 	for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) {
@@ -322,6 +333,10 @@ static int __init init_trusted(void)
 			    strlen(trusted_key_sources[i].name)))
 			continue;
 
+		get_random = trusted_key_sources[i].ops->get_random;
+		if (trusted_kernel_rng)
+			get_random = kernel_get_random;
+
 		static_call_update(trusted_key_init,
 				   trusted_key_sources[i].ops->init);
 		static_call_update(trusted_key_seal,
@@ -329,7 +344,7 @@ static int __init init_trusted(void)
 		static_call_update(trusted_key_unseal,
 				   trusted_key_sources[i].ops->unseal);
 		static_call_update(trusted_key_get_random,
-				   trusted_key_sources[i].ops->get_random);
+				   get_random);
 		static_call_update(trusted_key_exit,
 				   trusted_key_sources[i].ops->exit);
 		migratable = trusted_key_sources[i].ops->migratable;
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH 2/4] KEYS: trusted: allow trust sources to use kernel RNG for key material
  2021-07-21 16:48 [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
  2021-07-21 16:48 ` [PATCH 1/4] KEYS: trusted: allow users to use kernel RNG for key material Ahmad Fatoum
@ 2021-07-21 16:48 ` Ahmad Fatoum
  2021-07-22  6:31   ` Sumit Garg
  2021-07-21 16:48 ` [PATCH 3/4] crypto: caam - add in-kernel interface for blob generator Ahmad Fatoum
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 28+ messages in thread
From: Ahmad Fatoum @ 2021-07-21 16:48 UTC (permalink / raw)
  To: James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells
  Cc: kernel, Ahmad Fatoum, James Morris, Serge E. Hallyn,
	Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, Udit Agarwal,
	Eric Biggers, Jan Luebbe, David Gstir, Richard Weinberger,
	Franck LENORMAND, Sumit Garg, keyrings, linux-crypto,
	linux-integrity, linux-kernel, linux-security-module

The two existing trusted key sources don't make use of the kernel RNG,
but instead let the hardware that does the sealing/unsealing also
generate the random key material. While a previous change offers users
the choice to use the kernel RNG instead for both, new trust sources
may want to unconditionally use the kernel RNG for generating key
material, like it's done elsewhere in the kernel.

This is especially prudent for hardware that has proven-in-production
HWRNG drivers implemented, as otherwise code would have to be duplicated
only to arrive at a possibly worse result.

Make this possible by turning struct trusted_key_ops::get_random
into an optional member. If a driver leaves it NULL, kernel RNG
will be used instead.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: James Bottomley <jejb@linux.ibm.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: Mimi Zohar <zohar@linux.ibm.com>
To: David Howells <dhowells@redhat.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: "Horia Geantă" <horia.geanta@nxp.com>
Cc: Aymen Sghaier <aymen.sghaier@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Udit Agarwal <udit.agarwal@nxp.com>
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: Jan Luebbe <j.luebbe@pengutronix.de>
Cc: David Gstir <david@sigma-star.at>
Cc: Richard Weinberger <richard@nod.at>
Cc: Franck LENORMAND <franck.lenormand@nxp.com>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: keyrings@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
---
 include/keys/trusted-type.h               | 2 +-
 security/keys/trusted-keys/trusted_core.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index d89fa2579ac0..4eb64548a74f 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -64,7 +64,7 @@ struct trusted_key_ops {
 	/* Unseal a key. */
 	int (*unseal)(struct trusted_key_payload *p, char *datablob);
 
-	/* Get a randomized key. */
+	/* Optional: Get a randomized key. */
 	int (*get_random)(unsigned char *key, size_t key_len);
 
 	/* Exit key interface. */
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index 569af9af8df0..d2b7626cde8b 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -334,7 +334,7 @@ static int __init init_trusted(void)
 			continue;
 
 		get_random = trusted_key_sources[i].ops->get_random;
-		if (trusted_kernel_rng)
+		if (trusted_kernel_rng || !get_random)
 			get_random = kernel_get_random;
 
 		static_call_update(trusted_key_init,
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH 3/4] crypto: caam - add in-kernel interface for blob generator
  2021-07-21 16:48 [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
  2021-07-21 16:48 ` [PATCH 1/4] KEYS: trusted: allow users to use kernel RNG for key material Ahmad Fatoum
  2021-07-21 16:48 ` [PATCH 2/4] KEYS: trusted: allow trust sources " Ahmad Fatoum
@ 2021-07-21 16:48 ` Ahmad Fatoum
  2021-08-10 11:29   ` David Gstir
  2021-07-21 16:48 ` [PATCH 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
                   ` (2 subsequent siblings)
  5 siblings, 1 reply; 28+ messages in thread
From: Ahmad Fatoum @ 2021-07-21 16:48 UTC (permalink / raw)
  To: Horia Geantă, Aymen Sghaier, Herbert Xu, David S. Miller
  Cc: kernel, Ahmad Fatoum, James Bottomley, Jarkko Sakkinen,
	Mimi Zohar, David Howells, James Morris, Eric Biggers,
	Serge E. Hallyn, Udit Agarwal, Jan Luebbe, David Gstir,
	Richard Weinberger, Franck LENORMAND, Sumit Garg,
	linux-integrity, keyrings, linux-crypto, linux-kernel,
	linux-security-module

The CAAM can be used to protect user-defined data across system reboot:

  - When the system is fused and boots into secure state, the master
    key is a unique never-disclosed device-specific key
  - random key is encrypted by key derived from master key
  - data is encrypted using the random key
  - encrypted data and its encrypted random key are stored alongside
  - This blob can now be safely stored in non-volatile memory

On next power-on:
  - blob is loaded into CAAM
  - CAAM writes decrypted data either into memory or key register

Add functions to realize encrypting and decrypting into memory alongside
the CAAM driver.

They will be used in a later commit as a source for the trusted key
seal/unseal mechanism.

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: "Horia Geantă" <horia.geanta@nxp.com>
To: Aymen Sghaier <aymen.sghaier@nxp.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
To: "David S. Miller" <davem@davemloft.net>
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: Eric Biggers <ebiggers@kernel.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Udit Agarwal <udit.agarwal@nxp.com>
Cc: Jan Luebbe <j.luebbe@pengutronix.de>
Cc: David Gstir <david@sigma-star.at>
Cc: Richard Weinberger <richard@nod.at>
Cc: Franck LENORMAND <franck.lenormand@nxp.com>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: linux-integrity@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
---
 drivers/crypto/caam/Kconfig    |   3 +-
 drivers/crypto/caam/Makefile   |   1 +-
 drivers/crypto/caam/blob_gen.c | 230 ++++++++++++++++++++++++++++++++++-
 include/soc/fsl/caam-blob.h    |  56 ++++++++-
 4 files changed, 290 insertions(+)
 create mode 100644 drivers/crypto/caam/blob_gen.c
 create mode 100644 include/soc/fsl/caam-blob.h

diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig
index 84ea7cba5ee5..ea9f8b1ae981 100644
--- a/drivers/crypto/caam/Kconfig
+++ b/drivers/crypto/caam/Kconfig
@@ -151,6 +151,9 @@ config CRYPTO_DEV_FSL_CAAM_RNG_API
 	  Selecting this will register the SEC4 hardware rng to
 	  the hw_random API for supplying the kernel entropy pool.
 
+config CRYPTO_DEV_FSL_CAAM_BLOB_GEN
+	bool
+
 endif # CRYPTO_DEV_FSL_CAAM_JR
 
 endif # CRYPTO_DEV_FSL_CAAM
diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile
index 3570286eb9ce..25f7ae5a4642 100644
--- a/drivers/crypto/caam/Makefile
+++ b/drivers/crypto/caam/Makefile
@@ -21,6 +21,7 @@ caam_jr-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI) += caamalg_qi.o
 caam_jr-$(CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API) += caamhash.o
 caam_jr-$(CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API) += caamrng.o
 caam_jr-$(CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API) += caampkc.o pkc_desc.o
+caam_jr-$(CONFIG_CRYPTO_DEV_FSL_CAAM_BLOB_GEN) += blob_gen.o
 
 caam-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI) += qi.o
 ifneq ($(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API_QI),)
diff --git a/drivers/crypto/caam/blob_gen.c b/drivers/crypto/caam/blob_gen.c
new file mode 100644
index 000000000000..513d3f90e438
--- /dev/null
+++ b/drivers/crypto/caam/blob_gen.c
@@ -0,0 +1,230 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2015 Pengutronix, Steffen Trumtrar <kernel@pengutronix.de>
+ * Copyright (C) 2021 Pengutronix, Ahmad Fatoum <kernel@pengutronix.de>
+ */
+
+#include <linux/device.h>
+#include <soc/fsl/caam-blob.h>
+
+#include "compat.h"
+#include "desc_constr.h"
+#include "desc.h"
+#include "error.h"
+#include "intern.h"
+#include "jr.h"
+#include "regs.h"
+
+struct caam_blob_priv {
+	struct device jrdev;
+};
+
+struct caam_blob_job_result {
+	int err;
+	struct completion completion;
+};
+
+static void caam_blob_job_done(struct device *dev, u32 *desc, u32 err, void *context)
+{
+	struct caam_blob_job_result *res = context;
+	int ecode = 0;
+
+	dev_dbg(dev, "%s %d: err 0x%x\n", __func__, __LINE__, err);
+
+	if (err)
+		ecode = caam_jr_strstatus(dev, err);
+
+	res->err = ecode;
+
+	/*
+	 * Upon completion, desc points to a buffer containing a CAAM job
+	 * descriptor which encapsulates data into an externally-storable
+	 * blob.
+	 */
+	complete(&res->completion);
+}
+
+static u32 *caam_blob_alloc_desc(size_t keymod_len)
+{
+	size_t len;
+
+	/* header + (key mod immediate) + 2x pointers + op */
+	len = 4 + (4 + ALIGN(keymod_len, 4)) + 2*(4 + 4 + CAAM_PTR_SZ_MAX) + 4;
+
+	if (len > CAAM_DESC_BYTES_MAX)
+		return NULL;
+
+	return kzalloc(len, GFP_KERNEL | GFP_DMA);
+}
+
+int caam_encap_blob(struct caam_blob_priv *priv, const char *keymod,
+		    void *input, void *output, size_t length)
+{
+	u32 *desc;
+	struct device *jrdev = &priv->jrdev;
+	dma_addr_t dma_in, dma_out;
+	struct caam_blob_job_result testres;
+	size_t keymod_len = strlen(keymod);
+	int ret;
+
+	if (length <= CAAM_BLOB_OVERHEAD || keymod_len > CAAM_BLOB_KEYMOD_LENGTH)
+		return -EINVAL;
+
+	desc = caam_blob_alloc_desc(keymod_len);
+	if (!desc) {
+		dev_err(jrdev, "unable to allocate desc\n");
+		return -ENOMEM;
+	}
+
+	dma_in = dma_map_single(jrdev, input, length - CAAM_BLOB_OVERHEAD, DMA_TO_DEVICE);
+	if (dma_mapping_error(jrdev, dma_in)) {
+		dev_err(jrdev, "unable to map input DMA buffer\n");
+		ret = -ENOMEM;
+		goto out_free;
+	}
+
+	dma_out = dma_map_single(jrdev, output, length,	DMA_FROM_DEVICE);
+	if (dma_mapping_error(jrdev, dma_out)) {
+		dev_err(jrdev, "unable to map output DMA buffer\n");
+		ret = -ENOMEM;
+		goto out_unmap_in;
+	}
+
+	/*
+	 * A data blob is encrypted using a blob key (BK); a random number.
+	 * The BK is used as an AES-CCM key. The initial block (B0) and the
+	 * initial counter (Ctr0) are generated automatically and stored in
+	 * Class 1 Context DWords 0+1+2+3. The random BK is stored in the
+	 * Class 1 Key Register. Operation Mode is set to AES-CCM.
+	 */
+
+	init_job_desc(desc, 0);
+	append_key_as_imm(desc, keymod, keymod_len, keymod_len,
+			  CLASS_2 | KEY_DEST_CLASS_REG);
+	append_seq_in_ptr_intlen(desc, dma_in, length - CAAM_BLOB_OVERHEAD, 0);
+	append_seq_out_ptr_intlen(desc, dma_out, length, 0);
+	append_operation(desc, OP_TYPE_ENCAP_PROTOCOL | OP_PCLID_BLOB);
+
+	print_hex_dump_debug("data@"__stringify(__LINE__)": ",
+			     DUMP_PREFIX_ADDRESS, 16, 1, input,
+			     length - CAAM_BLOB_OVERHEAD, false);
+	print_hex_dump_debug("jobdesc@"__stringify(__LINE__)": ",
+			     DUMP_PREFIX_ADDRESS, 16, 1, desc,
+			     desc_bytes(desc), false);
+
+	testres.err = 0;
+	init_completion(&testres.completion);
+
+	ret = caam_jr_enqueue(jrdev, desc, caam_blob_job_done, &testres);
+	if (ret == -EINPROGRESS) {
+		wait_for_completion(&testres.completion);
+		ret = testres.err;
+		print_hex_dump_debug("output@"__stringify(__LINE__)": ",
+				     DUMP_PREFIX_ADDRESS, 16, 1, output,
+				     length, false);
+	}
+
+	dma_unmap_single(jrdev, dma_out, length, DMA_FROM_DEVICE);
+out_unmap_in:
+	dma_unmap_single(jrdev, dma_in, length - CAAM_BLOB_OVERHEAD, DMA_TO_DEVICE);
+out_free:
+	kfree(desc);
+
+	return ret;
+}
+EXPORT_SYMBOL(caam_encap_blob);
+
+int caam_decap_blob(struct caam_blob_priv *priv, const char *keymod,
+		    void *input, void *output, size_t length)
+{
+	u32 *desc;
+	struct device *jrdev = &priv->jrdev;
+	dma_addr_t dma_in, dma_out;
+	struct caam_blob_job_result testres;
+	size_t keymod_len = strlen(keymod);
+	int ret;
+
+	if (length <= CAAM_BLOB_OVERHEAD || keymod_len > CAAM_BLOB_KEYMOD_LENGTH)
+		return -EINVAL;
+
+	desc = caam_blob_alloc_desc(keymod_len);
+	if (!desc) {
+		dev_err(jrdev, "unable to allocate desc\n");
+		return -ENOMEM;
+	}
+
+	dma_in = dma_map_single(jrdev, input, length, DMA_TO_DEVICE);
+	if (dma_mapping_error(jrdev, dma_in)) {
+		dev_err(jrdev, "unable to map input DMA buffer\n");
+		ret = -ENOMEM;
+		goto out_free;
+	}
+
+	dma_out = dma_map_single(jrdev, output, length - CAAM_BLOB_OVERHEAD, DMA_FROM_DEVICE);
+	if (dma_mapping_error(jrdev, dma_out)) {
+		dev_err(jrdev, "unable to map output DMA buffer\n");
+		ret = -ENOMEM;
+		goto out_unmap_in;
+	}
+
+	/*
+	 * A data blob is encrypted using a blob key (BK); a random number.
+	 * The BK is used as an AES-CCM key. The initial block (B0) and the
+	 * initial counter (Ctr0) are generated automatically and stored in
+	 * Class 1 Context DWords 0+1+2+3. The random BK is stored in the
+	 * Class 1 Key Register. Operation Mode is set to AES-CCM.
+	 */
+
+	init_job_desc(desc, 0);
+	append_key_as_imm(desc, keymod, keymod_len, keymod_len,
+			  CLASS_2 | KEY_DEST_CLASS_REG);
+	append_seq_in_ptr(desc, dma_in, length, 0);
+	append_seq_out_ptr(desc, dma_out, length - CAAM_BLOB_OVERHEAD, 0);
+	append_operation(desc, OP_TYPE_DECAP_PROTOCOL | OP_PCLID_BLOB);
+
+	print_hex_dump_debug("data@"__stringify(__LINE__)": ",
+			     DUMP_PREFIX_ADDRESS, 16, 1, input,
+			     length, false);
+	print_hex_dump_debug("jobdesc@"__stringify(__LINE__)": ",
+			     DUMP_PREFIX_ADDRESS, 16, 1, desc,
+			     desc_bytes(desc), false);
+
+	testres.err = 0;
+	init_completion(&testres.completion);
+
+	ret = caam_jr_enqueue(jrdev, desc, caam_blob_job_done, &testres);
+	if (ret == -EINPROGRESS) {
+		wait_for_completion(&testres.completion);
+		ret = testres.err;
+		print_hex_dump_debug("output@"__stringify(__LINE__)": ",
+				     DUMP_PREFIX_ADDRESS, 16, 1, output,
+				     length - CAAM_BLOB_OVERHEAD, false);
+	}
+
+	dma_unmap_single(jrdev, dma_out, length - CAAM_BLOB_OVERHEAD, DMA_FROM_DEVICE);
+out_unmap_in:
+	dma_unmap_single(jrdev, dma_in, length, DMA_TO_DEVICE);
+out_free:
+	kfree(desc);
+
+	return ret;
+}
+EXPORT_SYMBOL(caam_decap_blob);
+
+struct caam_blob_priv *caam_blob_gen_init(void)
+{
+	struct device *jrdev;
+
+	jrdev = caam_jr_alloc();
+	if (IS_ERR(jrdev))
+		return ERR_CAST(jrdev);
+
+	return container_of(jrdev, struct caam_blob_priv, jrdev);
+}
+EXPORT_SYMBOL(caam_blob_gen_init);
+
+void caam_blob_gen_exit(struct caam_blob_priv *priv)
+{
+	caam_jr_free(&priv->jrdev);
+}
+EXPORT_SYMBOL(caam_blob_gen_exit);
diff --git a/include/soc/fsl/caam-blob.h b/include/soc/fsl/caam-blob.h
new file mode 100644
index 000000000000..aebbc9335f64
--- /dev/null
+++ b/include/soc/fsl/caam-blob.h
@@ -0,0 +1,56 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2020 Pengutronix, Ahmad Fatoum <kernel@pengutronix.de>
+ */
+
+#ifndef __CAAM_BLOB_GEN
+#define __CAAM_BLOB_GEN
+
+#include <linux/types.h>
+
+#define CAAM_BLOB_KEYMOD_LENGTH		16
+#define CAAM_BLOB_OVERHEAD		(32 + 16)
+#define CAAM_BLOB_MAX_LEN		4096
+
+struct caam_blob_priv;
+
+/** caam_blob_gen_init - initialize blob generation
+ *
+ * returns either pointer to new caam_blob_priv instance
+ * or error pointer
+ */
+struct caam_blob_priv *caam_blob_gen_init(void);
+
+/** caam_blob_gen_init - free blob generation resources
+ *
+ * @priv: instance returned by caam_blob_gen_init
+ */
+void caam_blob_gen_exit(struct caam_blob_priv *priv);
+
+/** caam_encap_blob - encapsulate blob
+ *
+ * @priv:   instance returned by caam_blob_gen_init
+ * @keymod: string to use as key modifier for blob encapsulation
+ *	    can't be longer than CAAM_BLOB_KEYMOD_LENGTH
+ * @input:  buffer which CAAM will DMA from
+ * @output: buffer which CAAM will DMA to
+ * @length: buffer length including blob overhead
+ *          CAAM_BLOB_OVERHEAD < length <= CAAM_BLOB_MAX_LEN
+ */
+int caam_encap_blob(struct caam_blob_priv *priv, const char *keymod,
+		    void *input, void *output, size_t length);
+
+/** caam_decap_blob - decapsulate blob
+ *
+ * @priv:   instance returned by caam_blob_gen_init
+ * @keymod: string to use as key modifier for blob decapsulation
+ *	    can't be longer than CAAM_BLOB_KEYMOD_LENGTH
+ * @input:  buffer which CAAM will DMA from
+ * @output: buffer which CAAM will DMA to
+ * @length: buffer length including blob overhead
+ *          CAAM_BLOB_OVERHEAD < length <= CAAM_BLOB_MAX_LEN
+ */
+int caam_decap_blob(struct caam_blob_priv *priv, const char *keymod,
+		    void *input, void *output, size_t length);
+
+#endif
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* [PATCH 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-07-21 16:48 [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
                   ` (2 preceding siblings ...)
  2021-07-21 16:48 ` [PATCH 3/4] crypto: caam - add in-kernel interface for blob generator Ahmad Fatoum
@ 2021-07-21 16:48 ` Ahmad Fatoum
  2021-08-06 15:12 ` [PATCH 0/4] " Ahmad Fatoum
  2021-08-20 15:39 ` Tim Harvey
  5 siblings, 0 replies; 28+ messages in thread
From: Ahmad Fatoum @ 2021-07-21 16:48 UTC (permalink / raw)
  To: Jonathan Corbet, David Howells, Jarkko Sakkinen, James Bottomley,
	Mimi Zohar
  Cc: kernel, Ahmad Fatoum, James Morris, Serge E. Hallyn,
	Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, Udit Agarwal,
	Eric Biggers, Jan Luebbe, David Gstir, Richard Weinberger,
	Franck LENORMAND, Sumit Garg, keyrings, linux-crypto, linux-doc,
	linux-integrity, linux-kernel, linux-security-module

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.

Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
To: Jonathan Corbet <corbet@lwn.net>
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Bottomley <jejb@linux.ibm.com>
To: Mimi Zohar <zohar@linux.ibm.com>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: "Horia Geantă" <horia.geanta@nxp.com>
Cc: Aymen Sghaier <aymen.sghaier@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Udit Agarwal <udit.agarwal@nxp.com>
Cc: Eric Biggers <ebiggers@kernel.org>
Cc: Jan Luebbe <j.luebbe@pengutronix.de>
Cc: David Gstir <david@sigma-star.at>
Cc: Richard Weinberger <richard@nod.at>
Cc: Franck LENORMAND <franck.lenormand@nxp.com>
Cc: Sumit Garg <sumit.garg@linaro.org>
Cc: keyrings@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
---
 Documentation/admin-guide/kernel-parameters.txt   |  1 +-
 Documentation/security/keys/trusted-encrypted.rst | 42 ++++++++-
 MAINTAINERS                                       |  9 ++-
 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         | 74 ++++++++++++++++-
 security/keys/trusted-keys/trusted_core.c         |  6 +-
 8 files changed, 152 insertions(+), 4 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 0267ead88902..43010cb27f17 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5729,6 +5729,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/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index 1d4b4b8f12f0..ad66573ca6fd 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -35,6 +35,13 @@ safe.
          Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip
          fuses and is accessible to TEE only.
 
+     (3) CAAM (Cryptographic Acceleration and Assurance Module: IP on NXP SoCs)
+
+         When High Assurance Boot (HAB) is enabled and the CAAM is in secure
+         mode, trust is rooted to the OTPMK, a never-disclosed 256-bit key
+         randomly generated and fused into each SoC at manufacturing time.
+         Otherwise, a common fixed test key is used instead.
+
   *  Execution isolation
 
      (1) TPM
@@ -46,6 +53,10 @@ safe.
          Customizable set of operations running in isolated execution
          environment verified via Secure/Trusted boot process.
 
+     (3) CAAM
+
+         Fixed set of operations running in isolated execution environment.
+
   * Optional binding to platform integrity state
 
      (1) TPM
@@ -63,6 +74,11 @@ safe.
          Relies on Secure/Trusted boot process for platform integrity. It can
          be extended with TEE based measured boot process.
 
+     (3) CAAM
+
+         Relies on the High Assurance Boot (HAB) mechanism of NXP SoCs
+         for platform integrity.
+
   *  Interfaces and APIs
 
      (1) TPM
@@ -74,10 +90,13 @@ safe.
          TEEs have well-documented, standardized client interface and APIs. For
          more details refer to ``Documentation/staging/tee.rst``.
 
+     (3) CAAM
+
+         Interface is specific to silicon vendor.
 
   *  Threat model
 
-     The strength and appropriateness of a particular TPM or TEE for a given
+     The strength and appropriateness of a particular trust source for a given
      purpose must be assessed when using them to protect security-relevant data.
 
 
@@ -104,8 +123,14 @@ selected trust source:
      from platform specific hardware RNG or a software based Fortuna CSPRNG
      which can be seeded via multiple entropy sources.
 
+  *  CAAM: Kernel RNG
+
+     The normal kernel random number generator is used. To seed it from the
+     CAAM HWRNG, enable CRYPTO_DEV_FSL_CAAM_RNG_API and ensure the device
+     can be probed.
+
 Optionally, users may specify ``trusted.kernel_rng=1`` on the kernel
-command-line to override the used RNG with the kernel's random number pool.
+command-line to force use of the kernel's random number pool.
 
 Encrypted Keys
 --------------
@@ -192,6 +217,19 @@ Usage::
 specific to TEE device implementation.  The key length for new keys is always
 in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
 
+Trusted Keys usage: CAAM
+------------------------
+
+Usage::
+
+    keyctl add trusted name "new keylen" ring
+    keyctl add trusted name "load hex_blob" ring
+    keyctl print keyid
+
+"keyctl print" returns an ASCII hex copy of the sealed key, which is in format
+specific to CAAM device implementation.  The key length for new keys is always
+in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
+
 Encrypted Keys usage
 --------------------
 
diff --git a/MAINTAINERS b/MAINTAINERS
index 6c8be735cc91..aa654e69075d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10265,6 +10265,15 @@ S:	Supported
 F:	include/keys/trusted_tee.h
 F:	security/keys/trusted-keys/trusted_tee.c
 
+KEYS-TRUSTED-CAAM
+M:	Ahmad Fatoum <a.fatoum@pengutronix.de>
+R:	Pengutronix Kernel Team <kernel@pengutronix.de>
+L:	linux-integrity@vger.kernel.org
+L:	keyrings@vger.kernel.org
+S:	Supported
+F:	include/keys/trusted_caam.h
+F:	security/keys/trusted-keys/trusted_caam.c
+
 KEYS/KEYRINGS
 M:	David Howells <dhowells@redhat.com>
 M:	Jarkko Sakkinen <jarkko@kernel.org>
diff --git a/include/keys/trusted_caam.h b/include/keys/trusted_caam.h
new file mode 100644
index 000000000000..2fba0996b0b0
--- /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 <kernel@pengutronix.de>
+ */
+
+#ifndef __CAAM_TRUSTED_KEY_H
+#define __CAAM_TRUSTED_KEY_H
+
+extern struct trusted_key_ops caam_trusted_key_ops;
+
+#endif
diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig
index c163cfeedff6..fac80117ef46 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..01adfd18adda
--- /dev/null
+++ b/security/keys/trusted-keys/trusted_caam.c
@@ -0,0 +1,74 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2021 Pengutronix, Ahmad Fatoum <kernel@pengutronix.de>
+ */
+
+#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 "kernel:trusted"
+
+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 length = p->key_len + CAAM_BLOB_OVERHEAD;
+	int ret;
+
+	ret = caam_encap_blob(blobifier, KEYMOD, p->key, p->blob, length);
+	if (ret)
+		return ret;
+
+	p->blob_len = length;
+	return 0;
+}
+
+static int trusted_caam_unseal(struct trusted_key_payload *p, char *datablob)
+{
+	int length = p->blob_len;
+	int ret;
+
+	ret = caam_decap_blob(blobifier, KEYMOD, p->blob, p->key, length);
+	if (ret)
+		return ret;
+
+	p->key_len = length - CAAM_BLOB_OVERHEAD;
+	return 0;
+}
+
+static int trusted_caam_init(void)
+{
+	int ret;
+
+	blobifier = caam_blob_gen_init();
+	if (IS_ERR(blobifier)) {
+		pr_err("Job Ring Device allocation for transform failed\n");
+		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 caam_trusted_key_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 d2b7626cde8b..305e44651180 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(kernel_rng, "Generate key material from kernel 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", &caam_trusted_key_ops },
+#endif
 };
 
 DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
-- 
git-series 0.9.1

^ permalink raw reply related	[flat|nested] 28+ messages in thread

* Re: [PATCH 1/4] KEYS: trusted: allow users to use kernel RNG for key material
  2021-07-21 16:48 ` [PATCH 1/4] KEYS: trusted: allow users to use kernel RNG for key material Ahmad Fatoum
@ 2021-07-22  6:17   ` Sumit Garg
  0 siblings, 0 replies; 28+ messages in thread
From: Sumit Garg @ 2021-07-22  6:17 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
	kernel, James Morris, Serge E. Hallyn, Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, Udit Agarwal,
	Jan Luebbe, Eric Biggers, David Gstir, Richard Weinberger,
	Franck LENORMAND, open list:ASYMMETRIC KEYS,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, linux-integrity,
	Linux Kernel Mailing List, open list:SECURITY SUBSYSTEM

On Wed, 21 Jul 2021 at 22:19, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> 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, Users may want to place
> less trust into the quality of the trust source's random number
> generator and instead use the kernel entropy pool, which can be
> seeded from multiple entropy sources.
>
> Make this possible by adding a new trusted.kernel_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>
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> To: James Bottomley <jejb@linux.ibm.com>
> To: Jarkko Sakkinen <jarkko@kernel.org>
> To: Mimi Zohar <zohar@linux.ibm.com>
> To: David Howells <dhowells@redhat.com>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: "Horia Geantă" <horia.geanta@nxp.com>
> Cc: Aymen Sghaier <aymen.sghaier@nxp.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Udit Agarwal <udit.agarwal@nxp.com>
> Cc: Jan Luebbe <j.luebbe@pengutronix.de>
> Cc: Eric Biggers <ebiggers@kernel.org>
> Cc: David Gstir <david@sigma-star.at>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: Franck LENORMAND <franck.lenormand@nxp.com>
> Cc: Sumit Garg <sumit.garg@linaro.org>
> Cc: keyrings@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-integrity@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> ---
>  Documentation/admin-guide/kernel-parameters.txt   |  7 ++++++-
>  Documentation/security/keys/trusted-encrypted.rst | 20 +++++++++-------
>  security/keys/trusted-keys/trusted_core.c         | 17 +++++++++++++-
>  3 files changed, 35 insertions(+), 9 deletions(-)
>

Sounds like a reasonable approach to me.

Acked-by: Sumit Garg <sumit.garg@linaro.org>

-Sumit

> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index bdb22006f713..0267ead88902 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5734,6 +5734,13 @@
>                         first trust source as a backend which is initialized
>                         successfully during iteration.
>
> +       trusted.kernel_rng =    [KEYS]
> +                       Format: <bool>
> +                       When set to true (1), the kernel random number pool
> +                       is used to generate key material for trusted keys.
> +                       The default is to leave the RNG's choice to each
> +                       individual trust source.
> +
>         tsc=            Disable clocksource stability checks for TSC.
>                         Format: <string>
>                         [x86] reliable: mark tsc clocksource as reliable, this
> diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
> index 80d5a5af62a1..1d4b4b8f12f0 100644
> --- a/Documentation/security/keys/trusted-encrypted.rst
> +++ b/Documentation/security/keys/trusted-encrypted.rst
> @@ -87,22 +87,26 @@ Key Generation
>  Trusted Keys
>  ------------
>
> -New keys are created from random numbers generated in the trust source. They
> -are encrypted/decrypted using a child key in the storage key hierarchy.
> -Encryption and decryption of the child key must be protected by a strong
> -access control policy within the trust source.
> +New keys are created from random numbers. They are encrypted/decrypted using
> +a child key in the storage key hierarchy. Encryption and decryption of the
> +child key must be protected by a strong access control policy within the
> +trust source. The random number generator in use differs according to the
> +selected trust source:
>
> -  *  TPM (hardware device) based RNG
> +  *  TPM: hardware device based RNG
>
> -     Strength of random numbers may vary from one device manufacturer to
> -     another.
> +     Keys are generated within the TPM. Strength of random numbers may vary
> +     from one device manufacturer to another.
>
> -  *  TEE (OP-TEE based on Arm TrustZone) based RNG
> +  *  TEE: OP-TEE based on Arm TrustZone based RNG
>
>       RNG is customizable as per platform needs. It can either be direct output
>       from platform specific hardware RNG or a software based Fortuna CSPRNG
>       which can be seeded via multiple entropy sources.
>
> +Optionally, users may specify ``trusted.kernel_rng=1`` on the kernel
> +command-line to override the used RNG with the kernel's random number pool.
> +
>  Encrypted Keys
>  --------------
>
> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> index 8cab69e5d0da..569af9af8df0 100644
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -16,12 +16,17 @@
>  #include <linux/key-type.h>
>  #include <linux/module.h>
>  #include <linux/parser.h>
> +#include <linux/random.h>
>  #include <linux/rcupdate.h>
>  #include <linux/slab.h>
>  #include <linux/static_call.h>
>  #include <linux/string.h>
>  #include <linux/uaccess.h>
>
> +static bool trusted_kernel_rng;
> +module_param_named(kernel_rng, trusted_kernel_rng, bool, 0);
> +MODULE_PARM_DESC(kernel_rng, "Generate key material from kernel 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)");
> @@ -312,8 +317,14 @@ struct key_type key_type_trusted = {
>  };
>  EXPORT_SYMBOL_GPL(key_type_trusted);
>
> +static int kernel_get_random(unsigned char *key, size_t key_len)
> +{
> +       return get_random_bytes_wait(key, key_len) ?: key_len;
> +}
> +
>  static int __init init_trusted(void)
>  {
> +       int (*get_random)(unsigned char *key, size_t key_len);
>         int i, ret = 0;
>
>         for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) {
> @@ -322,6 +333,10 @@ static int __init init_trusted(void)
>                             strlen(trusted_key_sources[i].name)))
>                         continue;
>
> +               get_random = trusted_key_sources[i].ops->get_random;
> +               if (trusted_kernel_rng)
> +                       get_random = kernel_get_random;
> +
>                 static_call_update(trusted_key_init,
>                                    trusted_key_sources[i].ops->init);
>                 static_call_update(trusted_key_seal,
> @@ -329,7 +344,7 @@ static int __init init_trusted(void)
>                 static_call_update(trusted_key_unseal,
>                                    trusted_key_sources[i].ops->unseal);
>                 static_call_update(trusted_key_get_random,
> -                                  trusted_key_sources[i].ops->get_random);
> +                                  get_random);
>                 static_call_update(trusted_key_exit,
>                                    trusted_key_sources[i].ops->exit);
>                 migratable = trusted_key_sources[i].ops->migratable;
> --
> git-series 0.9.1

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 2/4] KEYS: trusted: allow trust sources to use kernel RNG for key material
  2021-07-21 16:48 ` [PATCH 2/4] KEYS: trusted: allow trust sources " Ahmad Fatoum
@ 2021-07-22  6:31   ` Sumit Garg
  2021-08-09  7:52     ` Ahmad Fatoum
  0 siblings, 1 reply; 28+ messages in thread
From: Sumit Garg @ 2021-07-22  6:31 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
	kernel, James Morris, Serge E. Hallyn, Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, Udit Agarwal,
	Eric Biggers, Jan Luebbe, David Gstir, Richard Weinberger,
	Franck LENORMAND, open list:ASYMMETRIC KEYS,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, linux-integrity,
	Linux Kernel Mailing List, open list:SECURITY SUBSYSTEM

On Wed, 21 Jul 2021 at 22:19, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> The two existing trusted key sources don't make use of the kernel RNG,
> but instead let the hardware that does the sealing/unsealing also
> generate the random key material. While a previous change offers users
> the choice to use the kernel RNG instead for both, new trust sources
> may want to unconditionally use the kernel RNG for generating key
> material, like it's done elsewhere in the kernel.
>
> This is especially prudent for hardware that has proven-in-production
> HWRNG drivers implemented, as otherwise code would have to be duplicated
> only to arrive at a possibly worse result.
>
> Make this possible by turning struct trusted_key_ops::get_random
> into an optional member. If a driver leaves it NULL, kernel RNG
> will be used instead.
>
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> To: James Bottomley <jejb@linux.ibm.com>
> To: Jarkko Sakkinen <jarkko@kernel.org>
> To: Mimi Zohar <zohar@linux.ibm.com>
> To: David Howells <dhowells@redhat.com>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: "Horia Geantă" <horia.geanta@nxp.com>
> Cc: Aymen Sghaier <aymen.sghaier@nxp.com>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Udit Agarwal <udit.agarwal@nxp.com>
> Cc: Eric Biggers <ebiggers@kernel.org>
> Cc: Jan Luebbe <j.luebbe@pengutronix.de>
> Cc: David Gstir <david@sigma-star.at>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: Franck LENORMAND <franck.lenormand@nxp.com>
> Cc: Sumit Garg <sumit.garg@linaro.org>
> Cc: keyrings@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-integrity@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> ---
>  include/keys/trusted-type.h               | 2 +-
>  security/keys/trusted-keys/trusted_core.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> index d89fa2579ac0..4eb64548a74f 100644
> --- a/include/keys/trusted-type.h
> +++ b/include/keys/trusted-type.h
> @@ -64,7 +64,7 @@ struct trusted_key_ops {
>         /* Unseal a key. */
>         int (*unseal)(struct trusted_key_payload *p, char *datablob);
>
> -       /* Get a randomized key. */
> +       /* Optional: Get a randomized key. */
>         int (*get_random)(unsigned char *key, size_t key_len);
>
>         /* Exit key interface. */
> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> index 569af9af8df0..d2b7626cde8b 100644
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -334,7 +334,7 @@ static int __init init_trusted(void)
>                         continue;
>
>                 get_random = trusted_key_sources[i].ops->get_random;
> -               if (trusted_kernel_rng)
> +               if (trusted_kernel_rng || !get_random)
>                         get_random = kernel_get_random;
>

For ease of understanding, I would prefer to write it as:

                  get_random = trusted_key_sources[i].ops->get_random ?:
                                         kernel_get_random;
                  if (trusted_kernel_rng)
                        get_random = kernel_get_random;

With that:

Acked-by: Sumit Garg <sumit.garg@linaro.org>

-Sumit

>                 static_call_update(trusted_key_init,
> --
> git-series 0.9.1

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-07-21 16:48 [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
                   ` (3 preceding siblings ...)
  2021-07-21 16:48 ` [PATCH 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
@ 2021-08-06 15:12 ` Ahmad Fatoum
  2021-08-09  9:35   ` Jarkko Sakkinen
  2021-08-20 15:39 ` Tim Harvey
  5 siblings, 1 reply; 28+ messages in thread
From: Ahmad Fatoum @ 2021-08-06 15:12 UTC (permalink / raw)
  To: Jarkko Sakkinen, Horia Geantă,
	Mimi Zohar, Aymen Sghaier, Herbert Xu, David S. Miller,
	James Bottomley
  Cc: Jan Luebbe, Udit Agarwal, Sumit Garg, David Gstir, Eric Biggers,
	Franck LENORMAND, Richard Weinberger, James Morris, linux-kernel,
	David Howells, linux-security-module, keyrings, linux-crypto,
	kernel, linux-integrity, Steffen Trumtrar, Serge E. Hallyn

Dear trusted key maintainers,

On 21.07.21 18:48, Ahmad Fatoum wrote:
> Series applies on top of
> https://lore.kernel.org/linux-integrity/20210721160258.7024-1-a.fatoum@pengutronix.de/T/#u
> 
> v2 -> v3:
>  - Split off first Kconfig preparation patch. It fixes a regression,
>    so sent that out, so it can be applied separately (Sumit)
>  - Split off second key import patch. I'll send that out separately
>    as it's a development aid and not required within the CAAM series
>  - add MAINTAINERS entry

Gentle ping. I'd appreciate feedback on this series.

Cheers,
Ahmad

> 
> v1 -> v2:
>  - Added new commit to make trusted key Kconfig option independent
>    of TPM and added new Kconfig file for trusted keys
>  - Add new commit for importing existing key material
>  - Allow users to force use of kernel RNG (Jarkko)
>  - Enforce maximum keymod size (Horia)
>  - Use append_seq_(in|out)_ptr_intlen instead of append_seq_(in|out)_ptr
>    (Horia)
>  - Make blobifier handle private to CAAM glue code file (Horia)
>  - Extend trusted keys documentation for CAAM
>  - Rebased and updated original cover letter:
> 
> 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 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.MX6DL.
> 
> Looking forward to your feedback.
> 
> Cheers,
> Ahmad
> 
>  [1]: https://lore.kernel.org/linux-crypto/1447082306-19946-2-git-send-email-s.trumtrar@pengutronix.de/
>  [2]: https://lore.kernel.org/linux-integrity/20180723111432.26830-1-udit.agarwal@nxp.com/
>  [3]: https://lore.kernel.org/lkml/1551456599-10603-2-git-send-email-franck.lenormand@nxp.com/
>  [4]: https://lore.kernel.org/lkml/1604419306-26105-1-git-send-email-sumit.garg@linaro.org/
>  [5]: https://lore.kernel.org/linux-integrity/20210122084321.24012-2-a.fatoum@pengutronix.de/
> 
> ---
> To: Jarkko Sakkinen <jarkko@kernel.org>
> To: "Horia Geantă" <horia.geanta@nxp.com>
> To: Mimi Zohar <zohar@linux.ibm.com>
> To: Aymen Sghaier <aymen.sghaier@nxp.com>
> To: Herbert Xu <herbert@gondor.apana.org.au>
> To: "David S. Miller" <davem@davemloft.net>
> To: James Bottomley <jejb@linux.ibm.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> Cc: Udit Agarwal <udit.agarwal@nxp.com>
> Cc: Jan Luebbe <j.luebbe@pengutronix.de>
> Cc: David Gstir <david@sigma-star.at>
> Cc: Eric Biggers <ebiggers@kernel.org>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: Franck LENORMAND <franck.lenormand@nxp.com>
> Cc: Sumit Garg <sumit.garg@linaro.org>
> Cc: linux-integrity@vger.kernel.org
> Cc: keyrings@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
> 
> Ahmad Fatoum (4):
>   KEYS: trusted: allow users to use kernel RNG for key material
>   KEYS: trusted: allow trust sources to use kernel RNG for key material
>   crypto: caam - add in-kernel interface for blob generator
>   KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
> 
>  Documentation/admin-guide/kernel-parameters.txt   |   8 +-
>  Documentation/security/keys/trusted-encrypted.rst |  60 +++-
>  MAINTAINERS                                       |   9 +-
>  drivers/crypto/caam/Kconfig                       |   3 +-
>  drivers/crypto/caam/Makefile                      |   1 +-
>  drivers/crypto/caam/blob_gen.c                    | 230 +++++++++++++++-
>  include/keys/trusted-type.h                       |   2 +-
>  include/keys/trusted_caam.h                       |  11 +-
>  include/soc/fsl/caam-blob.h                       |  56 ++++-
>  security/keys/trusted-keys/Kconfig                |  11 +-
>  security/keys/trusted-keys/Makefile               |   2 +-
>  security/keys/trusted-keys/trusted_caam.c         |  74 +++++-
>  security/keys/trusted-keys/trusted_core.c         |  23 +-
>  13 files changed, 477 insertions(+), 13 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/trusted_caam.c
> 
> base-commit: 97408d81ed533b953326c580ff2c3f1948b3fcee
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 2/4] KEYS: trusted: allow trust sources to use kernel RNG for key material
  2021-07-22  6:31   ` Sumit Garg
@ 2021-08-09  7:52     ` Ahmad Fatoum
  2021-08-09  9:56       ` Jarkko Sakkinen
  0 siblings, 1 reply; 28+ messages in thread
From: Ahmad Fatoum @ 2021-08-09  7:52 UTC (permalink / raw)
  To: Sumit Garg
  Cc: James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
	kernel, James Morris, Serge E. Hallyn, Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, Udit Agarwal,
	Eric Biggers, Jan Luebbe, David Gstir, Richard Weinberger,
	Franck LENORMAND, open list:ASYMMETRIC KEYS,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, linux-integrity,
	Linux Kernel Mailing List, open list:SECURITY SUBSYSTEM

Hello Sumit,

On 22.07.21 08:31, Sumit Garg wrote:
> On Wed, 21 Jul 2021 at 22:19, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>
>> The two existing trusted key sources don't make use of the kernel RNG,
>> but instead let the hardware that does the sealing/unsealing also
>> generate the random key material. While a previous change offers users
>> the choice to use the kernel RNG instead for both, new trust sources
>> may want to unconditionally use the kernel RNG for generating key
>> material, like it's done elsewhere in the kernel.
>>
>> This is especially prudent for hardware that has proven-in-production
>> HWRNG drivers implemented, as otherwise code would have to be duplicated
>> only to arrive at a possibly worse result.
>>
>> Make this possible by turning struct trusted_key_ops::get_random
>> into an optional member. If a driver leaves it NULL, kernel RNG
>> will be used instead.
>>
>> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
>> ---
>> To: James Bottomley <jejb@linux.ibm.com>
>> To: Jarkko Sakkinen <jarkko@kernel.org>
>> To: Mimi Zohar <zohar@linux.ibm.com>
>> To: David Howells <dhowells@redhat.com>
>> Cc: James Morris <jmorris@namei.org>
>> Cc: "Serge E. Hallyn" <serge@hallyn.com>
>> Cc: "Horia Geantă" <horia.geanta@nxp.com>
>> Cc: Aymen Sghaier <aymen.sghaier@nxp.com>
>> Cc: Herbert Xu <herbert@gondor.apana.org.au>
>> Cc: "David S. Miller" <davem@davemloft.net>
>> Cc: Udit Agarwal <udit.agarwal@nxp.com>
>> Cc: Eric Biggers <ebiggers@kernel.org>
>> Cc: Jan Luebbe <j.luebbe@pengutronix.de>
>> Cc: David Gstir <david@sigma-star.at>
>> Cc: Richard Weinberger <richard@nod.at>
>> Cc: Franck LENORMAND <franck.lenormand@nxp.com>
>> Cc: Sumit Garg <sumit.garg@linaro.org>
>> Cc: keyrings@vger.kernel.org
>> Cc: linux-crypto@vger.kernel.org
>> Cc: linux-integrity@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-security-module@vger.kernel.org
>> ---
>>  include/keys/trusted-type.h               | 2 +-
>>  security/keys/trusted-keys/trusted_core.c | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
>> index d89fa2579ac0..4eb64548a74f 100644
>> --- a/include/keys/trusted-type.h
>> +++ b/include/keys/trusted-type.h
>> @@ -64,7 +64,7 @@ struct trusted_key_ops {
>>         /* Unseal a key. */
>>         int (*unseal)(struct trusted_key_payload *p, char *datablob);
>>
>> -       /* Get a randomized key. */
>> +       /* Optional: Get a randomized key. */
>>         int (*get_random)(unsigned char *key, size_t key_len);
>>
>>         /* Exit key interface. */
>> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
>> index 569af9af8df0..d2b7626cde8b 100644
>> --- a/security/keys/trusted-keys/trusted_core.c
>> +++ b/security/keys/trusted-keys/trusted_core.c
>> @@ -334,7 +334,7 @@ static int __init init_trusted(void)
>>                         continue;
>>
>>                 get_random = trusted_key_sources[i].ops->get_random;
>> -               if (trusted_kernel_rng)
>> +               if (trusted_kernel_rng || !get_random)
>>                         get_random = kernel_get_random;
>>
> 
> For ease of understanding, I would prefer to write it as:
> 
>                   get_random = trusted_key_sources[i].ops->get_random ?:
>                                          kernel_get_random;
>                   if (trusted_kernel_rng)
>                         get_random = kernel_get_random;
> 
> With that:
> 
> Acked-by: Sumit Garg <sumit.garg@linaro.org>

I don't think it improves readability to split up the conditional.
At least I need to take a second pass over the code to understand
the second conditional.

Cheers,
Ahmad

> 
> -Sumit
> 
>>                 static_call_update(trusted_key_init,
>> --
>> git-series 0.9.1
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-08-06 15:12 ` [PATCH 0/4] " Ahmad Fatoum
@ 2021-08-09  9:35   ` Jarkko Sakkinen
  2021-08-09 10:16     ` Ahmad Fatoum
  0 siblings, 1 reply; 28+ messages in thread
From: Jarkko Sakkinen @ 2021-08-09  9:35 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: Horia Geantă,
	Mimi Zohar, Aymen Sghaier, Herbert Xu, David S. Miller,
	James Bottomley, Jan Luebbe, Udit Agarwal, Sumit Garg,
	David Gstir, Eric Biggers, Franck LENORMAND, Richard Weinberger,
	James Morris, linux-kernel, David Howells, linux-security-module,
	keyrings, linux-crypto, kernel, linux-integrity,
	Steffen Trumtrar, Serge E. Hallyn

On Fri, Aug 06, 2021 at 05:12:19PM +0200, Ahmad Fatoum wrote:
> Dear trusted key maintainers,
> 
> On 21.07.21 18:48, Ahmad Fatoum wrote:
> > Series applies on top of
> > https://lore.kernel.org/linux-integrity/20210721160258.7024-1-a.fatoum@pengutronix.de/T/#u
> > 
> > v2 -> v3:
> >  - Split off first Kconfig preparation patch. It fixes a regression,
> >    so sent that out, so it can be applied separately (Sumit)
> >  - Split off second key import patch. I'll send that out separately
> >    as it's a development aid and not required within the CAAM series
> >  - add MAINTAINERS entry
> 
> Gentle ping. I'd appreciate feedback on this series.

Simple question: what is fscrypt?

/Jarkko

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 2/4] KEYS: trusted: allow trust sources to use kernel RNG for key material
  2021-08-09  7:52     ` Ahmad Fatoum
@ 2021-08-09  9:56       ` Jarkko Sakkinen
  2021-08-10  5:24         ` Sumit Garg
  0 siblings, 1 reply; 28+ messages in thread
From: Jarkko Sakkinen @ 2021-08-09  9:56 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: Sumit Garg, James Bottomley, Mimi Zohar, David Howells, kernel,
	James Morris, Serge E. Hallyn, Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, Udit Agarwal,
	Eric Biggers, Jan Luebbe, David Gstir, Richard Weinberger,
	Franck LENORMAND, open list:ASYMMETRIC KEYS,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, linux-integrity,
	Linux Kernel Mailing List, open list:SECURITY SUBSYSTEM

On Mon, Aug 09, 2021 at 09:52:20AM +0200, Ahmad Fatoum wrote:
> Hello Sumit,
> 
> On 22.07.21 08:31, Sumit Garg wrote:
> > On Wed, 21 Jul 2021 at 22:19, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>
> >> The two existing trusted key sources don't make use of the kernel RNG,
> >> but instead let the hardware that does the sealing/unsealing also
> >> generate the random key material. While a previous change offers users
> >> the choice to use the kernel RNG instead for both, new trust sources
> >> may want to unconditionally use the kernel RNG for generating key
> >> material, like it's done elsewhere in the kernel.
> >>
> >> This is especially prudent for hardware that has proven-in-production
> >> HWRNG drivers implemented, as otherwise code would have to be duplicated
> >> only to arrive at a possibly worse result.
> >>
> >> Make this possible by turning struct trusted_key_ops::get_random
> >> into an optional member. If a driver leaves it NULL, kernel RNG
> >> will be used instead.
> >>
> >> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> >> ---
> >> To: James Bottomley <jejb@linux.ibm.com>
> >> To: Jarkko Sakkinen <jarkko@kernel.org>
> >> To: Mimi Zohar <zohar@linux.ibm.com>
> >> To: David Howells <dhowells@redhat.com>
> >> Cc: James Morris <jmorris@namei.org>
> >> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> >> Cc: "Horia Geantă" <horia.geanta@nxp.com>
> >> Cc: Aymen Sghaier <aymen.sghaier@nxp.com>
> >> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> >> Cc: "David S. Miller" <davem@davemloft.net>
> >> Cc: Udit Agarwal <udit.agarwal@nxp.com>
> >> Cc: Eric Biggers <ebiggers@kernel.org>
> >> Cc: Jan Luebbe <j.luebbe@pengutronix.de>
> >> Cc: David Gstir <david@sigma-star.at>
> >> Cc: Richard Weinberger <richard@nod.at>
> >> Cc: Franck LENORMAND <franck.lenormand@nxp.com>
> >> Cc: Sumit Garg <sumit.garg@linaro.org>
> >> Cc: keyrings@vger.kernel.org
> >> Cc: linux-crypto@vger.kernel.org
> >> Cc: linux-integrity@vger.kernel.org
> >> Cc: linux-kernel@vger.kernel.org
> >> Cc: linux-security-module@vger.kernel.org
> >> ---
> >>  include/keys/trusted-type.h               | 2 +-
> >>  security/keys/trusted-keys/trusted_core.c | 2 +-
> >>  2 files changed, 2 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> >> index d89fa2579ac0..4eb64548a74f 100644
> >> --- a/include/keys/trusted-type.h
> >> +++ b/include/keys/trusted-type.h
> >> @@ -64,7 +64,7 @@ struct trusted_key_ops {
> >>         /* Unseal a key. */
> >>         int (*unseal)(struct trusted_key_payload *p, char *datablob);
> >>
> >> -       /* Get a randomized key. */
> >> +       /* Optional: Get a randomized key. */
> >>         int (*get_random)(unsigned char *key, size_t key_len);
> >>
> >>         /* Exit key interface. */
> >> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> >> index 569af9af8df0..d2b7626cde8b 100644
> >> --- a/security/keys/trusted-keys/trusted_core.c
> >> +++ b/security/keys/trusted-keys/trusted_core.c
> >> @@ -334,7 +334,7 @@ static int __init init_trusted(void)
> >>                         continue;
> >>
> >>                 get_random = trusted_key_sources[i].ops->get_random;
> >> -               if (trusted_kernel_rng)
> >> +               if (trusted_kernel_rng || !get_random)
> >>                         get_random = kernel_get_random;
> >>
> > 
> > For ease of understanding, I would prefer to write it as:
> > 
> >                   get_random = trusted_key_sources[i].ops->get_random ?:
> >                                          kernel_get_random;
> >                   if (trusted_kernel_rng)
> >                         get_random = kernel_get_random;
> > 
> > With that:
> > 
> > Acked-by: Sumit Garg <sumit.garg@linaro.org>
> 
> I don't think it improves readability to split up the conditional.
> At least I need to take a second pass over the code to understand
> the second conditional.

Ternary operators are pain to read, unless a super trivial case.

I'd stick to what you did.

/Jarkko

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-08-09  9:35   ` Jarkko Sakkinen
@ 2021-08-09 10:16     ` Ahmad Fatoum
  2021-08-10 11:28       ` David Gstir
  0 siblings, 1 reply; 28+ messages in thread
From: Ahmad Fatoum @ 2021-08-09 10:16 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Horia Geantă,
	Mimi Zohar, Aymen Sghaier, Herbert Xu, David S. Miller,
	James Bottomley, Jan Luebbe, Udit Agarwal, Sumit Garg,
	David Gstir, Eric Biggers, Franck LENORMAND, Richard Weinberger,
	James Morris, linux-kernel, David Howells, linux-security-module,
	keyrings, linux-crypto, kernel, linux-integrity,
	Steffen Trumtrar, Serge E. Hallyn

On 09.08.21 11:35, Jarkko Sakkinen wrote:
> On Fri, Aug 06, 2021 at 05:12:19PM +0200, Ahmad Fatoum wrote:
>> Dear trusted key maintainers,
>>
>> On 21.07.21 18:48, Ahmad Fatoum wrote:
>>> Series applies on top of
>>> https://lore.kernel.org/linux-integrity/20210721160258.7024-1-a.fatoum@pengutronix.de/T/#u
>>>
>>> v2 -> v3:
>>>  - Split off first Kconfig preparation patch. It fixes a regression,
>>>    so sent that out, so it can be applied separately (Sumit)
>>>  - Split off second key import patch. I'll send that out separately
>>>    as it's a development aid and not required within the CAAM series
>>>  - add MAINTAINERS entry
>>
>> Gentle ping. I'd appreciate feedback on this series.
> 
> Simple question: what is fscrypt?

For supported file systems, fscrypt[1] allows you to encrypt at a directory level.
It has no trusted key integration yet, which is something I am trying to upstream
in parallel to this series, so I eventually can use fscrypt together with CAAM-backed
trusted keys on an unpatched kernel.

If it interests you, I described[2] my CAAM+ubifs+fscrypt use case in the
discussion thread on my fscrypt-trusted-keys v1. Jan, a colleague of mine, held a
talk[3] on the different solutions for authenticated and encrypted storage, which
you may want to check out.

I'd really appreciate feedback here on the the CAAM parts of this series, so this can
eventually go mainline.

Thanks,
Ahmad


[1]: https://www.kernel.org/doc/html/v5.13/filesystems/fscrypt.html
[2]: https://lore.kernel.org/linux-fscrypt/367ea5bb-76cf-6020-cb99-91b5ca82d679@pengutronix.de/
[3]: https://www.youtube.com/watch?v=z_y84v9076c

> 
> /Jarkko
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 2/4] KEYS: trusted: allow trust sources to use kernel RNG for key material
  2021-08-09  9:56       ` Jarkko Sakkinen
@ 2021-08-10  5:24         ` Sumit Garg
  0 siblings, 0 replies; 28+ messages in thread
From: Sumit Garg @ 2021-08-10  5:24 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Ahmad Fatoum, James Bottomley, Mimi Zohar, David Howells, kernel,
	James Morris, Serge E. Hallyn, Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, Udit Agarwal,
	Eric Biggers, Jan Luebbe, David Gstir, Richard Weinberger,
	Franck LENORMAND, open list:ASYMMETRIC KEYS,
	open list:HARDWARE RANDOM NUMBER GENERATOR CORE, linux-integrity,
	Linux Kernel Mailing List, open list:SECURITY SUBSYSTEM

On Mon, 9 Aug 2021 at 15:26, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Mon, Aug 09, 2021 at 09:52:20AM +0200, Ahmad Fatoum wrote:
> > Hello Sumit,
> >
> > On 22.07.21 08:31, Sumit Garg wrote:
> > > On Wed, 21 Jul 2021 at 22:19, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> > >>
> > >> The two existing trusted key sources don't make use of the kernel RNG,
> > >> but instead let the hardware that does the sealing/unsealing also
> > >> generate the random key material. While a previous change offers users
> > >> the choice to use the kernel RNG instead for both, new trust sources
> > >> may want to unconditionally use the kernel RNG for generating key
> > >> material, like it's done elsewhere in the kernel.
> > >>
> > >> This is especially prudent for hardware that has proven-in-production
> > >> HWRNG drivers implemented, as otherwise code would have to be duplicated
> > >> only to arrive at a possibly worse result.
> > >>
> > >> Make this possible by turning struct trusted_key_ops::get_random
> > >> into an optional member. If a driver leaves it NULL, kernel RNG
> > >> will be used instead.
> > >>
> > >> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> > >> ---
> > >> To: James Bottomley <jejb@linux.ibm.com>
> > >> To: Jarkko Sakkinen <jarkko@kernel.org>
> > >> To: Mimi Zohar <zohar@linux.ibm.com>
> > >> To: David Howells <dhowells@redhat.com>
> > >> Cc: James Morris <jmorris@namei.org>
> > >> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> > >> Cc: "Horia Geantă" <horia.geanta@nxp.com>
> > >> Cc: Aymen Sghaier <aymen.sghaier@nxp.com>
> > >> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> > >> Cc: "David S. Miller" <davem@davemloft.net>
> > >> Cc: Udit Agarwal <udit.agarwal@nxp.com>
> > >> Cc: Eric Biggers <ebiggers@kernel.org>
> > >> Cc: Jan Luebbe <j.luebbe@pengutronix.de>
> > >> Cc: David Gstir <david@sigma-star.at>
> > >> Cc: Richard Weinberger <richard@nod.at>
> > >> Cc: Franck LENORMAND <franck.lenormand@nxp.com>
> > >> Cc: Sumit Garg <sumit.garg@linaro.org>
> > >> Cc: keyrings@vger.kernel.org
> > >> Cc: linux-crypto@vger.kernel.org
> > >> Cc: linux-integrity@vger.kernel.org
> > >> Cc: linux-kernel@vger.kernel.org
> > >> Cc: linux-security-module@vger.kernel.org
> > >> ---
> > >>  include/keys/trusted-type.h               | 2 +-
> > >>  security/keys/trusted-keys/trusted_core.c | 2 +-
> > >>  2 files changed, 2 insertions(+), 2 deletions(-)
> > >>
> > >> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> > >> index d89fa2579ac0..4eb64548a74f 100644
> > >> --- a/include/keys/trusted-type.h
> > >> +++ b/include/keys/trusted-type.h
> > >> @@ -64,7 +64,7 @@ struct trusted_key_ops {
> > >>         /* Unseal a key. */
> > >>         int (*unseal)(struct trusted_key_payload *p, char *datablob);
> > >>
> > >> -       /* Get a randomized key. */
> > >> +       /* Optional: Get a randomized key. */
> > >>         int (*get_random)(unsigned char *key, size_t key_len);
> > >>
> > >>         /* Exit key interface. */
> > >> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> > >> index 569af9af8df0..d2b7626cde8b 100644
> > >> --- a/security/keys/trusted-keys/trusted_core.c
> > >> +++ b/security/keys/trusted-keys/trusted_core.c
> > >> @@ -334,7 +334,7 @@ static int __init init_trusted(void)
> > >>                         continue;
> > >>
> > >>                 get_random = trusted_key_sources[i].ops->get_random;
> > >> -               if (trusted_kernel_rng)
> > >> +               if (trusted_kernel_rng || !get_random)
> > >>                         get_random = kernel_get_random;
> > >>
> > >
> > > For ease of understanding, I would prefer to write it as:
> > >
> > >                   get_random = trusted_key_sources[i].ops->get_random ?:
> > >                                          kernel_get_random;
> > >                   if (trusted_kernel_rng)
> > >                         get_random = kernel_get_random;
> > >
> > > With that:
> > >
> > > Acked-by: Sumit Garg <sumit.garg@linaro.org>
> >
> > I don't think it improves readability to split up the conditional.
> > At least I need to take a second pass over the code to understand
> > the second conditional.
>
> Ternary operators are pain to read, unless a super trivial case.
>
> I'd stick to what you did.

Fair enough, I am fine with the current patch.

-Sumit

>
> /Jarkko

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-08-09 10:16     ` Ahmad Fatoum
@ 2021-08-10 11:28       ` David Gstir
  2021-08-20 16:25         ` Ahmad Fatoum
  0 siblings, 1 reply; 28+ messages in thread
From: David Gstir @ 2021-08-10 11:28 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: Jarkko Sakkinen, Horia Geantă,
	Mimi Zohar, Aymen Sghaier, Herbert Xu, David S. Miller,
	James Bottomley, Jan Luebbe, Udit Agarwal, Sumit Garg,
	Eric Biggers, Franck LENORMAND, Richard Weinberger, James Morris,
	linux-kernel, David Howells, linux-security-module, keyrings,
	linux-crypto, kernel, linux-integrity, Steffen Trumtrar,
	Serge E. Hallyn

Hi Ahmad,

> On 09.08.2021, at 12:16, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:

[...]

> If it interests you, I described[2] my CAAM+ubifs+fscrypt use case in the
> discussion thread on my fscrypt-trusted-keys v1. Jan, a colleague of mine, held a
> talk[3] on the different solutions for authenticated and encrypted storage, which
> you may want to check out.
>
> I'd really appreciate feedback here on the the CAAM parts of this series, so this can
> eventually go mainline.

Since you mention the fscrypt trusted-keys use case:

I noticed that the key length for trusted-keys is limited to
256 - 1024bit keys. fscrypt does however also support keys
with e.g. 128bit keys (AES-128-CBC-ESSIV, AES-128-CTS-CBC).
AFAIK, CAAM and TEE key blobs would also support key lengths outside the 256 - 1024bit range.

Wouldn’t it make sense to align the supported key lengths?
I.e. extend the range of supported key lengths for trusted keys.
Or is there a specific reason why key lengths below 256bit are
not supported by trusted-keys?

Cheers,
David



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 3/4] crypto: caam - add in-kernel interface for blob generator
  2021-07-21 16:48 ` [PATCH 3/4] crypto: caam - add in-kernel interface for blob generator Ahmad Fatoum
@ 2021-08-10 11:29   ` David Gstir
  2021-08-11 10:22     ` Ahmad Fatoum
  0 siblings, 1 reply; 28+ messages in thread
From: David Gstir @ 2021-08-10 11:29 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, kernel,
	James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
	James Morris, Eric Biggers, Serge E. Hallyn, Udit Agarwal,
	Jan Luebbe, Richard Weinberger, Franck LENORMAND, Sumit Garg,
	linux-integrity, keyrings, linux-crypto, linux-kernel,
	linux-security-module

Hi Ahmad,

> On 21.07.2021, at 18:48, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:


[...]

> diff --git a/drivers/crypto/caam/blob_gen.c b/drivers/crypto/caam/blob_gen.c
> new file mode 100644
> index 000000000000..513d3f90e438
> --- /dev/null
> +++ b/drivers/crypto/caam/blob_gen.c
> @@ -0,0 +1,230 @@

[...]

> +
> +int caam_encap_blob(struct caam_blob_priv *priv, const char *keymod,
> +		    void *input, void *output, size_t length)
> +{
> +	u32 *desc;
> +	struct device *jrdev = &priv->jrdev;
> +	dma_addr_t dma_in, dma_out;
> +	struct caam_blob_job_result testres;
> +	size_t keymod_len = strlen(keymod);
> +	int ret;
> +
> +	if (length <= CAAM_BLOB_OVERHEAD || keymod_len > CAAM_BLOB_KEYMOD_LENGTH)

The docs for this function mention the length <= CAAM_BLOB_MAX_LEN
restriction. This is not checked here. Is this intended?

Since you already assert that MAX_BLOB_SIZE <= CAAM_BLOB_MAX_LEN
in security/keys/trusted-keys/trusted_caam.c, this will never
be an issue for CAAM-based trusted-keys though.


> +		return -EINVAL;
> +
> +	desc = caam_blob_alloc_desc(keymod_len);
> +	if (!desc) {
> +		dev_err(jrdev, "unable to allocate desc\n");
> +		return -ENOMEM;
> +	}
> +

[...]

> diff --git a/include/soc/fsl/caam-blob.h b/include/soc/fsl/caam-blob.h
> new file mode 100644
> index 000000000000..aebbc9335f64
> --- /dev/null
> +++ b/include/soc/fsl/caam-blob.h
> @@ -0,0 +1,56 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2020 Pengutronix, Ahmad Fatoum <kernel@pengutronix.de>
> + */
> +
> +#ifndef __CAAM_BLOB_GEN
> +#define __CAAM_BLOB_GEN
> +
> +#include <linux/types.h>
> +
> +#define CAAM_BLOB_KEYMOD_LENGTH		16
> +#define CAAM_BLOB_OVERHEAD		(32 + 16)
> +#define CAAM_BLOB_MAX_LEN		4096
> +
> +struct caam_blob_priv;
> +
> +/** caam_blob_gen_init - initialize blob generation
> + *
> + * returns either pointer to new caam_blob_priv instance
> + * or error pointer
> + */
> +struct caam_blob_priv *caam_blob_gen_init(void);
> +
> +/** caam_blob_gen_init - free blob generation resources

s/init/exit/


> + *
> + * @priv: instance returned by caam_blob_gen_init
> + */
> +void caam_blob_gen_exit(struct caam_blob_priv *priv);


Except these minor things, I noticed no issues with this whole series:

Reviewed-by: David Gstir <david@sigma-star.at>



^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 3/4] crypto: caam - add in-kernel interface for blob generator
  2021-08-10 11:29   ` David Gstir
@ 2021-08-11 10:22     ` Ahmad Fatoum
  2021-08-11 10:43       ` David Gstir
  0 siblings, 1 reply; 28+ messages in thread
From: Ahmad Fatoum @ 2021-08-11 10:22 UTC (permalink / raw)
  To: David Gstir
  Cc: Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, kernel,
	James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
	James Morris, Eric Biggers, Serge E. Hallyn, Udit Agarwal,
	Jan Luebbe, Richard Weinberger, Franck LENORMAND, Sumit Garg,
	linux-integrity, keyrings, linux-crypto, linux-kernel,
	linux-security-module

On 10.08.21 13:29, David Gstir wrote:
> Hi Ahmad,
> 
>> On 21.07.2021, at 18:48, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> 
> 
> [...]
> 
>> diff --git a/drivers/crypto/caam/blob_gen.c b/drivers/crypto/caam/blob_gen.c
>> new file mode 100644
>> index 000000000000..513d3f90e438
>> --- /dev/null
>> +++ b/drivers/crypto/caam/blob_gen.c
>> @@ -0,0 +1,230 @@
> 
> [...]
> 
>> +
>> +int caam_encap_blob(struct caam_blob_priv *priv, const char *keymod,
>> +		    void *input, void *output, size_t length)
>> +{
>> +	u32 *desc;
>> +	struct device *jrdev = &priv->jrdev;
>> +	dma_addr_t dma_in, dma_out;
>> +	struct caam_blob_job_result testres;
>> +	size_t keymod_len = strlen(keymod);
>> +	int ret;
>> +
>> +	if (length <= CAAM_BLOB_OVERHEAD || keymod_len > CAAM_BLOB_KEYMOD_LENGTH)
> 
> The docs for this function mention the length <= CAAM_BLOB_MAX_LEN
> restriction. This is not checked here. Is this intended?

Yes.

> Since you already assert that MAX_BLOB_SIZE <= CAAM_BLOB_MAX_LEN
> in security/keys/trusted-keys/trusted_caam.c, this will never
> be an issue for CAAM-based trusted-keys though.
I omitted checks in code, which are verified at compile-time.
Would you prefer a runtime check to be added as well?

>> +		return -EINVAL;
>> +
>> +	desc = caam_blob_alloc_desc(keymod_len);
>> +	if (!desc) {
>> +		dev_err(jrdev, "unable to allocate desc\n");
>> +		return -ENOMEM;
>> +	}
>> +
> 
> [...]
> 
>> diff --git a/include/soc/fsl/caam-blob.h b/include/soc/fsl/caam-blob.h
>> new file mode 100644
>> index 000000000000..aebbc9335f64
>> --- /dev/null
>> +++ b/include/soc/fsl/caam-blob.h
>> @@ -0,0 +1,56 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Copyright (C) 2020 Pengutronix, Ahmad Fatoum <kernel@pengutronix.de>
>> + */
>> +
>> +#ifndef __CAAM_BLOB_GEN
>> +#define __CAAM_BLOB_GEN
>> +
>> +#include <linux/types.h>
>> +
>> +#define CAAM_BLOB_KEYMOD_LENGTH		16
>> +#define CAAM_BLOB_OVERHEAD		(32 + 16)
>> +#define CAAM_BLOB_MAX_LEN		4096
>> +
>> +struct caam_blob_priv;
>> +
>> +/** caam_blob_gen_init - initialize blob generation
>> + *
>> + * returns either pointer to new caam_blob_priv instance
>> + * or error pointer
>> + */
>> +struct caam_blob_priv *caam_blob_gen_init(void);
>> +
>> +/** caam_blob_gen_init - free blob generation resources
> 
> s/init/exit/

Oh, thanks for catching.

>> + *
>> + * @priv: instance returned by caam_blob_gen_init
>> + */
>> +void caam_blob_gen_exit(struct caam_blob_priv *priv);
> 
> 
> Except these minor things, I noticed no issues with this whole series:
> 
> Reviewed-by: David Gstir <david@sigma-star.at>

Thanks! Will include it with the next iteration.

Cheers,
Ahmad 


> 
> 
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 3/4] crypto: caam - add in-kernel interface for blob generator
  2021-08-11 10:22     ` Ahmad Fatoum
@ 2021-08-11 10:43       ` David Gstir
  0 siblings, 0 replies; 28+ messages in thread
From: David Gstir @ 2021-08-11 10:43 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, kernel,
	James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
	James Morris, Eric Biggers, Serge E. Hallyn, Udit Agarwal,
	Jan Luebbe, Richard Weinberger, Franck LENORMAND, Sumit Garg,
	linux-integrity, keyrings, linux-crypto, linux-kernel,
	linux-security-module

Hi Ahmad,

> On 11.08.2021, at 12:22, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
>> Since you already assert that MAX_BLOB_SIZE <= CAAM_BLOB_MAX_LEN
>> in security/keys/trusted-keys/trusted_caam.c, this will never
>> be an issue for CAAM-based trusted-keys though.
> I omitted checks in code, which are verified at compile-time.
> Would you prefer a runtime check to be added as well?

I’d say the compile-time check suffices, unless this is intended
to be used outside of trusted-keys. But I don’t think this is very likely…

Cheers,
David

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-07-21 16:48 [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
                   ` (4 preceding siblings ...)
  2021-08-06 15:12 ` [PATCH 0/4] " Ahmad Fatoum
@ 2021-08-20 15:39 ` Tim Harvey
  2021-08-20 16:19   ` Ahmad Fatoum
  5 siblings, 1 reply; 28+ messages in thread
From: Tim Harvey @ 2021-08-20 15:39 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: Jarkko Sakkinen, Horia Geantă,
	Mimi Zohar, Aymen Sghaier, Herbert Xu, David S. Miller,
	James Bottomley, Sascha Hauer, David Howells, James Morris,
	Serge E. Hallyn, Steffen Trumtrar, Udit Agarwal, Jan Luebbe,
	David Gstir, Eric Biggers, Richard Weinberger, Franck LENORMAND,
	Sumit Garg, linux-integrity, keyrings, linux-crypto, open list,
	linux-security-module

On Wed, Jul 21, 2021 at 9:49 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> Series applies on top of
> https://lore.kernel.org/linux-integrity/20210721160258.7024-1-a.fatoum@pengutronix.de/T/#u
>
> v2 -> v3:
>  - Split off first Kconfig preparation patch. It fixes a regression,
>    so sent that out, so it can be applied separately (Sumit)
>  - Split off second key import patch. I'll send that out separately
>    as it's a development aid and not required within the CAAM series
>  - add MAINTAINERS entry
>
> v1 -> v2:
>  - Added new commit to make trusted key Kconfig option independent
>    of TPM and added new Kconfig file for trusted keys
>  - Add new commit for importing existing key material
>  - Allow users to force use of kernel RNG (Jarkko)
>  - Enforce maximum keymod size (Horia)
>  - Use append_seq_(in|out)_ptr_intlen instead of append_seq_(in|out)_ptr
>    (Horia)
>  - Make blobifier handle private to CAAM glue code file (Horia)
>  - Extend trusted keys documentation for CAAM
>  - Rebased and updated original cover letter:
>
> 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 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.MX6DL.
>
> Looking forward to your feedback.
>
> Cheers,
> Ahmad
>
>  [1]: https://lore.kernel.org/linux-crypto/1447082306-19946-2-git-send-email-s.trumtrar@pengutronix.de/
>  [2]: https://lore.kernel.org/linux-integrity/20180723111432.26830-1-udit.agarwal@nxp.com/
>  [3]: https://lore.kernel.org/lkml/1551456599-10603-2-git-send-email-franck.lenormand@nxp.com/
>  [4]: https://lore.kernel.org/lkml/1604419306-26105-1-git-send-email-sumit.garg@linaro.org/
>  [5]: https://lore.kernel.org/linux-integrity/20210122084321.24012-2-a.fatoum@pengutronix.de/
>
> ---
> To: Jarkko Sakkinen <jarkko@kernel.org>
> To: "Horia Geantă" <horia.geanta@nxp.com>
> To: Mimi Zohar <zohar@linux.ibm.com>
> To: Aymen Sghaier <aymen.sghaier@nxp.com>
> To: Herbert Xu <herbert@gondor.apana.org.au>
> To: "David S. Miller" <davem@davemloft.net>
> To: James Bottomley <jejb@linux.ibm.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: James Morris <jmorris@namei.org>
> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> Cc: Udit Agarwal <udit.agarwal@nxp.com>
> Cc: Jan Luebbe <j.luebbe@pengutronix.de>
> Cc: David Gstir <david@sigma-star.at>
> Cc: Eric Biggers <ebiggers@kernel.org>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: Franck LENORMAND <franck.lenormand@nxp.com>
> Cc: Sumit Garg <sumit.garg@linaro.org>
> Cc: linux-integrity@vger.kernel.org
> Cc: keyrings@vger.kernel.org
> Cc: linux-crypto@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-security-module@vger.kernel.org
>
> Ahmad Fatoum (4):
>   KEYS: trusted: allow users to use kernel RNG for key material
>   KEYS: trusted: allow trust sources to use kernel RNG for key material
>   crypto: caam - add in-kernel interface for blob generator
>   KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
>
>  Documentation/admin-guide/kernel-parameters.txt   |   8 +-
>  Documentation/security/keys/trusted-encrypted.rst |  60 +++-
>  MAINTAINERS                                       |   9 +-
>  drivers/crypto/caam/Kconfig                       |   3 +-
>  drivers/crypto/caam/Makefile                      |   1 +-
>  drivers/crypto/caam/blob_gen.c                    | 230 +++++++++++++++-
>  include/keys/trusted-type.h                       |   2 +-
>  include/keys/trusted_caam.h                       |  11 +-
>  include/soc/fsl/caam-blob.h                       |  56 ++++-
>  security/keys/trusted-keys/Kconfig                |  11 +-
>  security/keys/trusted-keys/Makefile               |   2 +-
>  security/keys/trusted-keys/trusted_caam.c         |  74 +++++-
>  security/keys/trusted-keys/trusted_core.c         |  23 +-
>  13 files changed, 477 insertions(+), 13 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/trusted_caam.c
>
> base-commit: 97408d81ed533b953326c580ff2c3f1948b3fcee
> --
> git-series 0.9.1

Ahmad,

Thanks for your work!

I've been asked to integrate the capability of using CAAM to
blob/deblob data to an older 5.4 kernel such as NXP's downstream
vendor kernel does [1] and I'm trying to understand how your series
works. I'm not at all familiar with the Linux Key Management API's or
trusted keys. Can you provide an example of how this can be used for
such a thing?

Best regards,

Tim
[1] https://source.codeaurora.org/external/imxsupport/imx_sec_apps/tree/demo-caam-blobs/README.txt

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-08-20 15:39 ` Tim Harvey
@ 2021-08-20 16:19   ` Ahmad Fatoum
  2021-08-20 20:20     ` Tim Harvey
  0 siblings, 1 reply; 28+ messages in thread
From: Ahmad Fatoum @ 2021-08-20 16:19 UTC (permalink / raw)
  To: Tim Harvey
  Cc: David Gstir, Aymen Sghaier, Mimi Zohar, Jan Luebbe, keyrings,
	Steffen Trumtrar, linux-security-module, Udit Agarwal,
	Herbert Xu, Horia Geantă,
	Richard Weinberger, James Morris, Eric Biggers, Serge E. Hallyn,
	Sumit Garg, James Bottomley, Franck LENORMAND, David Howells,
	open list, Jarkko Sakkinen, linux-crypto, Sascha Hauer,
	linux-integrity, David S. Miller

Hello Tim,

On 20.08.21 17:39, Tim Harvey wrote:
> On Wed, Jul 21, 2021 at 9:49 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>
>> Series applies on top of
>> https://lore.kernel.org/linux-integrity/20210721160258.7024-1-a.fatoum@pengutronix.de/T/#u
>>
>> v2 -> v3:
>>  - Split off first Kconfig preparation patch. It fixes a regression,
>>    so sent that out, so it can be applied separately (Sumit)
>>  - Split off second key import patch. I'll send that out separately
>>    as it's a development aid and not required within the CAAM series
>>  - add MAINTAINERS entry
>>
>> v1 -> v2:
>>  - Added new commit to make trusted key Kconfig option independent
>>    of TPM and added new Kconfig file for trusted keys
>>  - Add new commit for importing existing key material
>>  - Allow users to force use of kernel RNG (Jarkko)
>>  - Enforce maximum keymod size (Horia)
>>  - Use append_seq_(in|out)_ptr_intlen instead of append_seq_(in|out)_ptr
>>    (Horia)
>>  - Make blobifier handle private to CAAM glue code file (Horia)
>>  - Extend trusted keys documentation for CAAM
>>  - Rebased and updated original cover letter:
>>
>> 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 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.MX6DL.
>>
>> Looking forward to your feedback.
>>
>> Cheers,
>> Ahmad
>>
>>  [1]: https://lore.kernel.org/linux-crypto/1447082306-19946-2-git-send-email-s.trumtrar@pengutronix.de/
>>  [2]: https://lore.kernel.org/linux-integrity/20180723111432.26830-1-udit.agarwal@nxp.com/
>>  [3]: https://lore.kernel.org/lkml/1551456599-10603-2-git-send-email-franck.lenormand@nxp.com/
>>  [4]: https://lore.kernel.org/lkml/1604419306-26105-1-git-send-email-sumit.garg@linaro.org/
>>  [5]: https://lore.kernel.org/linux-integrity/20210122084321.24012-2-a.fatoum@pengutronix.de/
>>
>> ---
>> To: Jarkko Sakkinen <jarkko@kernel.org>
>> To: "Horia Geantă" <horia.geanta@nxp.com>
>> To: Mimi Zohar <zohar@linux.ibm.com>
>> To: Aymen Sghaier <aymen.sghaier@nxp.com>
>> To: Herbert Xu <herbert@gondor.apana.org.au>
>> To: "David S. Miller" <davem@davemloft.net>
>> To: James Bottomley <jejb@linux.ibm.com>
>> Cc: David Howells <dhowells@redhat.com>
>> Cc: James Morris <jmorris@namei.org>
>> Cc: "Serge E. Hallyn" <serge@hallyn.com>
>> Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
>> Cc: Udit Agarwal <udit.agarwal@nxp.com>
>> Cc: Jan Luebbe <j.luebbe@pengutronix.de>
>> Cc: David Gstir <david@sigma-star.at>
>> Cc: Eric Biggers <ebiggers@kernel.org>
>> Cc: Richard Weinberger <richard@nod.at>
>> Cc: Franck LENORMAND <franck.lenormand@nxp.com>
>> Cc: Sumit Garg <sumit.garg@linaro.org>
>> Cc: linux-integrity@vger.kernel.org
>> Cc: keyrings@vger.kernel.org
>> Cc: linux-crypto@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-security-module@vger.kernel.org
>>
>> Ahmad Fatoum (4):
>>   KEYS: trusted: allow users to use kernel RNG for key material
>>   KEYS: trusted: allow trust sources to use kernel RNG for key material
>>   crypto: caam - add in-kernel interface for blob generator
>>   KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
>>
>>  Documentation/admin-guide/kernel-parameters.txt   |   8 +-
>>  Documentation/security/keys/trusted-encrypted.rst |  60 +++-
>>  MAINTAINERS                                       |   9 +-
>>  drivers/crypto/caam/Kconfig                       |   3 +-
>>  drivers/crypto/caam/Makefile                      |   1 +-
>>  drivers/crypto/caam/blob_gen.c                    | 230 +++++++++++++++-
>>  include/keys/trusted-type.h                       |   2 +-
>>  include/keys/trusted_caam.h                       |  11 +-
>>  include/soc/fsl/caam-blob.h                       |  56 ++++-
>>  security/keys/trusted-keys/Kconfig                |  11 +-
>>  security/keys/trusted-keys/Makefile               |   2 +-
>>  security/keys/trusted-keys/trusted_caam.c         |  74 +++++-
>>  security/keys/trusted-keys/trusted_core.c         |  23 +-
>>  13 files changed, 477 insertions(+), 13 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/trusted_caam.c
>>
>> base-commit: 97408d81ed533b953326c580ff2c3f1948b3fcee
>> --
>> git-series 0.9.1
> 
> Ahmad,
> 
> Thanks for your work!
> 
> I've been asked to integrate the capability of using CAAM to
> blob/deblob data to an older 5.4 kernel such as NXP's downstream
> vendor kernel does [1] and I'm trying to understand how your series
> works. I'm not at all familiar with the Linux Key Management API's or
> trusted keys. Can you provide an example of how this can be used for
> such a thing?

Here's an example with dm-crypt:

  https://lore.kernel.org/linux-integrity/5d44e50e-4309-830b-79f6-f5d888b1ef69@pengutronix.de/

dm-crypt is a bit special at the moment, because it has direct support for
trusted keys. For interfacing with other parts of the kernel like ecryptfs
or EVM, you have to create encrypted keys rooted to the trusted keys and use
those. The kernel documentation has an example:

  https://www.kernel.org/doc/html/v5.13/security/keys/trusted-encrypted.html

If you backport this series, you can include the typo fix spotted by David.

I'll send out a revised series, but given that a regression fix I want to
rebase on hasn't been picked up for 3 weeks now, I am not in a hurry.

Cheers,
Ahmad

> 
> Best regards,
> 
> Tim
> [1] https://source.codeaurora.org/external/imxsupport/imx_sec_apps/tree/demo-caam-blobs/README.txt
> 
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-08-10 11:28       ` David Gstir
@ 2021-08-20 16:25         ` Ahmad Fatoum
  0 siblings, 0 replies; 28+ messages in thread
From: Ahmad Fatoum @ 2021-08-20 16:25 UTC (permalink / raw)
  To: David Gstir
  Cc: Jarkko Sakkinen, Horia Geantă,
	Mimi Zohar, Aymen Sghaier, Herbert Xu, David S. Miller,
	James Bottomley, Jan Luebbe, Udit Agarwal, Sumit Garg,
	Eric Biggers, Franck LENORMAND, Richard Weinberger, James Morris,
	linux-kernel, David Howells, linux-security-module, keyrings,
	linux-crypto, kernel, linux-integrity, Steffen Trumtrar,
	Serge E. Hallyn

Hello David,

On 10.08.21 13:28, David Gstir wrote:
> Hi Ahmad,
> 
>> On 09.08.2021, at 12:16, Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> 
> [...]
> 
>> If it interests you, I described[2] my CAAM+ubifs+fscrypt use case in the
>> discussion thread on my fscrypt-trusted-keys v1. Jan, a colleague of mine, held a
>> talk[3] on the different solutions for authenticated and encrypted storage, which
>> you may want to check out.
>>
>> I'd really appreciate feedback here on the the CAAM parts of this series, so this can
>> eventually go mainline.
> 
> Since you mention the fscrypt trusted-keys use case:
> 
> I noticed that the key length for trusted-keys is limited to
> 256 - 1024bit keys. fscrypt does however also support keys
> with e.g. 128bit keys (AES-128-CBC-ESSIV, AES-128-CTS-CBC).
> AFAIK, CAAM and TEE key blobs would also support key lengths outside the 256 - 1024bit range.
> 
> Wouldn’t it make sense to align the supported key lengths?
> I.e. extend the range of supported key lengths for trusted keys.
> Or is there a specific reason why key lengths below 256bit are
> not supported by trusted-keys?

No idea. I would suggest staying clear about arguing in its favor though
until CAAM and DCP are merged. My parallel fscrypt endeavors seem to have
only diverted maintainer attention. ;-)

Cheers,
Ahmad

> 
> Cheers,
> David
> 
> 
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-08-20 16:19   ` Ahmad Fatoum
@ 2021-08-20 20:20     ` Tim Harvey
  2021-08-20 20:36       ` Ahmad Fatoum
  0 siblings, 1 reply; 28+ messages in thread
From: Tim Harvey @ 2021-08-20 20:20 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: David Gstir, Aymen Sghaier, Mimi Zohar, Jan Luebbe, keyrings,
	Steffen Trumtrar, linux-security-module, Udit Agarwal,
	Herbert Xu, Horia Geantă,
	Richard Weinberger, James Morris, Eric Biggers, Serge E. Hallyn,
	Sumit Garg, James Bottomley, Franck LENORMAND, David Howells,
	open list, Jarkko Sakkinen, linux-crypto, Sascha Hauer,
	linux-integrity, David S. Miller

On Fri, Aug 20, 2021 at 9:20 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> Hello Tim,
>
> On 20.08.21 17:39, Tim Harvey wrote:
> > On Wed, Jul 21, 2021 at 9:49 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>
> >> Series applies on top of
> >> https://lore.kernel.org/linux-integrity/20210721160258.7024-1-a.fatoum@pengutronix.de/T/#u
> >>
> >> v2 -> v3:
> >>  - Split off first Kconfig preparation patch. It fixes a regression,
> >>    so sent that out, so it can be applied separately (Sumit)
> >>  - Split off second key import patch. I'll send that out separately
> >>    as it's a development aid and not required within the CAAM series
> >>  - add MAINTAINERS entry
> >>
> >> v1 -> v2:
> >>  - Added new commit to make trusted key Kconfig option independent
> >>    of TPM and added new Kconfig file for trusted keys
> >>  - Add new commit for importing existing key material
> >>  - Allow users to force use of kernel RNG (Jarkko)
> >>  - Enforce maximum keymod size (Horia)
> >>  - Use append_seq_(in|out)_ptr_intlen instead of append_seq_(in|out)_ptr
> >>    (Horia)
> >>  - Make blobifier handle private to CAAM glue code file (Horia)
> >>  - Extend trusted keys documentation for CAAM
> >>  - Rebased and updated original cover letter:
> >>
> >> 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 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.MX6DL.
> >>
> >> Looking forward to your feedback.
> >>
> >> Cheers,
> >> Ahmad
> >>
> >>  [1]: https://lore.kernel.org/linux-crypto/1447082306-19946-2-git-send-email-s.trumtrar@pengutronix.de/
> >>  [2]: https://lore.kernel.org/linux-integrity/20180723111432.26830-1-udit.agarwal@nxp.com/
> >>  [3]: https://lore.kernel.org/lkml/1551456599-10603-2-git-send-email-franck.lenormand@nxp.com/
> >>  [4]: https://lore.kernel.org/lkml/1604419306-26105-1-git-send-email-sumit.garg@linaro.org/
> >>  [5]: https://lore.kernel.org/linux-integrity/20210122084321.24012-2-a.fatoum@pengutronix.de/
> >>
> >> ---
> >> To: Jarkko Sakkinen <jarkko@kernel.org>
> >> To: "Horia Geantă" <horia.geanta@nxp.com>
> >> To: Mimi Zohar <zohar@linux.ibm.com>
> >> To: Aymen Sghaier <aymen.sghaier@nxp.com>
> >> To: Herbert Xu <herbert@gondor.apana.org.au>
> >> To: "David S. Miller" <davem@davemloft.net>
> >> To: James Bottomley <jejb@linux.ibm.com>
> >> Cc: David Howells <dhowells@redhat.com>
> >> Cc: James Morris <jmorris@namei.org>
> >> Cc: "Serge E. Hallyn" <serge@hallyn.com>
> >> Cc: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> >> Cc: Udit Agarwal <udit.agarwal@nxp.com>
> >> Cc: Jan Luebbe <j.luebbe@pengutronix.de>
> >> Cc: David Gstir <david@sigma-star.at>
> >> Cc: Eric Biggers <ebiggers@kernel.org>
> >> Cc: Richard Weinberger <richard@nod.at>
> >> Cc: Franck LENORMAND <franck.lenormand@nxp.com>
> >> Cc: Sumit Garg <sumit.garg@linaro.org>
> >> Cc: linux-integrity@vger.kernel.org
> >> Cc: keyrings@vger.kernel.org
> >> Cc: linux-crypto@vger.kernel.org
> >> Cc: linux-kernel@vger.kernel.org
> >> Cc: linux-security-module@vger.kernel.org
> >>
> >> Ahmad Fatoum (4):
> >>   KEYS: trusted: allow users to use kernel RNG for key material
> >>   KEYS: trusted: allow trust sources to use kernel RNG for key material
> >>   crypto: caam - add in-kernel interface for blob generator
> >>   KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
> >>
> >>  Documentation/admin-guide/kernel-parameters.txt   |   8 +-
> >>  Documentation/security/keys/trusted-encrypted.rst |  60 +++-
> >>  MAINTAINERS                                       |   9 +-
> >>  drivers/crypto/caam/Kconfig                       |   3 +-
> >>  drivers/crypto/caam/Makefile                      |   1 +-
> >>  drivers/crypto/caam/blob_gen.c                    | 230 +++++++++++++++-
> >>  include/keys/trusted-type.h                       |   2 +-
> >>  include/keys/trusted_caam.h                       |  11 +-
> >>  include/soc/fsl/caam-blob.h                       |  56 ++++-
> >>  security/keys/trusted-keys/Kconfig                |  11 +-
> >>  security/keys/trusted-keys/Makefile               |   2 +-
> >>  security/keys/trusted-keys/trusted_caam.c         |  74 +++++-
> >>  security/keys/trusted-keys/trusted_core.c         |  23 +-
> >>  13 files changed, 477 insertions(+), 13 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/trusted_caam.c
> >>
> >> base-commit: 97408d81ed533b953326c580ff2c3f1948b3fcee
> >> --
> >> git-series 0.9.1
> >
> > Ahmad,
> >
> > Thanks for your work!
> >
> > I've been asked to integrate the capability of using CAAM to
> > blob/deblob data to an older 5.4 kernel such as NXP's downstream
> > vendor kernel does [1] and I'm trying to understand how your series
> > works. I'm not at all familiar with the Linux Key Management API's or
> > trusted keys. Can you provide an example of how this can be used for
> > such a thing?
>
> Here's an example with dm-crypt:
>
>   https://lore.kernel.org/linux-integrity/5d44e50e-4309-830b-79f6-f5d888b1ef69@pengutronix.de/
>
> dm-crypt is a bit special at the moment, because it has direct support for
> trusted keys. For interfacing with other parts of the kernel like ecryptfs
> or EVM, you have to create encrypted keys rooted to the trusted keys and use
> those. The kernel documentation has an example:
>
>   https://www.kernel.org/doc/html/v5.13/security/keys/trusted-encrypted.html
>
> If you backport this series, you can include the typo fix spotted by David.
>
> I'll send out a revised series, but given that a regression fix I want to
> rebase on hasn't been picked up for 3 weeks now, I am not in a hurry.
>

Ahmad,

Thanks for the reference.

I'm still trying to understand the keyctl integration with caam. For
the 'data' param to keyctl you are using tings like 'new <len>' and
'load <data>'. Where are these 'commands' identified?

I may still be missing something. I'm using 4.14-rc6 with your series
and seeing the following:
# cat /proc/cmdline
trusted.source=caam
# keyctl add trusted mykey 'new 32' @s)# create new trusted key named
'mykey' of 32 bytes in the session keyring
480104283
# keyctl print 480104283 # dump the key
keyctl_read_alloc: Unknown error 126
^^^ not clear what this is

Best regards,

Tim

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-08-20 20:20     ` Tim Harvey
@ 2021-08-20 20:36       ` Ahmad Fatoum
  2021-08-20 21:19         ` Tim Harvey
  0 siblings, 1 reply; 28+ messages in thread
From: Ahmad Fatoum @ 2021-08-20 20:36 UTC (permalink / raw)
  To: Tim Harvey
  Cc: David Gstir, Aymen Sghaier, Mimi Zohar, Jan Luebbe, keyrings,
	Steffen Trumtrar, linux-security-module, Udit Agarwal,
	Herbert Xu, Horia Geantă,
	Richard Weinberger, James Morris, Eric Biggers, Serge E. Hallyn,
	Sumit Garg, James Bottomley, Franck LENORMAND, David Howells,
	open list, Jarkko Sakkinen, linux-crypto, Sascha Hauer,
	linux-integrity, David S. Miller

On 20.08.21 22:20, Tim Harvey wrote:
> On Fri, Aug 20, 2021 at 9:20 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>> On 20.08.21 17:39, Tim Harvey wrote:
>>> Thanks for your work!
>>>
>>> I've been asked to integrate the capability of using CAAM to
>>> blob/deblob data to an older 5.4 kernel such as NXP's downstream
>>> vendor kernel does [1] and I'm trying to understand how your series
>>> works. I'm not at all familiar with the Linux Key Management API's or
>>> trusted keys. Can you provide an example of how this can be used for
>>> such a thing?
>>
>> Here's an example with dm-crypt:
>>
>>   https://lore.kernel.org/linux-integrity/5d44e50e-4309-830b-79f6-f5d888b1ef69@pengutronix.de/
>>
>> dm-crypt is a bit special at the moment, because it has direct support for
>> trusted keys. For interfacing with other parts of the kernel like ecryptfs
>> or EVM, you have to create encrypted keys rooted to the trusted keys and use
>> those. The kernel documentation has an example:
>>
>>   https://www.kernel.org/doc/html/v5.13/security/keys/trusted-encrypted.html
>>
>> If you backport this series, you can include the typo fix spotted by David.
>>
>> I'll send out a revised series, but given that a regression fix I want to
>> rebase on hasn't been picked up for 3 weeks now, I am not in a hurry.
>>
> Thanks for the reference.
> 
> I'm still trying to understand the keyctl integration with caam. For
> the 'data' param to keyctl you are using tings like 'new <len>' and
> 'load <data>'. Where are these 'commands' identified?

Search for match_table_t in security/keys/trusted-keys/trusted_core.c

> I may still be missing something. I'm using 4.14-rc6 with your series
> and seeing the following:

That's an odd version to backport stuff to..

> # cat /proc/cmdline
> trusted.source=caam
> # keyctl add trusted mykey 'new 32' @s)# create new trusted key named
> 'mykey' of 32 bytes in the session keyring
> 480104283
> # keyctl print 480104283 # dump the key
> keyctl_read_alloc: Unknown error 126
> ^^^ not clear what this is

Not sure what returns -ENOKEY for you. I haven't been using trusted
keys on v4.14, but you can try tracing the keyctl syscall.

Cheers,
Ahmad

> 
> Best regards,
> 
> Tim
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-08-20 20:36       ` Ahmad Fatoum
@ 2021-08-20 21:19         ` Tim Harvey
  2021-08-23 13:29           ` Ahmad Fatoum
  0 siblings, 1 reply; 28+ messages in thread
From: Tim Harvey @ 2021-08-20 21:19 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: David Gstir, Aymen Sghaier, Mimi Zohar, Jan Luebbe, keyrings,
	Steffen Trumtrar, linux-security-module, Udit Agarwal,
	Herbert Xu, Horia Geantă,
	Richard Weinberger, James Morris, Eric Biggers, Serge E. Hallyn,
	Sumit Garg, James Bottomley, Franck LENORMAND, David Howells,
	open list, Jarkko Sakkinen, linux-crypto, Sascha Hauer,
	linux-integrity, David S. Miller

On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> On 20.08.21 22:20, Tim Harvey wrote:
> > On Fri, Aug 20, 2021 at 9:20 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >> On 20.08.21 17:39, Tim Harvey wrote:
> >>> Thanks for your work!
> >>>
> >>> I've been asked to integrate the capability of using CAAM to
> >>> blob/deblob data to an older 5.4 kernel such as NXP's downstream
> >>> vendor kernel does [1] and I'm trying to understand how your series
> >>> works. I'm not at all familiar with the Linux Key Management API's or
> >>> trusted keys. Can you provide an example of how this can be used for
> >>> such a thing?
> >>
> >> Here's an example with dm-crypt:
> >>
> >>   https://lore.kernel.org/linux-integrity/5d44e50e-4309-830b-79f6-f5d888b1ef69@pengutronix.de/
> >>
> >> dm-crypt is a bit special at the moment, because it has direct support for
> >> trusted keys. For interfacing with other parts of the kernel like ecryptfs
> >> or EVM, you have to create encrypted keys rooted to the trusted keys and use
> >> those. The kernel documentation has an example:
> >>
> >>   https://www.kernel.org/doc/html/v5.13/security/keys/trusted-encrypted.html
> >>
> >> If you backport this series, you can include the typo fix spotted by David.
> >>
> >> I'll send out a revised series, but given that a regression fix I want to
> >> rebase on hasn't been picked up for 3 weeks now, I am not in a hurry.
> >>
> > Thanks for the reference.
> >
> > I'm still trying to understand the keyctl integration with caam. For
> > the 'data' param to keyctl you are using tings like 'new <len>' and
> > 'load <data>'. Where are these 'commands' identified?
>
> Search for match_table_t in security/keys/trusted-keys/trusted_core.c
>
> > I may still be missing something. I'm using 4.14-rc6 with your series
> > and seeing the following:
>
> That's an odd version to backport stuff to..
>
> > # cat /proc/cmdline
> > trusted.source=caam
> > # keyctl add trusted mykey 'new 32' @s)# create new trusted key named
> > 'mykey' of 32 bytes in the session keyring
> > 480104283
> > # keyctl print 480104283 # dump the key
> > keyctl_read_alloc: Unknown error 126
> > ^^^ not clear what this is
>
> Not sure what returns -ENOKEY for you. I haven't been using trusted
> keys on v4.14, but you can try tracing the keyctl syscall.

yikes... that would be painful. I typo'd and meant 5.14-rc6 :) I'm
working with mainline first to make sure I understand everything. If I
backport this it would be to 5.4 but that looks to be extremely
painful. It looks like there was a lot of activity around trusted keys
in 5.13.

It works for a user keyring but not a session keyring... does that
explain anything?
# keyctl add trusted mykey 'new 32' @u
941210782
# keyctl print 941210782
83b7845cb45216496aead9ee2c6a406f587d64aad47bddc539d8947a247e618798d9306b36398b5dc2722a4c3f220a3a763ee175f6bd64758fdd49ca4db597e8ce328121b60edbba9b8d8d55056be896
# keyctl add trusted mykey 'new 32' @s
310571960
# keyctl print 310571960
keyctl_read_alloc: Unknown error 126

Sorry, I'm still trying to wrap my head around the differences in
keyrings and trusted vs user keys.

Tim

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-08-20 21:19         ` Tim Harvey
@ 2021-08-23 13:29           ` Ahmad Fatoum
  2021-08-23 17:50             ` Tim Harvey
  0 siblings, 1 reply; 28+ messages in thread
From: Ahmad Fatoum @ 2021-08-23 13:29 UTC (permalink / raw)
  To: Tim Harvey
  Cc: David Gstir, Aymen Sghaier, Mimi Zohar, Jan Luebbe, keyrings,
	Steffen Trumtrar, linux-security-module, Udit Agarwal,
	Herbert Xu, Horia Geantă,
	Richard Weinberger, James Morris, Eric Biggers, Serge E. Hallyn,
	Sumit Garg, James Bottomley, Franck LENORMAND, David Howells,
	open list, Jarkko Sakkinen, linux-crypto, Sascha Hauer,
	linux-integrity, David S. Miller

Hello Tim,

On 20.08.21 23:19, Tim Harvey wrote:
> On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>
>> On 20.08.21 22:20, Tim Harvey wrote:
>>> On Fri, Aug 20, 2021 at 9:20 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>>> On 20.08.21 17:39, Tim Harvey wrote:
>>>>> Thanks for your work!
>>>>>
>>>>> I've been asked to integrate the capability of using CAAM to
>>>>> blob/deblob data to an older 5.4 kernel such as NXP's downstream
>>>>> vendor kernel does [1] and I'm trying to understand how your series
>>>>> works. I'm not at all familiar with the Linux Key Management API's or
>>>>> trusted keys. Can you provide an example of how this can be used for
>>>>> such a thing?
>>>>
>>>> Here's an example with dm-crypt:
>>>>
>>>>   https://lore.kernel.org/linux-integrity/5d44e50e-4309-830b-79f6-f5d888b1ef69@pengutronix.de/
>>>>
>>>> dm-crypt is a bit special at the moment, because it has direct support for
>>>> trusted keys. For interfacing with other parts of the kernel like ecryptfs
>>>> or EVM, you have to create encrypted keys rooted to the trusted keys and use
>>>> those. The kernel documentation has an example:
>>>>
>>>>   https://www.kernel.org/doc/html/v5.13/security/keys/trusted-encrypted.html
>>>>
>>>> If you backport this series, you can include the typo fix spotted by David.
>>>>
>>>> I'll send out a revised series, but given that a regression fix I want to
>>>> rebase on hasn't been picked up for 3 weeks now, I am not in a hurry.
>>>>
>>> Thanks for the reference.
>>>
>>> I'm still trying to understand the keyctl integration with caam. For
>>> the 'data' param to keyctl you are using tings like 'new <len>' and
>>> 'load <data>'. Where are these 'commands' identified?
>>
>> Search for match_table_t in security/keys/trusted-keys/trusted_core.c
>>
>>> I may still be missing something. I'm using 4.14-rc6 with your series
>>> and seeing the following:
>>
>> That's an odd version to backport stuff to..
>>
>>> # cat /proc/cmdline
>>> trusted.source=caam
>>> # keyctl add trusted mykey 'new 32' @s)# create new trusted key named
>>> 'mykey' of 32 bytes in the session keyring
>>> 480104283
>>> # keyctl print 480104283 # dump the key
>>> keyctl_read_alloc: Unknown error 126
>>> ^^^ not clear what this is
>>
>> Not sure what returns -ENOKEY for you. I haven't been using trusted
>> keys on v4.14, but you can try tracing the keyctl syscall.
> 
> yikes... that would be painful. I typo'd and meant 5.14-rc6 :) 

^^

> I'm working with mainline first to make sure I understand everything. If I
> backport this it would be to 5.4 but that looks to be extremely
> painful. It looks like there was a lot of activity around trusted keys
> in 5.13.

Ye. It used to be limited to TPM before that.

> It works for a user keyring but not a session keyring... does that
> explain anything?
> # keyctl add trusted mykey 'new 32' @u
> 941210782
> # keyctl print 941210782
> 83b7845cb45216496aead9ee2c6a406f587d64aad47bddc539d8947a247e618798d9306b36398b5dc2722a4c3f220a3a763ee175f6bd64758fdd49ca4db597e8ce328121b60edbba9b8d8d55056be896
> # keyctl add trusted mykey 'new 32' @s
> 310571960
> # keyctl print 310571960
> keyctl_read_alloc: Unknown error 126

Both sequences work for me.

My getty is started by systemd. I think systemd allocates a new session
keyring for the getty that's inherited by the shell and the commands I run
it in. If you don't do that, each command will get its own session key.
 
> Sorry, I'm still trying to wrap my head around the differences in
> keyrings and trusted vs user keys.

No problem. HTH.

Cheers,
Ahmad

> 
> Tim
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-08-23 13:29           ` Ahmad Fatoum
@ 2021-08-23 17:50             ` Tim Harvey
  2021-08-24  7:33               ` Ahmad Fatoum
  0 siblings, 1 reply; 28+ messages in thread
From: Tim Harvey @ 2021-08-23 17:50 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: David Gstir, Aymen Sghaier, Mimi Zohar, Jan Luebbe, keyrings,
	Steffen Trumtrar, linux-security-module, Udit Agarwal,
	Herbert Xu, Horia Geantă,
	Richard Weinberger, James Morris, Eric Biggers, Serge E. Hallyn,
	Sumit Garg, James Bottomley, Franck LENORMAND, David Howells,
	open list, Jarkko Sakkinen, linux-crypto, Sascha Hauer,
	linux-integrity, David S. Miller

On Mon, Aug 23, 2021 at 6:29 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> Hello Tim,
>
> On 20.08.21 23:19, Tim Harvey wrote:
> > On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>
> >> On 20.08.21 22:20, Tim Harvey wrote:
> >>> On Fri, Aug 20, 2021 at 9:20 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>>> On 20.08.21 17:39, Tim Harvey wrote:
> >>>>> Thanks for your work!
> >>>>>
> >>>>> I've been asked to integrate the capability of using CAAM to
> >>>>> blob/deblob data to an older 5.4 kernel such as NXP's downstream
> >>>>> vendor kernel does [1] and I'm trying to understand how your series
> >>>>> works. I'm not at all familiar with the Linux Key Management API's or
> >>>>> trusted keys. Can you provide an example of how this can be used for
> >>>>> such a thing?
> >>>>
> >>>> Here's an example with dm-crypt:
> >>>>
> >>>>   https://lore.kernel.org/linux-integrity/5d44e50e-4309-830b-79f6-f5d888b1ef69@pengutronix.de/
> >>>>
> >>>> dm-crypt is a bit special at the moment, because it has direct support for
> >>>> trusted keys. For interfacing with other parts of the kernel like ecryptfs
> >>>> or EVM, you have to create encrypted keys rooted to the trusted keys and use
> >>>> those. The kernel documentation has an example:
> >>>>
> >>>>   https://www.kernel.org/doc/html/v5.13/security/keys/trusted-encrypted.html
> >>>>
> >>>> If you backport this series, you can include the typo fix spotted by David.
> >>>>
> >>>> I'll send out a revised series, but given that a regression fix I want to
> >>>> rebase on hasn't been picked up for 3 weeks now, I am not in a hurry.
> >>>>
> >>> Thanks for the reference.
> >>>
> >>> I'm still trying to understand the keyctl integration with caam. For
> >>> the 'data' param to keyctl you are using tings like 'new <len>' and
> >>> 'load <data>'. Where are these 'commands' identified?
> >>
> >> Search for match_table_t in security/keys/trusted-keys/trusted_core.c
> >>
> >>> I may still be missing something. I'm using 4.14-rc6 with your series
> >>> and seeing the following:
> >>
> >> That's an odd version to backport stuff to..
> >>
> >>> # cat /proc/cmdline
> >>> trusted.source=caam
> >>> # keyctl add trusted mykey 'new 32' @s)# create new trusted key named
> >>> 'mykey' of 32 bytes in the session keyring
> >>> 480104283
> >>> # keyctl print 480104283 # dump the key
> >>> keyctl_read_alloc: Unknown error 126
> >>> ^^^ not clear what this is
> >>
> >> Not sure what returns -ENOKEY for you. I haven't been using trusted
> >> keys on v4.14, but you can try tracing the keyctl syscall.
> >
> > yikes... that would be painful. I typo'd and meant 5.14-rc6 :)
>
> ^^
>
> > I'm working with mainline first to make sure I understand everything. If I
> > backport this it would be to 5.4 but that looks to be extremely
> > painful. It looks like there was a lot of activity around trusted keys
> > in 5.13.
>
> Ye. It used to be limited to TPM before that.
>
> > It works for a user keyring but not a session keyring... does that
> > explain anything?
> > # keyctl add trusted mykey 'new 32' @u
> > 941210782
> > # keyctl print 941210782
> > 83b7845cb45216496aead9ee2c6a406f587d64aad47bddc539d8947a247e618798d9306b36398b5dc2722a4c3f220a3a763ee175f6bd64758fdd49ca4db597e8ce328121b60edbba9b8d8d55056be896
> > # keyctl add trusted mykey 'new 32' @s
> > 310571960
> > # keyctl print 310571960
> > keyctl_read_alloc: Unknown error 126
>
> Both sequences work for me.
>
> My getty is started by systemd. I think systemd allocates a new session
> keyring for the getty that's inherited by the shell and the commands I run
> it in. If you don't do that, each command will get its own session key.
>
> > Sorry, I'm still trying to wrap my head around the differences in
> > keyrings and trusted vs user keys.
>
> No problem. HTH.

Ahmad,

Ok that explains it - my testing is using a very basic buildroot
ramdisk rootfs. If I do a 'keyctl new_session' first I can use the
system keyring fine as well.

Thanks - hoping to see this merged soon!

Tim

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-08-23 17:50             ` Tim Harvey
@ 2021-08-24  7:33               ` Ahmad Fatoum
  2021-08-24 15:23                 ` Tim Harvey
  0 siblings, 1 reply; 28+ messages in thread
From: Ahmad Fatoum @ 2021-08-24  7:33 UTC (permalink / raw)
  To: Tim Harvey
  Cc: David Gstir, Aymen Sghaier, Mimi Zohar, Jan Luebbe, keyrings,
	Steffen Trumtrar, linux-security-module, Udit Agarwal,
	Herbert Xu, Horia Geantă,
	Richard Weinberger, James Morris, Eric Biggers, Serge E. Hallyn,
	Sumit Garg, James Bottomley, Franck LENORMAND, David Howells,
	open list, Jarkko Sakkinen, linux-crypto, Sascha Hauer,
	linux-integrity, David S. Miller

On 23.08.21 19:50, Tim Harvey wrote:
> On Mon, Aug 23, 2021 at 6:29 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>> On 20.08.21 23:19, Tim Harvey wrote:
>>> On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>>> On 20.08.21 22:20, Tim Harvey wrote:
>>> It works for a user keyring but not a session keyring... does that
>>> explain anything?
>>> # keyctl add trusted mykey 'new 32' @u
>>> 941210782
>>> # keyctl print 941210782
>>> 83b7845cb45216496aead9ee2c6a406f587d64aad47bddc539d8947a247e618798d9306b36398b5dc2722a4c3f220a3a763ee175f6bd64758fdd49ca4db597e8ce328121b60edbba9b8d8d55056be896
>>> # keyctl add trusted mykey 'new 32' @s
>>> 310571960
>>> # keyctl print 310571960
>>> keyctl_read_alloc: Unknown error 126
>>
>> Both sequences work for me.
>>
>> My getty is started by systemd. I think systemd allocates a new session
>> keyring for the getty that's inherited by the shell and the commands I run
>> it in. If you don't do that, each command will get its own session key.
>>
>>> Sorry, I'm still trying to wrap my head around the differences in
>>> keyrings and trusted vs user keys.
>>
>> No problem. HTH.
> 
> Ahmad,
> 
> Ok that explains it - my testing is using a very basic buildroot
> ramdisk rootfs. If I do a 'keyctl new_session' first I can use the
> system keyring fine as well.

Great. Does this mean I can get your Tested-by: ? :)

> Thanks - hoping to see this merged soon!

You and me both.

Cheers,
Ahmad


> 
> Tim
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-08-24  7:33               ` Ahmad Fatoum
@ 2021-08-24 15:23                 ` Tim Harvey
  2021-08-25  9:34                   ` Ahmad Fatoum
  0 siblings, 1 reply; 28+ messages in thread
From: Tim Harvey @ 2021-08-24 15:23 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: David Gstir, Aymen Sghaier, Mimi Zohar, Jan Luebbe, keyrings,
	Steffen Trumtrar, linux-security-module, Udit Agarwal,
	Herbert Xu, Horia Geantă,
	Richard Weinberger, James Morris, Eric Biggers, Serge E. Hallyn,
	Sumit Garg, James Bottomley, Franck LENORMAND, David Howells,
	open list, Jarkko Sakkinen, linux-crypto, Sascha Hauer,
	linux-integrity, David S. Miller

On Tue, Aug 24, 2021 at 12:33 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>
> On 23.08.21 19:50, Tim Harvey wrote:
> > On Mon, Aug 23, 2021 at 6:29 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >> On 20.08.21 23:19, Tim Harvey wrote:
> >>> On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
> >>>> On 20.08.21 22:20, Tim Harvey wrote:
> >>> It works for a user keyring but not a session keyring... does that
> >>> explain anything?
> >>> # keyctl add trusted mykey 'new 32' @u
> >>> 941210782
> >>> # keyctl print 941210782
> >>> 83b7845cb45216496aead9ee2c6a406f587d64aad47bddc539d8947a247e618798d9306b36398b5dc2722a4c3f220a3a763ee175f6bd64758fdd49ca4db597e8ce328121b60edbba9b8d8d55056be896
> >>> # keyctl add trusted mykey 'new 32' @s
> >>> 310571960
> >>> # keyctl print 310571960
> >>> keyctl_read_alloc: Unknown error 126
> >>
> >> Both sequences work for me.
> >>
> >> My getty is started by systemd. I think systemd allocates a new session
> >> keyring for the getty that's inherited by the shell and the commands I run
> >> it in. If you don't do that, each command will get its own session key.
> >>
> >>> Sorry, I'm still trying to wrap my head around the differences in
> >>> keyrings and trusted vs user keys.
> >>
> >> No problem. HTH.
> >
> > Ahmad,
> >
> > Ok that explains it - my testing is using a very basic buildroot
> > ramdisk rootfs. If I do a 'keyctl new_session' first I can use the
> > system keyring fine as well.
>
> Great. Does this mean I can get your Tested-by: ? :)
>

Absolutely,

For the series:

I tested this series on top of v5.14.rc-7 on a Gateworks
imx8mm-venice-gw73xx board with kernel param trusted.source=caam and
keyutils-1.6:
# keyctl new_session
22544757
# keyctl add trusted mykey 'new 32' @s
160701809
# keyctl print 160701809
990e03aa4515aee420eede17e26a58d0c5568c8bd2c9c2ee2f22a0583181d20d4f65cf9cb1f944a3cc92c0e3184a44a29a7e511f0a55a6af11a70ac2b2924514002475e73ae09820042896b9ee00a5ec

Tested-By: Tim Harvey <tharvey@gateworks.com>

One more question: I've got a user that wants to blob/deblob generic
data. They can use the caam_encap_blob/caam_decap_blob functions in
kernel code but could you give me a suggestion for how they could use
this in:
a) userspace code (using the keyctl syscall I assume)
b) userspace cmdline (via keyutils I assume)

Many thanks,

Tim

^ permalink raw reply	[flat|nested] 28+ messages in thread

* Re: [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2021-08-24 15:23                 ` Tim Harvey
@ 2021-08-25  9:34                   ` Ahmad Fatoum
  0 siblings, 0 replies; 28+ messages in thread
From: Ahmad Fatoum @ 2021-08-25  9:34 UTC (permalink / raw)
  To: Tim Harvey
  Cc: David Gstir, Aymen Sghaier, Mimi Zohar, Jan Luebbe, keyrings,
	Steffen Trumtrar, linux-security-module, Udit Agarwal,
	Herbert Xu, Horia Geantă,
	Richard Weinberger, James Morris, Eric Biggers, Serge E. Hallyn,
	Sumit Garg, James Bottomley, Franck LENORMAND, David Howells,
	open list, Jarkko Sakkinen, linux-crypto, Sascha Hauer,
	linux-integrity, David S. Miller

On 24.08.21 17:23, Tim Harvey wrote:
> On Tue, Aug 24, 2021 at 12:33 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>
>> On 23.08.21 19:50, Tim Harvey wrote:
>>> On Mon, Aug 23, 2021 at 6:29 AM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>>> On 20.08.21 23:19, Tim Harvey wrote:
>>>>> On Fri, Aug 20, 2021 at 1:36 PM Ahmad Fatoum <a.fatoum@pengutronix.de> wrote:
>>>>>> On 20.08.21 22:20, Tim Harvey wrote:
>>>>> It works for a user keyring but not a session keyring... does that
>>>>> explain anything?
>>>>> # keyctl add trusted mykey 'new 32' @u
>>>>> 941210782
>>>>> # keyctl print 941210782
>>>>> 83b7845cb45216496aead9ee2c6a406f587d64aad47bddc539d8947a247e618798d9306b36398b5dc2722a4c3f220a3a763ee175f6bd64758fdd49ca4db597e8ce328121b60edbba9b8d8d55056be896
>>>>> # keyctl add trusted mykey 'new 32' @s
>>>>> 310571960
>>>>> # keyctl print 310571960
>>>>> keyctl_read_alloc: Unknown error 126
>>>>
>>>> Both sequences work for me.
>>>>
>>>> My getty is started by systemd. I think systemd allocates a new session
>>>> keyring for the getty that's inherited by the shell and the commands I run
>>>> it in. If you don't do that, each command will get its own session key.
>>>>
>>>>> Sorry, I'm still trying to wrap my head around the differences in
>>>>> keyrings and trusted vs user keys.
>>>>
>>>> No problem. HTH.
>>>
>>> Ahmad,
>>>
>>> Ok that explains it - my testing is using a very basic buildroot
>>> ramdisk rootfs. If I do a 'keyctl new_session' first I can use the
>>> system keyring fine as well.
>>
>> Great. Does this mean I can get your Tested-by: ? :)
>>
> 
> Absolutely,
> 
> For the series:
> 
> I tested this series on top of v5.14.rc-7 on a Gateworks
> imx8mm-venice-gw73xx board with kernel param trusted.source=caam and
> keyutils-1.6:
> # keyctl new_session
> 22544757
> # keyctl add trusted mykey 'new 32' @s
> 160701809
> # keyctl print 160701809
> 990e03aa4515aee420eede17e26a58d0c5568c8bd2c9c2ee2f22a0583181d20d4f65cf9cb1f944a3cc92c0e3184a44a29a7e511f0a55a6af11a70ac2b2924514002475e73ae09820042896b9ee00a5ec
> 
> Tested-By: Tim Harvey <tharvey@gateworks.com>

Thanks. I'll apply it to the whole series then.

> One more question: I've got a user that wants to blob/deblob generic
> data. They can use the caam_encap_blob/caam_decap_blob functions in
> kernel code but could you give me a suggestion for how they could use
> this in:
> a) userspace code (using the keyctl syscall I assume)
> b) userspace cmdline (via keyutils I assume)

Trusted keys aren't disclosed to userspace in plain text, only in sealed
form (bar vulnerabilities of course).

Cheers,
Ahmad

> 
> Many thanks,
> 
> Tim
> 


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 28+ messages in thread

end of thread, other threads:[~2021-08-25  9:34 UTC | newest]

Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-21 16:48 [PATCH 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
2021-07-21 16:48 ` [PATCH 1/4] KEYS: trusted: allow users to use kernel RNG for key material Ahmad Fatoum
2021-07-22  6:17   ` Sumit Garg
2021-07-21 16:48 ` [PATCH 2/4] KEYS: trusted: allow trust sources " Ahmad Fatoum
2021-07-22  6:31   ` Sumit Garg
2021-08-09  7:52     ` Ahmad Fatoum
2021-08-09  9:56       ` Jarkko Sakkinen
2021-08-10  5:24         ` Sumit Garg
2021-07-21 16:48 ` [PATCH 3/4] crypto: caam - add in-kernel interface for blob generator Ahmad Fatoum
2021-08-10 11:29   ` David Gstir
2021-08-11 10:22     ` Ahmad Fatoum
2021-08-11 10:43       ` David Gstir
2021-07-21 16:48 ` [PATCH 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
2021-08-06 15:12 ` [PATCH 0/4] " Ahmad Fatoum
2021-08-09  9:35   ` Jarkko Sakkinen
2021-08-09 10:16     ` Ahmad Fatoum
2021-08-10 11:28       ` David Gstir
2021-08-20 16:25         ` Ahmad Fatoum
2021-08-20 15:39 ` Tim Harvey
2021-08-20 16:19   ` Ahmad Fatoum
2021-08-20 20:20     ` Tim Harvey
2021-08-20 20:36       ` Ahmad Fatoum
2021-08-20 21:19         ` Tim Harvey
2021-08-23 13:29           ` Ahmad Fatoum
2021-08-23 17:50             ` Tim Harvey
2021-08-24  7:33               ` Ahmad Fatoum
2021-08-24 15:23                 ` Tim Harvey
2021-08-25  9:34                   ` Ahmad Fatoum

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.