All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v6 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
@ 2022-03-16 16:43 Ahmad Fatoum
  2022-03-16 16:43 ` [PATCH v6 1/4] KEYS: trusted: allow use of TEE as backend without TCG_TPM support Ahmad Fatoum
                   ` (3 more replies)
  0 siblings, 4 replies; 17+ messages in thread
From: Ahmad Fatoum @ 2022-03-16 16:43 UTC (permalink / raw)
  To: Jarkko Sakkinen, Horia Geantă,
	Mimi Zohar, Pankaj Gupta, Herbert Xu, David S. Miller,
	James Bottomley
  Cc: kernel, David Howells, James Morris, Serge E. Hallyn,
	Steffen Trumtrar, Jan Luebbe, David Gstir, Eric Biggers,
	Richard Weinberger, Franck LENORMAND, Sumit Garg,
	Andreas Rammhold, Tim Harvey, Matthias Schiffer, linux-integrity,
	keyrings, linux-crypto, linux-kernel, linux-security-module

Series applies on top of current linux-tpmdd/master

v5 was here:
https://lore.kernel.org/linux-integrity/20220222195819.2313913-1-a.fatoum@pengutronix.de/

Changelog was moved beneath each individual patch.


The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
built into many newer i.MX and QorIQ SoCs by NXP.

Its blob mechanism can AES encrypt/decrypt user data using a unique
never-disclosed device-specific key.

There has been multiple discussions on how to represent this within the kernel:

The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
built into many newer i.MX and QorIQ SoCs by NXP.

Its blob mechanism can AES encrypt/decrypt user data using a unique
never-disclosed device-specific key. There has been multiple
discussions on how to represent this within the kernel:

 - [RFC] crypto: caam - add red blobifier
   Steffen implemented[1] a PoC sysfs driver to start a discussion on how to
   best integrate the blob mechanism.
   Mimi suggested that it could be used to implement trusted keys.
   Trusted keys back then were a TPM-only feature.

 - security/keys/secure_key: Adds the secure key support based on CAAM.
   Udit Agarwal added[2] a new "secure" key type with the CAAM as backend.
   The key material stays within the kernel only.
   Mimi and James agreed that this needs a generic interface, not specific
   to CAAM. Mimi suggested trusted keys. Jan noted that this could serve as
   basis for TEE-backed keys.

 - [RFC] drivers: crypto: caam: key: Add caam_tk key type
   Franck added[3] a new "caam_tk" key type based on Udit's work. This time
   it uses CAAM "black blobs" instead of "red blobs", so key material stays
   within the CAAM and isn't exposed to kernel in plaintext.
   James voiced the opinion that there should be just one user-facing generic
   wrap/unwrap key type with multiple possible handlers.
   David suggested trusted keys.

 - Introduce TEE based Trusted Keys support
   Sumit reworked[4] trusted keys to support multiple possible backends with
   one chosen at boot time and added a new TEE backend along with TPM.
   This now sits in Jarkko's master branch to be sent out for v5.13

This patch series builds on top of Sumit's rework to have the CAAM as yet another
trusted key backend.

The CAAM bits are based on Steffen's initial patch from 2015. His work had been
used in the field for some years now, so I preferred not to deviate too much from it.

This series has been tested with dmcrypt[5] on an i.MX6Q/DL and an i.MX8M[6].

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/
 [6]: https://lore.kernel.org/linux-integrity/DU2PR04MB8630D83FE9BBC0D782C4FAF595089@DU2PR04MB8630.eurprd04.prod.outlook.com/

---
To: Jarkko Sakkinen <jarkko@kernel.org>
To: "Horia Geantă" <horia.geanta@nxp.com>
To: Mimi Zohar <zohar@linux.ibm.com>
To: Pankaj Gupta <pankaj.gupta@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: 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: Andreas Rammhold <andreas@rammhold.de>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
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 use of TEE as backend without TCG_TPM support
  KEYS: trusted: allow use of kernel RNG for key material
  crypto: caam - add in-kernel interface for blob generator
  KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

 .../admin-guide/kernel-parameters.txt         |  11 ++
 .../security/keys/trusted-encrypted.rst       |  60 ++++++-
 MAINTAINERS                                   |   9 +
 drivers/crypto/caam/Kconfig                   |   3 +
 drivers/crypto/caam/Makefile                  |   1 +
 drivers/crypto/caam/blob_gen.c                | 160 ++++++++++++++++++
 include/keys/trusted-type.h                   |   2 +-
 include/keys/trusted_caam.h                   |  11 ++
 include/soc/fsl/caam-blob.h                   |  79 +++++++++
 security/keys/Kconfig                         |  18 +-
 security/keys/trusted-keys/Kconfig            |  38 +++++
 security/keys/trusted-keys/Makefile           |  10 +-
 security/keys/trusted-keys/trusted_caam.c     |  74 ++++++++
 security/keys/trusted-keys/trusted_core.c     |  45 ++++-
 14 files changed, 492 insertions(+), 29 deletions(-)
 create mode 100644 drivers/crypto/caam/blob_gen.c
 create mode 100644 include/keys/trusted_caam.h
 create mode 100644 include/soc/fsl/caam-blob.h
 create mode 100644 security/keys/trusted-keys/Kconfig
 create mode 100644 security/keys/trusted-keys/trusted_caam.c

-- 
2.30.2


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

* [PATCH v6 1/4] KEYS: trusted: allow use of TEE as backend without TCG_TPM support
  2022-03-16 16:43 [PATCH v6 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
@ 2022-03-16 16:43 ` Ahmad Fatoum
  2022-03-16 16:43 ` [PATCH v6 2/4] KEYS: trusted: allow use of kernel RNG for key material Ahmad Fatoum
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 17+ messages in thread
From: Ahmad Fatoum @ 2022-03-16 16:43 UTC (permalink / raw)
  To: Jarkko Sakkinen, James Morris, Serge E. Hallyn, James Bottomley,
	Mimi Zohar, Sumit Garg, David Howells, Herbert Xu,
	David S. Miller
  Cc: kernel, Andreas Rammhold, Tim Harvey, Ahmad Fatoum, David Gstir,
	Richard Weinberger, Matthias Schiffer, keyrings, linux-crypto,
	linux-kernel, linux-security-module, linux-integrity

With recent rework, trusted keys are no longer limited to TPM as trust
source. The Kconfig symbol is unchanged however leading to a few issues:

  - TCG_TPM is required, even if only TEE is to be used
  - Enabling TCG_TPM, but excluding it from available trusted sources
    is not possible
  - TEE=m && TRUSTED_KEYS=y will lead to TEE support being silently
    dropped, which is not the best user experience

Remedy these issues by introducing two new boolean Kconfig symbols:
TRUSTED_KEYS_TPM and TRUSTED_KEYS_TEE with the appropriate
dependencies.

Any new code depending on the TPM trusted key backend in particular
or symbols exported by it will now need to explicitly state that it

  depends on TRUSTED_KEYS && TRUSTED_KEYS_TPM

The latter to ensure the dependency is built and the former to ensure
it's reachable for module builds. There are no such users yet.

Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Tested-By: Andreas Rammhold <andreas@rammhold.de>
Tested-By: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
v5 -> v6:
  - Rebased on asym_tpm removal
v4 -> v5:
  - collected Jarkko's Reviewed-by
v3 -> v4:
  - rebased on top of Andreas' regression fix and pulled it back
    into series
v2 -> v3:
  - factored this patch out as a fix for backporting
v1 -> v2:
  - Move rest of TPM-related selects from TRUSTED_KEYS to
    TRUSTED_KEYS_TPM (Sumit)
  - Remove left-over line in Makefile (Sumit)
  - added Fixes: tag
  - adjust commit message to reference the regression reported
    by Andreas
  - have ASYMMETRIC_TPM_KEY_SUBTYPE depend on TRUSTED_KEYS_TPM,
    because it references global symbols that are exported
    by the trusted key TPM backend.

[1]: https://lore.kernel.org/linux-integrity/f8285eb0135ba30c9d846cf9dd395d1f5f8b1efc.1624364386.git-series.a.fatoum@pengutronix.de/
[2]: https://lore.kernel.org/linux-integrity/20210719091335.vwfebcpkf4pag3wm@wrt/T/#t

To: Jarkko Sakkinen <jarkko@kernel.org>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: James Bottomley <jejb@linux.ibm.com>
To: Mimi Zohar <zohar@linux.ibm.com>
To: Sumit Garg <sumit.garg@linaro.org>
To: David Howells <dhowells@redhat.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
To: "David S. Miller" <davem@davemloft.net>
Cc: David Gstir <david@sigma-star.at>
Cc: Richard Weinberger <richard@nod.at>
Cc: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Cc: keyrings@vger.kernel.org
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
---
 security/keys/Kconfig                     | 18 ++++++--------
 security/keys/trusted-keys/Kconfig        | 29 +++++++++++++++++++++++
 security/keys/trusted-keys/Makefile       |  8 +++----
 security/keys/trusted-keys/trusted_core.c |  4 ++--
 4 files changed, 42 insertions(+), 17 deletions(-)
 create mode 100644 security/keys/trusted-keys/Kconfig

diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index 969122c7b92f..826cd0904f9a 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -70,23 +70,19 @@ config BIG_KEYS
 
 config TRUSTED_KEYS
 	tristate "TRUSTED KEYS"
-	depends on KEYS && TCG_TPM
-	select CRYPTO
-	select CRYPTO_HMAC
-	select CRYPTO_SHA1
-	select CRYPTO_HASH_INFO
-	select ASN1_ENCODER
-	select OID_REGISTRY
-	select ASN1
+	depends on KEYS
 	help
 	  This option provides support for creating, sealing, and unsealing
 	  keys in the kernel. Trusted keys are random number symmetric keys,
-	  generated and RSA-sealed by the TPM. The TPM only unseals the keys,
-	  if the boot PCRs and other criteria match.  Userspace will only ever
-	  see encrypted blobs.
+	  generated and sealed by a trust source selected at kernel boot-time.
+	  Userspace will only ever see encrypted blobs.
 
 	  If you are unsure as to whether this is required, answer N.
 
+if TRUSTED_KEYS
+source "security/keys/trusted-keys/Kconfig"
+endif
+
 config ENCRYPTED_KEYS
 	tristate "ENCRYPTED KEYS"
 	depends on KEYS
diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig
new file mode 100644
index 000000000000..fc4abd581abb
--- /dev/null
+++ b/security/keys/trusted-keys/Kconfig
@@ -0,0 +1,29 @@
+config TRUSTED_KEYS_TPM
+	bool "TPM-based trusted keys"
+	depends on TCG_TPM >= TRUSTED_KEYS
+	default y
+	select CRYPTO
+	select CRYPTO_HMAC
+	select CRYPTO_SHA1
+	select CRYPTO_HASH_INFO
+	select ASN1_ENCODER
+	select OID_REGISTRY
+	select ASN1
+	help
+	  Enable use of the Trusted Platform Module (TPM) as trusted key
+	  backend. Trusted keys are random number symmetric keys,
+	  which will be generated and RSA-sealed by the TPM.
+	  The TPM only unseals the keys, if the boot PCRs and other
+	  criteria match.
+
+config TRUSTED_KEYS_TEE
+	bool "TEE-based trusted keys"
+	depends on TEE >= TRUSTED_KEYS
+	default y
+	help
+	  Enable use of the Trusted Execution Environment (TEE) as trusted
+	  key backend.
+
+if !TRUSTED_KEYS_TPM && !TRUSTED_KEYS_TEE
+comment "No trust source selected!"
+endif
diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
index feb8b6c3cc79..2e2371eae4d5 100644
--- a/security/keys/trusted-keys/Makefile
+++ b/security/keys/trusted-keys/Makefile
@@ -5,10 +5,10 @@
 
 obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
 trusted-y += trusted_core.o
-trusted-y += trusted_tpm1.o
+trusted-$(CONFIG_TRUSTED_KEYS_TPM) += trusted_tpm1.o
 
 $(obj)/trusted_tpm2.o: $(obj)/tpm2key.asn1.h
-trusted-y += trusted_tpm2.o
-trusted-y += tpm2key.asn1.o
+trusted-$(CONFIG_TRUSTED_KEYS_TPM) += trusted_tpm2.o
+trusted-$(CONFIG_TRUSTED_KEYS_TPM) += tpm2key.asn1.o
 
-trusted-$(CONFIG_TEE) += trusted_tee.o
+trusted-$(CONFIG_TRUSTED_KEYS_TEE) += trusted_tee.o
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index 9b9d3ef79cbe..7cdbd16aed30 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -27,10 +27,10 @@ module_param_named(source, trusted_key_source, charp, 0);
 MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)");
 
 static const struct trusted_key_source trusted_key_sources[] = {
-#if IS_REACHABLE(CONFIG_TCG_TPM)
+#if defined(CONFIG_TRUSTED_KEYS_TPM)
 	{ "tpm", &trusted_key_tpm_ops },
 #endif
-#if IS_REACHABLE(CONFIG_TEE)
+#if defined(CONFIG_TRUSTED_KEYS_TEE)
 	{ "tee", &trusted_key_tee_ops },
 #endif
 };
-- 
2.30.2


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

* [PATCH v6 2/4] KEYS: trusted: allow use of kernel RNG for key material
  2022-03-16 16:43 [PATCH v6 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
  2022-03-16 16:43 ` [PATCH v6 1/4] KEYS: trusted: allow use of TEE as backend without TCG_TPM support Ahmad Fatoum
@ 2022-03-16 16:43 ` Ahmad Fatoum
  2022-03-16 16:43 ` [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob generator Ahmad Fatoum
  2022-03-16 16:43 ` [PATCH v6 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
  3 siblings, 0 replies; 17+ messages in thread
From: Ahmad Fatoum @ 2022-03-16 16:43 UTC (permalink / raw)
  To: James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells
  Cc: kernel, Sumit Garg, Pankaj Gupta, David Gstir, Ahmad Fatoum,
	James Morris, Serge E. Hallyn, Horia Geantă,
	Herbert Xu, David S. Miller, Jan Luebbe, Eric Biggers,
	Richard Weinberger, Franck LENORMAND, Matthias Schiffer,
	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, both users and future
backends may want to place less trust into the quality of the trust
source's random number generator and instead reuse the kernel entropy
pool, which can be seeded from multiple entropy sources.

Make this possible by adding a new trusted.rng parameter,
that will force use of the kernel RNG. In its absence, it's up
to the trust source to decide, which random numbers to use,
maintaining the existing behavior.

Suggested-by: Jarkko Sakkinen <jarkko@kernel.org>
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Acked-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: David Gstir <david@sigma-star.at>
Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
v5 -> v6:
  - Squash with follow-up patch enabling trust sources to use
    kernel RNG if they don't define their own .get_random
  - Collected Jarkko's Reviewed-by
v4 -> v5:
  - Changed trusted.kernel_rng bool option into a string trusted.rng option
    (Jarkko)
  - Typo fix in commit message (Jarkko)
v3 -> v4:
  - Collected Acked-by's, Reviewed-by's and Tested-by
v2 -> v3:
  - No change
v1 -> v2:
 - Allow users to force use of kernel RNG (Jarkko)

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: Pankaj Gupta <pankaj.gupta@nxp.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
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: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
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
---
 .../admin-guide/kernel-parameters.txt         | 10 ++++++
 .../security/keys/trusted-encrypted.rst       | 20 ++++++-----
 include/keys/trusted-type.h                   |  2 +-
 security/keys/trusted-keys/trusted_core.c     | 35 ++++++++++++++++++-
 4 files changed, 57 insertions(+), 10 deletions(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index f5a27f067db9..844c883ca9d8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5880,6 +5880,16 @@
 			first trust source as a backend which is initialized
 			successfully during iteration.
 
+	trusted.rng=	[KEYS]
+			Format: <string>
+			The RNG used to generate key material for trusted keys.
+			Can be one of:
+			- "kernel"
+			- the same value as trusted.source: "tpm" or "tee"
+			- "default"
+			If not specified, "default" is used. In this case,
+			the RNG's choice is left 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..99cf34d7c025 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.
 
+Users may override this by specifying ``trusted.rng=kernel`` on the kernel
+command-line to override the used RNG with the kernel's random number pool.
+
 Encrypted Keys
 --------------
 
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 7cdbd16aed30..9235fb7d0ec9 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 char *trusted_rng = "default";
+module_param_named(rng, trusted_rng, charp, 0);
+MODULE_PARM_DESC(rng, "Select trusted key RNG");
+
 static char *trusted_key_source;
 module_param_named(source, trusted_key_source, charp, 0);
 MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)");
@@ -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,28 @@ static int __init init_trusted(void)
 			    strlen(trusted_key_sources[i].name)))
 			continue;
 
+		/*
+		 * We always support trusted.rng="kernel" and "default" as
+		 * well as trusted.rng=$trusted.source if the trust source
+		 * defines its own get_random callback.
+		 */
+		get_random = trusted_key_sources[i].ops->get_random;
+		if (trusted_rng && strcmp(trusted_rng, "default")) {
+			if (!strcmp(trusted_rng, "kernel")) {
+				get_random = kernel_get_random;
+			} else if (strcmp(trusted_rng, trusted_key_sources[i].name) ||
+				   !get_random) {
+				pr_warn("Unsupported RNG. Supported: kernel");
+				if (get_random)
+					pr_cont(", %s", trusted_key_sources[i].name);
+				pr_cont(", default\n");
+				return -EINVAL;
+			}
+		}
+
+		if (!get_random)
+			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 +362,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;
-- 
2.30.2


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

* [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob generator
  2022-03-16 16:43 [PATCH v6 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
  2022-03-16 16:43 ` [PATCH v6 1/4] KEYS: trusted: allow use of TEE as backend without TCG_TPM support Ahmad Fatoum
  2022-03-16 16:43 ` [PATCH v6 2/4] KEYS: trusted: allow use of kernel RNG for key material Ahmad Fatoum
@ 2022-03-16 16:43 ` Ahmad Fatoum
  2022-03-22  6:25   ` [EXT] " Pankaj Gupta
  2022-03-24  9:55   ` Pankaj Gupta
  2022-03-16 16:43 ` [PATCH v6 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
  3 siblings, 2 replies; 17+ messages in thread
From: Ahmad Fatoum @ 2022-03-16 16:43 UTC (permalink / raw)
  To: Horia Geantă, Pankaj Gupta, Herbert Xu, David S. Miller
  Cc: kernel, David Gstir, Tim Harvey, Matthias Schiffer, Ahmad Fatoum,
	James Bottomley, Jarkko Sakkinen, Mimi Zohar, David Howells,
	James Morris, Eric Biggers, Serge E. Hallyn, Jan Luebbe,
	Richard Weinberger, Franck LENORMAND, Sumit Garg,
	linux-integrity, keyrings, linux-crypto, linux-kernel,
	linux-security-module

The NXP Cryptographic Acceleration and Assurance Module (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.

Reviewed-by: David Gstir <david@sigma-star.at>
Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Tested-By: Tim Harvey <tharvey@gateworks.com>
Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
v5 -> v6:
  - Dropped caam_blob_alloc_desc() in favor of kzalloc() with fixed size.
    This simplifies code and wastes at most 12 bytes which are freed
    at the end of the function anyway.
  - Factored out common code between caam_encap_blob and caam_decap_blob
    as both functions were largely identical
  - use append_seq_(in|out)_ptr_intlen for both encap/decap as a result
  - use reverse christmas tree order for caam_process_blob variable
    definitions.
v4 -> v5:
  - Collected Reviewed-by's and Tested-by's
  - Note in CAAM patch what CAAM is (Jarkko)
v3 -> v4:
  - Collected Acked-by's, Reviewed-by's and Tested-by
  - Fixed typo spotted by David
v2 -> v3:
 - No change
v1 -> v2:
 - 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)

To: "Horia Geantă" <horia.geanta@nxp.com>
To: Pankaj Gupta <pankaj.gupta@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: 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: Matthias Schiffer <matthias.schiffer@ew.tq-group.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 | 160 +++++++++++++++++++++++++++++++++
 include/soc/fsl/caam-blob.h    |  79 ++++++++++++++++
 4 files changed, 243 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..2564e63c8fe0
--- /dev/null
+++ b/drivers/crypto/caam/blob_gen.c
@@ -0,0 +1,160 @@
+// 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"
+
+/* header + (key mod immediate) + 2x seq_intlen pointers + op */
+#define CAAM_BLOB_DESC_BYTES_MAX \
+	(CAAM_CMD_SZ + \
+	 CAAM_CMD_SZ + CAAM_BLOB_KEYMOD_LENGTH + \
+	 2 * (CAAM_CMD_SZ + CAAM_PTR_SZ_MAX) + \
+	 CAAM_CMD_SZ)
+
+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);
+}
+
+int caam_process_blob(struct caam_blob_priv *priv, bool encap,
+		      const char *keymod, void *input, void *output,
+		      size_t length)
+{
+	size_t in_len = length, out_len = length;
+	struct caam_blob_job_result testres;
+	struct device *jrdev = &priv->jrdev;
+	dma_addr_t dma_in, dma_out;
+	int op = OP_PCLID_BLOB;
+	size_t keymod_len;
+	u32 *desc;
+	int ret;
+
+	keymod_len = strlen(keymod);
+
+	if (length <= CAAM_BLOB_OVERHEAD || keymod_len > CAAM_BLOB_KEYMOD_LENGTH)
+		return -EINVAL;
+
+	if (encap) {
+		op |= OP_TYPE_ENCAP_PROTOCOL;
+		in_len -= CAAM_BLOB_OVERHEAD;
+	} else {
+		op |= OP_TYPE_DECAP_PROTOCOL;
+		out_len -= CAAM_BLOB_OVERHEAD;
+	}
+
+	desc = kzalloc(CAAM_BLOB_DESC_BYTES_MAX, GFP_KERNEL | GFP_DMA);
+	if (!desc) {
+		dev_err(jrdev, "unable to allocate desc\n");
+		return -ENOMEM;
+	}
+
+	dma_in = dma_map_single(jrdev, input, in_len, 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, out_len, 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, in_len, 0);
+	append_seq_out_ptr_intlen(desc, dma_out, out_len, 0);
+	append_operation(desc, op);
+
+	print_hex_dump_debug("data@"__stringify(__LINE__)": ",
+			     DUMP_PREFIX_ADDRESS, 16, 1, input,
+			     in_len, 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,
+				     out_len, false);
+	}
+
+	dma_unmap_single(jrdev, dma_out, out_len, DMA_FROM_DEVICE);
+out_unmap_in:
+	dma_unmap_single(jrdev, dma_in, in_len, DMA_TO_DEVICE);
+out_free:
+	kfree(desc);
+
+	return ret;
+}
+EXPORT_SYMBOL(caam_process_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..2c4a05dc59cd
--- /dev/null
+++ b/include/soc/fsl/caam-blob.h
@@ -0,0 +1,79 @@
+/* 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_exit - free blob generation resources
+ *
+ * @priv: instance returned by caam_blob_gen_init
+ */
+void caam_blob_gen_exit(struct caam_blob_priv *priv);
+
+/** caam_process_blob - encapsulate or decapsulate blob
+ *
+ * @priv:   instance returned by caam_blob_gen_init
+ * @encap:  true for encapsulation, false for decapsulation
+ * @keymod: string to use as key modifier for blob capsulation
+ *	    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_process_blob(struct caam_blob_priv *priv, bool encap,
+		      const char *keymod, void *input, void *output,
+		      size_t length);
+
+/** 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
+ */
+static inline int caam_encap_blob(struct caam_blob_priv *priv,
+				  const char *keymod,
+				  void *input, void *output, size_t length)
+{
+	return caam_process_blob(priv, true, keymod, input, output, 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
+ */
+static inline int caam_decap_blob(struct caam_blob_priv *priv,
+				  const char *keymod,
+				  void *input, void *output, size_t length)
+{
+	return caam_process_blob(priv, false, keymod, input, output, length);
+}
+
+#endif
-- 
2.30.2


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

* [PATCH v6 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2022-03-16 16:43 [PATCH v6 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
                   ` (2 preceding siblings ...)
  2022-03-16 16:43 ` [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob generator Ahmad Fatoum
@ 2022-03-16 16:43 ` Ahmad Fatoum
  2022-03-20 21:02   ` Jarkko Sakkinen
  2022-03-28 10:46   ` [EXT] " Pankaj Gupta
  3 siblings, 2 replies; 17+ messages in thread
From: Ahmad Fatoum @ 2022-03-16 16:43 UTC (permalink / raw)
  To: Jonathan Corbet, David Howells, Jarkko Sakkinen, James Bottomley,
	Mimi Zohar
  Cc: kernel, David Gstir, Pankaj Gupta, Tim Harvey, Matthias Schiffer,
	Ahmad Fatoum, James Morris, Serge E. Hallyn, Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, Eric Biggers,
	Jan Luebbe, 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.

Reviewed-by: David Gstir <david@sigma-star.at>
Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Tested-By: Tim Harvey <tharvey@gateworks.com>
Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
Tested-by: Pankaj Gupta <pankaj.gupta@nxp.com>
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
v5 -> v6:
  - Rename caam_trusted_key_ops to trusted_key_caam_ops for symmetry
    with other trust sources (Pankaj)
  - collected Pankaj's Reviewed-by
v4 -> v5:
  - Collected Reviewed-by's and Tested-by's
  - Changed modifier to SECURE_KEY for compatibility with linux-imx
    (Matthias)
v3 -> v4:
  - Collected Acked-by's, Reviewed-by's and Tested-by
v2 -> v3:
 - add MAINTAINERS entry
v1 -> v2:
 - Extend trusted keys documentation for CAAM

To: Jonathan Corbet <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: 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: Matthias Schiffer <matthias.schiffer@ew.tq-group.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
---
 .../admin-guide/kernel-parameters.txt         |  1 +
 .../security/keys/trusted-encrypted.rst       | 40 +++++++++-
 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, 151 insertions(+), 3 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 844c883ca9d8..9e7ef4c6585d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5875,6 +5875,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 99cf34d7c025..ed60c48cb692 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,6 +123,12 @@ 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
+     is probed.
+
 Users may override this by specifying ``trusted.rng=kernel`` on the kernel
 command-line to override the used RNG with the kernel's random number pool.
 
@@ -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 05fd080b82f3..f13382a14967 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10647,6 +10647,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:	Maintained
+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..73fe2f32f65e
--- /dev/null
+++ b/include/keys/trusted_caam.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright (C) 2021 Pengutronix, Ahmad Fatoum <kernel@pengutronix.de>
+ */
+
+#ifndef __CAAM_TRUSTED_KEY_H
+#define __CAAM_TRUSTED_KEY_H
+
+extern struct trusted_key_ops trusted_key_caam_ops;
+
+#endif
diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-keys/Kconfig
index fc4abd581abb..dbfdd8536468 100644
--- a/security/keys/trusted-keys/Kconfig
+++ b/security/keys/trusted-keys/Kconfig
@@ -24,6 +24,15 @@ config TRUSTED_KEYS_TEE
 	  Enable use of the Trusted Execution Environment (TEE) as trusted
 	  key backend.
 
-if !TRUSTED_KEYS_TPM && !TRUSTED_KEYS_TEE
+config TRUSTED_KEYS_CAAM
+	bool "CAAM-based trusted keys"
+	depends on CRYPTO_DEV_FSL_CAAM_JR >= TRUSTED_KEYS
+	select CRYPTO_DEV_FSL_CAAM_BLOB_GEN
+	default y
+	help
+	  Enable use of NXP's Cryptographic Accelerator and Assurance Module
+	  (CAAM) as trusted key backend.
+
+if !TRUSTED_KEYS_TPM && !TRUSTED_KEYS_TEE && !TRUSTED_KEYS_CAAM
 comment "No trust source selected!"
 endif
diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
index 2e2371eae4d5..735aa0bc08ef 100644
--- a/security/keys/trusted-keys/Makefile
+++ b/security/keys/trusted-keys/Makefile
@@ -12,3 +12,5 @@ trusted-$(CONFIG_TRUSTED_KEYS_TPM) += trusted_tpm2.o
 trusted-$(CONFIG_TRUSTED_KEYS_TPM) += tpm2key.asn1.o
 
 trusted-$(CONFIG_TRUSTED_KEYS_TEE) += trusted_tee.o
+
+trusted-$(CONFIG_TRUSTED_KEYS_CAAM) += trusted_caam.o
diff --git a/security/keys/trusted-keys/trusted_caam.c b/security/keys/trusted-keys/trusted_caam.c
new file mode 100644
index 000000000000..5457c76c6602
--- /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 "SECURE_KEY"
+
+static_assert(MAX_KEY_SIZE + CAAM_BLOB_OVERHEAD <= CAAM_BLOB_MAX_LEN);
+static_assert(MAX_BLOB_SIZE <= CAAM_BLOB_MAX_LEN);
+
+static int trusted_caam_seal(struct trusted_key_payload *p, char *datablob)
+{
+	int 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 trusted_key_caam_ops = {
+	.migratable = 0, /* non-migratable */
+	.init = trusted_caam_init,
+	.seal = trusted_caam_seal,
+	.unseal = trusted_caam_unseal,
+	.exit = trusted_caam_exit,
+};
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index 9235fb7d0ec9..c6fc50d67214 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -9,6 +9,7 @@
 #include <keys/user-type.h>
 #include <keys/trusted-type.h>
 #include <keys/trusted_tee.h>
+#include <keys/trusted_caam.h>
 #include <keys/trusted_tpm.h>
 #include <linux/capability.h>
 #include <linux/err.h>
@@ -29,7 +30,7 @@ MODULE_PARM_DESC(rng, "Select trusted key RNG");
 
 static char *trusted_key_source;
 module_param_named(source, trusted_key_source, charp, 0);
-MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)");
+MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or caam)");
 
 static const struct trusted_key_source trusted_key_sources[] = {
 #if defined(CONFIG_TRUSTED_KEYS_TPM)
@@ -38,6 +39,9 @@ static const struct trusted_key_source trusted_key_sources[] = {
 #if defined(CONFIG_TRUSTED_KEYS_TEE)
 	{ "tee", &trusted_key_tee_ops },
 #endif
+#if defined(CONFIG_TRUSTED_KEYS_CAAM)
+	{ "caam", &trusted_key_caam_ops },
+#endif
 };
 
 DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
-- 
2.30.2


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

* Re: [PATCH v6 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2022-03-16 16:43 ` [PATCH v6 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
@ 2022-03-20 21:02   ` Jarkko Sakkinen
  2022-03-22  7:33     ` Ahmad Fatoum
  2022-03-28 10:46   ` [EXT] " Pankaj Gupta
  1 sibling, 1 reply; 17+ messages in thread
From: Jarkko Sakkinen @ 2022-03-20 21:02 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: Jonathan Corbet, David Howells, James Bottomley, Mimi Zohar,
	kernel, David Gstir, Pankaj Gupta, Tim Harvey, Matthias Schiffer,
	James Morris, Serge E. Hallyn, Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, Eric Biggers,
	Jan Luebbe, Richard Weinberger, Franck LENORMAND, Sumit Garg,
	keyrings, linux-crypto, linux-doc, linux-integrity, linux-kernel,
	linux-security-module

On Wed, Mar 16, 2022 at 05:43:35PM +0100, Ahmad Fatoum wrote:
> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
> built into many newer i.MX and QorIQ SoCs by NXP.
> 
> The CAAM does crypto acceleration, hardware number generation and
> has a blob mechanism for encapsulation/decapsulation of sensitive material.
> 
> This blob mechanism depends on a device specific random 256-bit One Time
> Programmable Master Key that is fused in each SoC at manufacturing
> time. This key is unreadable and can only be used by the CAAM for AES
> encryption/decryption of user data.
> 
> This makes it a suitable backend (source) for kernel trusted keys.
> 
> Previous commits generalized trusted keys to support multiple backends
> and added an API to access the CAAM blob mechanism. Based on these,
> provide the necessary glue to use the CAAM for trusted keys.
> 
> Reviewed-by: David Gstir <david@sigma-star.at>
> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
> Tested-By: Tim Harvey <tharvey@gateworks.com>
> Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> Tested-by: Pankaj Gupta <pankaj.gupta@nxp.com>
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> v5 -> v6:
>   - Rename caam_trusted_key_ops to trusted_key_caam_ops for symmetry
>     with other trust sources (Pankaj)
>   - collected Pankaj's Reviewed-by
> v4 -> v5:
>   - Collected Reviewed-by's and Tested-by's
>   - Changed modifier to SECURE_KEY for compatibility with linux-imx
>     (Matthias)
> v3 -> v4:
>   - Collected Acked-by's, Reviewed-by's and Tested-by
> v2 -> v3:
>  - add MAINTAINERS entry
> v1 -> v2:
>  - Extend trusted keys documentation for CAAM
> 
> To: Jonathan Corbet <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: 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: Matthias Schiffer <matthias.schiffer@ew.tq-group.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
> ---
>  .../admin-guide/kernel-parameters.txt         |  1 +
>  .../security/keys/trusted-encrypted.rst       | 40 +++++++++-
>  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, 151 insertions(+), 3 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 844c883ca9d8..9e7ef4c6585d 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5875,6 +5875,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 99cf34d7c025..ed60c48cb692 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,6 +123,12 @@ 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
> +     is probed.
> +
>  Users may override this by specifying ``trusted.rng=kernel`` on the kernel
>  command-line to override the used RNG with the kernel's random number pool.
>  
> @@ -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 05fd080b82f3..f13382a14967 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10647,6 +10647,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:	Maintained
> +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>

Documentation and MAINTAINERS updates must be separate patches.

BR, Jarkko

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

* RE: [EXT] [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob generator
  2022-03-16 16:43 ` [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob generator Ahmad Fatoum
@ 2022-03-22  6:25   ` Pankaj Gupta
  2022-03-22  7:32     ` Ahmad Fatoum
  2022-03-24  9:55   ` Pankaj Gupta
  1 sibling, 1 reply; 17+ messages in thread
From: Pankaj Gupta @ 2022-03-22  6:25 UTC (permalink / raw)
  To: Ahmad Fatoum, Horia Geanta, Herbert Xu, David S. Miller
  Cc: kernel, David Gstir, tharvey, Matthias Schiffer, James Bottomley,
	Jarkko Sakkinen, Mimi Zohar, David Howells, James Morris,
	Eric Biggers, Serge E. Hallyn, Jan Luebbe, Richard Weinberger,
	Franck Lenormand, Sumit Garg, linux-integrity, keyrings,
	linux-crypto, linux-kernel, linux-security-module

Hi Ahmad,

Suggested to define macro with more details.
Please find comments in-line.

Regards
Pankaj
> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Wednesday, March 16, 2022 10:14 PM
> To: Horia Geanta <horia.geanta@nxp.com>; Pankaj Gupta
> <pankaj.gupta@nxp.com>; Herbert Xu <herbert@gondor.apana.org.au>; David
> S. Miller <davem@davemloft.net>
> Cc: kernel@pengutronix.de; David Gstir <david@sigma-star.at>;
> tharvey@gateworks.com; Matthias Schiffer <matthias.schiffer@ew.tq-
> group.com>; Ahmad Fatoum <a.fatoum@pengutronix.de>; James Bottomley
> <jejb@linux.ibm.com>; Jarkko Sakkinen <jarkko@kernel.org>; Mimi Zohar
> <zohar@linux.ibm.com>; David Howells <dhowells@redhat.com>; James Morris
> <jmorris@namei.org>; Eric Biggers <ebiggers@kernel.org>; Serge E. Hallyn
> <serge@hallyn.com>; Jan Luebbe <j.luebbe@pengutronix.de>; Richard
> Weinberger <richard@nod.at>; Franck Lenormand
> <franck.lenormand@nxp.com>; Sumit Garg <sumit.garg@linaro.org>; linux-
> integrity@vger.kernel.org; keyrings@vger.kernel.org; linux-
> crypto@vger.kernel.org; linux-kernel@vger.kernel.org; linux-security-
> module@vger.kernel.org
> Subject: [EXT] [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob
> generator
> 
> Caution: EXT Email
> 
> The NXP Cryptographic Acceleration and Assurance Module (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.
> 
> Reviewed-by: David Gstir <david@sigma-star.at>
> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
> Tested-By: Tim Harvey <tharvey@gateworks.com>
> Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> v5 -> v6:
>   - Dropped caam_blob_alloc_desc() in favor of kzalloc() with fixed size.
>     This simplifies code and wastes at most 12 bytes which are freed
>     at the end of the function anyway.
>   - Factored out common code between caam_encap_blob and
> caam_decap_blob
>     as both functions were largely identical
>   - use append_seq_(in|out)_ptr_intlen for both encap/decap as a result
>   - use reverse christmas tree order for caam_process_blob variable
>     definitions.
> v4 -> v5:
>   - Collected Reviewed-by's and Tested-by's
>   - Note in CAAM patch what CAAM is (Jarkko)
> v3 -> v4:
>   - Collected Acked-by's, Reviewed-by's and Tested-by
>   - Fixed typo spotted by David
> v2 -> v3:
>  - No change
> v1 -> v2:
>  - 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)
> 
> To: "Horia Geantă" <horia.geanta@nxp.com>
> To: Pankaj Gupta <pankaj.gupta@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: 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: Matthias Schiffer <matthias.schiffer@ew.tq-group.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 | 160 +++++++++++++++++++++++++++++++++
>  include/soc/fsl/caam-blob.h    |  79 ++++++++++++++++
>  4 files changed, 243 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..2564e63c8fe0
> --- /dev/null
> +++ b/drivers/crypto/caam/blob_gen.c
> @@ -0,0 +1,160 @@
> +// 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"
> +

len = 4 + (4 + ALIGN(keymod_len, 4)) + 2*(4 + 4 + 
>>>> + CAAM_PTR_SZ_MAX) + 4;

> +/* header + (key mod immediate) + 2x seq_intlen pointers + op */
> +#define CAAM_BLOB_DESC_BYTES_MAX \
> +       (CAAM_CMD_SZ + \
> +        CAAM_CMD_SZ + CAAM_BLOB_KEYMOD_LENGTH + \
> +        2 * (CAAM_CMD_SZ + CAAM_PTR_SZ_MAX) + \
> +        CAAM_CMD_SZ)
> +

Suggested to replace the above macro like below:

+#define CAAM_BLOB_DESC_BYTES_MAX \			
+       (CAAM_CMD_SZ + \					/* Command to initialize & stating length of  descriptor */
+        CAAM_CMD_SZ + CAAM_BLOB_KEYMOD_LENGTH + \	/* Command to append the key-modifier + followed by the key-modifier data */
+        (CAAM_CMD_SZ + CAAM_PTR_SZ_MAX) + \		/* Command to include input plain key and pointer to the input key */
+        (CAAM_CMD_SZ + CAAM_PTR_SZ_MAX) + \		/* Command to include output-key blob and pointer to the output-key blob */
+        CAAM_CMD_SZ)						/* Command describing the Operation to perform */



> +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);
> +}
> +
> +int caam_process_blob(struct caam_blob_priv *priv, bool encap,
> +                     const char *keymod, void *input, void *output,
> +                     size_t length)
> +{
> +       size_t in_len = length, out_len = length;
> +       struct caam_blob_job_result testres;
> +       struct device *jrdev = &priv->jrdev;
> +       dma_addr_t dma_in, dma_out;
> +       int op = OP_PCLID_BLOB;
> +       size_t keymod_len;
> +       u32 *desc;
> +       int ret;
> +
> +       keymod_len = strlen(keymod);
> +
> +       if (length <= CAAM_BLOB_OVERHEAD || keymod_len >
> CAAM_BLOB_KEYMOD_LENGTH)
> +               return -EINVAL;
> +
> +       if (encap) {
> +               op |= OP_TYPE_ENCAP_PROTOCOL;
> +               in_len -= CAAM_BLOB_OVERHEAD;
> +       } else {
> +               op |= OP_TYPE_DECAP_PROTOCOL;
> +               out_len -= CAAM_BLOB_OVERHEAD;
> +       }
> +
> +       desc = kzalloc(CAAM_BLOB_DESC_BYTES_MAX, GFP_KERNEL | GFP_DMA);
> +       if (!desc) {
> +               dev_err(jrdev, "unable to allocate desc\n");
> +               return -ENOMEM;
> +       }
> +
> +       dma_in = dma_map_single(jrdev, input, in_len, 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, out_len, 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, in_len, 0);
> +       append_seq_out_ptr_intlen(desc, dma_out, out_len, 0);
> +       append_operation(desc, op);
> +
> +       print_hex_dump_debug("data@"__stringify(__LINE__)": ",
> +                            DUMP_PREFIX_ADDRESS, 16, 1, input,
> +                            in_len, 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,
> +                                    out_len, false);
> +       }
> +
> +       dma_unmap_single(jrdev, dma_out, out_len, DMA_FROM_DEVICE);
> +out_unmap_in:
> +       dma_unmap_single(jrdev, dma_in, in_len, DMA_TO_DEVICE);
> +out_free:
> +       kfree(desc);
> +
> +       return ret;
> +}
> +EXPORT_SYMBOL(caam_process_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..2c4a05dc59cd
> --- /dev/null
> +++ b/include/soc/fsl/caam-blob.h
> @@ -0,0 +1,79 @@
> +/* 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_exit - free blob generation resources
> + *
> + * @priv: instance returned by caam_blob_gen_init  */ void
> +caam_blob_gen_exit(struct caam_blob_priv *priv);
> +
> +/** caam_process_blob - encapsulate or decapsulate blob
> + *
> + * @priv:   instance returned by caam_blob_gen_init
> + * @encap:  true for encapsulation, false for decapsulation
> + * @keymod: string to use as key modifier for blob capsulation
> + *         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_process_blob(struct caam_blob_priv *priv, bool encap,
> +                     const char *keymod, void *input, void *output,
> +                     size_t length);
> +
> +/** 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
> + */
> +static inline int caam_encap_blob(struct caam_blob_priv *priv,
> +                                 const char *keymod,
> +                                 void *input, void *output, size_t
> +length) {
> +       return caam_process_blob(priv, true, keymod, input, output,
> +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
> + */
> +static inline int caam_decap_blob(struct caam_blob_priv *priv,
> +                                 const char *keymod,
> +                                 void *input, void *output, size_t
> +length) {
> +       return caam_process_blob(priv, false, keymod, input, output,
> +length); }
> +
> +#endif
> --
> 2.30.2


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

* Re: [EXT] [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob generator
  2022-03-22  6:25   ` [EXT] " Pankaj Gupta
@ 2022-03-22  7:32     ` Ahmad Fatoum
  2022-03-22  9:37       ` Ahmad Fatoum
  0 siblings, 1 reply; 17+ messages in thread
From: Ahmad Fatoum @ 2022-03-22  7:32 UTC (permalink / raw)
  To: Pankaj Gupta, Horia Geanta, Herbert Xu, David S. Miller
  Cc: linux-security-module, Eric Biggers, David Gstir,
	Matthias Schiffer, Sumit Garg, Jan Luebbe, Richard Weinberger,
	tharvey, Franck Lenormand, James Morris, Mimi Zohar,
	linux-kernel, David Howells, Jarkko Sakkinen, keyrings,
	linux-crypto, kernel, linux-integrity, James Bottomley,
	Serge E. Hallyn

Hello Pankaj,

On 22.03.22 07:25, Pankaj Gupta wrote:
> Hi Ahmad,
> 
> Suggested to define macro with more details.
> Please find comments in-line.
> 

> len = 4 + (4 + ALIGN(keymod_len, 4)) + 2*(4 + 4 + 
>>>>> + CAAM_PTR_SZ_MAX) + 4;
> 
>> +/* header + (key mod immediate) + 2x seq_intlen pointers + op */
>> +#define CAAM_BLOB_DESC_BYTES_MAX \
>> +       (CAAM_CMD_SZ + \
>> +        CAAM_CMD_SZ + CAAM_BLOB_KEYMOD_LENGTH + \
>> +        2 * (CAAM_CMD_SZ + CAAM_PTR_SZ_MAX) + \
>> +        CAAM_CMD_SZ)
>> +
> 
> Suggested to replace the above macro like below:
> 
> +#define CAAM_BLOB_DESC_BYTES_MAX \			
> +       (CAAM_CMD_SZ + \					/* Command to initialize & stating length of  descriptor */
> +        CAAM_CMD_SZ + CAAM_BLOB_KEYMOD_LENGTH + \	/* Command to append the key-modifier + followed by the key-modifier data */
> +        (CAAM_CMD_SZ + CAAM_PTR_SZ_MAX) + \		/* Command to include input plain key and pointer to the input key */
> +        (CAAM_CMD_SZ + CAAM_PTR_SZ_MAX) + \		/* Command to include output-key blob and pointer to the output-key blob */
> +        CAAM_CMD_SZ)						/* Command describing the Operation to perform */


Sure thing, will do for v7. Otherwise, if all looks good to you,
can I have your Reviewed-by?

Thanks,
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] 17+ messages in thread

* Re: [PATCH v6 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2022-03-20 21:02   ` Jarkko Sakkinen
@ 2022-03-22  7:33     ` Ahmad Fatoum
  2022-03-22  8:17       ` Jarkko Sakkinen
  0 siblings, 1 reply; 17+ messages in thread
From: Ahmad Fatoum @ 2022-03-22  7:33 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jonathan Corbet, David Howells, James Bottomley, Mimi Zohar,
	kernel, David Gstir, Pankaj Gupta, Tim Harvey, Matthias Schiffer,
	James Morris, Serge E. Hallyn, Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, Eric Biggers,
	Jan Luebbe, Richard Weinberger, Franck LENORMAND, Sumit Garg,
	keyrings, linux-crypto, linux-doc, linux-integrity, linux-kernel,
	linux-security-module

Hello Jarkko,

On 20.03.22 22:02, Jarkko Sakkinen wrote:
> On Wed, Mar 16, 2022 at 05:43:35PM +0100, Ahmad Fatoum wrote:
>> @@ -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 05fd080b82f3..f13382a14967 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -10647,6 +10647,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:	Maintained
>> +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>
> 
> Documentation and MAINTAINERS updates must be separate patches.

I will do so for v7. Does this patch look otherwise ok to you?

Thanks,
Ahmad

> 
> BR, 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] 17+ messages in thread

* Re: [PATCH v6 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2022-03-22  7:33     ` Ahmad Fatoum
@ 2022-03-22  8:17       ` Jarkko Sakkinen
  0 siblings, 0 replies; 17+ messages in thread
From: Jarkko Sakkinen @ 2022-03-22  8:17 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: Jonathan Corbet, David Howells, James Bottomley, Mimi Zohar,
	kernel, David Gstir, Pankaj Gupta, Tim Harvey, Matthias Schiffer,
	James Morris, Serge E. Hallyn, Horia Geantă,
	Aymen Sghaier, Herbert Xu, David S. Miller, Eric Biggers,
	Jan Luebbe, Richard Weinberger, Franck LENORMAND, Sumit Garg,
	keyrings, linux-crypto, linux-doc, linux-integrity, linux-kernel,
	linux-security-module

On Tue, Mar 22, 2022 at 08:33:34AM +0100, Ahmad Fatoum wrote:
> Hello Jarkko,
> 
> On 20.03.22 22:02, Jarkko Sakkinen wrote:
> > On Wed, Mar 16, 2022 at 05:43:35PM +0100, Ahmad Fatoum wrote:
> >> @@ -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 05fd080b82f3..f13382a14967 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -10647,6 +10647,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:	Maintained
> >> +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>
> > 
> > Documentation and MAINTAINERS updates must be separate patches.
> 
> I will do so for v7. Does this patch look otherwise ok to you?
> 
> Thanks,
> Ahmad

I don't give heads ups. It's improperly constructed patch, i.e. I won't
review it in this from.

BR, Jarkko

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

* Re: [EXT] [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob generator
  2022-03-22  7:32     ` Ahmad Fatoum
@ 2022-03-22  9:37       ` Ahmad Fatoum
  0 siblings, 0 replies; 17+ messages in thread
From: Ahmad Fatoum @ 2022-03-22  9:37 UTC (permalink / raw)
  To: Pankaj Gupta, Horia Geanta, Herbert Xu, David S. Miller
  Cc: Sumit Garg, David Gstir, Matthias Schiffer, kernel,
	Franck Lenormand, Richard Weinberger, Jan Luebbe, James Morris,
	Mimi Zohar, linux-kernel, Eric Biggers, linux-security-module,
	keyrings, linux-crypto, David Howells, Jarkko Sakkinen,
	linux-integrity, James Bottomley, tharvey, Serge E. Hallyn

Hello Pankaj,

On 22.03.22 08:32, Ahmad Fatoum wrote:
> Hello Pankaj,
> 
> On 22.03.22 07:25, Pankaj Gupta wrote:
>> Hi Ahmad,
>>
>> Suggested to define macro with more details.
>> Please find comments in-line.
>>
> 
>> len = 4 + (4 + ALIGN(keymod_len, 4)) + 2*(4 + 4 + 
>>>>>> + CAAM_PTR_SZ_MAX) + 4;
>>
>>> +/* header + (key mod immediate) + 2x seq_intlen pointers + op */
>>> +#define CAAM_BLOB_DESC_BYTES_MAX \
>>> +       (CAAM_CMD_SZ + \
>>> +        CAAM_CMD_SZ + CAAM_BLOB_KEYMOD_LENGTH + \
>>> +        2 * (CAAM_CMD_SZ + CAAM_PTR_SZ_MAX) + \
>>> +        CAAM_CMD_SZ)
>>> +
>>
>> Suggested to replace the above macro like below:
>>
>> +#define CAAM_BLOB_DESC_BYTES_MAX \			
>> +       (CAAM_CMD_SZ + \					/* Command to initialize & stating length of  descriptor */
>> +        CAAM_CMD_SZ + CAAM_BLOB_KEYMOD_LENGTH + \	/* Command to append the key-modifier + followed by the key-modifier data */
>> +        (CAAM_CMD_SZ + CAAM_PTR_SZ_MAX) + \		/* Command to include input plain key and pointer to the input key */
>> +        (CAAM_CMD_SZ + CAAM_PTR_SZ_MAX) + \		/* Command to include output-key blob and pointer to the output-key blob */
>> +        CAAM_CMD_SZ)						/* Command describing the Operation to perform */
> 
> 
> Sure thing, will do for v7. Otherwise, if all looks good to you,
> can I have your Reviewed-by?
This doesn't compile as-is and it leads to quite long lines.
The description isn't accurate also, because what's plain and what's blob
changes depending on whether we encapsulate or decapsulate.

Here's my revised macro version:

#define CAAM_BLOB_DESC_BYTES_MAX                                        \
        /* Command to initialize & stating length of descriptor */      \
        (CAAM_CMD_SZ +                                                  \
        /* Command to append the key-modifier + key-modifier data */    \
         CAAM_CMD_SZ + CAAM_BLOB_KEYMOD_LENGTH +                        \
        /* Command to include input key + pointer to the input key */   \
         CAAM_CMD_SZ + CAAM_PTR_SZ_MAX +                                \
        /* Command to include output key + pointer to the output key */ \
         CAAM_CMD_SZ + CAAM_PTR_SZ_MAX +                                \
        /* Command describing the Operation to perform */               \
         CAAM_CMD_SZ)

Alternatively, I can change it back into a function:

static inline u32 *caam_blob_desc_alloc(void)
{
        size_t size = 0;

        /* Command to initialize & stating length of descriptor */
        size += CAAM_CMD_SZ;
        /* Command to append the key-modifier + key-modifier data */
        size += CAAM_CMD_SZ + CAAM_BLOB_KEYMOD_LENGTH;
        /* Command to include input plain key + pointer to the input key */
        size += CAAM_CMD_SZ + CAAM_PTR_SZ_MAX;
        /* Command to include output-key blob + pointer to the output key */
        size += CAAM_CMD_SZ + CAAM_PTR_SZ_MAX;
        /* Command describing the Operation to perform */
        size += CAAM_CMD_SZ;

        return kzalloc(size, GFP_KERNEL | GFP_DMA);
}

Let me know what works better for you.

Cheers,
Ahmad

> 
> Thanks,
> 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] 17+ messages in thread

* RE: [EXT] [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob generator
  2022-03-16 16:43 ` [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob generator Ahmad Fatoum
  2022-03-22  6:25   ` [EXT] " Pankaj Gupta
@ 2022-03-24  9:55   ` Pankaj Gupta
  2022-03-24 10:10     ` Ahmad Fatoum
  1 sibling, 1 reply; 17+ messages in thread
From: Pankaj Gupta @ 2022-03-24  9:55 UTC (permalink / raw)
  To: Ahmad Fatoum, Horia Geanta, Herbert Xu, David S. Miller
  Cc: kernel, David Gstir, tharvey, Matthias Schiffer, James Bottomley,
	Jarkko Sakkinen, Mimi Zohar, David Howells, James Morris,
	Eric Biggers, Serge E. Hallyn, Jan Luebbe, Richard Weinberger,
	Franck Lenormand, Sumit Garg, linux-integrity, keyrings,
	linux-crypto, linux-kernel, linux-security-module

Hi Ahmad,

Please find the comments in-line.

Regards
Pankaj

> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Wednesday, March 16, 2022 10:14 PM
> To: Horia Geanta <horia.geanta@nxp.com>; Pankaj Gupta
> <pankaj.gupta@nxp.com>; Herbert Xu <herbert@gondor.apana.org.au>;
> David S. Miller <davem@davemloft.net>
> Cc: kernel@pengutronix.de; David Gstir <david@sigma-star.at>;
> tharvey@gateworks.com; Matthias Schiffer <matthias.schiffer@ew.tq-
> group.com>; Ahmad Fatoum <a.fatoum@pengutronix.de>; James Bottomley
> <jejb@linux.ibm.com>; Jarkko Sakkinen <jarkko@kernel.org>; Mimi Zohar
> <zohar@linux.ibm.com>; David Howells <dhowells@redhat.com>; James
> Morris <jmorris@namei.org>; Eric Biggers <ebiggers@kernel.org>; Serge E.
> Hallyn <serge@hallyn.com>; Jan Luebbe <j.luebbe@pengutronix.de>;
> Richard Weinberger <richard@nod.at>; Franck Lenormand
> <franck.lenormand@nxp.com>; Sumit Garg <sumit.garg@linaro.org>; linux-
> integrity@vger.kernel.org; keyrings@vger.kernel.org; linux-
> crypto@vger.kernel.org; linux-kernel@vger.kernel.org; linux-security-
> module@vger.kernel.org
> Subject: [EXT] [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob
> generator
> 
> Caution: EXT Email
> 
> The NXP Cryptographic Acceleration and Assurance Module (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.
> 
> Reviewed-by: David Gstir <david@sigma-star.at>
> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
> Tested-By: Tim Harvey <tharvey@gateworks.com>
> Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> v5 -> v6:
>   - Dropped caam_blob_alloc_desc() in favor of kzalloc() with fixed size.
>     This simplifies code and wastes at most 12 bytes which are freed
>     at the end of the function anyway.
>   - Factored out common code between caam_encap_blob and
> caam_decap_blob

Suggest to continue to use two separate descriptor-creation-function for 'encap' and 'decap'.
This will help these API(s) to be maintained easily going forward. 

>     as both functions were largely identical
>   - use append_seq_(in|out)_ptr_intlen for both encap/decap as a result
>   - use reverse christmas tree order for caam_process_blob variable
>     definitions.
> v4 -> v5:
>   - Collected Reviewed-by's and Tested-by's
>   - Note in CAAM patch what CAAM is (Jarkko)
> v3 -> v4:
>   - Collected Acked-by's, Reviewed-by's and Tested-by
>   - Fixed typo spotted by David
> v2 -> v3:
>  - No change
> v1 -> v2:
>  - 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)
> 
> To: "Horia Geantă" <horia.geanta@nxp.com>
> To: Pankaj Gupta <pankaj.gupta@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: 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: Matthias Schiffer <matthias.schiffer@ew.tq-group.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 | 160
> +++++++++++++++++++++++++++++++++
>  include/soc/fsl/caam-blob.h    |  79 ++++++++++++++++
>  4 files changed, 243 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..2564e63c8fe0
> --- /dev/null
> +++ b/drivers/crypto/caam/blob_gen.c
> @@ -0,0 +1,160 @@
> +// 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"
> +
> +/* header + (key mod immediate) + 2x seq_intlen pointers + op */
> +#define CAAM_BLOB_DESC_BYTES_MAX \
> +       (CAAM_CMD_SZ + \
> +        CAAM_CMD_SZ + CAAM_BLOB_KEYMOD_LENGTH + \
> +        2 * (CAAM_CMD_SZ + CAAM_PTR_SZ_MAX) + \
> +        CAAM_CMD_SZ)
> +
> +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);
> +}
> +
> +int caam_process_blob(struct caam_blob_priv *priv, bool encap,
> +                     const char *keymod, void *input, void *output,
> +                     size_t length)
> +{
> +       size_t in_len = length, out_len = length;
> +       struct caam_blob_job_result testres;
> +       struct device *jrdev = &priv->jrdev;
> +       dma_addr_t dma_in, dma_out;
> +       int op = OP_PCLID_BLOB;
> +       size_t keymod_len;
> +       u32 *desc;
> +       int ret;
> +
> +       keymod_len = strlen(keymod);
> +
> +       if (length <= CAAM_BLOB_OVERHEAD || keymod_len >
> CAAM_BLOB_KEYMOD_LENGTH)
> +               return -EINVAL;
> +
> +       if (encap) {
> +               op |= OP_TYPE_ENCAP_PROTOCOL;
> +               in_len -= CAAM_BLOB_OVERHEAD;
> +       } else {
> +               op |= OP_TYPE_DECAP_PROTOCOL;
> +               out_len -= CAAM_BLOB_OVERHEAD;
> +       }
> +
> +       desc = kzalloc(CAAM_BLOB_DESC_BYTES_MAX, GFP_KERNEL |
> GFP_DMA);
> +       if (!desc) {
> +               dev_err(jrdev, "unable to allocate desc\n");
> +               return -ENOMEM;
> +       }
> +
> +       dma_in = dma_map_single(jrdev, input, in_len, 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, out_len,
> 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, in_len, 0);
> +       append_seq_out_ptr_intlen(desc, dma_out, out_len, 0);
> +       append_operation(desc, op);
> +
> +       print_hex_dump_debug("data@"__stringify(__LINE__)": ",
> +                            DUMP_PREFIX_ADDRESS, 16, 1, input,
> +                            in_len, 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,
> +                                    out_len, false);
> +       }
> +
> +       dma_unmap_single(jrdev, dma_out, out_len, DMA_FROM_DEVICE);
> +out_unmap_in:
> +       dma_unmap_single(jrdev, dma_in, in_len, DMA_TO_DEVICE);
> +out_free:
> +       kfree(desc);
> +
> +       return ret;
> +}
> +EXPORT_SYMBOL(caam_process_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..2c4a05dc59cd
> --- /dev/null
> +++ b/include/soc/fsl/caam-blob.h
> @@ -0,0 +1,79 @@
> +/* 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_exit - free blob generation resources
> + *
> + * @priv: instance returned by caam_blob_gen_init  */ void
> +caam_blob_gen_exit(struct caam_blob_priv *priv);
> +
> +/** caam_process_blob - encapsulate or decapsulate blob
> + *
> + * @priv:   instance returned by caam_blob_gen_init
> + * @encap:  true for encapsulation, false for decapsulation
> + * @keymod: string to use as key modifier for blob capsulation
> + *         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_process_blob(struct caam_blob_priv *priv, bool encap,
> +                     const char *keymod, void *input, void *output,
> +                     size_t length);
> +
> +/** 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
> + */
> +static inline int caam_encap_blob(struct caam_blob_priv *priv,
> +                                 const char *keymod,
> +                                 void *input, void *output, size_t
> +length) {
> +       return caam_process_blob(priv, true, keymod, input, output,
> +length); }
> +

In continuation to the previous comment, there is another suggestion:

Either: 
struct keyblob_info {
        void *key;
        size_t key_len;

        void *blob;
        size_t blob_len;

        size_t key_mod_len;
        const void *key_mod;
};

Or:

struct keyblob_info {        
        void *input;
        void *input_len;

        void *output;
        void *out_len;

        size_t key_mod_len;
        const void *key_mod;
};


int caam_blob_encap(struct caam_blob_priv *priv, struct keyblob_info *info);

int caam_blob_decap(struct caam_blob_priv *priv, struct keyblob_info *info);

> +/** 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
> + */
> +static inline int caam_decap_blob(struct caam_blob_priv *priv,
> +                                 const char *keymod,
> +                                 void *input, void *output, size_t
> +length) {
> +       return caam_process_blob(priv, false, keymod, input, output,
> +length); }
> +
> +#endif
> --
> 2.30.2


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

* Re: [EXT] [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob generator
  2022-03-24  9:55   ` Pankaj Gupta
@ 2022-03-24 10:10     ` Ahmad Fatoum
  2022-03-28  9:29       ` Pankaj Gupta
  0 siblings, 1 reply; 17+ messages in thread
From: Ahmad Fatoum @ 2022-03-24 10:10 UTC (permalink / raw)
  To: Pankaj Gupta, Horia Geanta, Herbert Xu, David S. Miller
  Cc: linux-security-module, Eric Biggers, David Gstir,
	Matthias Schiffer, Sumit Garg, Jan Luebbe, Richard Weinberger,
	tharvey, Franck Lenormand, James Morris, Mimi Zohar,
	linux-kernel, David Howells, Jarkko Sakkinen, keyrings,
	linux-crypto, kernel, linux-integrity, James Bottomley,
	Serge E. Hallyn

Hello Pankaj,

On 24.03.22 10:55, Pankaj Gupta wrote:
> Hi Ahmad,
> 
> Please find the comments in-line.

Thanks for you review.

> Suggest to continue to use two separate descriptor-creation-function for 'encap' and 'decap'.
> This will help these API(s) to be maintained easily going forward. 

We can still split them up in future once there is a real need.
But currently they are exactly the same, except for input/output length,
so I think it's correct to not introduce duplication unless needed.

>>   - use append_seq_(in|out)_ptr_intlen for both encap/decap as a result

Case in point. The intlen omission was because the two functions are largely
identical and I only fixed up one of them. This is prone to repeat when
we go back to have identical code with minor differences.

> In continuation to the previous comment, there is another suggestion:
> 
> Either: 
> struct keyblob_info {
>         void *key;
>         size_t key_len;
> 
>         void *blob;
>         size_t blob_len;
> 
>         size_t key_mod_len;
>         const void *key_mod;
> };

I can do that.

Whats your opinion on the desc size computation? Comment the macro or add
the static inline helper?

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] 17+ messages in thread

* RE: [EXT] [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob generator
  2022-03-24 10:10     ` Ahmad Fatoum
@ 2022-03-28  9:29       ` Pankaj Gupta
  2022-04-15 20:07         ` Ahmad Fatoum
  0 siblings, 1 reply; 17+ messages in thread
From: Pankaj Gupta @ 2022-03-28  9:29 UTC (permalink / raw)
  To: Ahmad Fatoum, Horia Geanta, Herbert Xu, David S. Miller
  Cc: linux-security-module, Eric Biggers, David Gstir,
	Matthias Schiffer, Sumit Garg, Jan Luebbe, Richard Weinberger,
	tharvey, Franck Lenormand, James Morris, Mimi Zohar,
	linux-kernel, David Howells, Jarkko Sakkinen, keyrings,
	linux-crypto, kernel, linux-integrity, James Bottomley,
	Serge E. Hallyn

Hi Ahmad,

Please find the comments in-line.

Regards
Pankaj

> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Thursday, March 24, 2022 3:40 PM
> To: Pankaj Gupta <pankaj.gupta@nxp.com>; Horia Geanta
> <horia.geanta@nxp.com>; Herbert Xu <herbert@gondor.apana.org.au>;
> David S. Miller <davem@davemloft.net>
> Cc: linux-security-module@vger.kernel.org; Eric Biggers
> <ebiggers@kernel.org>; David Gstir <david@sigma-star.at>; Matthias
> Schiffer <matthias.schiffer@ew.tq-group.com>; Sumit Garg
> <sumit.garg@linaro.org>; Jan Luebbe <j.luebbe@pengutronix.de>; Richard
> Weinberger <richard@nod.at>; tharvey@gateworks.com; Franck Lenormand
> <franck.lenormand@nxp.com>; James Morris <jmorris@namei.org>; Mimi
> Zohar <zohar@linux.ibm.com>; linux-kernel@vger.kernel.org; David Howells
> <dhowells@redhat.com>; Jarkko Sakkinen <jarkko@kernel.org>;
> keyrings@vger.kernel.org; linux-crypto@vger.kernel.org;
> kernel@pengutronix.de; linux-integrity@vger.kernel.org; James Bottomley
> <jejb@linux.ibm.com>; Serge E. Hallyn <serge@hallyn.com>
> Subject: Re: [EXT] [PATCH v6 3/4] crypto: caam - add in-kernel interface for
> blob generator
> 
> Caution: EXT Email
> 
> Hello Pankaj,
> 
> On 24.03.22 10:55, Pankaj Gupta wrote:
> > Hi Ahmad,
> >
> > Please find the comments in-line.
> 
> Thanks for you review.
> 
> > Suggest to continue to use two separate descriptor-creation-function for
> 'encap' and 'decap'.
> > This will help these API(s) to be maintained easily going forward.
> 
> We can still split them up in future once there is a real need.
> But currently they are exactly the same, except for input/output length, so I
> think it's correct to not introduce duplication unless needed.
> 
> >>   - use append_seq_(in|out)_ptr_intlen for both encap/decap as a
> >> result
> 
> Case in point. The intlen omission was because the two functions are largely
> identical and I only fixed up one of them. This is prone to repeat when we go
> back to have identical code with minor differences.
> 
> > In continuation to the previous comment, there is another suggestion:
> >
> > Either:
> > struct keyblob_info {
> >         void *key;
> >         size_t key_len;
> >
> >         void *blob;
> >         size_t blob_len;
> >
> >         size_t key_mod_len;
> >         const void *key_mod;
> > };
> 
> I can do that.
> 

Please do. Thanks.
Patch 4/4, needs to be re-worked to.

> Whats your opinion on the desc size computation? Comment the macro or
> add the static inline helper?
> 

Comment the macro is fine.

> Cheers,
> Ahmad
> 
> --
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       |
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
> pengutronix.de%2F&amp;data=04%7C01%7Cpankaj.gupta%40nxp.com%7C4
> d60f0d524a04b7cbd7b08da0d7e7d21%7C686ea1d3bc2b4c6fa92cd99c5c30163
> 5%7C0%7C0%7C637837134158793951%7CUnknown%7CTWFpbGZsb3d8eyJWI
> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
> 000&amp;sdata=PetvZm8teusBwQ4BeZ1VLEOvBlCrZ2k2bNG3SJBEXPw%3D&
> amp;reserved=0  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

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

* RE: [EXT] [PATCH v6 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2022-03-16 16:43 ` [PATCH v6 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
  2022-03-20 21:02   ` Jarkko Sakkinen
@ 2022-03-28 10:46   ` Pankaj Gupta
  2022-04-15 20:02     ` Ahmad Fatoum
  1 sibling, 1 reply; 17+ messages in thread
From: Pankaj Gupta @ 2022-03-28 10:46 UTC (permalink / raw)
  To: Ahmad Fatoum, Jonathan Corbet, David Howells, Jarkko Sakkinen,
	James Bottomley, Mimi Zohar
  Cc: kernel, David Gstir, tharvey, Matthias Schiffer, James Morris,
	Serge E. Hallyn, Horia Geanta, Aymen Sghaier, Herbert Xu,
	David S. Miller, Eric Biggers, Jan Luebbe, Richard Weinberger,
	Franck Lenormand, Sumit Garg, keyrings, linux-crypto, linux-doc,
	linux-integrity, linux-kernel, linux-security-module

Hi Ahmad,

Please find the comments in-line.

Regards
Pankaj

> -----Original Message-----
> From: Ahmad Fatoum <a.fatoum@pengutronix.de>
> Sent: Wednesday, March 16, 2022 10:14 PM
> To: Jonathan Corbet <corbet@lwn.net>; David Howells
> <dhowells@redhat.com>; Jarkko Sakkinen <jarkko@kernel.org>; James
> Bottomley <jejb@linux.ibm.com>; Mimi Zohar <zohar@linux.ibm.com>
> Cc: kernel@pengutronix.de; David Gstir <david@sigma-star.at>; Pankaj
> Gupta <pankaj.gupta@nxp.com>; tharvey@gateworks.com; Matthias
> Schiffer <matthias.schiffer@ew.tq-group.com>; Ahmad Fatoum
> <a.fatoum@pengutronix.de>; James Morris <jmorris@namei.org>; Serge E.
> Hallyn <serge@hallyn.com>; Horia Geanta <horia.geanta@nxp.com>; Aymen
> Sghaier <aymen.sghaier@nxp.com>; Herbert Xu
> <herbert@gondor.apana.org.au>; David S. Miller <davem@davemloft.net>;
> Eric Biggers <ebiggers@kernel.org>; Jan Luebbe <j.luebbe@pengutronix.de>;
> Richard Weinberger <richard@nod.at>; Franck Lenormand
> <franck.lenormand@nxp.com>; Sumit Garg <sumit.garg@linaro.org>;
> keyrings@vger.kernel.org; linux-crypto@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-integrity@vger.kernel.org; linux-
> kernel@vger.kernel.org; linux-security-module@vger.kernel.org
> Subject: [EXT] [PATCH v6 4/4] KEYS: trusted: Introduce support for NXP
> CAAM-based trusted keys
> 
> Caution: EXT Email
> 
> The Cryptographic Acceleration and Assurance Module (CAAM) is an IP core
> built into many newer i.MX and QorIQ SoCs by NXP.
> 
> The CAAM does crypto acceleration, hardware number generation and has a
> blob mechanism for encapsulation/decapsulation of sensitive material.
> 
> This blob mechanism depends on a device specific random 256-bit One Time
> Programmable Master Key that is fused in each SoC at manufacturing time.
> This key is unreadable and can only be used by the CAAM for AES
> encryption/decryption of user data.
> 
> This makes it a suitable backend (source) for kernel trusted keys.
> 
> Previous commits generalized trusted keys to support multiple backends and
> added an API to access the CAAM blob mechanism. Based on these, provide
> the necessary glue to use the CAAM for trusted keys.
> 
> Reviewed-by: David Gstir <david@sigma-star.at>
> Reviewed-by: Pankaj Gupta <pankaj.gupta@nxp.com>
> Tested-By: Tim Harvey <tharvey@gateworks.com>
> Tested-by: Matthias Schiffer <matthias.schiffer@ew.tq-group.com>
> Tested-by: Pankaj Gupta <pankaj.gupta@nxp.com>
> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
> ---
> v5 -> v6:
>   - Rename caam_trusted_key_ops to trusted_key_caam_ops for symmetry
>     with other trust sources (Pankaj)
>   - collected Pankaj's Reviewed-by
> v4 -> v5:
>   - Collected Reviewed-by's and Tested-by's
>   - Changed modifier to SECURE_KEY for compatibility with linux-imx
>     (Matthias)
> v3 -> v4:
>   - Collected Acked-by's, Reviewed-by's and Tested-by
> v2 -> v3:
>  - add MAINTAINERS entry
> v1 -> v2:
>  - Extend trusted keys documentation for CAAM
> 
> To: Jonathan Corbet <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: 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: Matthias Schiffer <matthias.schiffer@ew.tq-group.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
> ---
>  .../admin-guide/kernel-parameters.txt         |  1 +
>  .../security/keys/trusted-encrypted.rst       | 40 +++++++++-
>  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, 151 insertions(+), 3 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 844c883ca9d8..9e7ef4c6585d 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5875,6 +5875,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 99cf34d7c025..ed60c48cb692 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,6 +123,12 @@ 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
> +     is probed.
> +
>  Users may override this by specifying ``trusted.rng=kernel`` on the kernel
> command-line to override the used RNG with the kernel's random number
> pool.
> 
> @@ -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 05fd080b82f3..f13382a14967 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10647,6 +10647,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:     Maintained
> +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..73fe2f32f65e
> --- /dev/null
> +++ b/include/keys/trusted_caam.h
> @@ -0,0 +1,11 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2021 Pengutronix, Ahmad Fatoum <kernel@pengutronix.de>
> +*/
> +
> +#ifndef __CAAM_TRUSTED_KEY_H
> +#define __CAAM_TRUSTED_KEY_H
> +
> +extern struct trusted_key_ops trusted_key_caam_ops;
> +
> +#endif
> diff --git a/security/keys/trusted-keys/Kconfig b/security/keys/trusted-
> keys/Kconfig
> index fc4abd581abb..dbfdd8536468 100644
> --- a/security/keys/trusted-keys/Kconfig
> +++ b/security/keys/trusted-keys/Kconfig
> @@ -24,6 +24,15 @@ config TRUSTED_KEYS_TEE
>           Enable use of the Trusted Execution Environment (TEE) as trusted
>           key backend.
> 
> -if !TRUSTED_KEYS_TPM && !TRUSTED_KEYS_TEE
> +config TRUSTED_KEYS_CAAM
> +       bool "CAAM-based trusted keys"
> +       depends on CRYPTO_DEV_FSL_CAAM_JR >= TRUSTED_KEYS
> +       select CRYPTO_DEV_FSL_CAAM_BLOB_GEN
> +       default y
> +       help
> +         Enable use of NXP's Cryptographic Accelerator and Assurance Module
> +         (CAAM) as trusted key backend.
> +
> +if !TRUSTED_KEYS_TPM && !TRUSTED_KEYS_TEE
> && !TRUSTED_KEYS_CAAM
>  comment "No trust source selected!"
>  endif
> diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-
> keys/Makefile
> index 2e2371eae4d5..735aa0bc08ef 100644
> --- a/security/keys/trusted-keys/Makefile
> +++ b/security/keys/trusted-keys/Makefile
> @@ -12,3 +12,5 @@ trusted-$(CONFIG_TRUSTED_KEYS_TPM) +=
> trusted_tpm2.o
>  trusted-$(CONFIG_TRUSTED_KEYS_TPM) += tpm2key.asn1.o
> 
>  trusted-$(CONFIG_TRUSTED_KEYS_TEE) += trusted_tee.o
> +
> +trusted-$(CONFIG_TRUSTED_KEYS_CAAM) += trusted_caam.o
> diff --git a/security/keys/trusted-keys/trusted_caam.c
> b/security/keys/trusted-keys/trusted_caam.c
> new file mode 100644
> index 000000000000..5457c76c6602
> --- /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 "SECURE_KEY"
> +
> +static_assert(MAX_KEY_SIZE + CAAM_BLOB_OVERHEAD <=
> CAAM_BLOB_MAX_LEN);
> +static_assert(MAX_BLOB_SIZE <= CAAM_BLOB_MAX_LEN);
> +
> +static int trusted_caam_seal(struct trusted_key_payload *p, char
> +*datablob) {

If the structure "struct keyblob_info", is used in patch 3/4, then below use for CAAM specific macros
will not be needed to be set in this file/function.

> +       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;
> +

If the structure "struct keyblob_info", is used in patch 3/4, then below line of code will not be needed.

> +       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;
> +

If the structure "struct keyblob_info", is used in patch 3/4, then below line of code will not be needed.

> +       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 trusted_key_caam_ops = {
> +       .migratable = 0, /* non-migratable */
> +       .init = trusted_caam_init,
> +       .seal = trusted_caam_seal,
> +       .unseal = trusted_caam_unseal,
> +       .exit = trusted_caam_exit,
> +};
> diff --git a/security/keys/trusted-keys/trusted_core.c
> b/security/keys/trusted-keys/trusted_core.c
> index 9235fb7d0ec9..c6fc50d67214 100644
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -9,6 +9,7 @@
>  #include <keys/user-type.h>
>  #include <keys/trusted-type.h>
>  #include <keys/trusted_tee.h>
> +#include <keys/trusted_caam.h>
>  #include <keys/trusted_tpm.h>
>  #include <linux/capability.h>
>  #include <linux/err.h>
> @@ -29,7 +30,7 @@ MODULE_PARM_DESC(rng, "Select trusted key RNG");
> 
>  static char *trusted_key_source;
>  module_param_named(source, trusted_key_source, charp, 0); -
> MODULE_PARM_DESC(source, "Select trusted keys source (tpm or tee)");
> +MODULE_PARM_DESC(source, "Select trusted keys source (tpm, tee or
> +caam)");
> 
>  static const struct trusted_key_source trusted_key_sources[] = {  #if
> defined(CONFIG_TRUSTED_KEYS_TPM) @@ -38,6 +39,9 @@ static const
> struct trusted_key_source trusted_key_sources[] = {  #if
> defined(CONFIG_TRUSTED_KEYS_TEE)
>         { "tee", &trusted_key_tee_ops },  #endif
> +#if defined(CONFIG_TRUSTED_KEYS_CAAM)
> +       { "caam", &trusted_key_caam_ops }, #endif
>  };
> 
>  DEFINE_STATIC_CALL_NULL(trusted_key_init,
> *trusted_key_sources[0].ops->init);
> --
> 2.30.2


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

* Re: [EXT] [PATCH v6 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
  2022-03-28 10:46   ` [EXT] " Pankaj Gupta
@ 2022-04-15 20:02     ` Ahmad Fatoum
  0 siblings, 0 replies; 17+ messages in thread
From: Ahmad Fatoum @ 2022-04-15 20:02 UTC (permalink / raw)
  To: Pankaj Gupta, Jonathan Corbet, David Howells, Jarkko Sakkinen,
	James Bottomley, Mimi Zohar
  Cc: kernel, David Gstir, tharvey, Matthias Schiffer, James Morris,
	Serge E. Hallyn, Horia Geanta, Aymen Sghaier, Herbert Xu,
	David S. Miller, Eric Biggers, Jan Luebbe, Richard Weinberger,
	Franck Lenormand, Sumit Garg, keyrings, linux-crypto, linux-doc,
	linux-integrity, linux-kernel, linux-security-module

Hello Pankaj,

On 28.03.22 12:46, Pankaj Gupta wrote:
> If the structure "struct keyblob_info", is used in patch 3/4, then below use for CAAM specific macros
> will not be needed to be set in this file/function.

Yes, I moved the output size computation into the previous patch.

> If the structure "struct keyblob_info", is used in patch 3/4, then below line of code will not be needed.

It must be set regardless. How else would the trusted key core know how big
the blob is.

> If the structure "struct keyblob_info", is used in patch 3/4, then below line of code will not be needed.
> 
>> +       p->key_len = length - CAAM_BLOB_OVERHEAD;

Likewise.

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] 17+ messages in thread

* Re: [EXT] [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob generator
  2022-03-28  9:29       ` Pankaj Gupta
@ 2022-04-15 20:07         ` Ahmad Fatoum
  0 siblings, 0 replies; 17+ messages in thread
From: Ahmad Fatoum @ 2022-04-15 20:07 UTC (permalink / raw)
  To: Pankaj Gupta, Horia Geanta, Herbert Xu, David S. Miller
  Cc: Sumit Garg, David Gstir, Matthias Schiffer, kernel,
	Franck Lenormand, Richard Weinberger, Jan Luebbe, James Morris,
	Mimi Zohar, linux-kernel, Eric Biggers, linux-security-module,
	keyrings, linux-crypto, David Howells, Jarkko Sakkinen,
	linux-integrity, James Bottomley, tharvey, Serge E. Hallyn

On 28.03.22 11:29, Pankaj Gupta wrote:
>>> struct keyblob_info {
>>>         void *key;
>>>         size_t key_len;
>>>
>>>         void *blob;
>>>         size_t blob_len;
>>>
>>>         size_t key_mod_len;
>>>         const void *key_mod;
>>> };
>>
>> I can do that.
>>
> 
> Please do. Thanks.

I went with your other suggestion instead: void *input and void *output.
This keeps the code simple and avoids having to do:

if (encap) {
  in = info->key;
  in_len = info->key_len;
  out = info->blob_len;
  out_len = info->key_len + CAAM_BLOB_OVERHEAD; 
} else {
  in = info->blob;
  in_len = info->blob_len;
  out = info->key_len;
  out_len = info->blob_len - CAAM_BLOB_OVERHEAD; 
}

> Patch 4/4, needs to be re-worked to.
> 
>> Whats your opinion on the desc size computation? Comment the macro or
>> add the static inline helper?
>>
> 
> Comment the macro is fine.
> 
>> Cheers,
>> Ahmad
>>
>> --
>> Pengutronix e.K.                           |                             |
>> Steuerwalder Str. 21                       |
>> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.
>> pengutronix.de%2F&amp;data=04%7C01%7Cpankaj.gupta%40nxp.com%7C4
>> d60f0d524a04b7cbd7b08da0d7e7d21%7C686ea1d3bc2b4c6fa92cd99c5c30163
>> 5%7C0%7C0%7C637837134158793951%7CUnknown%7CTWFpbGZsb3d8eyJWI
>> joiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3
>> 000&amp;sdata=PetvZm8teusBwQ4BeZ1VLEOvBlCrZ2k2bNG3SJBEXPw%3D&
>> amp;reserved=0  |
>> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
>> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 
> 


-- 
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] 17+ messages in thread

end of thread, other threads:[~2022-04-15 20:07 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-16 16:43 [PATCH v6 0/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
2022-03-16 16:43 ` [PATCH v6 1/4] KEYS: trusted: allow use of TEE as backend without TCG_TPM support Ahmad Fatoum
2022-03-16 16:43 ` [PATCH v6 2/4] KEYS: trusted: allow use of kernel RNG for key material Ahmad Fatoum
2022-03-16 16:43 ` [PATCH v6 3/4] crypto: caam - add in-kernel interface for blob generator Ahmad Fatoum
2022-03-22  6:25   ` [EXT] " Pankaj Gupta
2022-03-22  7:32     ` Ahmad Fatoum
2022-03-22  9:37       ` Ahmad Fatoum
2022-03-24  9:55   ` Pankaj Gupta
2022-03-24 10:10     ` Ahmad Fatoum
2022-03-28  9:29       ` Pankaj Gupta
2022-04-15 20:07         ` Ahmad Fatoum
2022-03-16 16:43 ` [PATCH v6 4/4] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys Ahmad Fatoum
2022-03-20 21:02   ` Jarkko Sakkinen
2022-03-22  7:33     ` Ahmad Fatoum
2022-03-22  8:17       ` Jarkko Sakkinen
2022-03-28 10:46   ` [EXT] " Pankaj Gupta
2022-04-15 20:02     ` 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.