linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v8 0/4] Introduce TEE based Trusted Keys support
@ 2020-11-03 16:01 Sumit Garg
  2020-11-03 16:01 ` [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework Sumit Garg
                   ` (4 more replies)
  0 siblings, 5 replies; 52+ messages in thread
From: Sumit Garg @ 2020-11-03 16:01 UTC (permalink / raw)
  To: jarkko.sakkinen, zohar, jejb
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Sumit Garg

Add support for TEE based trusted keys where TEE provides the functionality
to seal and unseal trusted keys using hardware unique key. Also, this is
an alternative in case platform doesn't possess a TPM device.

This patch-set has been tested with OP-TEE based early TA which is already
merged in upstream [1].

[1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d7e5b86b

Changes in v8:
1. Added static calls support instead of indirect calls.
2. Documented trusted keys source module parameter.
3. Refined patch #1 commit message discription.
4. Addressed misc. comments on patch #2.
5. Added myself as Trusted Keys co-maintainer instead.
6. Rebased to latest tpmdd master.

Changes in v7:
1. Added a trusted.source module parameter in order to enforce user's
   choice in case a particular platform posses both TPM and TEE.
2. Refine commit description for patch #1.

Changes in v6:
1. Revert back to dynamic detection of trust source.
2. Drop author mention from trusted_core.c and trusted_tpm1.c files.
3. Rebased to latest tpmdd/master.

Changes in v5:
1. Drop dynamic detection of trust source and use compile time flags
   instead.
2. Rename trusted_common.c -> trusted_core.c.
3. Rename callback: cleanup() -> exit().
4. Drop "tk" acronym.
5. Other misc. comments.
6. Added review tags for patch #3 and #4.

Changes in v4:
1. Pushed independent TEE features separately:
  - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062
2. Updated trusted-encrypted doc with TEE as a new trust source.
3. Rebased onto latest tpmdd/master.

Changes in v3:
1. Update patch #2 to support registration of multiple kernel pages.
2. Incoporate dependency patch #4 in this patch-set:
   https://patchwork.kernel.org/patch/11091435/

Changes in v2:
1. Add reviewed-by tags for patch #1 and #2.
2. Incorporate comments from Jens for patch #3.
3. Switch to use generic trusted keys framework.

Sumit Garg (4):
  KEYS: trusted: Add generic trusted keys framework
  KEYS: trusted: Introduce TEE based Trusted Keys
  doc: trusted-encrypted: updates with TEE as a new trust source
  MAINTAINERS: Add myself as Trusted Keys co-maintainer

 Documentation/admin-guide/kernel-parameters.txt   |  12 +
 Documentation/security/keys/trusted-encrypted.rst | 203 +++++++++++--
 MAINTAINERS                                       |   2 +
 include/keys/trusted-type.h                       |  47 +++
 include/keys/trusted_tee.h                        |  55 ++++
 include/keys/trusted_tpm.h                        |  17 +-
 security/keys/trusted-keys/Makefile               |   2 +
 security/keys/trusted-keys/trusted_core.c         | 354 ++++++++++++++++++++++
 security/keys/trusted-keys/trusted_tee.c          | 278 +++++++++++++++++
 security/keys/trusted-keys/trusted_tpm1.c         | 336 ++++----------------
 10 files changed, 979 insertions(+), 327 deletions(-)
 create mode 100644 include/keys/trusted_tee.h
 create mode 100644 security/keys/trusted-keys/trusted_core.c
 create mode 100644 security/keys/trusted-keys/trusted_tee.c

-- 
2.7.4


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

* [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework
  2020-11-03 16:01 [PATCH v8 0/4] Introduce TEE based Trusted Keys support Sumit Garg
@ 2020-11-03 16:01 ` Sumit Garg
  2020-11-24  3:42   ` Jarkko Sakkinen
  2021-02-10 17:00   ` Jarkko Sakkinen
  2020-11-03 16:01 ` [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg
                   ` (3 subsequent siblings)
  4 siblings, 2 replies; 52+ messages in thread
From: Sumit Garg @ 2020-11-03 16:01 UTC (permalink / raw)
  To: jarkko.sakkinen, zohar, jejb
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Sumit Garg

Current trusted keys framework is tightly coupled to use TPM device as
an underlying implementation which makes it difficult for implementations
like Trusted Execution Environment (TEE) etc. to provide trusted keys
support in case platform doesn't posses a TPM device.

Add a generic trusted keys framework where underlying implementations
can be easily plugged in. Create struct trusted_key_ops to achieve this,
which contains necessary functions of a backend.

Also, define a module parameter in order to select a particular trust
source in case a platform support multiple trust sources. In case its
not specified then implementation itetrates through trust sources list
starting with TPM and assign the first trust source as a backend which
has initiazed successfully during iteration.

Note that current implementation only supports a single trust source at
runtime which is either selectable at compile time or during boot via
aforementioned module parameter.

Suggested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 Documentation/admin-guide/kernel-parameters.txt |  12 +
 include/keys/trusted-type.h                     |  47 ++++
 include/keys/trusted_tpm.h                      |  17 +-
 security/keys/trusted-keys/Makefile             |   1 +
 security/keys/trusted-keys/trusted_core.c       | 350 ++++++++++++++++++++++++
 security/keys/trusted-keys/trusted_tpm1.c       | 336 ++++-------------------
 6 files changed, 468 insertions(+), 295 deletions(-)
 create mode 100644 security/keys/trusted-keys/trusted_core.c

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 526d65d..df9b9fe 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5392,6 +5392,18 @@
 			See Documentation/admin-guide/mm/transhuge.rst
 			for more details.
 
+	trusted.source=	[KEYS]
+			Format: <string>
+			This parameter identifies the trust source as a backend
+			for trusted keys implementation. Supported trust
+			sources:
+			- "tpm"
+			- "tee"
+			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
+			successfully during iteration.
+
 	tsc=		Disable clocksource stability checks for TSC.
 			Format: <string>
 			[x86] reliable: mark tsc clocksource as reliable, this
diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
index a94c03a..a566451 100644
--- a/include/keys/trusted-type.h
+++ b/include/keys/trusted-type.h
@@ -40,6 +40,53 @@ struct trusted_key_options {
 	uint32_t policyhandle;
 };
 
+struct trusted_key_ops {
+	/*
+	 * flag to indicate if trusted key implementation supports migration
+	 * or not.
+	 */
+	unsigned char migratable;
+
+	/* Initialize key interface. */
+	int (*init)(void);
+
+	/* Seal a key. */
+	int (*seal)(struct trusted_key_payload *p, char *datablob);
+
+	/* Unseal a key. */
+	int (*unseal)(struct trusted_key_payload *p, char *datablob);
+
+	/* Get a randomized key. */
+	int (*get_random)(unsigned char *key, size_t key_len);
+
+	/* Exit key interface. */
+	void (*exit)(void);
+};
+
+struct trusted_key_source {
+	char *name;
+	struct trusted_key_ops *ops;
+};
+
 extern struct key_type key_type_trusted;
 
+#define TRUSTED_DEBUG 0
+
+#if TRUSTED_DEBUG
+static inline void dump_payload(struct trusted_key_payload *p)
+{
+	pr_info("trusted_key: key_len %d\n", p->key_len);
+	print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
+		       16, 1, p->key, p->key_len, 0);
+	pr_info("trusted_key: bloblen %d\n", p->blob_len);
+	print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
+		       16, 1, p->blob, p->blob_len, 0);
+	pr_info("trusted_key: migratable %d\n", p->migratable);
+}
+#else
+static inline void dump_payload(struct trusted_key_payload *p)
+{
+}
+#endif
+
 #endif /* _KEYS_TRUSTED_TYPE_H */
diff --git a/include/keys/trusted_tpm.h b/include/keys/trusted_tpm.h
index a56d8e1..fb3280a 100644
--- a/include/keys/trusted_tpm.h
+++ b/include/keys/trusted_tpm.h
@@ -16,6 +16,8 @@
 #define LOAD32N(buffer, offset)	(*(uint32_t *)&buffer[offset])
 #define LOAD16(buffer, offset)	(ntohs(*(uint16_t *)&buffer[offset]))
 
+extern struct trusted_key_ops tpm_trusted_key_ops;
+
 struct osapsess {
 	uint32_t handle;
 	unsigned char secret[SHA1_DIGEST_SIZE];
@@ -60,17 +62,6 @@ static inline void dump_options(struct trusted_key_options *o)
 		       16, 1, o->pcrinfo, o->pcrinfo_len, 0);
 }
 
-static inline void dump_payload(struct trusted_key_payload *p)
-{
-	pr_info("trusted_key: key_len %d\n", p->key_len);
-	print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
-		       16, 1, p->key, p->key_len, 0);
-	pr_info("trusted_key: bloblen %d\n", p->blob_len);
-	print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
-		       16, 1, p->blob, p->blob_len, 0);
-	pr_info("trusted_key: migratable %d\n", p->migratable);
-}
-
 static inline void dump_sess(struct osapsess *s)
 {
 	print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
@@ -96,10 +87,6 @@ static inline void dump_options(struct trusted_key_options *o)
 {
 }
 
-static inline void dump_payload(struct trusted_key_payload *p)
-{
-}
-
 static inline void dump_sess(struct osapsess *s)
 {
 }
diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
index 7b73ceb..49e3bcf 100644
--- a/security/keys/trusted-keys/Makefile
+++ b/security/keys/trusted-keys/Makefile
@@ -4,5 +4,6 @@
 #
 
 obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
+trusted-y += trusted_core.o
 trusted-y += trusted_tpm1.o
 trusted-y += trusted_tpm2.o
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
new file mode 100644
index 0000000..aa4f2a0
--- /dev/null
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -0,0 +1,350 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2010 IBM Corporation
+ * Copyright (c) 2019-2020, Linaro Limited
+ *
+ * See Documentation/security/keys/trusted-encrypted.rst
+ */
+
+#include <keys/user-type.h>
+#include <keys/trusted-type.h>
+#include <keys/trusted_tpm.h>
+#include <linux/capability.h>
+#include <linux/err.h>
+#include <linux/init.h>
+#include <linux/key-type.h>
+#include <linux/module.h>
+#include <linux/parser.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_key_source;
+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 defined(CONFIG_TCG_TPM)
+	{ "tpm", &tpm_trusted_key_ops },
+#endif
+};
+
+DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
+DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal);
+DEFINE_STATIC_CALL_NULL(trusted_key_unseal,
+			*trusted_key_sources[0].ops->unseal);
+DEFINE_STATIC_CALL_NULL(trusted_key_get_random,
+			*trusted_key_sources[0].ops->get_random);
+DEFINE_STATIC_CALL_NULL(trusted_key_exit, *trusted_key_sources[0].ops->exit);
+static unsigned char migratable;
+
+enum {
+	Opt_err,
+	Opt_new, Opt_load, Opt_update,
+};
+
+static const match_table_t key_tokens = {
+	{Opt_new, "new"},
+	{Opt_load, "load"},
+	{Opt_update, "update"},
+	{Opt_err, NULL}
+};
+
+/*
+ * datablob_parse - parse the keyctl data and fill in the
+ *                  payload structure
+ *
+ * On success returns 0, otherwise -EINVAL.
+ */
+static int datablob_parse(char *datablob, struct trusted_key_payload *p)
+{
+	substring_t args[MAX_OPT_ARGS];
+	long keylen;
+	int ret = -EINVAL;
+	int key_cmd;
+	char *c;
+
+	/* main command */
+	c = strsep(&datablob, " \t");
+	if (!c)
+		return -EINVAL;
+	key_cmd = match_token(c, key_tokens, args);
+	switch (key_cmd) {
+	case Opt_new:
+		/* first argument is key size */
+		c = strsep(&datablob, " \t");
+		if (!c)
+			return -EINVAL;
+		ret = kstrtol(c, 10, &keylen);
+		if (ret < 0 || keylen < MIN_KEY_SIZE || keylen > MAX_KEY_SIZE)
+			return -EINVAL;
+		p->key_len = keylen;
+		ret = Opt_new;
+		break;
+	case Opt_load:
+		/* first argument is sealed blob */
+		c = strsep(&datablob, " \t");
+		if (!c)
+			return -EINVAL;
+		p->blob_len = strlen(c) / 2;
+		if (p->blob_len > MAX_BLOB_SIZE)
+			return -EINVAL;
+		ret = hex2bin(p->blob, c, p->blob_len);
+		if (ret < 0)
+			return -EINVAL;
+		ret = Opt_load;
+		break;
+	case Opt_update:
+		ret = Opt_update;
+		break;
+	case Opt_err:
+		return -EINVAL;
+	}
+	return ret;
+}
+
+static struct trusted_key_payload *trusted_payload_alloc(struct key *key)
+{
+	struct trusted_key_payload *p = NULL;
+	int ret;
+
+	ret = key_payload_reserve(key, sizeof(*p));
+	if (ret < 0)
+		return p;
+	p = kzalloc(sizeof(*p), GFP_KERNEL);
+
+	p->migratable = migratable;
+
+	return p;
+}
+
+/*
+ * trusted_instantiate - create a new trusted key
+ *
+ * Unseal an existing trusted blob or, for a new key, get a
+ * random key, then seal and create a trusted key-type key,
+ * adding it to the specified keyring.
+ *
+ * On success, return 0. Otherwise return errno.
+ */
+static int trusted_instantiate(struct key *key,
+			       struct key_preparsed_payload *prep)
+{
+	struct trusted_key_payload *payload = NULL;
+	size_t datalen = prep->datalen;
+	char *datablob;
+	int ret = 0;
+	int key_cmd;
+	size_t key_len;
+
+	if (datalen <= 0 || datalen > 32767 || !prep->data)
+		return -EINVAL;
+
+	datablob = kmalloc(datalen + 1, GFP_KERNEL);
+	if (!datablob)
+		return -ENOMEM;
+	memcpy(datablob, prep->data, datalen);
+	datablob[datalen] = '\0';
+
+	payload = trusted_payload_alloc(key);
+	if (!payload) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	key_cmd = datablob_parse(datablob, payload);
+	if (key_cmd < 0) {
+		ret = key_cmd;
+		goto out;
+	}
+
+	dump_payload(payload);
+
+	switch (key_cmd) {
+	case Opt_load:
+		ret = static_call(trusted_key_unseal)(payload, datablob);
+		dump_payload(payload);
+		if (ret < 0)
+			pr_info("trusted_key: key_unseal failed (%d)\n", ret);
+		break;
+	case Opt_new:
+		key_len = payload->key_len;
+		ret = static_call(trusted_key_get_random)(payload->key,
+							  key_len);
+		if (ret != key_len) {
+			pr_info("trusted_key: key_create failed (%d)\n", ret);
+			goto out;
+		}
+
+		ret = static_call(trusted_key_seal)(payload, datablob);
+		if (ret < 0)
+			pr_info("trusted_key: key_seal failed (%d)\n", ret);
+		break;
+	default:
+		ret = -EINVAL;
+	}
+out:
+	kfree_sensitive(datablob);
+	if (!ret)
+		rcu_assign_keypointer(key, payload);
+	else
+		kfree_sensitive(payload);
+	return ret;
+}
+
+static void trusted_rcu_free(struct rcu_head *rcu)
+{
+	struct trusted_key_payload *p;
+
+	p = container_of(rcu, struct trusted_key_payload, rcu);
+	kfree_sensitive(p);
+}
+
+/*
+ * trusted_update - reseal an existing key with new PCR values
+ */
+static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
+{
+	struct trusted_key_payload *p;
+	struct trusted_key_payload *new_p;
+	size_t datalen = prep->datalen;
+	char *datablob;
+	int ret = 0;
+
+	if (key_is_negative(key))
+		return -ENOKEY;
+	p = key->payload.data[0];
+	if (!p->migratable)
+		return -EPERM;
+	if (datalen <= 0 || datalen > 32767 || !prep->data)
+		return -EINVAL;
+
+	datablob = kmalloc(datalen + 1, GFP_KERNEL);
+	if (!datablob)
+		return -ENOMEM;
+
+	new_p = trusted_payload_alloc(key);
+	if (!new_p) {
+		ret = -ENOMEM;
+		goto out;
+	}
+
+	memcpy(datablob, prep->data, datalen);
+	datablob[datalen] = '\0';
+	ret = datablob_parse(datablob, new_p);
+	if (ret != Opt_update) {
+		ret = -EINVAL;
+		kfree_sensitive(new_p);
+		goto out;
+	}
+
+	/* copy old key values, and reseal with new pcrs */
+	new_p->migratable = p->migratable;
+	new_p->key_len = p->key_len;
+	memcpy(new_p->key, p->key, p->key_len);
+	dump_payload(p);
+	dump_payload(new_p);
+
+	ret = static_call(trusted_key_seal)(new_p, datablob);
+	if (ret < 0) {
+		pr_info("trusted_key: key_seal failed (%d)\n", ret);
+		kfree_sensitive(new_p);
+		goto out;
+	}
+
+	rcu_assign_keypointer(key, new_p);
+	call_rcu(&p->rcu, trusted_rcu_free);
+out:
+	kfree_sensitive(datablob);
+	return ret;
+}
+
+/*
+ * trusted_read - copy the sealed blob data to userspace in hex.
+ * On success, return to userspace the trusted key datablob size.
+ */
+static long trusted_read(const struct key *key, char *buffer,
+			 size_t buflen)
+{
+	const struct trusted_key_payload *p;
+	char *bufp;
+	int i;
+
+	p = dereference_key_locked(key);
+	if (!p)
+		return -EINVAL;
+
+	if (buffer && buflen >= 2 * p->blob_len) {
+		bufp = buffer;
+		for (i = 0; i < p->blob_len; i++)
+			bufp = hex_byte_pack(bufp, p->blob[i]);
+	}
+	return 2 * p->blob_len;
+}
+
+/*
+ * trusted_destroy - clear and free the key's payload
+ */
+static void trusted_destroy(struct key *key)
+{
+	kfree_sensitive(key->payload.data[0]);
+}
+
+struct key_type key_type_trusted = {
+	.name = "trusted",
+	.instantiate = trusted_instantiate,
+	.update = trusted_update,
+	.destroy = trusted_destroy,
+	.describe = user_describe,
+	.read = trusted_read,
+};
+EXPORT_SYMBOL_GPL(key_type_trusted);
+
+static int __init init_trusted(void)
+{
+	int i, ret = 0;
+
+	for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) {
+		if (trusted_key_source &&
+		    strncmp(trusted_key_source, trusted_key_sources[i].name,
+			    strlen(trusted_key_sources[i].name)))
+			continue;
+
+		static_call_update(trusted_key_init,
+				   trusted_key_sources[i].ops->init);
+		static_call_update(trusted_key_seal,
+				   trusted_key_sources[i].ops->seal);
+		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);
+		static_call_update(trusted_key_exit,
+				   trusted_key_sources[i].ops->exit);
+		migratable = trusted_key_sources[i].ops->migratable;
+
+		ret = static_call(trusted_key_init)();
+		if (!ret)
+			break;
+	}
+
+	/*
+	 * encrypted_keys.ko depends on successful load of this module even if
+	 * trusted key implementation is not found.
+	 */
+	if (ret == -ENODEV)
+		return 0;
+
+	return ret;
+}
+
+static void __exit cleanup_trusted(void)
+{
+	static_call(trusted_key_exit)();
+}
+
+late_initcall(init_trusted);
+module_exit(cleanup_trusted);
+
+MODULE_LICENSE("GPL");
diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
index b9fe02e..bd03914 100644
--- a/security/keys/trusted-keys/trusted_tpm1.c
+++ b/security/keys/trusted-keys/trusted_tpm1.c
@@ -1,29 +1,22 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
  * Copyright (C) 2010 IBM Corporation
- *
- * Author:
- * David Safford <safford@us.ibm.com>
+ * Copyright (c) 2019-2020, Linaro Limited
  *
  * See Documentation/security/keys/trusted-encrypted.rst
  */
 
 #include <crypto/hash_info.h>
-#include <linux/uaccess.h>
-#include <linux/module.h>
 #include <linux/init.h>
 #include <linux/slab.h>
 #include <linux/parser.h>
 #include <linux/string.h>
 #include <linux/err.h>
-#include <keys/user-type.h>
 #include <keys/trusted-type.h>
 #include <linux/key-type.h>
-#include <linux/rcupdate.h>
 #include <linux/crypto.h>
 #include <crypto/hash.h>
 #include <crypto/sha.h>
-#include <linux/capability.h>
 #include <linux/tpm.h>
 #include <linux/tpm_command.h>
 
@@ -703,7 +696,6 @@ static int key_unseal(struct trusted_key_payload *p,
 
 enum {
 	Opt_err,
-	Opt_new, Opt_load, Opt_update,
 	Opt_keyhandle, Opt_keyauth, Opt_blobauth,
 	Opt_pcrinfo, Opt_pcrlock, Opt_migratable,
 	Opt_hash,
@@ -712,9 +704,6 @@ enum {
 };
 
 static const match_table_t key_tokens = {
-	{Opt_new, "new"},
-	{Opt_load, "load"},
-	{Opt_update, "update"},
 	{Opt_keyhandle, "keyhandle=%s"},
 	{Opt_keyauth, "keyauth=%s"},
 	{Opt_blobauth, "blobauth=%s"},
@@ -841,71 +830,6 @@ static int getoptions(char *c, struct trusted_key_payload *pay,
 	return 0;
 }
 
-/*
- * datablob_parse - parse the keyctl data and fill in the
- * 		    payload and options structures
- *
- * On success returns 0, otherwise -EINVAL.
- */
-static int datablob_parse(char *datablob, struct trusted_key_payload *p,
-			  struct trusted_key_options *o)
-{
-	substring_t args[MAX_OPT_ARGS];
-	long keylen;
-	int ret = -EINVAL;
-	int key_cmd;
-	char *c;
-
-	/* main command */
-	c = strsep(&datablob, " \t");
-	if (!c)
-		return -EINVAL;
-	key_cmd = match_token(c, key_tokens, args);
-	switch (key_cmd) {
-	case Opt_new:
-		/* first argument is key size */
-		c = strsep(&datablob, " \t");
-		if (!c)
-			return -EINVAL;
-		ret = kstrtol(c, 10, &keylen);
-		if (ret < 0 || keylen < MIN_KEY_SIZE || keylen > MAX_KEY_SIZE)
-			return -EINVAL;
-		p->key_len = keylen;
-		ret = getoptions(datablob, p, o);
-		if (ret < 0)
-			return ret;
-		ret = Opt_new;
-		break;
-	case Opt_load:
-		/* first argument is sealed blob */
-		c = strsep(&datablob, " \t");
-		if (!c)
-			return -EINVAL;
-		p->blob_len = strlen(c) / 2;
-		if (p->blob_len > MAX_BLOB_SIZE)
-			return -EINVAL;
-		ret = hex2bin(p->blob, c, p->blob_len);
-		if (ret < 0)
-			return -EINVAL;
-		ret = getoptions(datablob, p, o);
-		if (ret < 0)
-			return ret;
-		ret = Opt_load;
-		break;
-	case Opt_update:
-		/* all arguments are options */
-		ret = getoptions(datablob, p, o);
-		if (ret < 0)
-			return ret;
-		ret = Opt_update;
-		break;
-	case Opt_err:
-		return -EINVAL;
-		break;
-	}
-	return ret;
-}
-
 static struct trusted_key_options *trusted_options_alloc(void)
 {
 	struct trusted_key_options *options;
@@ -926,248 +850,99 @@ static struct trusted_key_options *trusted_options_alloc(void)
 	return options;
 }
 
-static struct trusted_key_payload *trusted_payload_alloc(struct key *key)
+static int trusted_tpm_seal(struct trusted_key_payload *p, char *datablob)
 {
-	struct trusted_key_payload *p = NULL;
-	int ret;
-
-	ret = key_payload_reserve(key, sizeof *p);
-	if (ret < 0)
-		return p;
-	p = kzalloc(sizeof *p, GFP_KERNEL);
-	if (p)
-		p->migratable = 1; /* migratable by default */
-	return p;
-}
-
-/*
- * trusted_instantiate - create a new trusted key
- *
- * Unseal an existing trusted blob or, for a new key, get a
- * random key, then seal and create a trusted key-type key,
- * adding it to the specified keyring.
- *
- * On success, return 0. Otherwise return errno.
- */
-static int trusted_instantiate(struct key *key,
-			       struct key_preparsed_payload *prep)
-{
-	struct trusted_key_payload *payload = NULL;
 	struct trusted_key_options *options = NULL;
-	size_t datalen = prep->datalen;
-	char *datablob;
 	int ret = 0;
-	int key_cmd;
-	size_t key_len;
 	int tpm2;
 
 	tpm2 = tpm_is_tpm2(chip);
 	if (tpm2 < 0)
 		return tpm2;
 
-	if (datalen <= 0 || datalen > 32767 || !prep->data)
-		return -EINVAL;
-
-	datablob = kmalloc(datalen + 1, GFP_KERNEL);
-	if (!datablob)
-		return -ENOMEM;
-	memcpy(datablob, prep->data, datalen);
-	datablob[datalen] = '\0';
-
 	options = trusted_options_alloc();
-	if (!options) {
-		ret = -ENOMEM;
-		goto out;
-	}
-	payload = trusted_payload_alloc(key);
-	if (!payload) {
-		ret = -ENOMEM;
-		goto out;
-	}
+	if (!options)
+		return -ENOMEM;
 
-	key_cmd = datablob_parse(datablob, payload, options);
-	if (key_cmd < 0) {
-		ret = key_cmd;
+	ret = getoptions(datablob, p, options);
+	if (ret < 0)
 		goto out;
-	}
+	dump_options(options);
 
 	if (!options->keyhandle) {
 		ret = -EINVAL;
 		goto out;
 	}
 
-	dump_payload(payload);
-	dump_options(options);
+	if (tpm2)
+		ret = tpm2_seal_trusted(chip, p, options);
+	else
+		ret = key_seal(p, options);
+	if (ret < 0) {
+		pr_info("tpm_trusted_key: key_seal failed (%d)\n", ret);
+		goto out;
+	}
 
-	switch (key_cmd) {
-	case Opt_load:
-		if (tpm2)
-			ret = tpm2_unseal_trusted(chip, payload, options);
-		else
-			ret = key_unseal(payload, options);
-		dump_payload(payload);
-		dump_options(options);
-		if (ret < 0)
-			pr_info("trusted_key: key_unseal failed (%d)\n", ret);
-		break;
-	case Opt_new:
-		key_len = payload->key_len;
-		ret = tpm_get_random(chip, payload->key, key_len);
-		if (ret != key_len) {
-			pr_info("trusted_key: key_create failed (%d)\n", ret);
+	if (options->pcrlock) {
+		ret = pcrlock(options->pcrlock);
+		if (ret < 0) {
+			pr_info("tpm_trusted_key: pcrlock failed (%d)\n", ret);
 			goto out;
 		}
-		if (tpm2)
-			ret = tpm2_seal_trusted(chip, payload, options);
-		else
-			ret = key_seal(payload, options);
-		if (ret < 0)
-			pr_info("trusted_key: key_seal failed (%d)\n", ret);
-		break;
-	default:
-		ret = -EINVAL;
-		goto out;
 	}
-	if (!ret && options->pcrlock)
-		ret = pcrlock(options->pcrlock);
 out:
-	kfree_sensitive(datablob);
 	kfree_sensitive(options);
-	if (!ret)
-		rcu_assign_keypointer(key, payload);
-	else
-		kfree_sensitive(payload);
 	return ret;
 }
 
-static void trusted_rcu_free(struct rcu_head *rcu)
-{
-	struct trusted_key_payload *p;
-
-	p = container_of(rcu, struct trusted_key_payload, rcu);
-	kfree_sensitive(p);
-}
-
-/*
- * trusted_update - reseal an existing key with new PCR values
- */
-static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
+static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
 {
-	struct trusted_key_payload *p;
-	struct trusted_key_payload *new_p;
-	struct trusted_key_options *new_o;
-	size_t datalen = prep->datalen;
-	char *datablob;
+	struct trusted_key_options *options = NULL;
 	int ret = 0;
+	int tpm2;
 
-	if (key_is_negative(key))
-		return -ENOKEY;
-	p = key->payload.data[0];
-	if (!p->migratable)
-		return -EPERM;
-	if (datalen <= 0 || datalen > 32767 || !prep->data)
-		return -EINVAL;
+	tpm2 = tpm_is_tpm2(chip);
+	if (tpm2 < 0)
+		return tpm2;
 
-	datablob = kmalloc(datalen + 1, GFP_KERNEL);
-	if (!datablob)
+	options = trusted_options_alloc();
+	if (!options)
 		return -ENOMEM;
-	new_o = trusted_options_alloc();
-	if (!new_o) {
-		ret = -ENOMEM;
-		goto out;
-	}
-	new_p = trusted_payload_alloc(key);
-	if (!new_p) {
-		ret = -ENOMEM;
-		goto out;
-	}
 
-	memcpy(datablob, prep->data, datalen);
-	datablob[datalen] = '\0';
-	ret = datablob_parse(datablob, new_p, new_o);
-	if (ret != Opt_update) {
-		ret = -EINVAL;
-		kfree_sensitive(new_p);
+	ret = getoptions(datablob, p, options);
+	if (ret < 0)
 		goto out;
-	}
+	dump_options(options);
 
-	if (!new_o->keyhandle) {
+	if (!options->keyhandle) {
 		ret = -EINVAL;
-		kfree_sensitive(new_p);
 		goto out;
 	}
 
-	/* copy old key values, and reseal with new pcrs */
-	new_p->migratable = p->migratable;
-	new_p->key_len = p->key_len;
-	memcpy(new_p->key, p->key, p->key_len);
-	dump_payload(p);
-	dump_payload(new_p);
+	if (tpm2)
+		ret = tpm2_unseal_trusted(chip, p, options);
+	else
+		ret = key_unseal(p, options);
+	if (ret < 0)
+		pr_info("tpm_trusted_key: key_unseal failed (%d)\n", ret);
 
-	ret = key_seal(new_p, new_o);
-	if (ret < 0) {
-		pr_info("trusted_key: key_seal failed (%d)\n", ret);
-		kfree_sensitive(new_p);
-		goto out;
-	}
-	if (new_o->pcrlock) {
-		ret = pcrlock(new_o->pcrlock);
+	if (options->pcrlock) {
+		ret = pcrlock(options->pcrlock);
 		if (ret < 0) {
-			pr_info("trusted_key: pcrlock failed (%d)\n", ret);
-			kfree_sensitive(new_p);
+			pr_info("tpm_trusted_key: pcrlock failed (%d)\n", ret);
 			goto out;
 		}
 	}
-	rcu_assign_keypointer(key, new_p);
-	call_rcu(&p->rcu, trusted_rcu_free);
 out:
-	kfree_sensitive(datablob);
-	kfree_sensitive(new_o);
+	kfree_sensitive(options);
 	return ret;
 }
 
-/*
- * trusted_read - copy the sealed blob data to userspace in hex.
- * On success, return to userspace the trusted key datablob size.
- */
-static long trusted_read(const struct key *key, char *buffer,
-			 size_t buflen)
-{
-	const struct trusted_key_payload *p;
-	char *bufp;
-	int i;
-
-	p = dereference_key_locked(key);
-	if (!p)
-		return -EINVAL;
-
-	if (buffer && buflen >= 2 * p->blob_len) {
-		bufp = buffer;
-		for (i = 0; i < p->blob_len; i++)
-			bufp = hex_byte_pack(bufp, p->blob[i]);
-	}
-	return 2 * p->blob_len;
-}
-
-/*
- * trusted_destroy - clear and free the key's payload
- */
-static void trusted_destroy(struct key *key)
+static int trusted_tpm_get_random(unsigned char *key, size_t key_len)
 {
-	kfree_sensitive(key->payload.data[0]);
+	return tpm_get_random(chip, key, key_len);
 }
 
-struct key_type key_type_trusted = {
-	.name = "trusted",
-	.instantiate = trusted_instantiate,
-	.update = trusted_update,
-	.destroy = trusted_destroy,
-	.describe = user_describe,
-	.read = trusted_read,
-};
-
-EXPORT_SYMBOL_GPL(key_type_trusted);
-
 static void trusted_shash_release(void)
 {
 	if (hashalg)
@@ -1182,14 +957,14 @@ static int __init trusted_shash_alloc(void)
 
 	hmacalg = crypto_alloc_shash(hmac_alg, 0, 0);
 	if (IS_ERR(hmacalg)) {
-		pr_info("trusted_key: could not allocate crypto %s\n",
+		pr_info("tpm_trusted_key: could not allocate crypto %s\n",
 			hmac_alg);
 		return PTR_ERR(hmacalg);
 	}
 
 	hashalg = crypto_alloc_shash(hash_alg, 0, 0);
 	if (IS_ERR(hashalg)) {
-		pr_info("trusted_key: could not allocate crypto %s\n",
+		pr_info("tpm_trusted_key: could not allocate crypto %s\n",
 			hash_alg);
 		ret = PTR_ERR(hashalg);
 		goto hashalg_fail;
@@ -1217,16 +992,13 @@ static int __init init_digests(void)
 	return 0;
 }
 
-static int __init init_trusted(void)
+static int trusted_tpm_init(void)
 {
 	int ret;
 
-	/* encrypted_keys.ko depends on successful load of this module even if
-	 * TPM is not used.
-	 */
 	chip = tpm_default_chip();
 	if (!chip)
-		return 0;
+		return -ENODEV;
 
 	ret = init_digests();
 	if (ret < 0)
@@ -1247,7 +1019,7 @@ static int __init init_trusted(void)
 	return ret;
 }
 
-static void __exit cleanup_trusted(void)
+static void trusted_tpm_exit(void)
 {
 	if (chip) {
 		put_device(&chip->dev);
@@ -1257,7 +1029,11 @@ static void __exit cleanup_trusted(void)
 	}
 }
 
-late_initcall(init_trusted);
-module_exit(cleanup_trusted);
-
-MODULE_LICENSE("GPL");
+struct trusted_key_ops tpm_trusted_key_ops = {
+	.migratable = 1, /* migratable by default */
+	.init = trusted_tpm_init,
+	.seal = trusted_tpm_seal,
+	.unseal = trusted_tpm_unseal,
+	.get_random = trusted_tpm_get_random,
+	.exit = trusted_tpm_exit,
+};
-- 
2.7.4


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

* [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2020-11-03 16:01 [PATCH v8 0/4] Introduce TEE based Trusted Keys support Sumit Garg
  2020-11-03 16:01 ` [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework Sumit Garg
@ 2020-11-03 16:01 ` Sumit Garg
  2020-11-24  3:46   ` Jarkko Sakkinen
                     ` (2 more replies)
  2020-11-03 16:01 ` [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg
                   ` (2 subsequent siblings)
  4 siblings, 3 replies; 52+ messages in thread
From: Sumit Garg @ 2020-11-03 16:01 UTC (permalink / raw)
  To: jarkko.sakkinen, zohar, jejb
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Sumit Garg

Add support for TEE based trusted keys where TEE provides the functionality
to seal and unseal trusted keys using hardware unique key.

Refer to Documentation/tee.txt for detailed information about TEE.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 include/keys/trusted_tee.h                |  55 ++++++
 security/keys/trusted-keys/Makefile       |   1 +
 security/keys/trusted-keys/trusted_core.c |   4 +
 security/keys/trusted-keys/trusted_tee.c  | 278 ++++++++++++++++++++++++++++++
 4 files changed, 338 insertions(+)
 create mode 100644 include/keys/trusted_tee.h
 create mode 100644 security/keys/trusted-keys/trusted_tee.c

diff --git a/include/keys/trusted_tee.h b/include/keys/trusted_tee.h
new file mode 100644
index 0000000..2e2bb15
--- /dev/null
+++ b/include/keys/trusted_tee.h
@@ -0,0 +1,55 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019-2020 Linaro Ltd.
+ *
+ * Author:
+ * Sumit Garg <sumit.garg@linaro.org>
+ */
+
+#ifndef __TEE_TRUSTED_KEY_H
+#define __TEE_TRUSTED_KEY_H
+
+#include <linux/tee_drv.h>
+
+#define DRIVER_NAME "tee-trusted-key"
+
+/*
+ * Get random data for symmetric key
+ *
+ * [out]     memref[0]        Random data
+ */
+#define TA_CMD_GET_RANDOM	0x0
+
+/*
+ * Seal trusted key using hardware unique key
+ *
+ * [in]      memref[0]        Plain key
+ * [out]     memref[1]        Sealed key datablob
+ */
+#define TA_CMD_SEAL		0x1
+
+/*
+ * Unseal trusted key using hardware unique key
+ *
+ * [in]      memref[0]        Sealed key datablob
+ * [out]     memref[1]        Plain key
+ */
+#define TA_CMD_UNSEAL		0x2
+
+/**
+ * struct trusted_key_private - TEE Trusted key private data
+ * @dev:		TEE based Trusted key device.
+ * @ctx:		TEE context handler.
+ * @session_id:		Trusted key TA session identifier.
+ * @shm_pool:		Memory pool shared with TEE device.
+ */
+struct trusted_key_private {
+	struct device *dev;
+	struct tee_context *ctx;
+	u32 session_id;
+	struct tee_shm *shm_pool;
+};
+
+extern struct trusted_key_ops tee_trusted_key_ops;
+
+#endif
diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
index 49e3bcf..012dd78 100644
--- a/security/keys/trusted-keys/Makefile
+++ b/security/keys/trusted-keys/Makefile
@@ -7,3 +7,4 @@ obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
 trusted-y += trusted_core.o
 trusted-y += trusted_tpm1.o
 trusted-y += trusted_tpm2.o
+trusted-y += trusted_tee.o
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index aa4f2a0..15b1b0f3 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -8,6 +8,7 @@
 
 #include <keys/user-type.h>
 #include <keys/trusted-type.h>
+#include <keys/trusted_tee.h>
 #include <keys/trusted_tpm.h>
 #include <linux/capability.h>
 #include <linux/err.h>
@@ -29,6 +30,9 @@ static const struct trusted_key_source trusted_key_sources[] = {
 #if defined(CONFIG_TCG_TPM)
 	{ "tpm", &tpm_trusted_key_ops },
 #endif
+#if defined(CONFIG_TEE)
+	{ "tee", &tee_trusted_key_ops },
+#endif
 };
 
 DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
new file mode 100644
index 0000000..da8785a
--- /dev/null
+++ b/security/keys/trusted-keys/trusted_tee.c
@@ -0,0 +1,278 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019-2020 Linaro Ltd.
+ *
+ * Author:
+ * Sumit Garg <sumit.garg@linaro.org>
+ */
+
+#include <linux/err.h>
+#include <linux/key-type.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/uuid.h>
+
+#include <keys/trusted-type.h>
+#include <keys/trusted_tee.h>
+
+static struct trusted_key_private pvt_data;
+
+/*
+ * Have the TEE seal(encrypt) the symmetric key
+ */
+static int trusted_tee_seal(struct trusted_key_payload *p, char *datablob)
+{
+	int ret;
+	struct tee_ioctl_invoke_arg inv_arg;
+	struct tee_param param[4];
+	struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
+
+	memset(&inv_arg, 0, sizeof(inv_arg));
+	memset(&param, 0, sizeof(param));
+
+	reg_shm_in = tee_shm_register(pvt_data.ctx, (unsigned long)p->key,
+				      p->key_len, TEE_SHM_DMA_BUF |
+				      TEE_SHM_KERNEL_MAPPED);
+	if (IS_ERR(reg_shm_in)) {
+		dev_err(pvt_data.dev, "key shm register failed\n");
+		return PTR_ERR(reg_shm_in);
+	}
+
+	reg_shm_out = tee_shm_register(pvt_data.ctx, (unsigned long)p->blob,
+				       sizeof(p->blob), TEE_SHM_DMA_BUF |
+				       TEE_SHM_KERNEL_MAPPED);
+	if (IS_ERR(reg_shm_out)) {
+		dev_err(pvt_data.dev, "blob shm register failed\n");
+		ret = PTR_ERR(reg_shm_out);
+		goto out;
+	}
+
+	inv_arg.func = TA_CMD_SEAL;
+	inv_arg.session = pvt_data.session_id;
+	inv_arg.num_params = 4;
+
+	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
+	param[0].u.memref.shm = reg_shm_in;
+	param[0].u.memref.size = p->key_len;
+	param[0].u.memref.shm_offs = 0;
+	param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
+	param[1].u.memref.shm = reg_shm_out;
+	param[1].u.memref.size = sizeof(p->blob);
+	param[1].u.memref.shm_offs = 0;
+
+	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
+	if ((ret < 0) || (inv_arg.ret != 0)) {
+		dev_err(pvt_data.dev, "TA_CMD_SEAL invoke err: %x\n",
+			inv_arg.ret);
+		ret = -EFAULT;
+	} else {
+		p->blob_len = param[1].u.memref.size;
+	}
+
+out:
+	if (reg_shm_out)
+		tee_shm_free(reg_shm_out);
+	if (reg_shm_in)
+		tee_shm_free(reg_shm_in);
+
+	return ret;
+}
+
+/*
+ * Have the TEE unseal(decrypt) the symmetric key
+ */
+static int trusted_tee_unseal(struct trusted_key_payload *p, char *datablob)
+{
+	int ret;
+	struct tee_ioctl_invoke_arg inv_arg;
+	struct tee_param param[4];
+	struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
+
+	memset(&inv_arg, 0, sizeof(inv_arg));
+	memset(&param, 0, sizeof(param));
+
+	reg_shm_in = tee_shm_register(pvt_data.ctx, (unsigned long)p->blob,
+				      p->blob_len, TEE_SHM_DMA_BUF |
+				      TEE_SHM_KERNEL_MAPPED);
+	if (IS_ERR(reg_shm_in)) {
+		dev_err(pvt_data.dev, "blob shm register failed\n");
+		return PTR_ERR(reg_shm_in);
+	}
+
+	reg_shm_out = tee_shm_register(pvt_data.ctx, (unsigned long)p->key,
+				       sizeof(p->key), TEE_SHM_DMA_BUF |
+				       TEE_SHM_KERNEL_MAPPED);
+	if (IS_ERR(reg_shm_out)) {
+		dev_err(pvt_data.dev, "key shm register failed\n");
+		ret = PTR_ERR(reg_shm_out);
+		goto out;
+	}
+
+	inv_arg.func = TA_CMD_UNSEAL;
+	inv_arg.session = pvt_data.session_id;
+	inv_arg.num_params = 4;
+
+	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
+	param[0].u.memref.shm = reg_shm_in;
+	param[0].u.memref.size = p->blob_len;
+	param[0].u.memref.shm_offs = 0;
+	param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
+	param[1].u.memref.shm = reg_shm_out;
+	param[1].u.memref.size = sizeof(p->key);
+	param[1].u.memref.shm_offs = 0;
+
+	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
+	if ((ret < 0) || (inv_arg.ret != 0)) {
+		dev_err(pvt_data.dev, "TA_CMD_UNSEAL invoke err: %x\n",
+			inv_arg.ret);
+		ret = -EFAULT;
+	} else {
+		p->key_len = param[1].u.memref.size;
+	}
+
+out:
+	if (reg_shm_out)
+		tee_shm_free(reg_shm_out);
+	if (reg_shm_in)
+		tee_shm_free(reg_shm_in);
+
+	return ret;
+}
+
+/*
+ * Have the TEE generate random symmetric key
+ */
+static int trusted_tee_get_random(unsigned char *key, size_t key_len)
+{
+	int ret;
+	struct tee_ioctl_invoke_arg inv_arg;
+	struct tee_param param[4];
+	struct tee_shm *reg_shm = NULL;
+
+	memset(&inv_arg, 0, sizeof(inv_arg));
+	memset(&param, 0, sizeof(param));
+
+	reg_shm = tee_shm_register(pvt_data.ctx, (unsigned long)key, key_len,
+				   TEE_SHM_DMA_BUF | TEE_SHM_KERNEL_MAPPED);
+	if (IS_ERR(reg_shm)) {
+		dev_err(pvt_data.dev, "key shm register failed\n");
+		return PTR_ERR(reg_shm);
+	}
+
+	inv_arg.func = TA_CMD_GET_RANDOM;
+	inv_arg.session = pvt_data.session_id;
+	inv_arg.num_params = 4;
+
+	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
+	param[0].u.memref.shm = reg_shm;
+	param[0].u.memref.size = key_len;
+	param[0].u.memref.shm_offs = 0;
+
+	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
+	if ((ret < 0) || (inv_arg.ret != 0)) {
+		dev_err(pvt_data.dev, "TA_CMD_GET_RANDOM invoke err: %x\n",
+			inv_arg.ret);
+		ret = -EFAULT;
+	} else {
+		ret = param[0].u.memref.size;
+	}
+
+	tee_shm_free(reg_shm);
+
+	return ret;
+}
+
+static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
+{
+	if (ver->impl_id == TEE_IMPL_ID_OPTEE)
+		return 1;
+	else
+		return 0;
+}
+
+static int trusted_key_probe(struct device *dev)
+{
+	struct tee_client_device *rng_device = to_tee_client_device(dev);
+	int ret;
+	struct tee_ioctl_open_session_arg sess_arg;
+
+	memset(&sess_arg, 0, sizeof(sess_arg));
+
+	pvt_data.ctx = tee_client_open_context(NULL, optee_ctx_match, NULL,
+					       NULL);
+	if (IS_ERR(pvt_data.ctx))
+		return -ENODEV;
+
+	memcpy(sess_arg.uuid, rng_device->id.uuid.b, TEE_IOCTL_UUID_LEN);
+	sess_arg.clnt_login = TEE_IOCTL_LOGIN_REE_KERNEL;
+	sess_arg.num_params = 0;
+
+	ret = tee_client_open_session(pvt_data.ctx, &sess_arg, NULL);
+	if ((ret < 0) || (sess_arg.ret != 0)) {
+		dev_err(dev, "tee_client_open_session failed, err: %x\n",
+			sess_arg.ret);
+		ret = -EINVAL;
+		goto out_ctx;
+	}
+	pvt_data.session_id = sess_arg.session;
+
+	ret = register_key_type(&key_type_trusted);
+	if (ret < 0)
+		goto out_sess;
+
+	pvt_data.dev = dev;
+
+	return 0;
+
+out_sess:
+	tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
+out_ctx:
+	tee_client_close_context(pvt_data.ctx);
+
+	return ret;
+}
+
+static int trusted_key_remove(struct device *dev)
+{
+	unregister_key_type(&key_type_trusted);
+	tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
+	tee_client_close_context(pvt_data.ctx);
+
+	return 0;
+}
+
+static const struct tee_client_device_id trusted_key_id_table[] = {
+	{UUID_INIT(0xf04a0fe7, 0x1f5d, 0x4b9b,
+		   0xab, 0xf7, 0x61, 0x9b, 0x85, 0xb4, 0xce, 0x8c)},
+	{}
+};
+MODULE_DEVICE_TABLE(tee, trusted_key_id_table);
+
+static struct tee_client_driver trusted_key_driver = {
+	.id_table	= trusted_key_id_table,
+	.driver		= {
+		.name		= DRIVER_NAME,
+		.bus		= &tee_bus_type,
+		.probe		= trusted_key_probe,
+		.remove		= trusted_key_remove,
+	},
+};
+
+static int trusted_tee_init(void)
+{
+	return driver_register(&trusted_key_driver.driver);
+}
+
+static void trusted_tee_exit(void)
+{
+	driver_unregister(&trusted_key_driver.driver);
+}
+
+struct trusted_key_ops tee_trusted_key_ops = {
+	.migratable = 0, /* non-migratable */
+	.init = trusted_tee_init,
+	.seal = trusted_tee_seal,
+	.unseal = trusted_tee_unseal,
+	.get_random = trusted_tee_get_random,
+	.exit = trusted_tee_exit,
+};
-- 
2.7.4


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

* [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-11-03 16:01 [PATCH v8 0/4] Introduce TEE based Trusted Keys support Sumit Garg
  2020-11-03 16:01 ` [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework Sumit Garg
  2020-11-03 16:01 ` [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg
@ 2020-11-03 16:01 ` Sumit Garg
  2020-12-02 19:34   ` gmail Elaine Palmer
                     ` (2 more replies)
  2020-11-03 16:01 ` [PATCH v8 4/4] MAINTAINERS: Add myself as Trusted Keys co-maintainer Sumit Garg
  2020-11-05  5:07 ` [PATCH v8 0/4] Introduce TEE based Trusted Keys support Jarkko Sakkinen
  4 siblings, 3 replies; 52+ messages in thread
From: Sumit Garg @ 2020-11-03 16:01 UTC (permalink / raw)
  To: jarkko.sakkinen, zohar, jejb
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Sumit Garg

Update documentation for Trusted and Encrypted Keys with TEE as a new
trust source. Following is brief description of updates:

- Add a section to demostrate a list of supported devices along with
  their security properties/guarantees.
- Add a key generation section.
- Updates for usage section including differences specific to a trust
  source.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
---
 Documentation/security/keys/trusted-encrypted.rst | 203 ++++++++++++++++++----
 1 file changed, 171 insertions(+), 32 deletions(-)

diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index 1da879a..16042c8 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -6,30 +6,161 @@ Trusted and Encrypted Keys are two new key types added to the existing kernel
 key ring service.  Both of these new types are variable length symmetric keys,
 and in both cases all keys are created in the kernel, and user space sees,
 stores, and loads only encrypted blobs.  Trusted Keys require the availability
-of a Trusted Platform Module (TPM) chip for greater security, while Encrypted
-Keys can be used on any system.  All user level blobs, are displayed and loaded
-in hex ascii for convenience, and are integrity verified.
+of a Trust Source for greater security, while Encrypted Keys can be used on any
+system. All user level blobs, are displayed and loaded in hex ascii for
+convenience, and are integrity verified.
 
-Trusted Keys use a TPM both to generate and to seal the keys.  Keys are sealed
-under a 2048 bit RSA key in the TPM, and optionally sealed to specified PCR
-(integrity measurement) values, and only unsealed by the TPM, if PCRs and blob
-integrity verifications match.  A loaded Trusted Key can be updated with new
-(future) PCR values, so keys are easily migrated to new pcr values, such as
-when the kernel and initramfs are updated.  The same key can have many saved
-blobs under different PCR values, so multiple boots are easily supported.
 
-TPM 1.2
--------
+Trust Source
+============
 
-By default, trusted keys are sealed under the SRK, which has the default
-authorization value (20 zeros).  This can be set at takeownership time with the
-trouser's utility: "tpm_takeownership -u -z".
+Trust Source provides the source of security for the Trusted Keys, on which
+basis Trusted Keys establishes a Trust model with its user. A Trust Source could
+differ from one system to another depending on its security requirements. It
+could be either an off-chip device or an on-chip device. Following section
+demostrates a list of supported devices along with their security properties/
+guarantees:
 
-TPM 2.0
--------
+  *  Root of trust for storage
 
-The user must first create a storage key and make it persistent, so the key is
-available after reboot. This can be done using the following commands.
+     (1) TPM (Trusted Platform Module: hardware device)
+
+         Rooted to Storage Root Key (SRK) which never leaves the TPM that
+         provides crypto operation to establish root of trust for storage.
+
+     (2) TEE (Trusted Execution Environment: OP-TEE based on Arm TrustZone)
+
+         Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip
+         fuses and is accessible to TEE only.
+
+  *  Execution isolation
+
+     (1) TPM
+
+         Fixed set of operations running in isolated execution environment.
+
+     (2) TEE
+
+         Customizable set of operations running in isolated execution
+         environment verified via Secure/Trusted boot process.
+
+  * Optional binding to platform integrity state
+
+     (1) TPM
+
+         Keys can be optionally sealed to specified PCR (integrity measurement)
+         values, and only unsealed by the TPM, if PCRs and blob integrity
+         verifications match. A loaded Trusted Key can be updated with new
+         (future) PCR values, so keys are easily migrated to new PCR values,
+         such as when the kernel and initramfs are updated. The same key can
+         have many saved blobs under different PCR values, so multiple boots are
+         easily supported.
+
+     (2) TEE
+
+         Relies on Secure/Trusted boot process for platform integrity. It can
+         be extended with TEE based measured boot process.
+
+  *  On-chip versus off-chip
+
+     (1) TPM
+
+         Off-chip device connected via serial bus (like I2C, SPI etc.) exposing
+         physical access which represents an attack surface that can be
+         mitigated via tamper detection.
+
+     (2) TEE
+
+         On-chip functionality, immune to this attack surface.
+
+  *  Memory attacks (DRAM based like attaching a bus monitor etc.)
+
+     (1) TPM
+
+         Immune to these attacks as it doesn’t make use of system DRAM.
+
+     (2) TEE
+
+         An implementation based on TrustZone protected DRAM is susceptible to
+         such attacks. In order to mitigate these attacks one needs to rely on
+         on-chip secure RAM to store secrets or have the entire TEE
+         implementation based on on-chip secure RAM. An alternative mitigation
+         would be to use encrypted DRAM.
+
+  *  Side-channel attacks (cache, memory, CPU or time based)
+
+     (1) TPM
+
+         Immune to side-channel attacks as its resources are isolated from the
+         main OS.
+
+     (2) TEE
+
+         A careful implementation is required to mitigate against these attacks
+         for resources which are shared (eg. shared memory) with the main OS.
+         Cache and CPU based side-channel attacks can be mitigated via
+         invalidating caches and CPU registers during context switch to and from
+         the secure world.
+         To mitigate against time based attacks, one needs to have time
+         invariant implementations (like crypto algorithms etc.).
+
+  *  Resistance to physical attacks (power analysis, electromagnetic emanation,
+     probes etc.)
+
+     (1) TPM
+
+         Provides limited protection utilizing tamper resistance.
+
+     (2) TEE
+
+         Provides no protection by itself, relies on the underlying platform for
+         features such as tamper resistance.
+
+
+Key Generation
+==============
+
+Trusted Keys
+------------
+
+New keys are created from trust source generated random numbers, and are
+encrypted/decrypted using trust source storage root key.
+
+  *  TPM (hardware device) based RNG
+
+     Strength of random numbers may vary from one device manufacturer to
+     another.
+
+  *  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.
+
+Encrypted Keys
+--------------
+
+Encrypted keys do not depend on a trust source, and are faster, as they use AES
+for encryption/decryption. New keys are created from kernel generated random
+numbers, and are encrypted/decrypted using a specified ‘master’ key. The
+‘master’ key can either be a trusted-key or user-key type. The main disadvantage
+of encrypted keys is that if they are not rooted in a trusted key, they are only
+as secure as the user key encrypting them. The master user key should therefore
+be loaded in as secure a way as possible, preferably early in boot.
+
+
+Usage
+=====
+
+Trusted Keys usage: TPM
+-----------------------
+
+TPM 1.2: By default, trusted keys are sealed under the SRK, which has the
+default authorization value (20 zeros).  This can be set at takeownership time
+with the TrouSerS utility: "tpm_takeownership -u -z".
+
+TPM 2.0: The user must first create a storage key and make it persistent, so the
+key is available after reboot. This can be done using the following commands.
 
 With the IBM TSS 2 stack::
 
@@ -78,14 +209,21 @@ TPM_STORED_DATA format.  The key length for new keys are always in bytes.
 Trusted Keys can be 32 - 128 bytes (256 - 1024 bits), the upper limit is to fit
 within the 2048 bit SRK (RSA) keylength, with all necessary structure/padding.
 
-Encrypted keys do not depend on a TPM, and are faster, as they use AES for
-encryption/decryption.  New keys are created from kernel generated random
-numbers, and are encrypted/decrypted using a specified 'master' key.  The
-'master' key can either be a trusted-key or user-key type.  The main
-disadvantage of encrypted keys is that if they are not rooted in a trusted key,
-they are only as secure as the user key encrypting them.  The master user key
-should therefore be loaded in as secure a way as possible, preferably early in
-boot.
+Trusted Keys usage: TEE
+-----------------------
+
+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 TEE device implementation.  The key length for new keys are always
+in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
+
+Encrypted Keys usage
+--------------------
 
 The decrypted portion of encrypted keys can contain either a simple symmetric
 key or a more complex structure. The format of the more complex structure is
@@ -103,8 +241,8 @@ Where::
 	format:= 'default | ecryptfs | enc32'
 	key-type:= 'trusted' | 'user'
 
-
 Examples of trusted and encrypted key usage:
+--------------------------------------------
 
 Create and save a trusted key named "kmk" of length 32 bytes.
 
@@ -150,7 +288,7 @@ Load a trusted key from the saved blob::
     f1f8fff03ad0acb083725535636addb08d73dedb9832da198081e5deae84bfaf0409c22b
     e4a8aea2b607ec96931e6f4d4fe563ba
 
-Reseal a trusted key under new pcr values::
+Reseal (TPM specific) a trusted key under new PCR values::
 
     $ keyctl update 268728824 "update pcrinfo=`cat pcr.blob`"
     $ keyctl print 268728824
@@ -164,11 +302,12 @@ Reseal a trusted key under new pcr values::
     7ef6a24defe4846104209bf0c3eced7fa1a672ed5b125fc9d8cd88b476a658a4434644ef
     df8ae9a178e9f83ba9f08d10fa47e4226b98b0702f06b3b8
 
+
 The initial consumer of trusted keys is EVM, which at boot time needs a high
-quality symmetric key for HMAC protection of file metadata.  The use of a
+quality symmetric key for HMAC protection of file metadata. The use of a
 trusted key provides strong guarantees that the EVM key has not been
-compromised by a user level problem, and when sealed to specific boot PCR
-values, protects against boot and offline attacks.  Create and save an
+compromised by a user level problem, and when sealed to a platform integrity
+state, protects against boot and offline attacks. Create and save an
 encrypted key "evm" using the above trusted key "kmk":
 
 option 1: omitting 'format'::
-- 
2.7.4


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

* [PATCH v8 4/4] MAINTAINERS: Add myself as Trusted Keys co-maintainer
  2020-11-03 16:01 [PATCH v8 0/4] Introduce TEE based Trusted Keys support Sumit Garg
                   ` (2 preceding siblings ...)
  2020-11-03 16:01 ` [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg
@ 2020-11-03 16:01 ` Sumit Garg
  2020-11-24  3:46   ` Jarkko Sakkinen
  2020-11-05  5:07 ` [PATCH v8 0/4] Introduce TEE based Trusted Keys support Jarkko Sakkinen
  4 siblings, 1 reply; 52+ messages in thread
From: Sumit Garg @ 2020-11-03 16:01 UTC (permalink / raw)
  To: jarkko.sakkinen, zohar, jejb
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Sumit Garg

Add a Trusted Keys co-maintainer entry in order to support TEE based
Trusted Keys framework.

Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index e73636b..52687bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9732,11 +9732,13 @@ KEYS-TRUSTED
 M:	James Bottomley <jejb@linux.ibm.com>
 M:	Jarkko Sakkinen <jarkko@kernel.org>
 M:	Mimi Zohar <zohar@linux.ibm.com>
+M:	Sumit Garg <sumit.garg@linaro.org>
 L:	linux-integrity@vger.kernel.org
 L:	keyrings@vger.kernel.org
 S:	Supported
 F:	Documentation/security/keys/trusted-encrypted.rst
 F:	include/keys/trusted-type.h
+F:	include/keys/trusted_tee.h
 F:	include/keys/trusted_tpm.h
 F:	security/keys/trusted-keys/
 
-- 
2.7.4


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

* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support
  2020-11-03 16:01 [PATCH v8 0/4] Introduce TEE based Trusted Keys support Sumit Garg
                   ` (3 preceding siblings ...)
  2020-11-03 16:01 ` [PATCH v8 4/4] MAINTAINERS: Add myself as Trusted Keys co-maintainer Sumit Garg
@ 2020-11-05  5:07 ` Jarkko Sakkinen
  2020-11-06  9:32   ` Sumit Garg
  4 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2020-11-05  5:07 UTC (permalink / raw)
  To: Sumit Garg
  Cc: jarkko.sakkinen, zohar, jejb, dhowells, jens.wiklander, corbet,
	jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee

On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote:
> Add support for TEE based trusted keys where TEE provides the functionality
> to seal and unseal trusted keys using hardware unique key. Also, this is
> an alternative in case platform doesn't possess a TPM device.
> 
> This patch-set has been tested with OP-TEE based early TA which is already
> merged in upstream [1].

Is the new RPI400 computer a platform that can be used for testing
patch sets like this? I've been looking for a while something ARM64
based with similar convenience as Intel NUC's, and on the surface
this new RPI product looks great for kernel testing purposes.

/Jarkko

> 
> [1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d7e5b86b
> 
> Changes in v8:
> 1. Added static calls support instead of indirect calls.
> 2. Documented trusted keys source module parameter.
> 3. Refined patch #1 commit message discription.
> 4. Addressed misc. comments on patch #2.
> 5. Added myself as Trusted Keys co-maintainer instead.
> 6. Rebased to latest tpmdd master.
> 
> Changes in v7:
> 1. Added a trusted.source module parameter in order to enforce user's
>    choice in case a particular platform posses both TPM and TEE.
> 2. Refine commit description for patch #1.
> 
> Changes in v6:
> 1. Revert back to dynamic detection of trust source.
> 2. Drop author mention from trusted_core.c and trusted_tpm1.c files.
> 3. Rebased to latest tpmdd/master.
> 
> Changes in v5:
> 1. Drop dynamic detection of trust source and use compile time flags
>    instead.
> 2. Rename trusted_common.c -> trusted_core.c.
> 3. Rename callback: cleanup() -> exit().
> 4. Drop "tk" acronym.
> 5. Other misc. comments.
> 6. Added review tags for patch #3 and #4.
> 
> Changes in v4:
> 1. Pushed independent TEE features separately:
>   - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062
> 2. Updated trusted-encrypted doc with TEE as a new trust source.
> 3. Rebased onto latest tpmdd/master.
> 
> Changes in v3:
> 1. Update patch #2 to support registration of multiple kernel pages.
> 2. Incoporate dependency patch #4 in this patch-set:
>    https://patchwork.kernel.org/patch/11091435/
> 
> Changes in v2:
> 1. Add reviewed-by tags for patch #1 and #2.
> 2. Incorporate comments from Jens for patch #3.
> 3. Switch to use generic trusted keys framework.
> 
> Sumit Garg (4):
>   KEYS: trusted: Add generic trusted keys framework
>   KEYS: trusted: Introduce TEE based Trusted Keys
>   doc: trusted-encrypted: updates with TEE as a new trust source
>   MAINTAINERS: Add myself as Trusted Keys co-maintainer
> 
>  Documentation/admin-guide/kernel-parameters.txt   |  12 +
>  Documentation/security/keys/trusted-encrypted.rst | 203 +++++++++++--
>  MAINTAINERS                                       |   2 +
>  include/keys/trusted-type.h                       |  47 +++
>  include/keys/trusted_tee.h                        |  55 ++++
>  include/keys/trusted_tpm.h                        |  17 +-
>  security/keys/trusted-keys/Makefile               |   2 +
>  security/keys/trusted-keys/trusted_core.c         | 354 ++++++++++++++++++++++
>  security/keys/trusted-keys/trusted_tee.c          | 278 +++++++++++++++++
>  security/keys/trusted-keys/trusted_tpm1.c         | 336 ++++----------------
>  10 files changed, 979 insertions(+), 327 deletions(-)
>  create mode 100644 include/keys/trusted_tee.h
>  create mode 100644 security/keys/trusted-keys/trusted_core.c
>  create mode 100644 security/keys/trusted-keys/trusted_tee.c
> 
> -- 
> 2.7.4
> 
> 

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

* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support
  2020-11-05  5:07 ` [PATCH v8 0/4] Introduce TEE based Trusted Keys support Jarkko Sakkinen
@ 2020-11-06  9:32   ` Sumit Garg
  2020-11-06 14:52     ` Jarkko Sakkinen
  0 siblings, 1 reply; 52+ messages in thread
From: Sumit Garg @ 2020-11-06  9:32 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Thu, 5 Nov 2020 at 10:37, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote:
> > Add support for TEE based trusted keys where TEE provides the functionality
> > to seal and unseal trusted keys using hardware unique key. Also, this is
> > an alternative in case platform doesn't possess a TPM device.
> >
> > This patch-set has been tested with OP-TEE based early TA which is already
> > merged in upstream [1].
>
> Is the new RPI400 computer a platform that can be used for testing
> patch sets like this? I've been looking for a while something ARM64
> based with similar convenience as Intel NUC's, and on the surface
> this new RPI product looks great for kernel testing purposes.

Here [1] is the list of supported versions of Raspberry Pi in OP-TEE.
The easiest approach would be to pick up a supported version or else
do an OP-TEE port for an unsupported one (which should involve minimal
effort).

[1] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#what-versions-of-raspberry-pi-will-work

-Sumit

>
> /Jarkko
>
> >
> > [1] https://github.com/OP-TEE/optee_os/commit/f86ab8e7e0de869dfa25ca05a37ee070d7e5b86b
> >
> > Changes in v8:
> > 1. Added static calls support instead of indirect calls.
> > 2. Documented trusted keys source module parameter.
> > 3. Refined patch #1 commit message discription.
> > 4. Addressed misc. comments on patch #2.
> > 5. Added myself as Trusted Keys co-maintainer instead.
> > 6. Rebased to latest tpmdd master.
> >
> > Changes in v7:
> > 1. Added a trusted.source module parameter in order to enforce user's
> >    choice in case a particular platform posses both TPM and TEE.
> > 2. Refine commit description for patch #1.
> >
> > Changes in v6:
> > 1. Revert back to dynamic detection of trust source.
> > 2. Drop author mention from trusted_core.c and trusted_tpm1.c files.
> > 3. Rebased to latest tpmdd/master.
> >
> > Changes in v5:
> > 1. Drop dynamic detection of trust source and use compile time flags
> >    instead.
> > 2. Rename trusted_common.c -> trusted_core.c.
> > 3. Rename callback: cleanup() -> exit().
> > 4. Drop "tk" acronym.
> > 5. Other misc. comments.
> > 6. Added review tags for patch #3 and #4.
> >
> > Changes in v4:
> > 1. Pushed independent TEE features separately:
> >   - Part of recent TEE PR: https://lkml.org/lkml/2020/5/4/1062
> > 2. Updated trusted-encrypted doc with TEE as a new trust source.
> > 3. Rebased onto latest tpmdd/master.
> >
> > Changes in v3:
> > 1. Update patch #2 to support registration of multiple kernel pages.
> > 2. Incoporate dependency patch #4 in this patch-set:
> >    https://patchwork.kernel.org/patch/11091435/
> >
> > Changes in v2:
> > 1. Add reviewed-by tags for patch #1 and #2.
> > 2. Incorporate comments from Jens for patch #3.
> > 3. Switch to use generic trusted keys framework.
> >
> > Sumit Garg (4):
> >   KEYS: trusted: Add generic trusted keys framework
> >   KEYS: trusted: Introduce TEE based Trusted Keys
> >   doc: trusted-encrypted: updates with TEE as a new trust source
> >   MAINTAINERS: Add myself as Trusted Keys co-maintainer
> >
> >  Documentation/admin-guide/kernel-parameters.txt   |  12 +
> >  Documentation/security/keys/trusted-encrypted.rst | 203 +++++++++++--
> >  MAINTAINERS                                       |   2 +
> >  include/keys/trusted-type.h                       |  47 +++
> >  include/keys/trusted_tee.h                        |  55 ++++
> >  include/keys/trusted_tpm.h                        |  17 +-
> >  security/keys/trusted-keys/Makefile               |   2 +
> >  security/keys/trusted-keys/trusted_core.c         | 354 ++++++++++++++++++++++
> >  security/keys/trusted-keys/trusted_tee.c          | 278 +++++++++++++++++
> >  security/keys/trusted-keys/trusted_tpm1.c         | 336 ++++----------------
> >  10 files changed, 979 insertions(+), 327 deletions(-)
> >  create mode 100644 include/keys/trusted_tee.h
> >  create mode 100644 security/keys/trusted-keys/trusted_core.c
> >  create mode 100644 security/keys/trusted-keys/trusted_tee.c
> >
> > --
> > 2.7.4
> >
> >

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

* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support
  2020-11-06  9:32   ` Sumit Garg
@ 2020-11-06 14:52     ` Jarkko Sakkinen
  2020-12-04  5:16       ` Jarkko Sakkinen
  0 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2020-11-06 14:52 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Fri, Nov 06, 2020 at 03:02:41PM +0530, Sumit Garg wrote:
> On Thu, 5 Nov 2020 at 10:37, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote:
> > > Add support for TEE based trusted keys where TEE provides the functionality
> > > to seal and unseal trusted keys using hardware unique key. Also, this is
> > > an alternative in case platform doesn't possess a TPM device.
> > >
> > > This patch-set has been tested with OP-TEE based early TA which is already
> > > merged in upstream [1].
> >
> > Is the new RPI400 computer a platform that can be used for testing
> > patch sets like this? I've been looking for a while something ARM64
> > based with similar convenience as Intel NUC's, and on the surface
> > this new RPI product looks great for kernel testing purposes.
> 
> Here [1] is the list of supported versions of Raspberry Pi in OP-TEE.
> The easiest approach would be to pick up a supported version or else
> do an OP-TEE port for an unsupported one (which should involve minimal
> effort).
> 
> [1] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#what-versions-of-raspberry-pi-will-work
> 
> -Sumit

If porting is doable, then I'll just order RPI 400, and test with QEMU
up until either I port OP-TEE myself or someone else does it.

For seldom ARM testing, RPI 400 is really convenient device with its
boxed form factor.

/Jarkko

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

* Re: [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework
  2020-11-03 16:01 ` [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework Sumit Garg
@ 2020-11-24  3:42   ` Jarkko Sakkinen
  2021-02-15 13:13     ` Sumit Garg
  2021-02-10 17:00   ` Jarkko Sakkinen
  1 sibling, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2020-11-24  3:42 UTC (permalink / raw)
  To: Sumit Garg
  Cc: jarkko.sakkinen, zohar, jejb, dhowells, jens.wiklander, corbet,
	jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee

On Tue, Nov 03, 2020 at 09:31:43PM +0530, Sumit Garg wrote:
> Current trusted keys framework is tightly coupled to use TPM device as
> an underlying implementation which makes it difficult for implementations
> like Trusted Execution Environment (TEE) etc. to provide trusted keys
> support in case platform doesn't posses a TPM device.
> 
> Add a generic trusted keys framework where underlying implementations
> can be easily plugged in. Create struct trusted_key_ops to achieve this,
> which contains necessary functions of a backend.
> 
> Also, define a module parameter in order to select a particular trust
> source in case a platform support multiple trust sources. In case its
> not specified then implementation itetrates through trust sources list
> starting with TPM and assign the first trust source as a backend which
> has initiazed successfully during iteration.
> 
> Note that current implementation only supports a single trust source at
> runtime which is either selectable at compile time or during boot via
> aforementioned module parameter.
> 
> Suggested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  Documentation/admin-guide/kernel-parameters.txt |  12 +
>  include/keys/trusted-type.h                     |  47 ++++



>  include/keys/trusted_tpm.h                      |  17 +-
>  security/keys/trusted-keys/Makefile             |   1 +
>  security/keys/trusted-keys/trusted_core.c       | 350 ++++++++++++++++++++++++
>  security/keys/trusted-keys/trusted_tpm1.c       | 336 ++++-------------------
>  6 files changed, 468 insertions(+), 295 deletions(-)
>  create mode 100644 security/keys/trusted-keys/trusted_core.c
> 
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 526d65d..df9b9fe 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -5392,6 +5392,18 @@
>  			See Documentation/admin-guide/mm/transhuge.rst
>  			for more details.
>  
> +	trusted.source=	[KEYS]
> +			Format: <string>
> +			This parameter identifies the trust source as a backend
> +			for trusted keys implementation. Supported trust
> +			sources:
> +			- "tpm"
> +			- "tee"
> +			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
> +			successfully during iteration.
> +
>  	tsc=		Disable clocksource stability checks for TSC.
>  			Format: <string>
>  			[x86] reliable: mark tsc clocksource as reliable, this
> diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> index a94c03a..a566451 100644
> --- a/include/keys/trusted-type.h
> +++ b/include/keys/trusted-type.h
> @@ -40,6 +40,53 @@ struct trusted_key_options {
>  	uint32_t policyhandle;
>  };
>  
> +struct trusted_key_ops {
> +	/*
> +	 * flag to indicate if trusted key implementation supports migration
> +	 * or not.
> +	 */
> +	unsigned char migratable;
> +
> +	/* Initialize key interface. */
> +	int (*init)(void);
> +
> +	/* Seal a key. */
> +	int (*seal)(struct trusted_key_payload *p, char *datablob);
> +
> +	/* Unseal a key. */
> +	int (*unseal)(struct trusted_key_payload *p, char *datablob);
> +
> +	/* Get a randomized key. */
> +	int (*get_random)(unsigned char *key, size_t key_len);
> +
> +	/* Exit key interface. */
> +	void (*exit)(void);
> +};
> +
> +struct trusted_key_source {
> +	char *name;
> +	struct trusted_key_ops *ops;
> +};
> +
>  extern struct key_type key_type_trusted;
>  
> +#define TRUSTED_DEBUG 0
> +
> +#if TRUSTED_DEBUG
> +static inline void dump_payload(struct trusted_key_payload *p)
> +{
> +	pr_info("trusted_key: key_len %d\n", p->key_len);
> +	print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
> +		       16, 1, p->key, p->key_len, 0);
> +	pr_info("trusted_key: bloblen %d\n", p->blob_len);
> +	print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
> +		       16, 1, p->blob, p->blob_len, 0);
> +	pr_info("trusted_key: migratable %d\n", p->migratable);
> +}
> +#else
> +static inline void dump_payload(struct trusted_key_payload *p)
> +{
> +}
> +#endif
> +
>  #endif /* _KEYS_TRUSTED_TYPE_H */
> diff --git a/include/keys/trusted_tpm.h b/include/keys/trusted_tpm.h
> index a56d8e1..fb3280a 100644
> --- a/include/keys/trusted_tpm.h
> +++ b/include/keys/trusted_tpm.h
> @@ -16,6 +16,8 @@
>  #define LOAD32N(buffer, offset)	(*(uint32_t *)&buffer[offset])
>  #define LOAD16(buffer, offset)	(ntohs(*(uint16_t *)&buffer[offset]))
>  
> +extern struct trusted_key_ops tpm_trusted_key_ops;
> +
>  struct osapsess {
>  	uint32_t handle;
>  	unsigned char secret[SHA1_DIGEST_SIZE];
> @@ -60,17 +62,6 @@ static inline void dump_options(struct trusted_key_options *o)
>  		       16, 1, o->pcrinfo, o->pcrinfo_len, 0);
>  }
>  
> -static inline void dump_payload(struct trusted_key_payload *p)
> -{
> -	pr_info("trusted_key: key_len %d\n", p->key_len);
> -	print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
> -		       16, 1, p->key, p->key_len, 0);
> -	pr_info("trusted_key: bloblen %d\n", p->blob_len);
> -	print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
> -		       16, 1, p->blob, p->blob_len, 0);
> -	pr_info("trusted_key: migratable %d\n", p->migratable);
> -}
> -
>  static inline void dump_sess(struct osapsess *s)
>  {
>  	print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
> @@ -96,10 +87,6 @@ static inline void dump_options(struct trusted_key_options *o)
>  {
>  }
>  
> -static inline void dump_payload(struct trusted_key_payload *p)
> -{
> -}
> -
>  static inline void dump_sess(struct osapsess *s)
>  {
>  }
> diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
> index 7b73ceb..49e3bcf 100644
> --- a/security/keys/trusted-keys/Makefile
> +++ b/security/keys/trusted-keys/Makefile
> @@ -4,5 +4,6 @@
>  #
>  
>  obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
> +trusted-y += trusted_core.o
>  trusted-y += trusted_tpm1.o
>  trusted-y += trusted_tpm2.o
> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> new file mode 100644
> index 0000000..aa4f2a0
> --- /dev/null
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -0,0 +1,350 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2010 IBM Corporation
> + * Copyright (c) 2019-2020, Linaro Limited
> + *
> + * See Documentation/security/keys/trusted-encrypted.rst
> + */
> +
> +#include <keys/user-type.h>
> +#include <keys/trusted-type.h>
> +#include <keys/trusted_tpm.h>
> +#include <linux/capability.h>
> +#include <linux/err.h>
> +#include <linux/init.h>
> +#include <linux/key-type.h>
> +#include <linux/module.h>
> +#include <linux/parser.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_key_source;
> +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 defined(CONFIG_TCG_TPM)
> +	{ "tpm", &tpm_trusted_key_ops },
> +#endif
> +};
> +
> +DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
> +DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal);
> +DEFINE_STATIC_CALL_NULL(trusted_key_unseal,
> +			*trusted_key_sources[0].ops->unseal);
> +DEFINE_STATIC_CALL_NULL(trusted_key_get_random,
> +			*trusted_key_sources[0].ops->get_random);
> +DEFINE_STATIC_CALL_NULL(trusted_key_exit, *trusted_key_sources[0].ops->exit);
> +static unsigned char migratable;
> +
> +enum {
> +	Opt_err,
> +	Opt_new, Opt_load, Opt_update,
> +};
> +
> +static const match_table_t key_tokens = {
> +	{Opt_new, "new"},
> +	{Opt_load, "load"},
> +	{Opt_update, "update"},
> +	{Opt_err, NULL}
> +};
> +
> +/*
> + * datablob_parse - parse the keyctl data and fill in the
> + *                  payload structure
> + *
> + * On success returns 0, otherwise -EINVAL.
> + */
> +static int datablob_parse(char *datablob, struct trusted_key_payload *p)
> +{
> +	substring_t args[MAX_OPT_ARGS];
> +	long keylen;
> +	int ret = -EINVAL;
> +	int key_cmd;
> +	char *c;
> +
> +	/* main command */
> +	c = strsep(&datablob, " \t");
> +	if (!c)
> +		return -EINVAL;
> +	key_cmd = match_token(c, key_tokens, args);
> +	switch (key_cmd) {
> +	case Opt_new:
> +		/* first argument is key size */
> +		c = strsep(&datablob, " \t");
> +		if (!c)
> +			return -EINVAL;
> +		ret = kstrtol(c, 10, &keylen);
> +		if (ret < 0 || keylen < MIN_KEY_SIZE || keylen > MAX_KEY_SIZE)
> +			return -EINVAL;
> +		p->key_len = keylen;
> +		ret = Opt_new;
> +		break;
> +	case Opt_load:
> +		/* first argument is sealed blob */
> +		c = strsep(&datablob, " \t");
> +		if (!c)
> +			return -EINVAL;
> +		p->blob_len = strlen(c) / 2;
> +		if (p->blob_len > MAX_BLOB_SIZE)
> +			return -EINVAL;
> +		ret = hex2bin(p->blob, c, p->blob_len);
> +		if (ret < 0)
> +			return -EINVAL;
> +		ret = Opt_load;
> +		break;
> +	case Opt_update:
> +		ret = Opt_update;
> +		break;
> +	case Opt_err:
> +		return -EINVAL;
> +	}
> +	return ret;
> +}
> +
> +static struct trusted_key_payload *trusted_payload_alloc(struct key *key)
> +{
> +	struct trusted_key_payload *p = NULL;
> +	int ret;
> +
> +	ret = key_payload_reserve(key, sizeof(*p));
> +	if (ret < 0)
> +		return p;
> +	p = kzalloc(sizeof(*p), GFP_KERNEL);
> +
> +	p->migratable = migratable;
> +
> +	return p;
> +}
> +
> +/*
> + * trusted_instantiate - create a new trusted key
> + *
> + * Unseal an existing trusted blob or, for a new key, get a
> + * random key, then seal and create a trusted key-type key,
> + * adding it to the specified keyring.
> + *
> + * On success, return 0. Otherwise return errno.
> + */
> +static int trusted_instantiate(struct key *key,
> +			       struct key_preparsed_payload *prep)
> +{
> +	struct trusted_key_payload *payload = NULL;
> +	size_t datalen = prep->datalen;
> +	char *datablob;
> +	int ret = 0;
> +	int key_cmd;
> +	size_t key_len;
> +
> +	if (datalen <= 0 || datalen > 32767 || !prep->data)
> +		return -EINVAL;
> +
> +	datablob = kmalloc(datalen + 1, GFP_KERNEL);
> +	if (!datablob)
> +		return -ENOMEM;
> +	memcpy(datablob, prep->data, datalen);
> +	datablob[datalen] = '\0';
> +
> +	payload = trusted_payload_alloc(key);
> +	if (!payload) {
> +		ret = -ENOMEM;
> +		goto out;
> +	}
> +
> +	key_cmd = datablob_parse(datablob, payload);
> +	if (key_cmd < 0) {
> +		ret = key_cmd;
> +		goto out;
> +	}
> +
> +	dump_payload(payload);
> +
> +	switch (key_cmd) {
> +	case Opt_load:
> +		ret = static_call(trusted_key_unseal)(payload, datablob);
> +		dump_payload(payload);
> +		if (ret < 0)
> +			pr_info("trusted_key: key_unseal failed (%d)\n", ret);
> +		break;
> +	case Opt_new:
> +		key_len = payload->key_len;
> +		ret = static_call(trusted_key_get_random)(payload->key,
> +							  key_len);
> +		if (ret != key_len) {
> +			pr_info("trusted_key: key_create failed (%d)\n", ret);
> +			goto out;
> +		}
> +
> +		ret = static_call(trusted_key_seal)(payload, datablob);
> +		if (ret < 0)
> +			pr_info("trusted_key: key_seal failed (%d)\n", ret);
> +		break;
> +	default:
> +		ret = -EINVAL;
> +	}
> +out:
> +	kfree_sensitive(datablob);
> +	if (!ret)
> +		rcu_assign_keypointer(key, payload);
> +	else
> +		kfree_sensitive(payload);
> +	return ret;
> +}
> +
> +static void trusted_rcu_free(struct rcu_head *rcu)
> +{
> +	struct trusted_key_payload *p;
> +
> +	p = container_of(rcu, struct trusted_key_payload, rcu);
> +	kfree_sensitive(p);
> +}
> +
> +/*
> + * trusted_update - reseal an existing key with new PCR values
> + */
> +static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
> +{
> +	struct trusted_key_payload *p;
> +	struct trusted_key_payload *new_p;
> +	size_t datalen = prep->datalen;
> +	char *datablob;
> +	int ret = 0;
> +
> +	if (key_is_negative(key))
> +		return -ENOKEY;
> +	p = key->payload.data[0];
> +	if (!p->migratable)
> +		return -EPERM;
> +	if (datalen <= 0 || datalen > 32767 || !prep->data)
> +		return -EINVAL;
> +
> +	datablob = kmalloc(datalen + 1, GFP_KERNEL);
> +	if (!datablob)
> +		return -ENOMEM;
> +
> +	new_p = trusted_payload_alloc(key);
> +	if (!new_p) {
> +		ret = -ENOMEM;
> +		goto out;
> +	}
> +
> +	memcpy(datablob, prep->data, datalen);
> +	datablob[datalen] = '\0';
> +	ret = datablob_parse(datablob, new_p);
> +	if (ret != Opt_update) {
> +		ret = -EINVAL;
> +		kfree_sensitive(new_p);
> +		goto out;
> +	}
> +
> +	/* copy old key values, and reseal with new pcrs */
> +	new_p->migratable = p->migratable;
> +	new_p->key_len = p->key_len;
> +	memcpy(new_p->key, p->key, p->key_len);
> +	dump_payload(p);
> +	dump_payload(new_p);
> +
> +	ret = static_call(trusted_key_seal)(new_p, datablob);
> +	if (ret < 0) {
> +		pr_info("trusted_key: key_seal failed (%d)\n", ret);
> +		kfree_sensitive(new_p);
> +		goto out;
> +	}
> +
> +	rcu_assign_keypointer(key, new_p);
> +	call_rcu(&p->rcu, trusted_rcu_free);
> +out:
> +	kfree_sensitive(datablob);
> +	return ret;
> +}
> +
> +/*
> + * trusted_read - copy the sealed blob data to userspace in hex.
> + * On success, return to userspace the trusted key datablob size.
> + */
> +static long trusted_read(const struct key *key, char *buffer,
> +			 size_t buflen)
> +{
> +	const struct trusted_key_payload *p;
> +	char *bufp;
> +	int i;
> +
> +	p = dereference_key_locked(key);
> +	if (!p)
> +		return -EINVAL;
> +
> +	if (buffer && buflen >= 2 * p->blob_len) {
> +		bufp = buffer;
> +		for (i = 0; i < p->blob_len; i++)
> +			bufp = hex_byte_pack(bufp, p->blob[i]);
> +	}
> +	return 2 * p->blob_len;
> +}
> +
> +/*
> + * trusted_destroy - clear and free the key's payload
> + */
> +static void trusted_destroy(struct key *key)
> +{
> +	kfree_sensitive(key->payload.data[0]);
> +}
> +
> +struct key_type key_type_trusted = {
> +	.name = "trusted",
> +	.instantiate = trusted_instantiate,
> +	.update = trusted_update,
> +	.destroy = trusted_destroy,
> +	.describe = user_describe,
> +	.read = trusted_read,
> +};
> +EXPORT_SYMBOL_GPL(key_type_trusted);
> +
> +static int __init init_trusted(void)
> +{
> +	int i, ret = 0;
> +
> +	for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) {
> +		if (trusted_key_source &&
> +		    strncmp(trusted_key_source, trusted_key_sources[i].name,
> +			    strlen(trusted_key_sources[i].name)))
> +			continue;
> +
> +		static_call_update(trusted_key_init,
> +				   trusted_key_sources[i].ops->init);
> +		static_call_update(trusted_key_seal,
> +				   trusted_key_sources[i].ops->seal);
> +		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);
> +		static_call_update(trusted_key_exit,
> +				   trusted_key_sources[i].ops->exit);
> +		migratable = trusted_key_sources[i].ops->migratable;
> +
> +		ret = static_call(trusted_key_init)();
> +		if (!ret)
> +			break;
> +	}
> +
> +	/*
> +	 * encrypted_keys.ko depends on successful load of this module even if
> +	 * trusted key implementation is not found.
> +	 */
> +	if (ret == -ENODEV)
> +		return 0;
> +
> +	return ret;
> +}
> +
> +static void __exit cleanup_trusted(void)
> +{
> +	static_call(trusted_key_exit)();
> +}
> +
> +late_initcall(init_trusted);
> +module_exit(cleanup_trusted);
> +
> +MODULE_LICENSE("GPL");
> diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> index b9fe02e..bd03914 100644
> --- a/security/keys/trusted-keys/trusted_tpm1.c
> +++ b/security/keys/trusted-keys/trusted_tpm1.c
> @@ -1,29 +1,22 @@
>  // SPDX-License-Identifier: GPL-2.0-only
>  /*
>   * Copyright (C) 2010 IBM Corporation
> - *
> - * Author:
> - * David Safford <safford@us.ibm.com>
> + * Copyright (c) 2019-2020, Linaro Limited
>   *
>   * See Documentation/security/keys/trusted-encrypted.rst
>   */
>  
>  #include <crypto/hash_info.h>
> -#include <linux/uaccess.h>
> -#include <linux/module.h>
>  #include <linux/init.h>
>  #include <linux/slab.h>
>  #include <linux/parser.h>
>  #include <linux/string.h>
>  #include <linux/err.h>
> -#include <keys/user-type.h>
>  #include <keys/trusted-type.h>
>  #include <linux/key-type.h>
> -#include <linux/rcupdate.h>
>  #include <linux/crypto.h>
>  #include <crypto/hash.h>
>  #include <crypto/sha.h>
> -#include <linux/capability.h>
>  #include <linux/tpm.h>
>  #include <linux/tpm_command.h>
>  
> @@ -703,7 +696,6 @@ static int key_unseal(struct trusted_key_payload *p,
>  
>  enum {
>  	Opt_err,
> -	Opt_new, Opt_load, Opt_update,
>  	Opt_keyhandle, Opt_keyauth, Opt_blobauth,
>  	Opt_pcrinfo, Opt_pcrlock, Opt_migratable,
>  	Opt_hash,
> @@ -712,9 +704,6 @@ enum {
>  };
>  
>  static const match_table_t key_tokens = {
> -	{Opt_new, "new"},
> -	{Opt_load, "load"},
> -	{Opt_update, "update"},
>  	{Opt_keyhandle, "keyhandle=%s"},
>  	{Opt_keyauth, "keyauth=%s"},
>  	{Opt_blobauth, "blobauth=%s"},
> @@ -841,71 +830,6 @@ static int getoptions(char *c, struct trusted_key_payload *pay,
>  	return 0;
>  }
>  
> -/*
> - * datablob_parse - parse the keyctl data and fill in the
> - * 		    payload and options structures
> - *
> - * On success returns 0, otherwise -EINVAL.
> - */
> -static int datablob_parse(char *datablob, struct trusted_key_payload *p,
> -			  struct trusted_key_options *o)
> -{
> -	substring_t args[MAX_OPT_ARGS];
> -	long keylen;
> -	int ret = -EINVAL;
> -	int key_cmd;
> -	char *c;
> -
> -	/* main command */
> -	c = strsep(&datablob, " \t");
> -	if (!c)
> -		return -EINVAL;
> -	key_cmd = match_token(c, key_tokens, args);
> -	switch (key_cmd) {
> -	case Opt_new:
> -		/* first argument is key size */
> -		c = strsep(&datablob, " \t");
> -		if (!c)
> -			return -EINVAL;
> -		ret = kstrtol(c, 10, &keylen);
> -		if (ret < 0 || keylen < MIN_KEY_SIZE || keylen > MAX_KEY_SIZE)
> -			return -EINVAL;
> -		p->key_len = keylen;
> -		ret = getoptions(datablob, p, o);
> -		if (ret < 0)
> -			return ret;
> -		ret = Opt_new;
> -		break;
> -	case Opt_load:
> -		/* first argument is sealed blob */
> -		c = strsep(&datablob, " \t");
> -		if (!c)
> -			return -EINVAL;
> -		p->blob_len = strlen(c) / 2;
> -		if (p->blob_len > MAX_BLOB_SIZE)
> -			return -EINVAL;
> -		ret = hex2bin(p->blob, c, p->blob_len);
> -		if (ret < 0)
> -			return -EINVAL;
> -		ret = getoptions(datablob, p, o);
> -		if (ret < 0)
> -			return ret;
> -		ret = Opt_load;
> -		break;
> -	case Opt_update:
> -		/* all arguments are options */
> -		ret = getoptions(datablob, p, o);
> -		if (ret < 0)
> -			return ret;
> -		ret = Opt_update;
> -		break;
> -	case Opt_err:
> -		return -EINVAL;
> -		break;
> -	}
> -	return ret;
> -}
> -
>  static struct trusted_key_options *trusted_options_alloc(void)
>  {
>  	struct trusted_key_options *options;
> @@ -926,248 +850,99 @@ static struct trusted_key_options *trusted_options_alloc(void)
>  	return options;
>  }
>  
> -static struct trusted_key_payload *trusted_payload_alloc(struct key *key)
> +static int trusted_tpm_seal(struct trusted_key_payload *p, char *datablob)
>  {
> -	struct trusted_key_payload *p = NULL;
> -	int ret;
> -
> -	ret = key_payload_reserve(key, sizeof *p);
> -	if (ret < 0)
> -		return p;
> -	p = kzalloc(sizeof *p, GFP_KERNEL);
> -	if (p)
> -		p->migratable = 1; /* migratable by default */
> -	return p;
> -}
> -
> -/*
> - * trusted_instantiate - create a new trusted key
> - *
> - * Unseal an existing trusted blob or, for a new key, get a
> - * random key, then seal and create a trusted key-type key,
> - * adding it to the specified keyring.
> - *
> - * On success, return 0. Otherwise return errno.
> - */
> -static int trusted_instantiate(struct key *key,
> -			       struct key_preparsed_payload *prep)
> -{
> -	struct trusted_key_payload *payload = NULL;
>  	struct trusted_key_options *options = NULL;
> -	size_t datalen = prep->datalen;
> -	char *datablob;
>  	int ret = 0;
> -	int key_cmd;
> -	size_t key_len;
>  	int tpm2;
>  
>  	tpm2 = tpm_is_tpm2(chip);
>  	if (tpm2 < 0)
>  		return tpm2;
>  
> -	if (datalen <= 0 || datalen > 32767 || !prep->data)
> -		return -EINVAL;
> -
> -	datablob = kmalloc(datalen + 1, GFP_KERNEL);
> -	if (!datablob)
> -		return -ENOMEM;
> -	memcpy(datablob, prep->data, datalen);
> -	datablob[datalen] = '\0';
> -
>  	options = trusted_options_alloc();
> -	if (!options) {
> -		ret = -ENOMEM;
> -		goto out;
> -	}
> -	payload = trusted_payload_alloc(key);
> -	if (!payload) {
> -		ret = -ENOMEM;
> -		goto out;
> -	}
> +	if (!options)
> +		return -ENOMEM;
>  
> -	key_cmd = datablob_parse(datablob, payload, options);
> -	if (key_cmd < 0) {
> -		ret = key_cmd;
> +	ret = getoptions(datablob, p, options);
> +	if (ret < 0)
>  		goto out;
> -	}
> +	dump_options(options);
>  
>  	if (!options->keyhandle) {
>  		ret = -EINVAL;
>  		goto out;
>  	}
>  
> -	dump_payload(payload);
> -	dump_options(options);
> +	if (tpm2)
> +		ret = tpm2_seal_trusted(chip, p, options);
> +	else
> +		ret = key_seal(p, options);
> +	if (ret < 0) {
> +		pr_info("tpm_trusted_key: key_seal failed (%d)\n", ret);
> +		goto out;
> +	}
>  
> -	switch (key_cmd) {
> -	case Opt_load:
> -		if (tpm2)
> -			ret = tpm2_unseal_trusted(chip, payload, options);
> -		else
> -			ret = key_unseal(payload, options);
> -		dump_payload(payload);
> -		dump_options(options);
> -		if (ret < 0)
> -			pr_info("trusted_key: key_unseal failed (%d)\n", ret);
> -		break;
> -	case Opt_new:
> -		key_len = payload->key_len;
> -		ret = tpm_get_random(chip, payload->key, key_len);
> -		if (ret != key_len) {
> -			pr_info("trusted_key: key_create failed (%d)\n", ret);
> +	if (options->pcrlock) {
> +		ret = pcrlock(options->pcrlock);
> +		if (ret < 0) {
> +			pr_info("tpm_trusted_key: pcrlock failed (%d)\n", ret);
>  			goto out;
>  		}
> -		if (tpm2)
> -			ret = tpm2_seal_trusted(chip, payload, options);
> -		else
> -			ret = key_seal(payload, options);
> -		if (ret < 0)
> -			pr_info("trusted_key: key_seal failed (%d)\n", ret);
> -		break;
> -	default:
> -		ret = -EINVAL;
> -		goto out;
>  	}
> -	if (!ret && options->pcrlock)
> -		ret = pcrlock(options->pcrlock);
>  out:
> -	kfree_sensitive(datablob);
>  	kfree_sensitive(options);
> -	if (!ret)
> -		rcu_assign_keypointer(key, payload);
> -	else
> -		kfree_sensitive(payload);
>  	return ret;
>  }
>  
> -static void trusted_rcu_free(struct rcu_head *rcu)
> -{
> -	struct trusted_key_payload *p;
> -
> -	p = container_of(rcu, struct trusted_key_payload, rcu);
> -	kfree_sensitive(p);
> -}
> -
> -/*
> - * trusted_update - reseal an existing key with new PCR values
> - */
> -static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
> +static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
>  {
> -	struct trusted_key_payload *p;
> -	struct trusted_key_payload *new_p;
> -	struct trusted_key_options *new_o;
> -	size_t datalen = prep->datalen;
> -	char *datablob;
> +	struct trusted_key_options *options = NULL;
>  	int ret = 0;
> +	int tpm2;
>  
> -	if (key_is_negative(key))
> -		return -ENOKEY;
> -	p = key->payload.data[0];
> -	if (!p->migratable)
> -		return -EPERM;
> -	if (datalen <= 0 || datalen > 32767 || !prep->data)
> -		return -EINVAL;
> +	tpm2 = tpm_is_tpm2(chip);
> +	if (tpm2 < 0)
> +		return tpm2;
>  
> -	datablob = kmalloc(datalen + 1, GFP_KERNEL);
> -	if (!datablob)
> +	options = trusted_options_alloc();
> +	if (!options)
>  		return -ENOMEM;
> -	new_o = trusted_options_alloc();
> -	if (!new_o) {
> -		ret = -ENOMEM;
> -		goto out;
> -	}
> -	new_p = trusted_payload_alloc(key);
> -	if (!new_p) {
> -		ret = -ENOMEM;
> -		goto out;
> -	}
>  
> -	memcpy(datablob, prep->data, datalen);
> -	datablob[datalen] = '\0';
> -	ret = datablob_parse(datablob, new_p, new_o);
> -	if (ret != Opt_update) {
> -		ret = -EINVAL;
> -		kfree_sensitive(new_p);
> +	ret = getoptions(datablob, p, options);
> +	if (ret < 0)
>  		goto out;
> -	}
> +	dump_options(options);
>  
> -	if (!new_o->keyhandle) {
> +	if (!options->keyhandle) {
>  		ret = -EINVAL;
> -		kfree_sensitive(new_p);
>  		goto out;
>  	}
>  
> -	/* copy old key values, and reseal with new pcrs */
> -	new_p->migratable = p->migratable;
> -	new_p->key_len = p->key_len;
> -	memcpy(new_p->key, p->key, p->key_len);
> -	dump_payload(p);
> -	dump_payload(new_p);
> +	if (tpm2)
> +		ret = tpm2_unseal_trusted(chip, p, options);
> +	else
> +		ret = key_unseal(p, options);
> +	if (ret < 0)
> +		pr_info("tpm_trusted_key: key_unseal failed (%d)\n", ret);
>  
> -	ret = key_seal(new_p, new_o);
> -	if (ret < 0) {
> -		pr_info("trusted_key: key_seal failed (%d)\n", ret);
> -		kfree_sensitive(new_p);
> -		goto out;
> -	}
> -	if (new_o->pcrlock) {
> -		ret = pcrlock(new_o->pcrlock);
> +	if (options->pcrlock) {
> +		ret = pcrlock(options->pcrlock);
>  		if (ret < 0) {
> -			pr_info("trusted_key: pcrlock failed (%d)\n", ret);
> -			kfree_sensitive(new_p);
> +			pr_info("tpm_trusted_key: pcrlock failed (%d)\n", ret);
>  			goto out;
>  		}
>  	}
> -	rcu_assign_keypointer(key, new_p);
> -	call_rcu(&p->rcu, trusted_rcu_free);
>  out:
> -	kfree_sensitive(datablob);
> -	kfree_sensitive(new_o);
> +	kfree_sensitive(options);
>  	return ret;
>  }
>  
> -/*
> - * trusted_read - copy the sealed blob data to userspace in hex.
> - * On success, return to userspace the trusted key datablob size.
> - */
> -static long trusted_read(const struct key *key, char *buffer,
> -			 size_t buflen)
> -{
> -	const struct trusted_key_payload *p;
> -	char *bufp;
> -	int i;
> -
> -	p = dereference_key_locked(key);
> -	if (!p)
> -		return -EINVAL;
> -
> -	if (buffer && buflen >= 2 * p->blob_len) {
> -		bufp = buffer;
> -		for (i = 0; i < p->blob_len; i++)
> -			bufp = hex_byte_pack(bufp, p->blob[i]);
> -	}
> -	return 2 * p->blob_len;
> -}
> -
> -/*
> - * trusted_destroy - clear and free the key's payload
> - */
> -static void trusted_destroy(struct key *key)
> +static int trusted_tpm_get_random(unsigned char *key, size_t key_len)
>  {
> -	kfree_sensitive(key->payload.data[0]);
> +	return tpm_get_random(chip, key, key_len);
>  }
>  
> -struct key_type key_type_trusted = {
> -	.name = "trusted",
> -	.instantiate = trusted_instantiate,
> -	.update = trusted_update,
> -	.destroy = trusted_destroy,
> -	.describe = user_describe,
> -	.read = trusted_read,
> -};
> -
> -EXPORT_SYMBOL_GPL(key_type_trusted);
> -
>  static void trusted_shash_release(void)
>  {
>  	if (hashalg)
> @@ -1182,14 +957,14 @@ static int __init trusted_shash_alloc(void)
>  
>  	hmacalg = crypto_alloc_shash(hmac_alg, 0, 0);
>  	if (IS_ERR(hmacalg)) {
> -		pr_info("trusted_key: could not allocate crypto %s\n",
> +		pr_info("tpm_trusted_key: could not allocate crypto %s\n",
>  			hmac_alg);
>  		return PTR_ERR(hmacalg);
>  	}
>  
>  	hashalg = crypto_alloc_shash(hash_alg, 0, 0);
>  	if (IS_ERR(hashalg)) {
> -		pr_info("trusted_key: could not allocate crypto %s\n",
> +		pr_info("tpm_trusted_key: could not allocate crypto %s\n",

Let's just add interal trusted.h file with:

#undef pr_fmt
#define pr_fmt(fmt) "trusted_key: " fmt

and remove tags from these. Does not add value to have separate tags
for backends. Makes the klog only a bit messier I think.


>  			hash_alg);
>  		ret = PTR_ERR(hashalg);
>  		goto hashalg_fail;
> @@ -1217,16 +992,13 @@ static int __init init_digests(void)
>  	return 0;
>  }
>  
> -static int __init init_trusted(void)
> +static int trusted_tpm_init(void)
>  {
>  	int ret;
>  
> -	/* encrypted_keys.ko depends on successful load of this module even if
> -	 * TPM is not used.
> -	 */
>  	chip = tpm_default_chip();
>  	if (!chip)
> -		return 0;
> +		return -ENODEV;
>  
>  	ret = init_digests();
>  	if (ret < 0)
> @@ -1247,7 +1019,7 @@ static int __init init_trusted(void)
>  	return ret;
>  }
>  
> -static void __exit cleanup_trusted(void)
> +static void trusted_tpm_exit(void)
>  {
>  	if (chip) {
>  		put_device(&chip->dev);
> @@ -1257,7 +1029,11 @@ static void __exit cleanup_trusted(void)
>  	}
>  }
>  
> -late_initcall(init_trusted);
> -module_exit(cleanup_trusted);
> -
> -MODULE_LICENSE("GPL");
> +struct trusted_key_ops tpm_trusted_key_ops = {
> +	.migratable = 1, /* migratable by default */
> +	.init = trusted_tpm_init,
> +	.seal = trusted_tpm_seal,
> +	.unseal = trusted_tpm_unseal,
> +	.get_random = trusted_tpm_get_random,
> +	.exit = trusted_tpm_exit,
> +};
> -- 
> 2.7.4
> 
> 

/Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2020-11-03 16:01 ` [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg
@ 2020-11-24  3:46   ` Jarkko Sakkinen
  2021-01-11 16:35   ` Jarkko Sakkinen
  2021-01-20 13:36   ` Ahmad Fatoum
  2 siblings, 0 replies; 52+ messages in thread
From: Jarkko Sakkinen @ 2020-11-24  3:46 UTC (permalink / raw)
  To: Sumit Garg
  Cc: jarkko.sakkinen, zohar, jejb, dhowells, jens.wiklander, corbet,
	jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee

On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> Add support for TEE based trusted keys where TEE provides the functionality
> to seal and unseal trusted keys using hardware unique key.
> 
> Refer to Documentation/tee.txt for detailed information about TEE.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  include/keys/trusted_tee.h                |  55 ++++++
>  security/keys/trusted-keys/Makefile       |   1 +
>  security/keys/trusted-keys/trusted_core.c |   4 +
>  security/keys/trusted-keys/trusted_tee.c  | 278 ++++++++++++++++++++++++++++++
>  4 files changed, 338 insertions(+)
>  create mode 100644 include/keys/trusted_tee.h
>  create mode 100644 security/keys/trusted-keys/trusted_tee.c
> 
> diff --git a/include/keys/trusted_tee.h b/include/keys/trusted_tee.h
> new file mode 100644
> index 0000000..2e2bb15
> --- /dev/null
> +++ b/include/keys/trusted_tee.h
> @@ -0,0 +1,55 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2019-2020 Linaro Ltd.
> + *
> + * Author:
> + * Sumit Garg <sumit.garg@linaro.org>
> + */
> +
> +#ifndef __TEE_TRUSTED_KEY_H
> +#define __TEE_TRUSTED_KEY_H
> +
> +#include <linux/tee_drv.h>
> +
> +#define DRIVER_NAME "tee-trusted-key"
> +
> +/*
> + * Get random data for symmetric key
> + *
> + * [out]     memref[0]        Random data
> + */
> +#define TA_CMD_GET_RANDOM	0x0
> +
> +/*
> + * Seal trusted key using hardware unique key
> + *
> + * [in]      memref[0]        Plain key
> + * [out]     memref[1]        Sealed key datablob
> + */
> +#define TA_CMD_SEAL		0x1
> +
> +/*
> + * Unseal trusted key using hardware unique key
> + *
> + * [in]      memref[0]        Sealed key datablob
> + * [out]     memref[1]        Plain key
> + */
> +#define TA_CMD_UNSEAL		0x2
> +
> +/**
> + * struct trusted_key_private - TEE Trusted key private data
> + * @dev:		TEE based Trusted key device.
> + * @ctx:		TEE context handler.
> + * @session_id:		Trusted key TA session identifier.
> + * @shm_pool:		Memory pool shared with TEE device.
> + */
> +struct trusted_key_private {
> +	struct device *dev;
> +	struct tee_context *ctx;
> +	u32 session_id;
> +	struct tee_shm *shm_pool;
> +};
> +
> +extern struct trusted_key_ops tee_trusted_key_ops;
> +
> +#endif
> diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
> index 49e3bcf..012dd78 100644
> --- a/security/keys/trusted-keys/Makefile
> +++ b/security/keys/trusted-keys/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
>  trusted-y += trusted_core.o
>  trusted-y += trusted_tpm1.o
>  trusted-y += trusted_tpm2.o
> +trusted-y += trusted_tee.o
> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> index aa4f2a0..15b1b0f3 100644
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -8,6 +8,7 @@
>  
>  #include <keys/user-type.h>
>  #include <keys/trusted-type.h>
> +#include <keys/trusted_tee.h>
>  #include <keys/trusted_tpm.h>
>  #include <linux/capability.h>
>  #include <linux/err.h>
> @@ -29,6 +30,9 @@ static const struct trusted_key_source trusted_key_sources[] = {
>  #if defined(CONFIG_TCG_TPM)
>  	{ "tpm", &tpm_trusted_key_ops },
>  #endif
> +#if defined(CONFIG_TEE)
> +	{ "tee", &tee_trusted_key_ops },
> +#endif
>  };
>  
>  DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
> diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
> new file mode 100644
> index 0000000..da8785a
> --- /dev/null
> +++ b/security/keys/trusted-keys/trusted_tee.c
> @@ -0,0 +1,278 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019-2020 Linaro Ltd.
> + *
> + * Author:
> + * Sumit Garg <sumit.garg@linaro.org>
> + */
> +
> +#include <linux/err.h>
> +#include <linux/key-type.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <linux/uuid.h>
> +
> +#include <keys/trusted-type.h>
> +#include <keys/trusted_tee.h>
> +
> +static struct trusted_key_private pvt_data;
> +
> +/*
> + * Have the TEE seal(encrypt) the symmetric key
> + */
> +static int trusted_tee_seal(struct trusted_key_payload *p, char *datablob)
> +{
> +	int ret;
> +	struct tee_ioctl_invoke_arg inv_arg;
> +	struct tee_param param[4];
> +	struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
> +
> +	memset(&inv_arg, 0, sizeof(inv_arg));
> +	memset(&param, 0, sizeof(param));
> +
> +	reg_shm_in = tee_shm_register(pvt_data.ctx, (unsigned long)p->key,
> +				      p->key_len, TEE_SHM_DMA_BUF |
> +				      TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm_in)) {
> +		dev_err(pvt_data.dev, "key shm register failed\n");
> +		return PTR_ERR(reg_shm_in);
> +	}
> +
> +	reg_shm_out = tee_shm_register(pvt_data.ctx, (unsigned long)p->blob,
> +				       sizeof(p->blob), TEE_SHM_DMA_BUF |
> +				       TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm_out)) {
> +		dev_err(pvt_data.dev, "blob shm register failed\n");
> +		ret = PTR_ERR(reg_shm_out);
> +		goto out;
> +	}
> +
> +	inv_arg.func = TA_CMD_SEAL;
> +	inv_arg.session = pvt_data.session_id;
> +	inv_arg.num_params = 4;
> +
> +	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
> +	param[0].u.memref.shm = reg_shm_in;
> +	param[0].u.memref.size = p->key_len;
> +	param[0].u.memref.shm_offs = 0;
> +	param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
> +	param[1].u.memref.shm = reg_shm_out;
> +	param[1].u.memref.size = sizeof(p->blob);
> +	param[1].u.memref.shm_offs = 0;
> +
> +	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
> +	if ((ret < 0) || (inv_arg.ret != 0)) {
> +		dev_err(pvt_data.dev, "TA_CMD_SEAL invoke err: %x\n",
> +			inv_arg.ret);
> +		ret = -EFAULT;
> +	} else {
> +		p->blob_len = param[1].u.memref.size;
> +	}
> +
> +out:
> +	if (reg_shm_out)
> +		tee_shm_free(reg_shm_out);
> +	if (reg_shm_in)
> +		tee_shm_free(reg_shm_in);
> +
> +	return ret;
> +}
> +
> +/*
> + * Have the TEE unseal(decrypt) the symmetric key
> + */
> +static int trusted_tee_unseal(struct trusted_key_payload *p, char *datablob)
> +{
> +	int ret;
> +	struct tee_ioctl_invoke_arg inv_arg;
> +	struct tee_param param[4];
> +	struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
> +
> +	memset(&inv_arg, 0, sizeof(inv_arg));
> +	memset(&param, 0, sizeof(param));
> +
> +	reg_shm_in = tee_shm_register(pvt_data.ctx, (unsigned long)p->blob,
> +				      p->blob_len, TEE_SHM_DMA_BUF |
> +				      TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm_in)) {
> +		dev_err(pvt_data.dev, "blob shm register failed\n");
> +		return PTR_ERR(reg_shm_in);
> +	}
> +
> +	reg_shm_out = tee_shm_register(pvt_data.ctx, (unsigned long)p->key,
> +				       sizeof(p->key), TEE_SHM_DMA_BUF |
> +				       TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm_out)) {
> +		dev_err(pvt_data.dev, "key shm register failed\n");
> +		ret = PTR_ERR(reg_shm_out);
> +		goto out;
> +	}
> +
> +	inv_arg.func = TA_CMD_UNSEAL;
> +	inv_arg.session = pvt_data.session_id;
> +	inv_arg.num_params = 4;
> +
> +	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
> +	param[0].u.memref.shm = reg_shm_in;
> +	param[0].u.memref.size = p->blob_len;
> +	param[0].u.memref.shm_offs = 0;
> +	param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
> +	param[1].u.memref.shm = reg_shm_out;
> +	param[1].u.memref.size = sizeof(p->key);
> +	param[1].u.memref.shm_offs = 0;
> +
> +	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
> +	if ((ret < 0) || (inv_arg.ret != 0)) {
> +		dev_err(pvt_data.dev, "TA_CMD_UNSEAL invoke err: %x\n",
> +			inv_arg.ret);
> +		ret = -EFAULT;
> +	} else {
> +		p->key_len = param[1].u.memref.size;
> +	}
> +
> +out:
> +	if (reg_shm_out)
> +		tee_shm_free(reg_shm_out);
> +	if (reg_shm_in)
> +		tee_shm_free(reg_shm_in);
> +
> +	return ret;
> +}
> +
> +/*
> + * Have the TEE generate random symmetric key
> + */
> +static int trusted_tee_get_random(unsigned char *key, size_t key_len)
> +{
> +	int ret;
> +	struct tee_ioctl_invoke_arg inv_arg;
> +	struct tee_param param[4];
> +	struct tee_shm *reg_shm = NULL;
> +
> +	memset(&inv_arg, 0, sizeof(inv_arg));
> +	memset(&param, 0, sizeof(param));
> +
> +	reg_shm = tee_shm_register(pvt_data.ctx, (unsigned long)key, key_len,
> +				   TEE_SHM_DMA_BUF | TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm)) {
> +		dev_err(pvt_data.dev, "key shm register failed\n");
> +		return PTR_ERR(reg_shm);
> +	}
> +
> +	inv_arg.func = TA_CMD_GET_RANDOM;
> +	inv_arg.session = pvt_data.session_id;
> +	inv_arg.num_params = 4;
> +
> +	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
> +	param[0].u.memref.shm = reg_shm;
> +	param[0].u.memref.size = key_len;
> +	param[0].u.memref.shm_offs = 0;
> +
> +	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
> +	if ((ret < 0) || (inv_arg.ret != 0)) {
> +		dev_err(pvt_data.dev, "TA_CMD_GET_RANDOM invoke err: %x\n",
> +			inv_arg.ret);
> +		ret = -EFAULT;
> +	} else {
> +		ret = param[0].u.memref.size;
> +	}
> +
> +	tee_shm_free(reg_shm);
> +
> +	return ret;
> +}
> +
> +static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
> +{
> +	if (ver->impl_id == TEE_IMPL_ID_OPTEE)
> +		return 1;
> +	else
> +		return 0;
> +}
> +
> +static int trusted_key_probe(struct device *dev)
> +{
> +	struct tee_client_device *rng_device = to_tee_client_device(dev);
> +	int ret;
> +	struct tee_ioctl_open_session_arg sess_arg;
> +
> +	memset(&sess_arg, 0, sizeof(sess_arg));
> +
> +	pvt_data.ctx = tee_client_open_context(NULL, optee_ctx_match, NULL,
> +					       NULL);
> +	if (IS_ERR(pvt_data.ctx))
> +		return -ENODEV;
> +
> +	memcpy(sess_arg.uuid, rng_device->id.uuid.b, TEE_IOCTL_UUID_LEN);
> +	sess_arg.clnt_login = TEE_IOCTL_LOGIN_REE_KERNEL;
> +	sess_arg.num_params = 0;
> +
> +	ret = tee_client_open_session(pvt_data.ctx, &sess_arg, NULL);
> +	if ((ret < 0) || (sess_arg.ret != 0)) {
> +		dev_err(dev, "tee_client_open_session failed, err: %x\n",
> +			sess_arg.ret);
> +		ret = -EINVAL;
> +		goto out_ctx;
> +	}
> +	pvt_data.session_id = sess_arg.session;
> +
> +	ret = register_key_type(&key_type_trusted);
> +	if (ret < 0)
> +		goto out_sess;
> +
> +	pvt_data.dev = dev;
> +
> +	return 0;
> +
> +out_sess:
> +	tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
> +out_ctx:
> +	tee_client_close_context(pvt_data.ctx);
> +
> +	return ret;
> +}
> +
> +static int trusted_key_remove(struct device *dev)
> +{
> +	unregister_key_type(&key_type_trusted);
> +	tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
> +	tee_client_close_context(pvt_data.ctx);
> +
> +	return 0;
> +}
> +
> +static const struct tee_client_device_id trusted_key_id_table[] = {
> +	{UUID_INIT(0xf04a0fe7, 0x1f5d, 0x4b9b,
> +		   0xab, 0xf7, 0x61, 0x9b, 0x85, 0xb4, 0xce, 0x8c)},
> +	{}
> +};
> +MODULE_DEVICE_TABLE(tee, trusted_key_id_table);
> +
> +static struct tee_client_driver trusted_key_driver = {
> +	.id_table	= trusted_key_id_table,
> +	.driver		= {
> +		.name		= DRIVER_NAME,
> +		.bus		= &tee_bus_type,
> +		.probe		= trusted_key_probe,
> +		.remove		= trusted_key_remove,
> +	},
> +};
> +
> +static int trusted_tee_init(void)
> +{
> +	return driver_register(&trusted_key_driver.driver);
> +}
> +
> +static void trusted_tee_exit(void)
> +{
> +	driver_unregister(&trusted_key_driver.driver);
> +}
> +
> +struct trusted_key_ops tee_trusted_key_ops = {


Nit: trusted_key_tee_ops

> +	.migratable = 0, /* non-migratable */
> +	.init = trusted_tee_init,
> +	.seal = trusted_tee_seal,
> +	.unseal = trusted_tee_unseal,
> +	.get_random = trusted_tee_get_random,
> +	.exit = trusted_tee_exit,
> +};
> -- 
> 2.7.4
> 
> 
/Jarkko

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

* Re: [PATCH v8 4/4] MAINTAINERS: Add myself as Trusted Keys co-maintainer
  2020-11-03 16:01 ` [PATCH v8 4/4] MAINTAINERS: Add myself as Trusted Keys co-maintainer Sumit Garg
@ 2020-11-24  3:46   ` Jarkko Sakkinen
  0 siblings, 0 replies; 52+ messages in thread
From: Jarkko Sakkinen @ 2020-11-24  3:46 UTC (permalink / raw)
  To: Sumit Garg
  Cc: jarkko.sakkinen, zohar, jejb, dhowells, jens.wiklander, corbet,
	jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee

On Tue, Nov 03, 2020 at 09:31:46PM +0530, Sumit Garg wrote:
> Add a Trusted Keys co-maintainer entry in order to support TEE based
> Trusted Keys framework.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>

Acked-by: Jarkko Sakkinen <jarkko@kernel.org>

> ---
>  MAINTAINERS | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e73636b..52687bb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9732,11 +9732,13 @@ KEYS-TRUSTED
>  M:	James Bottomley <jejb@linux.ibm.com>
>  M:	Jarkko Sakkinen <jarkko@kernel.org>
>  M:	Mimi Zohar <zohar@linux.ibm.com>
> +M:	Sumit Garg <sumit.garg@linaro.org>
>  L:	linux-integrity@vger.kernel.org
>  L:	keyrings@vger.kernel.org
>  S:	Supported
>  F:	Documentation/security/keys/trusted-encrypted.rst
>  F:	include/keys/trusted-type.h
> +F:	include/keys/trusted_tee.h
>  F:	include/keys/trusted_tpm.h
>  F:	security/keys/trusted-keys/
>  
> -- 
> 2.7.4
> 
> 

/Jarkko

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

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-11-03 16:01 ` [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg
@ 2020-12-02 19:34   ` gmail Elaine Palmer
  2020-12-04 15:30     ` Jarkko Sakkinen
  2020-12-06 18:51   ` Randy Dunlap
  2020-12-08 15:55   ` Mimi Zohar
  2 siblings, 1 reply; 52+ messages in thread
From: gmail Elaine Palmer @ 2020-12-02 19:34 UTC (permalink / raw)
  To: Sumit Garg
  Cc: jarkko.sakkinen, zohar, jejb, dhowells, jens.wiklander, corbet,
	jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee, Kenneth Goldman, gcwilson, zgu, stefanb, NAYNA JAIN1


Hi Sumit,  

Thank you for the detailed descriptions and examples of trust sources for Trusted Keys.   A group of us in IBM (Stefan Berger, Ken Goldman, Zhongshu Gu, Nayna Jain, Elaine Palmer, George Wilson, Mimi Zohar) have been doing related work for quite some time, and we have one primary concern and some suggested changes to the document. 

Our primary concern is that describing a TEE as a Trust Source needs to be more specific.   For example, "ARM TrustZone" is not sufficient, but "wolfSSL embedded SSL/TLS library with ARM TrustZone CryptoCell-310" is.  Just because a key is protected by software running in a TEE is not enough to establish trust.  Just like cryptographic modules, a Trust Source should be defined as a specific implementation on specific hardware with well-documented environmental assumptions, dependencies, and threats.

In addition to the above concern, our suggested changes are inline below.

> Begin forwarded message:
> 
> From: Sumit Garg <sumit.garg@linaro.org>
> Subject: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
> Date: November 3, 2020 at 11:01:45 AM EST
> To: jarkko.sakkinen@linux.intel.com, zohar@linux.ibm.com, jejb@linux.ibm.com
> Cc: dhowells@redhat.com, jens.wiklander@linaro.org, corbet@lwn.net, jmorris@namei.org, serge@hallyn.com, casey@schaufler-ca.com, janne.karhunen@gmail.com, daniel.thompson@linaro.org, Markus.Wamser@mixed-mode.de, lhinds@redhat.com, keyrings@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, op-tee@lists.trustedfirmware.org, Sumit Garg <sumit.garg@linaro.org>
> 
> Update documentation for Trusted and Encrypted Keys with TEE as a new
> trust source. Following is brief description of updates:
> 
> - Add a section to demostrate a list of supported devices along with
> their security properties/guarantees.
> - Add a key generation section.
> - Updates for usage section including differences specific to a trust
> source.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
> Documentation/security/keys/trusted-encrypted.rst | 203 ++++++++++++++++++----
> 1 file changed, 171 insertions(+), 32 deletions(-)
> 
> diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
> index 1da879a..16042c8 100644
> --- a/Documentation/security/keys/trusted-encrypted.rst
> +++ b/Documentation/security/keys/trusted-encrypted.rst
> @@ -6,30 +6,161 @@ Trusted and Encrypted Keys are two new key types added to the existing kernel
> key ring service.  Both of these new types are variable length symmetric keys,
> and in both cases all keys are created in the kernel, and user space sees,
> stores, and loads only encrypted blobs.  Trusted Keys require the availability
> -of a Trusted Platform Module (TPM) chip for greater security, while Encrypted
> -Keys can be used on any system.  All user level blobs, are displayed and loaded
> -in hex ascii for convenience, and are integrity verified.
> +of a Trust Source for greater security, while Encrypted Keys can be used on any
> +system. All user level blobs, are displayed and loaded in hex ascii for
> +convenience, and are integrity verified.
> 
> -Trusted Keys use a TPM both to generate and to seal the keys.  Keys are sealed
> -under a 2048 bit RSA key in the TPM, and optionally sealed to specified PCR
> -(integrity measurement) values, and only unsealed by the TPM, if PCRs and blob
> -integrity verifications match.  A loaded Trusted Key can be updated with new
> -(future) PCR values, so keys are easily migrated to new pcr values, such as
> -when the kernel and initramfs are updated.  The same key can have many saved
> -blobs under different PCR values, so multiple boots are easily supported.
> 
> -TPM 1.2
> --------
> +Trust Source
> +============
> 
> -By default, trusted keys are sealed under the SRK, which has the default
> -authorization value (20 zeros).  This can be set at takeownership time with the
> -trouser's utility: "tpm_takeownership -u -z".
> +Trust Source provides the source of security for the Trusted Keys, on which
> +basis Trusted Keys establishes a Trust model with its user. A Trust Source could
> +differ from one system to another depending on its security requirements. It
> +could be either an off-chip device or an on-chip device. Following section
> +demostrates a list of supported devices along with their security properties/
> +guarantees:
Please change the following 
"Trust Source provides the source of security for the Trusted Keys, on which basis Trusted Keys establishes a Trust model with its user." 
to 
"A trust source provides the source of security for the Trusted Keys.  Whether or not a trust source is sufficiently safe depends on the strength and correctness of its implementation, as well as the threat environment for a specific use case.  Since the kernel doesn't know what the environment is, and there is no metric of trust, it is dependent on the consumer of the Trusted Keys to determine if the trust source is sufficiently safe."
> 
> -TPM 2.0
> --------
> +  *  Root of trust for storage
> 
> -The user must first create a storage key and make it persistent, so the key is
> -available after reboot. This can be done using the following commands.
> +     (1) TPM (Trusted Platform Module: hardware device)
> +
> +         Rooted to Storage Root Key (SRK) which never leaves the TPM that
> +         provides crypto operation to establish root of trust for storage.
> +
> +     (2) TEE (Trusted Execution Environment: OP-TEE based on Arm TrustZone)
> +
> +         Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip
> +         fuses and is accessible to TEE only.
> +
> +  *  Execution isolation
> +
> +     (1) TPM
> +
> +         Fixed set of operations running in isolated execution environment.
> +
> +     (2) TEE
> +
> +         Customizable set of operations running in isolated execution
> +         environment verified via Secure/Trusted boot process.
> +
> +  * Optional binding to platform integrity state
> +
> +     (1) TPM
> +
> +         Keys can be optionally sealed to specified PCR (integrity measurement)
> +         values, and only unsealed by the TPM, if PCRs and blob integrity
> +         verifications match. A loaded Trusted Key can be updated with new
> +         (future) PCR values, so keys are easily migrated to new PCR values,
> +         such as when the kernel and initramfs are updated. The same key can
> +         have many saved blobs under different PCR values, so multiple boots are
> +         easily supported.
> +
> +     (2) TEE
> +
> +         Relies on Secure/Trusted boot process for platform integrity. It can
> +         be extended with TEE based measured boot process.
> +
> +  *  On-chip versus off-chip
> +
> +     (1) TPM
> +
> +         Off-chip device connected via serial bus (like I2C, SPI etc.) exposing
> +         physical access which represents an attack surface that can be
> +         mitigated via tamper detection.
> +
> +     (2) TEE
> +
> +         On-chip functionality, immune to this attack surface.
> +
> +  *  Memory attacks (DRAM based like attaching a bus monitor etc.)
> +
> +     (1) TPM
> +
> +         Immune to these attacks as it doesn’t make use of system DRAM.
> +
> +     (2) TEE
> +
> +         An implementation based on TrustZone protected DRAM is susceptible to
> +         such attacks. In order to mitigate these attacks one needs to rely on
> +         on-chip secure RAM to store secrets or have the entire TEE
> +         implementation based on on-chip secure RAM. An alternative mitigation
> +         would be to use encrypted DRAM.
> +
> +  *  Side-channel attacks (cache, memory, CPU or time based)
> +
> +     (1) TPM
> +
> +         Immune to side-channel attacks as its resources are isolated from the
> +         main OS.
> +
> +     (2) TEE
> +
> +         A careful implementation is required to mitigate against these attacks
> +         for resources which are shared (eg. shared memory) with the main OS.
> +         Cache and CPU based side-channel attacks can be mitigated via
> +         invalidating caches and CPU registers during context switch to and from
> +         the secure world.
> +         To mitigate against time based attacks, one needs to have time
> +         invariant implementations (like crypto algorithms etc.).
> +
> +  *  Resistance to physical attacks (power analysis, electromagnetic emanation,
> +     probes etc.)
> +
> +     (1) TPM
> +
> +         Provides limited protection utilizing tamper resistance.
> +
> +     (2) TEE
> +
> +         Provides no protection by itself, relies on the underlying platform for
> +         features such as tamper resistance.
> +
> +
please add the following:

* Provisioning - the trust source's unique and verifiable cryptographic identity is provisioned during manufacturing

(1) TPM
The unique and verifiable cryptographic identity is the endorsement key (EK) or its primary seed.  A review of the generation of the EK and its accompanying certificate is part of the Common Criteria evaluation of the product's lifecycle processes (ALC_*).  See "TCG Protection Profile for PC Client Specific TPM 2" (https://trustedcomputinggroup.org/resource/pc-client-protection-profile-for-tpm-2-0/).

(2) TEE
A protection profile for TEEs does not yet exist.  Therefore, the provisioning process that generates the Hardware Unique Key is not evaluated by an independent third party and is highly dependent on the manufacturing environment.  


* Cryptography
(1) TPM
As part of the TPM's mandatory Common Criteria evaluation, the correctness of the TPM's implementation of cryptographic algorithms, the protection of keys, and the generation of random numbers, and other security-relevant functions must be documented, reviewed, and tested by an independent third party evaluation agency.  It must meet the requirements of FIPS 140-2, FIPS 140-3, or ISO/IEC 19790:2012. 

(2) TEE
Evaluations of cryptographic modules within TEEs are not required, but some are available for specific implementations within TEEs.



* Interfaces and APIs
(1) TPMs have well-documented, standardized interfaces and APIs.
(2) Unless they implement functionality such as a virtual TPM, TEEs have custom interfaces and APIs. 



* Threat model
The strength and appropriateness of  TPMs and TEEs for a given purpose must be assessed when using them to protect security-relevant data.    

We suggest documenting environmental assumptions and dependencies in a high-level threat model for each additional trust source.  Just as each new LSM needs to comply with Documentation/security/lsm-development.rst, each new Trusted Key source should provide a high-level threat model.   An example of a high-level threat model is "Common Security Threats v1.0” (https://www.opencompute.org/documents/common-security-threats-notes-1-pdf ). 

The original Trusted Keys implementation assumed discrete physical TPMs for key protection.  However, even physical TPMs themselves vary based on the manufacturer and systems in which they are placed.  The embedded chipset, firmware load, algorithms, packaging, pins, and countermeasures vary.  (Threats and mitigations on physical TPMs are well documented, e.g., "Threat Model of a Scenario Based on Trusted Platform Module 2.0 Specification” (http://ceur-ws.org/Vol-1011/6.pdf).

Specific to Trusted Keys and TPMs, there is some discussion of threats and mitigations in the Integrity_overview.pdf on the IMA wiki:

	• The trusted key component does two things to help with secure key management on Linux. First, it provides a kernel key ring service in which the symmetric encryption keys are never visible in plain text to userspace. The keys are created in the kernel, and sealed by a hardware device such as a TPM, with userspace seeing only the sealed blobs. Malicious or compromised applications cannot steal a trusted key, since only the kernel can see the unsealed blobs. Secondly, the trusted keys can tie key unsealing to the integrity measurements, so that keys cannot be stolen in an offline attack, such as by booting an unlocked Linux image from CD or USB.  As the measurements will be different, the TPM chip will refuse to unseal the keys, even for the kernel.

Consumers of Trusted Keys in different environments need enough information so that they can create their own threat models tailored to their use cases.  For the present submission, a high-level security model of ARM TrustZone and how Trusted Keys key protection is implemented along with an enumeration of security considerations for end-use threat models would be appropriate.  

An excellent and related paper describes the strengths, weaknesses, and countermeasures of a firmware TPM implemented within a TEE.  See "fTPM: A Software-only Implementation of a TPM Chip” (https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/raj)


> +Key Generation
> +==============
> +
> +Trusted Keys
> +------------
> +
> +New keys are created from trust source generated random numbers, and are
> +encrypted/decrypted using trust source storage root key.
Please change the following
"New keys are created from trust source generated random numbers, and are encrypted/decrypted using trust source storage root key."
to
"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. “

Thank you. 
Elaine
_____________________________________
Elaine R. Palmer, Senior Technical Staff Member
Secure Systems and Academy of Technology
IBM T.J. Watson Research Center

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

* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support
  2020-11-06 14:52     ` Jarkko Sakkinen
@ 2020-12-04  5:16       ` Jarkko Sakkinen
  2020-12-08 11:51         ` Sumit Garg
  0 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2020-12-04  5:16 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Fri, Nov 06, 2020 at 04:52:52PM +0200, Jarkko Sakkinen wrote:
> On Fri, Nov 06, 2020 at 03:02:41PM +0530, Sumit Garg wrote:
> > On Thu, 5 Nov 2020 at 10:37, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >
> > > On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote:
> > > > Add support for TEE based trusted keys where TEE provides the functionality
> > > > to seal and unseal trusted keys using hardware unique key. Also, this is
> > > > an alternative in case platform doesn't possess a TPM device.
> > > >
> > > > This patch-set has been tested with OP-TEE based early TA which is already
> > > > merged in upstream [1].
> > >
> > > Is the new RPI400 computer a platform that can be used for testing
> > > patch sets like this? I've been looking for a while something ARM64
> > > based with similar convenience as Intel NUC's, and on the surface
> > > this new RPI product looks great for kernel testing purposes.
> > 
> > Here [1] is the list of supported versions of Raspberry Pi in OP-TEE.
> > The easiest approach would be to pick up a supported version or else
> > do an OP-TEE port for an unsupported one (which should involve minimal
> > effort).
> > 
> > [1] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#what-versions-of-raspberry-pi-will-work
> > 
> > -Sumit
> 
> If porting is doable, then I'll just order RPI 400, and test with QEMU
> up until either I port OP-TEE myself or someone else does it.
> 
> For seldom ARM testing, RPI 400 is really convenient device with its
> boxed form factor.

I'm now a proud owner of Raspberry Pi 400 home computer :-)

I also found instructions on how to boot a custom OS from a USB stick:

https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

Also, my favorite build system BuildRoot has bunch of of the shelf
configs:

➜  buildroot-sgx (master) ✔ ls -1 configs | grep raspberry
raspberrypi0_defconfig
raspberrypi0w_defconfig
raspberrypi2_defconfig
raspberrypi3_64_defconfig
raspberrypi3_defconfig
raspberrypi3_qt5we_defconfig
raspberrypi4_64_defconfig
raspberrypi4_defconfig
raspberrypi_defconfig

I.e. I'm capable of compiling kernel and user space and boot it up
with it.

Further, I can select this compilation option:

BR2_TARGET_OPTEE_OS:                                                                                                                                              │  
                                                                                                                                                                     │  
   OP-TEE OS provides the secure world boot image and the trust                                                                                                      │  
   application development kit of the OP-TEE project. OP-TEE OS                                                                                                      │  
   also provides generic trusted application one can embedded                                                                                                        │  
   into its system.                                                                                                                                                  │  
                                                                                                                                                                     │  
   http://github.com/OP-TEE/optee_os       

Is that what I want? If I put this all together and apply your patches,
should the expectation be that I can use trusted keys?

Please note that I had a few remarks about your patches (minor but need
to be fixed), but this version is already solid enough for testing.

/Jarkko

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

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-02 19:34   ` gmail Elaine Palmer
@ 2020-12-04 15:30     ` Jarkko Sakkinen
  2020-12-08 15:02       ` Mimi Zohar
  0 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2020-12-04 15:30 UTC (permalink / raw)
  To: gmail Elaine Palmer
  Cc: Sumit Garg, jarkko.sakkinen, zohar, jejb, dhowells,
	jens.wiklander, corbet, jmorris, serge, casey, janne.karhunen,
	daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Kenneth Goldman, gcwilson, zgu,
	stefanb, NAYNA JAIN1

On Wed, Dec 02, 2020 at 02:34:07PM -0500, gmail Elaine Palmer wrote:
> Hi Sumit,  
> 
> Thank you for the detailed descriptions and examples of trust sources
> for Trusted Keys.   A group of us in IBM (Stefan Berger, Ken Goldman,
> Zhongshu Gu, Nayna Jain, Elaine Palmer, George Wilson, Mimi Zohar)
> have been doing related work for quite some time, and we have one
> primary concern and some suggested changes to the document. 
> 
> Our primary concern is that describing a TEE as a Trust Source needs
> to be more specific.   For example, "ARM TrustZone" is not sufficient,
> but "wolfSSL embedded SSL/TLS library with ARM TrustZone
> CryptoCell-310" is.  Just because a key is protected by software
> running in a TEE is not enough to establish trust.  Just like
> cryptographic modules, a Trust Source should be defined as a specific
> implementation on specific hardware with well-documented environmental
> assumptions, dependencies, and threats.
> 
> In addition to the above concern, our suggested changes are inline
> below.

In order to give a decent review comment it should have two ingredients:

- Where the existing line of code / text / whatever goes wrong.
- How it should modified and why that makes sense. And use as plain
  English and non-academic terms as possible, if it is documentation.
  Further, scope is only the kernel implementation, no more or no
  less.

"do this" is not unfortunately an argument. Feedback is welcome when
it is supported by something common sensse.

Some meta suggestion of related to email:

Please also use a proper email client and split your paragraphs into
at most 80 character lines with new line characters when writing email.
I prefer to use 72 character line length so that there's some space
for longer email threads.

/Jarkko

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

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-11-03 16:01 ` [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg
  2020-12-02 19:34   ` gmail Elaine Palmer
@ 2020-12-06 18:51   ` Randy Dunlap
  2020-12-08 15:55   ` Mimi Zohar
  2 siblings, 0 replies; 52+ messages in thread
From: Randy Dunlap @ 2020-12-06 18:51 UTC (permalink / raw)
  To: Sumit Garg, jarkko.sakkinen, zohar, jejb
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee

Hi--

Please see doc. comments below.


On 11/3/20 8:01 AM, Sumit Garg wrote:
> Update documentation for Trusted and Encrypted Keys with TEE as a new
> trust source. Following is brief description of updates:
> 
> - Add a section to demostrate a list of supported devices along with

                     demonstrate

>   their security properties/guarantees.
> - Add a key generation section.
> - Updates for usage section including differences specific to a trust
>   source.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
>  Documentation/security/keys/trusted-encrypted.rst | 203 ++++++++++++++++++----
>  1 file changed, 171 insertions(+), 32 deletions(-)
> 
> diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
> index 1da879a..16042c8 100644
> --- a/Documentation/security/keys/trusted-encrypted.rst
> +++ b/Documentation/security/keys/trusted-encrypted.rst
> @@ -6,30 +6,161 @@ Trusted and Encrypted Keys are two new key types added to the existing kernel
>  key ring service.  Both of these new types are variable length symmetric keys,
>  and in both cases all keys are created in the kernel, and user space sees,
>  stores, and loads only encrypted blobs.  Trusted Keys require the availability
> -of a Trusted Platform Module (TPM) chip for greater security, while Encrypted
> -Keys can be used on any system.  All user level blobs, are displayed and loaded
> -in hex ascii for convenience, and are integrity verified.
> +of a Trust Source for greater security, while Encrypted Keys can be used on any
> +system. All user level blobs, are displayed and loaded in hex ascii for

s/ascii/ASCII/ please. Yes, I know that it was already there in lower case.

> +convenience, and are integrity verified.
>  
> -Trusted Keys use a TPM both to generate and to seal the keys.  Keys are sealed
> -under a 2048 bit RSA key in the TPM, and optionally sealed to specified PCR
> -(integrity measurement) values, and only unsealed by the TPM, if PCRs and blob
> -integrity verifications match.  A loaded Trusted Key can be updated with new
> -(future) PCR values, so keys are easily migrated to new pcr values, such as
> -when the kernel and initramfs are updated.  The same key can have many saved
> -blobs under different PCR values, so multiple boots are easily supported.
>  
> -TPM 1.2
> --------
> +Trust Source
> +============
>  
> -By default, trusted keys are sealed under the SRK, which has the default
> -authorization value (20 zeros).  This can be set at takeownership time with the
> -trouser's utility: "tpm_takeownership -u -z".
> +Trust Source provides the source of security for the Trusted Keys, on which
> +basis Trusted Keys establishes a Trust model with its user. A Trust Source could
> +differ from one system to another depending on its security requirements. It
> +could be either an off-chip device or an on-chip device. Following section
> +demostrates a list of supported devices along with their security properties/

   demonstrates

> +guarantees:
>  
> -TPM 2.0
> --------
> +  *  Root of trust for storage
>  
> -The user must first create a storage key and make it persistent, so the key is
> -available after reboot. This can be done using the following commands.
> +     (1) TPM (Trusted Platform Module: hardware device)
> +
> +         Rooted to Storage Root Key (SRK) which never leaves the TPM that
> +         provides crypto operation to establish root of trust for storage.
> +
> +     (2) TEE (Trusted Execution Environment: OP-TEE based on Arm TrustZone)
> +
> +         Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip
> +         fuses and is accessible to TEE only.
> +
> +  *  Execution isolation
> +
> +     (1) TPM
> +
> +         Fixed set of operations running in isolated execution environment.
> +
> +     (2) TEE
> +
> +         Customizable set of operations running in isolated execution
> +         environment verified via Secure/Trusted boot process.
> +
> +  * Optional binding to platform integrity state
> +
> +     (1) TPM
> +
> +         Keys can be optionally sealed to specified PCR (integrity measurement)
> +         values, and only unsealed by the TPM, if PCRs and blob integrity
> +         verifications match. A loaded Trusted Key can be updated with new
> +         (future) PCR values, so keys are easily migrated to new PCR values,
> +         such as when the kernel and initramfs are updated. The same key can
> +         have many saved blobs under different PCR values, so multiple boots are
> +         easily supported.
> +
> +     (2) TEE
> +
> +         Relies on Secure/Trusted boot process for platform integrity. It can
> +         be extended with TEE based measured boot process.
> +
> +  *  On-chip versus off-chip
> +
> +     (1) TPM
> +
> +         Off-chip device connected via serial bus (like I2C, SPI etc.) exposing
> +         physical access which represents an attack surface that can be
> +         mitigated via tamper detection.
> +
> +     (2) TEE
> +
> +         On-chip functionality, immune to this attack surface.
> +
> +  *  Memory attacks (DRAM based like attaching a bus monitor etc.)

                        DRAM-based

> +
> +     (1) TPM
> +
> +         Immune to these attacks as it doesn’t make use of system DRAM.
> +
> +     (2) TEE
> +
> +         An implementation based on TrustZone protected DRAM is susceptible to
> +         such attacks. In order to mitigate these attacks one needs to rely on
> +         on-chip secure RAM to store secrets or have the entire TEE
> +         implementation based on on-chip secure RAM. An alternative mitigation
> +         would be to use encrypted DRAM.
> +
> +  *  Side-channel attacks (cache, memory, CPU or time based)
> +
> +     (1) TPM
> +
> +         Immune to side-channel attacks as its resources are isolated from the
> +         main OS.
> +
> +     (2) TEE
> +
> +         A careful implementation is required to mitigate against these attacks
> +         for resources which are shared (eg. shared memory) with the main OS.

	                                    e.g.

> +         Cache and CPU based side-channel attacks can be mitigated via
> +         invalidating caches and CPU registers during context switch to and from
> +         the secure world.
> +         To mitigate against time based attacks, one needs to have time
> +         invariant implementations (like crypto algorithms etc.).
> +
> +  *  Resistance to physical attacks (power analysis, electromagnetic emanation,
> +     probes etc.)
> +
> +     (1) TPM
> +
> +         Provides limited protection utilizing tamper resistance.
> +
> +     (2) TEE
> +
> +         Provides no protection by itself, relies on the underlying platform for
> +         features such as tamper resistance.
> +
> +
> +Key Generation
> +==============
> +
> +Trusted Keys
> +------------
> +
> +New keys are created from trust source generated random numbers, and are
> +encrypted/decrypted using trust source storage root key.
> +
> +  *  TPM (hardware device) based RNG
> +
> +     Strength of random numbers may vary from one device manufacturer to
> +     another.
> +
> +  *  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.
> +
> +Encrypted Keys
> +--------------
> +
> +Encrypted keys do not depend on a trust source, and are faster, as they use AES
> +for encryption/decryption. New keys are created from kernel generated random

                                                        kernel-generated

> +numbers, and are encrypted/decrypted using a specified ‘master’ key. The
> +‘master’ key can either be a trusted-key or user-key type. The main disadvantage
> +of encrypted keys is that if they are not rooted in a trusted key, they are only
> +as secure as the user key encrypting them. The master user key should therefore
> +be loaded in as secure a way as possible, preferably early in boot.
> +
> +
> +Usage
> +=====
> +
> +Trusted Keys usage: TPM
> +-----------------------
> +
> +TPM 1.2: By default, trusted keys are sealed under the SRK, which has the
> +default authorization value (20 zeros).  This can be set at takeownership time

Does "20 zeros" mean 20 bytes of 0s or 20 bits of 0s or something else?

> +with the TrouSerS utility: "tpm_takeownership -u -z".
> +
> +TPM 2.0: The user must first create a storage key and make it persistent, so the
> +key is available after reboot. This can be done using the following commands.
>  
>  With the IBM TSS 2 stack::
>  
> @@ -78,14 +209,21 @@ TPM_STORED_DATA format.  The key length for new keys are always in bytes.
>  Trusted Keys can be 32 - 128 bytes (256 - 1024 bits), the upper limit is to fit
>  within the 2048 bit SRK (RSA) keylength, with all necessary structure/padding.
>  
> -Encrypted keys do not depend on a TPM, and are faster, as they use AES for
> -encryption/decryption.  New keys are created from kernel generated random
> -numbers, and are encrypted/decrypted using a specified 'master' key.  The
> -'master' key can either be a trusted-key or user-key type.  The main
> -disadvantage of encrypted keys is that if they are not rooted in a trusted key,
> -they are only as secure as the user key encrypting them.  The master user key
> -should therefore be loaded in as secure a way as possible, preferably early in
> -boot.
> +Trusted Keys usage: TEE
> +-----------------------
> +
> +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

                             ASCII

> +specific to TEE device implementation.  The key length for new keys are always

                                                                       is always

> +in bytes. Trusted Keys can be 32 - 128 bytes (256 - 1024 bits).
> +
> +Encrypted Keys usage
> +--------------------
>  
>  The decrypted portion of encrypted keys can contain either a simple symmetric
>  key or a more complex structure. The format of the more complex structure is
> @@ -103,8 +241,8 @@ Where::
>  	format:= 'default | ecryptfs | enc32'
>  	key-type:= 'trusted' | 'user'
>  
> -
>  Examples of trusted and encrypted key usage:
> +--------------------------------------------

No colon at end of heading, please.

>  
>  Create and save a trusted key named "kmk" of length 32 bytes.
>  
> @@ -150,7 +288,7 @@ Load a trusted key from the saved blob::
>      f1f8fff03ad0acb083725535636addb08d73dedb9832da198081e5deae84bfaf0409c22b
>      e4a8aea2b607ec96931e6f4d4fe563ba
>  
> -Reseal a trusted key under new pcr values::
> +Reseal (TPM specific) a trusted key under new PCR values::
>  
>      $ keyctl update 268728824 "update pcrinfo=`cat pcr.blob`"
>      $ keyctl print 268728824
> @@ -164,11 +302,12 @@ Reseal a trusted key under new pcr values::
>      7ef6a24defe4846104209bf0c3eced7fa1a672ed5b125fc9d8cd88b476a658a4434644ef
>      df8ae9a178e9f83ba9f08d10fa47e4226b98b0702f06b3b8
>  
> +
>  The initial consumer of trusted keys is EVM, which at boot time needs a high
> -quality symmetric key for HMAC protection of file metadata.  The use of a
> +quality symmetric key for HMAC protection of file metadata. The use of a
>  trusted key provides strong guarantees that the EVM key has not been
> -compromised by a user level problem, and when sealed to specific boot PCR
> -values, protects against boot and offline attacks.  Create and save an
> +compromised by a user level problem, and when sealed to a platform integrity
> +state, protects against boot and offline attacks. Create and save an
>  encrypted key "evm" using the above trusted key "kmk":
>  
>  option 1: omitting 'format'::
> 


thanks.
-- 
~Randy


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

* Re: [PATCH v8 0/4] Introduce TEE based Trusted Keys support
  2020-12-04  5:16       ` Jarkko Sakkinen
@ 2020-12-08 11:51         ` Sumit Garg
  0 siblings, 0 replies; 52+ messages in thread
From: Sumit Garg @ 2020-12-08 11:51 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

Hi Jarkko,

Apologies for the delay in my response as I was busy with other high
priority work.

On Fri, 4 Dec 2020 at 10:46, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Fri, Nov 06, 2020 at 04:52:52PM +0200, Jarkko Sakkinen wrote:
> > On Fri, Nov 06, 2020 at 03:02:41PM +0530, Sumit Garg wrote:
> > > On Thu, 5 Nov 2020 at 10:37, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >
> > > > On Tue, Nov 03, 2020 at 09:31:42PM +0530, Sumit Garg wrote:
> > > > > Add support for TEE based trusted keys where TEE provides the functionality
> > > > > to seal and unseal trusted keys using hardware unique key. Also, this is
> > > > > an alternative in case platform doesn't possess a TPM device.
> > > > >
> > > > > This patch-set has been tested with OP-TEE based early TA which is already
> > > > > merged in upstream [1].
> > > >
> > > > Is the new RPI400 computer a platform that can be used for testing
> > > > patch sets like this? I've been looking for a while something ARM64
> > > > based with similar convenience as Intel NUC's, and on the surface
> > > > this new RPI product looks great for kernel testing purposes.
> > >
> > > Here [1] is the list of supported versions of Raspberry Pi in OP-TEE.
> > > The easiest approach would be to pick up a supported version or else
> > > do an OP-TEE port for an unsupported one (which should involve minimal
> > > effort).
> > >
> > > [1] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#what-versions-of-raspberry-pi-will-work
> > >
> > > -Sumit
> >
> > If porting is doable, then I'll just order RPI 400, and test with QEMU
> > up until either I port OP-TEE myself or someone else does it.
> >
> > For seldom ARM testing, RPI 400 is really convenient device with its
> > boxed form factor.
>
> I'm now a proud owner of Raspberry Pi 400 home computer :-)
>
> I also found instructions on how to boot a custom OS from a USB stick:
>
> https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md
>
> Also, my favorite build system BuildRoot has bunch of of the shelf
> configs:
>
> ➜  buildroot-sgx (master) ✔ ls -1 configs | grep raspberry
> raspberrypi0_defconfig
> raspberrypi0w_defconfig
> raspberrypi2_defconfig
> raspberrypi3_64_defconfig
> raspberrypi3_defconfig
> raspberrypi3_qt5we_defconfig
> raspberrypi4_64_defconfig
> raspberrypi4_defconfig
> raspberrypi_defconfig
>
> I.e. I'm capable of compiling kernel and user space and boot it up
> with it.
>
> Further, I can select this compilation option:
>
> BR2_TARGET_OPTEE_OS:                                                                                                                                              │
>                                                                                                                                                                      │
>    OP-TEE OS provides the secure world boot image and the trust                                                                                                      │
>    application development kit of the OP-TEE project. OP-TEE OS                                                                                                      │
>    also provides generic trusted application one can embedded                                                                                                        │
>    into its system.                                                                                                                                                  │
>                                                                                                                                                                      │
>    http://github.com/OP-TEE/optee_os
>
> Is that what I want? If I put this all together and apply your patches,
> should the expectation be that I can use trusted keys?
>

Firstly you need to do an OP-TEE port for RPI 400 (refer here [1] for
guidelines). And then in order to boot up OP-TEE on RPI 400, you can
refer to Raspberry Pi 3 build instructions [2].

[1] https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html
[2] https://optee.readthedocs.io/en/latest/building/devices/rpi3.html#build-instructions

> Please note that I had a few remarks about your patches (minor but need
> to be fixed), but this version is already solid enough for testing.
>

Sure, I will incorporate your remarks and Randy's documentation
comments in the next version.

-Sumit

> /Jarkko

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

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-04 15:30     ` Jarkko Sakkinen
@ 2020-12-08 15:02       ` Mimi Zohar
  2020-12-08 17:49         ` Jarkko Sakkinen
  0 siblings, 1 reply; 52+ messages in thread
From: Mimi Zohar @ 2020-12-08 15:02 UTC (permalink / raw)
  To: Jarkko Sakkinen, Elaine Palmer
  Cc: Sumit Garg, jarkko.sakkinen, jejb, dhowells, jens.wiklander,
	corbet, jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee, Kenneth Goldman, gcwilson, zgu, stefanb, NAYNA JAIN1

Hi Jarkko,

On Fri, 2020-12-04 at 17:30 +0200, Jarkko Sakkinen wrote:
> On Wed, Dec 02, 2020 at 02:34:07PM -0500, gmail Elaine Palmer wrote:
> > Hi Sumit,  
> > 
> > Thank you for the detailed descriptions and examples of trust sources
> > for Trusted Keys.   A group of us in IBM (Stefan Berger, Ken Goldman,
> > Zhongshu Gu, Nayna Jain, Elaine Palmer, George Wilson, Mimi Zohar)
> > have been doing related work for quite some time, and we have one
> > primary concern and some suggested changes to the document. 
> > 
> > Our primary concern is that describing a TEE as a Trust Source needs
> > to be more specific.   For example, "ARM TrustZone" is not sufficient,
> > but "wolfSSL embedded SSL/TLS library with ARM TrustZone
> > CryptoCell-310" is.  Just because a key is protected by software
> > running in a TEE is not enough to establish trust.  Just like
> > cryptographic modules, a Trust Source should be defined as a specific
> > implementation on specific hardware with well-documented environmental
> > assumptions, dependencies, and threats.
> > 
> > In addition to the above concern, our suggested changes are inline
> > below.
> 
> In order to give a decent review comment it should have two ingredients:
> 
> - Where the existing line of code / text / whatever goes wrong.
> - How it should modified and why that makes sense. And use as plain
>   English and non-academic terms as possible, if it is documentation.
>   Further, scope is only the kernel implementation, no more or no
>   less.
> 
> "do this" is not unfortunately an argument. Feedback is welcome when
> it is supported by something common sensse.

Even after the code is fully debugged, reviewed and tested, our concern
is that people will assume the security guarantees of TEE based trusted
keys to be equivalent to that of a discrete TPM.

> 
> Some meta suggestion of related to email:
> 
> Please also use a proper email client and split your paragraphs into
> at most 80 character lines with new line characters when writing email.
> I prefer to use 72 character line length so that there's some space
> for longer email threads.

Sure, we'll re-post the suggested documentation changes/additions.

Mimi


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

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-11-03 16:01 ` [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg
  2020-12-02 19:34   ` gmail Elaine Palmer
  2020-12-06 18:51   ` Randy Dunlap
@ 2020-12-08 15:55   ` Mimi Zohar
  2020-12-08 17:07     ` Mimi Zohar
  2 siblings, 1 reply; 52+ messages in thread
From: Mimi Zohar @ 2020-12-08 15:55 UTC (permalink / raw)
  To: Sumit Garg, jarkko.sakkinen, jejb, Elaine Palmer
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, George Wilson

Hi Sumit, Jarkko,

Re-posting Elaine Palmer's comments, inline below, trimmed and properly
formatted.

On Tue, 2020-11-03 at 21:31 +0530, Sumit Garg wrote:
> Update documentation for Trusted and Encrypted Keys with TEE as a new
> trust source. Following is brief description of updates:
> 
> - Add a section to demostrate a list of supported devices along with
>   their security properties/guarantees.
> - Add a key generation section.
> - Updates for usage section including differences specific to a trust
>   source.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> Reviewed-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
>  Documentation/security/keys/trusted-encrypted.rst | 203 ++++++++++++++++++----
>  1 file changed, 171 insertions(+), 32 deletions(-)
> 
> diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
> index 1da879a..16042c8 100644
> --- a/Documentation/security/keys/trusted-encrypted.rst
> +++ b/Documentation/security/keys/trusted-encrypted.rst
> @@ -6,30 +6,161 @@ Trusted and Encrypted Keys are two new key types added to the existing kernel
>  key ring service.  Both of these new types are variable length symmetric keys,
>  and in both cases all keys are created in the kernel, and user space sees,
>  stores, and loads only encrypted blobs.  Trusted Keys require the availability
> -of a Trusted Platform Module (TPM) chip for greater security, while Encrypted
> -Keys can be used on any system.  All user level blobs, are displayed and loaded
> -in hex ascii for convenience, and are integrity verified.
> +of a Trust Source for greater security, while Encrypted Keys can be used on any
> +system. All user level blobs, are displayed and loaded in hex ascii for
> +convenience, and are integrity verified.
>  
> -Trusted Keys use a TPM both to generate and to seal the keys.  Keys are sealed
> -under a 2048 bit RSA key in the TPM, and optionally sealed to specified PCR
> -(integrity measurement) values, and only unsealed by the TPM, if PCRs and blob
> -integrity verifications match.  A loaded Trusted Key can be updated with new
> -(future) PCR values, so keys are easily migrated to new pcr values, such as
> -when the kernel and initramfs are updated.  The same key can have many saved
> -blobs under different PCR values, so multiple boots are easily supported.
>  
> -TPM 1.2
> --------
> +Trust Source
> +============
>  
> -By default, trusted keys are sealed under the SRK, which has the default
> -authorization value (20 zeros).  This can be set at takeownership time with the
> -trouser's utility: "tpm_takeownership -u -z".
> +Trust Source provides the source of security for the Trusted Keys, on which
> +basis Trusted Keys establishes a Trust model with its user.

A trust source provides the source of security for the Trusted
Keys.  Whether or not a trust source is sufficiently safe depends on
the strength and correctness of its implementation, as well as the
threat environment for a specific use case.  Since the kernel doesn't
know what the environment is, and there is no metric of trust, it is
dependent on the consumer of the Trusted Keys to determine if the trust
source is sufficiently safe.

>  A Trust Source could
> +differ from one system to another depending on its security requirements. It
> +could be either an off-chip device or an on-chip device. Following section
> +demostrates a list of supported devices along with their security properties/
> +guarantees:
>  
> -TPM 2.0
> --------
> +  *  Root of trust for storage
>  
> -The user must first create a storage key and make it persistent, so the key is
> -available after reboot. This can be done using the following commands.
> +     (1) TPM (Trusted Platform Module: hardware device)
> +
> +         Rooted to Storage Root Key (SRK) which never leaves the TPM that
> +         provides crypto operation to establish root of trust for storage.
> +
> +     (2) TEE (Trusted Execution Environment: OP-TEE based on Arm TrustZone)
> +
> +         Rooted to Hardware Unique Key (HUK) which is generally burnt in on-chip
> +         fuses and is accessible to TEE only.
> +
> +  *  Execution isolation
> +
> +     (1) TPM
> +
> +         Fixed set of operations running in isolated execution environment.
> +
> +     (2) TEE
> +
> +         Customizable set of operations running in isolated execution
> +         environment verified via Secure/Trusted boot process.
> +
> +  * Optional binding to platform integrity state
> +
> +     (1) TPM
> +
> +         Keys can be optionally sealed to specified PCR (integrity measurement)
> +         values, and only unsealed by the TPM, if PCRs and blob integrity
> +         verifications match. A loaded Trusted Key can be updated with new
> +         (future) PCR values, so keys are easily migrated to new PCR values,
> +         such as when the kernel and initramfs are updated. The same key can
> +         have many saved blobs under different PCR values, so multiple boots are
> +         easily supported.
> +
> +     (2) TEE
> +
> +         Relies on Secure/Trusted boot process for platform integrity. It can
> +         be extended with TEE based measured boot process.
> +
> +  *  On-chip versus off-chip
> +
> +     (1) TPM
> +
> +         Off-chip device connected via serial bus (like I2C, SPI etc.) exposing
> +         physical access which represents an attack surface that can be
> +         mitigated via tamper detection.
> +
> +     (2) TEE
> +
> +         On-chip functionality, immune to this attack surface.
> +
> +  *  Memory attacks (DRAM based like attaching a bus monitor etc.)
> +
> +     (1) TPM
> +
> +         Immune to these attacks as it doesn’t make use of system DRAM.
> +
> +     (2) TEE
> +
> +         An implementation based on TrustZone protected DRAM is susceptible to
> +         such attacks. In order to mitigate these attacks one needs to rely on
> +         on-chip secure RAM to store secrets or have the entire TEE
> +         implementation based on on-chip secure RAM. An alternative mitigation
> +         would be to use encrypted DRAM.
> +
> +  *  Side-channel attacks (cache, memory, CPU or time based)
> +
> +     (1) TPM
> +
> +         Immune to side-channel attacks as its resources are isolated from the
> +         main OS.
> +
> +     (2) TEE
> +
> +         A careful implementation is required to mitigate against these attacks
> +         for resources which are shared (eg. shared memory) with the main OS.
> +         Cache and CPU based side-channel attacks can be mitigated via
> +         invalidating caches and CPU registers during context switch to and from
> +         the secure world.
> +         To mitigate against time based attacks, one needs to have time
> +         invariant implementations (like crypto algorithms etc.).
> +
> +  *  Resistance to physical attacks (power analysis, electromagnetic emanation,
> +     probes etc.)
> +
> +     (1) TPM
> +
> +         Provides limited protection utilizing tamper resistance.
> +
> +     (2) TEE
> +
> +         Provides no protection by itself, relies on the underlying platform for
> +         features such as tamper resistance.
> +

Please add the following topics:

* Provisioning - the trust source's unique and verifiable cryptographic
identity is provisioned during manufacturing

(1) TPM

The unique and verifiable cryptographic identity is the endorsement key
(EK) or its primary seed.  A review of the generation of the EK and its
accompanying certificate is part of the Common Criteria evaluation of
the product's lifecycle processes (ALC_*).  See "TCG Protection Profile
for PC Client Specific TPM 2" (
https://trustedcomputinggroup.org/resource/pc-client-protection-profile-for-tpm-2-0/
).

(2) TEE

A protection profile for TEEs does not yet exist.  Therefore, the
provisioning process that generates the Hardware Unique Key is not
evaluated by an independent third party and is highly dependent on the
manufacturing environment.


* Cryptography

(1) TPM

As part of the TPM's mandatory Common Criteria evaluation, the
correctness of the TPM's implementation of cryptographic algorithms,
the protection of keys, and the generation of random numbers, and other
security-relevant functions must be documented, reviewed, and tested by
an independent third party evaluation agency.  It must meet the
requirements of FIPS 140-2, FIPS 140-3, or ISO/IEC 19790:2012. 

(2) TEE

Evaluations of cryptographic modules within TEEs are not required, but
some are available for specific implementations within TEEs.


* Interfaces and APIs

(1) TPM

 TPMs have well-documented, standardized interfaces and APIs.

(2) TEE

Unless TEEs implement functionality such as a virtual TPM, they have
custom interfaces and APIs. 


* Threat model

The strength and appropriateness of TPMs and TEEs for a given purpose
must be assessed when using them to protect security-relevant data.

> +
> +Key Generation
> +==============
> +
> +Trusted Keys
> +------------
> +
> +New keys are created from trust source generated random numbers, and are
> +encrypted/decrypted using trust source storage root key.

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.

Thank you,

Elaine (and Mimi)


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

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-08 15:55   ` Mimi Zohar
@ 2020-12-08 17:07     ` Mimi Zohar
  0 siblings, 0 replies; 52+ messages in thread
From: Mimi Zohar @ 2020-12-08 17:07 UTC (permalink / raw)
  To: Sumit Garg, jarkko.sakkinen, jejb, Elaine Palmer
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, George Wilson

Hi Sumit, Jarkko,

On Tue, 2020-12-08 at 10:55 -0500, Mimi Zohar wrote:
> Re-posting Elaine Palmer's comments, inline below, trimmed and properly
> formatted.

Continued ...

Thank you for the detailed descriptions and examples of trust sources
for Trusted Keys.  A group of us in IBM (Stefan Berger, Ken Goldman,
Zhongshu Gu, Nayna Jain, Elaine Palmer, George Wilson, Mimi Zohar) have
some concerns with extending trusted keys to new sources without
providing a threat model.   The following is based on our internal
discussions.

> * Threat model
> 
> The strength and appropriateness of TPMs and TEEs for a given purpose
> must be assessed when using them to protect security-relevant data.

The original Trusted Keys implementation assumed discrete physical TPMs
for key protection[1].  However, even physical TPMs themselves vary
based on the manufacturer and systems in which they are placed.  The
embedded chipset, firmware load, algorithms, packaging, pins, and
countermeasures vary.  (Threats and mitigations on physical TPMs are
well documented, e.g., "Threat Model of a Scenario Based on Trusted
Platform Module 2.0 Specification” (http://ceur-ws.org/Vol-1011/6.pdf).

Extending Trusted Keys to support new trust sources needs to provide
consumers of these new sources enough information so that they can
create their own threat models tailored to their use cases.

Just as each new LSM needs to comply with Documentation/security/lsm-
development.rst, we recommend each new source should provide a high-
level threat model.  We suggest documenting environmental assumptions
and dependencies in a high-level threat model for each additional trust
source.  An example of a high-level threat model is "Common Security
Threats v1.0” (
https://www.opencompute.org/documents/common-security-threats-notes-1-pdf
 ).

Thank you,

Elaine (and Mimi)


[1] Specific to Trusted Keys and TPMs, there is some discussion of
threats and mitigations in the Integrity_overview.pdf on the IMA wiki:

"The trusted key component does two things to help with secure key management on Linux. First, it provides a kernel key ring service in which the symmetric encryption keys are never visible in plain text to userspace. The keys are created in the kernel, and sealed by a hardware device such as a TPM, with userspace seeing only the sealed blobs. Malicious or compromised applications cannot steal a trusted key, since only the kernel can see the unsealed blobs. Secondly, the trusted keys can tie key unsealing to the integrity measurements, so that keys cannot be stolen in an offline attack, such as by booting an unlocked Linux image from CD or USB.  As the measurements will be different, the TPM chip will refuse to unseal the keys, even for the kernel."


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

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-08 15:02       ` Mimi Zohar
@ 2020-12-08 17:49         ` Jarkko Sakkinen
  2020-12-09 16:50           ` Mimi Zohar
  0 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2020-12-08 17:49 UTC (permalink / raw)
  To: Mimi Zohar, sumit.garg
  Cc: Elaine Palmer, jarkko.sakkinen, jejb, dhowells, jens.wiklander,
	corbet, jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee, Kenneth Goldman, gcwilson, zgu, stefanb, NAYNA JAIN1

On Tue, Dec 08, 2020 at 10:02:57AM -0500, Mimi Zohar wrote:
> Hi Jarkko,
> 
> On Fri, 2020-12-04 at 17:30 +0200, Jarkko Sakkinen wrote:
> > On Wed, Dec 02, 2020 at 02:34:07PM -0500, gmail Elaine Palmer wrote:
> > > Hi Sumit,  
> > > 
> > > Thank you for the detailed descriptions and examples of trust sources
> > > for Trusted Keys.   A group of us in IBM (Stefan Berger, Ken Goldman,
> > > Zhongshu Gu, Nayna Jain, Elaine Palmer, George Wilson, Mimi Zohar)
> > > have been doing related work for quite some time, and we have one
> > > primary concern and some suggested changes to the document. 
> > > 
> > > Our primary concern is that describing a TEE as a Trust Source needs
> > > to be more specific.   For example, "ARM TrustZone" is not sufficient,
> > > but "wolfSSL embedded SSL/TLS library with ARM TrustZone
> > > CryptoCell-310" is.  Just because a key is protected by software
> > > running in a TEE is not enough to establish trust.  Just like
> > > cryptographic modules, a Trust Source should be defined as a specific
> > > implementation on specific hardware with well-documented environmental
> > > assumptions, dependencies, and threats.
> > > 
> > > In addition to the above concern, our suggested changes are inline
> > > below.
> > 
> > In order to give a decent review comment it should have two ingredients:
> > 
> > - Where the existing line of code / text / whatever goes wrong.
> > - How it should modified and why that makes sense. And use as plain
> >   English and non-academic terms as possible, if it is documentation.
> >   Further, scope is only the kernel implementation, no more or no
> >   less.
> > 
> > "do this" is not unfortunately an argument. Feedback is welcome when
> > it is supported by something common sensse.
> 
> Even after the code is fully debugged, reviewed and tested, our concern
> is that people will assume the security guarantees of TEE based trusted
> keys to be equivalent to that of a discrete TPM.
> 
> > 
> > Some meta suggestion of related to email:
> > 
> > Please also use a proper email client and split your paragraphs into
> > at most 80 character lines with new line characters when writing email.
> > I prefer to use 72 character line length so that there's some space
> > for longer email threads.
> 
> Sure, we'll re-post the suggested documentation changes/additions.
> 
> Mimi

So. Wouldn't it be a better idea to post a patch that Sumit could
squash to his (and add co-developed-by tag)?

/Jarkko

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

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-08 17:49         ` Jarkko Sakkinen
@ 2020-12-09 16:50           ` Mimi Zohar
  2020-12-11 10:36             ` Jarkko Sakkinen
  0 siblings, 1 reply; 52+ messages in thread
From: Mimi Zohar @ 2020-12-09 16:50 UTC (permalink / raw)
  To: Jarkko Sakkinen, sumit.garg
  Cc: Elaine Palmer, jarkko.sakkinen, jejb, dhowells, jens.wiklander,
	corbet, jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee, Kenneth Goldman, gcwilson, zgu, stefanb, NAYNA JAIN1

On Tue, 2020-12-08 at 19:49 +0200, Jarkko Sakkinen wrote:
> On Tue, Dec 08, 2020 at 10:02:57AM -0500, Mimi Zohar wrote:

> > > Please also use a proper email client and split your paragraphs into
> > > at most 80 character lines with new line characters when writing email.
> > > I prefer to use 72 character line length so that there's some space
> > > for longer email threads.
> > 
> > Sure, we'll re-post the suggested documentation changes/additions.
> > 
> > Mimi
> 
> So. Wouldn't it be a better idea to post a patch that Sumit could
> squash to his (and add co-developed-by tag)?

I just posted it on Elaine's behalf.
  
Mimi


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

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-09 16:50           ` Mimi Zohar
@ 2020-12-11 10:36             ` Jarkko Sakkinen
  2020-12-11 15:29               ` Mimi Zohar
  0 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2020-12-11 10:36 UTC (permalink / raw)
  To: Mimi Zohar
  Cc: sumit.garg, Elaine Palmer, jarkko.sakkinen, jejb, dhowells,
	jens.wiklander, corbet, jmorris, serge, casey, janne.karhunen,
	daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Kenneth Goldman, gcwilson, zgu,
	stefanb, NAYNA JAIN1

On Wed, Dec 09, 2020 at 11:50:19AM -0500, Mimi Zohar wrote:
> On Tue, 2020-12-08 at 19:49 +0200, Jarkko Sakkinen wrote:
> > On Tue, Dec 08, 2020 at 10:02:57AM -0500, Mimi Zohar wrote:
> 
> > > > Please also use a proper email client and split your paragraphs into
> > > > at most 80 character lines with new line characters when writing email.
> > > > I prefer to use 72 character line length so that there's some space
> > > > for longer email threads.
> > > 
> > > Sure, we'll re-post the suggested documentation changes/additions.
> > > 
> > > Mimi
> > 
> > So. Wouldn't it be a better idea to post a patch that Sumit could
> > squash to his (and add co-developed-by tag)?
> 
> I just posted it on Elaine's behalf.
>   
> Mimi

I responded. It's good that this feedback came as I think the whole
thing does not have the correct label for it.

/Jarkko

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

* Re: [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source
  2020-12-11 10:36             ` Jarkko Sakkinen
@ 2020-12-11 15:29               ` Mimi Zohar
  0 siblings, 0 replies; 52+ messages in thread
From: Mimi Zohar @ 2020-12-11 15:29 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: sumit.garg, Elaine Palmer, jarkko.sakkinen, jejb, dhowells,
	jens.wiklander, corbet, jmorris, serge, casey, janne.karhunen,
	daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee, Kenneth Goldman, gcwilson, zgu,
	stefanb, NAYNA JAIN1, Zohargshu Gu

On Fri, 2020-12-11 at 12:36 +0200, Jarkko Sakkinen wrote:
> On Wed, Dec 09, 2020 at 11:50:19AM -0500, Mimi Zohar wrote:
> > On Tue, 2020-12-08 at 19:49 +0200, Jarkko Sakkinen wrote:
> > > On Tue, Dec 08, 2020 at 10:02:57AM -0500, Mimi Zohar wrote:
> > 
> > > > > Please also use a proper email client and split your paragraphs into
> > > > > at most 80 character lines with new line characters when writing email.
> > > > > I prefer to use 72 character line length so that there's some space
> > > > > for longer email threads.
> > > > 
> > > > Sure, we'll re-post the suggested documentation changes/additions.
> > > > 
> > > 
> > > So. Wouldn't it be a better idea to post a patch that Sumit could
> > > squash to his (and add co-developed-by tag)?
> > 
> > I just posted it on Elaine's behalf.
> >   
> 
> I responded. It's good that this feedback came as I think the whole
> thing does not have the correct label for it.

Every HW is going to want to add "trusted keys" support.   We've seen
this with Udit Agarwal's "secure keys" proposal for NXP CAAM crypto HW
accelerator.  If we go down this route to extend "trusted keys" to
support specific implementations like this one, I strongly recommend
requiring an accompaying high-level threat model.  This is similar to
how new LSMs need to comply with Documentation/security/lsm-
development.rst.

Based on Elaine's work with OCP, an example of a high-level threat
model is "Common Security Threats v1.0” (
https://www.opencompute.org/documents/common-security-threats-notes-1-pdf
 ).

thanks,

Mimi


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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2020-11-03 16:01 ` [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg
  2020-11-24  3:46   ` Jarkko Sakkinen
@ 2021-01-11 16:35   ` Jarkko Sakkinen
  2021-01-13 11:17     ` Sumit Garg
  2021-01-20 13:36   ` Ahmad Fatoum
  2 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-01-11 16:35 UTC (permalink / raw)
  To: Sumit Garg
  Cc: jarkko.sakkinen, zohar, jejb, dhowells, jens.wiklander, corbet,
	jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee

On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> Add support for TEE based trusted keys where TEE provides the functionality
> to seal and unseal trusted keys using hardware unique key.
> 
> Refer to Documentation/tee.txt for detailed information about TEE.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>

I haven't yet got QEMU environment working with aarch64, this produces
just a blank screen:

./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio

My BuildRoot fork for TPM and keyring testing is located over here:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/

The "ARM version" is at this point in aarch64 branch. Over time I will
define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
in the master branch.

To create identical images you just need to

$ make tpmdd_defconfig && make

Can you check if you see anything obviously wrong? I'm eager to test this
patch set, and in bigger picture I really need to have ready to run
aarch64 environment available.

/Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-11 16:35   ` Jarkko Sakkinen
@ 2021-01-13 11:17     ` Sumit Garg
  2021-01-14  2:05       ` Jarkko Sakkinen
  0 siblings, 1 reply; 52+ messages in thread
From: Sumit Garg @ 2021-01-13 11:17 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

Hi Jarkko,

On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > Add support for TEE based trusted keys where TEE provides the functionality
> > to seal and unseal trusted keys using hardware unique key.
> >
> > Refer to Documentation/tee.txt for detailed information about TEE.
> >
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
>
> I haven't yet got QEMU environment working with aarch64, this produces
> just a blank screen:
>
> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
>
> My BuildRoot fork for TPM and keyring testing is located over here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
>
> The "ARM version" is at this point in aarch64 branch. Over time I will
> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> in the master branch.
>
> To create identical images you just need to
>
> $ make tpmdd_defconfig && make
>
> Can you check if you see anything obviously wrong? I'm eager to test this
> patch set, and in bigger picture I really need to have ready to run
> aarch64 environment available.

I would rather suggest you to follow steps listed here [1] as to test
this feature on Qemu aarch64 we need to build firmwares such as TF-A,
OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
system [2]. And then it would be easier to migrate them to your
buildroot environment as well.

[1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
[2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8

-Sumit

>
> /Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-13 11:17     ` Sumit Garg
@ 2021-01-14  2:05       ` Jarkko Sakkinen
  2021-01-15  6:02         ` Sumit Garg
  0 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-01-14  2:05 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> Hi Jarkko,
> 
> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > Add support for TEE based trusted keys where TEE provides the functionality
> > > to seal and unseal trusted keys using hardware unique key.
> > >
> > > Refer to Documentation/tee.txt for detailed information about TEE.
> > >
> > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> >
> > I haven't yet got QEMU environment working with aarch64, this produces
> > just a blank screen:
> >
> > ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> >
> > My BuildRoot fork for TPM and keyring testing is located over here:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> >
> > The "ARM version" is at this point in aarch64 branch. Over time I will
> > define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > in the master branch.
> >
> > To create identical images you just need to
> >
> > $ make tpmdd_defconfig && make
> >
> > Can you check if you see anything obviously wrong? I'm eager to test this
> > patch set, and in bigger picture I really need to have ready to run
> > aarch64 environment available.
> 
> I would rather suggest you to follow steps listed here [1] as to test
> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> system [2]. And then it would be easier to migrate them to your
> buildroot environment as well.
> 
> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> 
> -Sumit

Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.

After I've successfully tested 2/4, I'd suggest that you roll out one more
version and CC the documentation patch to Elaine and Mini, and clearly
remark in the commit message that TEE is a standard, with a link to the
specification.

/Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-14  2:05       ` Jarkko Sakkinen
@ 2021-01-15  6:02         ` Sumit Garg
  2021-01-19 10:30           ` Jarkko Sakkinen
  0 siblings, 1 reply; 52+ messages in thread
From: Sumit Garg @ 2021-01-15  6:02 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > Hi Jarkko,
> >
> > On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >
> > > On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > > Add support for TEE based trusted keys where TEE provides the functionality
> > > > to seal and unseal trusted keys using hardware unique key.
> > > >
> > > > Refer to Documentation/tee.txt for detailed information about TEE.
> > > >
> > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > >
> > > I haven't yet got QEMU environment working with aarch64, this produces
> > > just a blank screen:
> > >
> > > ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > >
> > > My BuildRoot fork for TPM and keyring testing is located over here:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > >
> > > The "ARM version" is at this point in aarch64 branch. Over time I will
> > > define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > in the master branch.
> > >
> > > To create identical images you just need to
> > >
> > > $ make tpmdd_defconfig && make
> > >
> > > Can you check if you see anything obviously wrong? I'm eager to test this
> > > patch set, and in bigger picture I really need to have ready to run
> > > aarch64 environment available.
> >
> > I would rather suggest you to follow steps listed here [1] as to test
> > this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > system [2]. And then it would be easier to migrate them to your
> > buildroot environment as well.
> >
> > [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> >
> > -Sumit
>
> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
>

$ cat keyctl_change
diff --git a/common.mk b/common.mk
index aeb7b41..663e528 100644
--- a/common.mk
+++ b/common.mk
@@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
 BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
 BR2_PACKAGE_STRACE ?= y
 BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
$(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
+BR2_PACKAGE_KEYUTILS := y

 # All BR2_* variables from the makefile or the environment are appended to
 # ../out-br/extra.conf. All values are quoted "..." except y and n.
diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
index 368c18a..832ab74 100644
--- a/kconfigs/qemu.conf
+++ b/kconfigs/qemu.conf
@@ -20,3 +20,5 @@ CONFIG_9P_FS=y
 CONFIG_9P_FS_POSIX_ACL=y
 CONFIG_HW_RANDOM=y
 CONFIG_HW_RANDOM_VIRTIO=y
+CONFIG_TRUSTED_KEYS=y
+CONFIG_ENCRYPTED_KEYS=y

> After I've successfully tested 2/4, I'd suggest that you roll out one more
> version and CC the documentation patch to Elaine and Mini, and clearly
> remark in the commit message that TEE is a standard, with a link to the
> specification.
>

Sure, I will roll out the next version after your testing.

-Sumit

> /Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-15  6:02         ` Sumit Garg
@ 2021-01-19 10:30           ` Jarkko Sakkinen
  2021-01-20  1:31             ` Jarkko Sakkinen
  0 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-01-19 10:30 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > > Hi Jarkko,
> > >
> > > On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >
> > > > On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > > > Add support for TEE based trusted keys where TEE provides the functionality
> > > > > to seal and unseal trusted keys using hardware unique key.
> > > > >
> > > > > Refer to Documentation/tee.txt for detailed information about TEE.
> > > > >
> > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > >
> > > > I haven't yet got QEMU environment working with aarch64, this produces
> > > > just a blank screen:
> > > >
> > > > ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > > >
> > > > My BuildRoot fork for TPM and keyring testing is located over here:
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > > >
> > > > The "ARM version" is at this point in aarch64 branch. Over time I will
> > > > define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > > in the master branch.
> > > >
> > > > To create identical images you just need to
> > > >
> > > > $ make tpmdd_defconfig && make
> > > >
> > > > Can you check if you see anything obviously wrong? I'm eager to test this
> > > > patch set, and in bigger picture I really need to have ready to run
> > > > aarch64 environment available.
> > >
> > > I would rather suggest you to follow steps listed here [1] as to test
> > > this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > > OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > > system [2]. And then it would be easier to migrate them to your
> > > buildroot environment as well.
> > >
> > > [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > > [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > >
> > > -Sumit
> >
> > Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> >
> 
> $ cat keyctl_change
> diff --git a/common.mk b/common.mk
> index aeb7b41..663e528 100644
> --- a/common.mk
> +++ b/common.mk
> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
>  BR2_PACKAGE_STRACE ?= y
>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> +BR2_PACKAGE_KEYUTILS := y
> 
>  # All BR2_* variables from the makefile or the environment are appended to
>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> index 368c18a..832ab74 100644
> --- a/kconfigs/qemu.conf
> +++ b/kconfigs/qemu.conf
> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
>  CONFIG_9P_FS_POSIX_ACL=y
>  CONFIG_HW_RANDOM=y
>  CONFIG_HW_RANDOM_VIRTIO=y
> +CONFIG_TRUSTED_KEYS=y
> +CONFIG_ENCRYPTED_KEYS=y
> 
> > After I've successfully tested 2/4, I'd suggest that you roll out one more
> > version and CC the documentation patch to Elaine and Mini, and clearly
> > remark in the commit message that TEE is a standard, with a link to the
> > specification.
> >
> 
> Sure, I will roll out the next version after your testing.

Thanks, I'll try this at instant, and give my feedback.

/Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-19 10:30           ` Jarkko Sakkinen
@ 2021-01-20  1:31             ` Jarkko Sakkinen
  2021-01-20  7:23               ` Sumit Garg
  0 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-01-20  1:31 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >
> > > On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > > > Hi Jarkko,
> > > >
> > > > On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > >
> > > > > On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > > > > Add support for TEE based trusted keys where TEE provides the functionality
> > > > > > to seal and unseal trusted keys using hardware unique key.
> > > > > >
> > > > > > Refer to Documentation/tee.txt for detailed information about TEE.
> > > > > >
> > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > >
> > > > > I haven't yet got QEMU environment working with aarch64, this produces
> > > > > just a blank screen:
> > > > >
> > > > > ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > > > >
> > > > > My BuildRoot fork for TPM and keyring testing is located over here:
> > > > >
> > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > > > >
> > > > > The "ARM version" is at this point in aarch64 branch. Over time I will
> > > > > define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > > > in the master branch.
> > > > >
> > > > > To create identical images you just need to
> > > > >
> > > > > $ make tpmdd_defconfig && make
> > > > >
> > > > > Can you check if you see anything obviously wrong? I'm eager to test this
> > > > > patch set, and in bigger picture I really need to have ready to run
> > > > > aarch64 environment available.
> > > >
> > > > I would rather suggest you to follow steps listed here [1] as to test
> > > > this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > > > OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > > > system [2]. And then it would be easier to migrate them to your
> > > > buildroot environment as well.
> > > >
> > > > [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > > > [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > >
> > > > -Sumit
> > >
> > > Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> > >
> > 
> > $ cat keyctl_change
> > diff --git a/common.mk b/common.mk
> > index aeb7b41..663e528 100644
> > --- a/common.mk
> > +++ b/common.mk
> > @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> >  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> >  BR2_PACKAGE_STRACE ?= y
> >  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > +BR2_PACKAGE_KEYUTILS := y
> > 
> >  # All BR2_* variables from the makefile or the environment are appended to
> >  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> > diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> > index 368c18a..832ab74 100644
> > --- a/kconfigs/qemu.conf
> > +++ b/kconfigs/qemu.conf
> > @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> >  CONFIG_9P_FS_POSIX_ACL=y
> >  CONFIG_HW_RANDOM=y
> >  CONFIG_HW_RANDOM_VIRTIO=y
> > +CONFIG_TRUSTED_KEYS=y
> > +CONFIG_ENCRYPTED_KEYS=y
> > 
> > > After I've successfully tested 2/4, I'd suggest that you roll out one more
> > > version and CC the documentation patch to Elaine and Mini, and clearly
> > > remark in the commit message that TEE is a standard, with a link to the
> > > specification.
> > >
> > 
> > Sure, I will roll out the next version after your testing.
> 
> Thanks, I'll try this at instant, and give my feedback.

I bump into this:

$ make run-only
ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
make: *** [Makefile:194: run-only] Error 1

/Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-20  1:31             ` Jarkko Sakkinen
@ 2021-01-20  7:23               ` Sumit Garg
  2021-01-21  0:01                 ` Jarkko Sakkinen
       [not found]                 ` <01000177223f74d3-1eef7685-4a19-40d2-ace6-d4cd7f35579d-000000@email.amazonses.com>
  0 siblings, 2 replies; 52+ messages in thread
From: Sumit Garg @ 2021-01-20  7:23 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> > On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > > On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >
> > > > On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > > > > Hi Jarkko,
> > > > >
> > > > > On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > >
> > > > > > On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > > > > > Add support for TEE based trusted keys where TEE provides the functionality
> > > > > > > to seal and unseal trusted keys using hardware unique key.
> > > > > > >
> > > > > > > Refer to Documentation/tee.txt for detailed information about TEE.
> > > > > > >
> > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > >
> > > > > > I haven't yet got QEMU environment working with aarch64, this produces
> > > > > > just a blank screen:
> > > > > >
> > > > > > ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > > > > >
> > > > > > My BuildRoot fork for TPM and keyring testing is located over here:
> > > > > >
> > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > > > > >
> > > > > > The "ARM version" is at this point in aarch64 branch. Over time I will
> > > > > > define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > > > > in the master branch.
> > > > > >
> > > > > > To create identical images you just need to
> > > > > >
> > > > > > $ make tpmdd_defconfig && make
> > > > > >
> > > > > > Can you check if you see anything obviously wrong? I'm eager to test this
> > > > > > patch set, and in bigger picture I really need to have ready to run
> > > > > > aarch64 environment available.
> > > > >
> > > > > I would rather suggest you to follow steps listed here [1] as to test
> > > > > this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > > > > OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > > > > system [2]. And then it would be easier to migrate them to your
> > > > > buildroot environment as well.
> > > > >
> > > > > [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > > > > [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > >
> > > > > -Sumit
> > > >
> > > > Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> > > >
> > >
> > > $ cat keyctl_change
> > > diff --git a/common.mk b/common.mk
> > > index aeb7b41..663e528 100644
> > > --- a/common.mk
> > > +++ b/common.mk
> > > @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> > >  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> > >  BR2_PACKAGE_STRACE ?= y
> > >  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > > $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > > +BR2_PACKAGE_KEYUTILS := y
> > >
> > >  # All BR2_* variables from the makefile or the environment are appended to
> > >  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> > > diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> > > index 368c18a..832ab74 100644
> > > --- a/kconfigs/qemu.conf
> > > +++ b/kconfigs/qemu.conf
> > > @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> > >  CONFIG_9P_FS_POSIX_ACL=y
> > >  CONFIG_HW_RANDOM=y
> > >  CONFIG_HW_RANDOM_VIRTIO=y
> > > +CONFIG_TRUSTED_KEYS=y
> > > +CONFIG_ENCRYPTED_KEYS=y
> > >
> > > > After I've successfully tested 2/4, I'd suggest that you roll out one more
> > > > version and CC the documentation patch to Elaine and Mini, and clearly
> > > > remark in the commit message that TEE is a standard, with a link to the
> > > > specification.
> > > >
> > >
> > > Sure, I will roll out the next version after your testing.
> >
> > Thanks, I'll try this at instant, and give my feedback.
>
> I bump into this:
>
> $ make run-only
> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> make: *** [Makefile:194: run-only] Error 1
>

Could you check if the following directory tree is built after
executing the below command?

$ make -j`nproc`
CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c

$ tree out/bin/
out/bin/
├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
├── bl31.bin ->
/home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
├── bl32.bin ->
/home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
├── bl32_extra1.bin ->
/home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
├── bl32_extra2.bin ->
/home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
├── bl33.bin ->
/home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
└── rootfs.cpio.gz ->
/home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz

0 directories, 9 files

-Sumit

> /Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2020-11-03 16:01 ` [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg
  2020-11-24  3:46   ` Jarkko Sakkinen
  2021-01-11 16:35   ` Jarkko Sakkinen
@ 2021-01-20 13:36   ` Ahmad Fatoum
  2 siblings, 0 replies; 52+ messages in thread
From: Ahmad Fatoum @ 2021-01-20 13:36 UTC (permalink / raw)
  To: Sumit Garg, jarkko.sakkinen, zohar, jejb
  Cc: dhowells, jens.wiklander, corbet, jmorris, serge, casey,
	janne.karhunen, daniel.thompson, Markus.Wamser, lhinds, keyrings,
	linux-integrity, linux-security-module, linux-doc, linux-kernel,
	linux-arm-kernel, op-tee

Hello Sumit,

On 03.11.20 17:01, Sumit Garg wrote:
> Add support for TEE based trusted keys where TEE provides the functionality
> to seal and unseal trusted keys using hardware unique key.
> 
> Refer to Documentation/tee.txt for detailed information about TEE.
> 
> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> ---
>  include/keys/trusted_tee.h                |  55 ++++++
>  security/keys/trusted-keys/Makefile       |   1 +
>  security/keys/trusted-keys/trusted_core.c |   4 +
>  security/keys/trusted-keys/trusted_tee.c  | 278 ++++++++++++++++++++++++++++++
>  4 files changed, 338 insertions(+)
>  create mode 100644 include/keys/trusted_tee.h
>  create mode 100644 security/keys/trusted-keys/trusted_tee.c
> 
> diff --git a/include/keys/trusted_tee.h b/include/keys/trusted_tee.h
> new file mode 100644
> index 0000000..2e2bb15
> --- /dev/null
> +++ b/include/keys/trusted_tee.h
> @@ -0,0 +1,55 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) 2019-2020 Linaro Ltd.
> + *
> + * Author:
> + * Sumit Garg <sumit.garg@linaro.org>
> + */
> +
> +#ifndef __TEE_TRUSTED_KEY_H
> +#define __TEE_TRUSTED_KEY_H
> +
> +#include <linux/tee_drv.h>
> +
> +#define DRIVER_NAME "tee-trusted-key"

Looks unusual to define this in a header, especially when
it's included in trusted_core.c as well. Could you move it?

> +
> +/*
> + * Get random data for symmetric key
> + *
> + * [out]     memref[0]        Random data
> + */
> +#define TA_CMD_GET_RANDOM	0x0
> +
> +/*
> + * Seal trusted key using hardware unique key
> + *
> + * [in]      memref[0]        Plain key
> + * [out]     memref[1]        Sealed key datablob
> + */
> +#define TA_CMD_SEAL		0x1
> +
> +/*
> + * Unseal trusted key using hardware unique key
> + *
> + * [in]      memref[0]        Sealed key datablob
> + * [out]     memref[1]        Plain key
> + */
> +#define TA_CMD_UNSEAL		0x2

These also look like implementation-specific stuff
that should go into trusted_tee.c?

> +
> +/**
> + * struct trusted_key_private - TEE Trusted key private data
> + * @dev:		TEE based Trusted key device.
> + * @ctx:		TEE context handler.
> + * @session_id:		Trusted key TA session identifier.
> + * @shm_pool:		Memory pool shared with TEE device.
> + */
> +struct trusted_key_private {

This is name is a bit too generic. Either move it to trusted_tee
or put a caam_ prefix in front?

> +	struct device *dev;
> +	struct tee_context *ctx;
> +	u32 session_id;
> +	struct tee_shm *shm_pool;
> +};
> +
> +extern struct trusted_key_ops tee_trusted_key_ops;

This looks like the only thing that must be in this header.

> +
> +#endif
> diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
> index 49e3bcf..012dd78 100644
> --- a/security/keys/trusted-keys/Makefile
> +++ b/security/keys/trusted-keys/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
>  trusted-y += trusted_core.o
>  trusted-y += trusted_tpm1.o
>  trusted-y += trusted_tpm2.o
> +trusted-y += trusted_tee.o

Shouldn't this depend on CONFIG_TEE or similar? Otherwise without LTO, you'd
run into linker errors.

[Apologies if these points were raised in previous review cycles, I just
 recently subscribed]

Cheers,
Ahmad

> diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> index aa4f2a0..15b1b0f3 100644
> --- a/security/keys/trusted-keys/trusted_core.c
> +++ b/security/keys/trusted-keys/trusted_core.c
> @@ -8,6 +8,7 @@
>  
>  #include <keys/user-type.h>
>  #include <keys/trusted-type.h>
> +#include <keys/trusted_tee.h>
>  #include <keys/trusted_tpm.h>
>  #include <linux/capability.h>
>  #include <linux/err.h>
> @@ -29,6 +30,9 @@ static const struct trusted_key_source trusted_key_sources[] = {
>  #if defined(CONFIG_TCG_TPM)
>  	{ "tpm", &tpm_trusted_key_ops },
>  #endif
> +#if defined(CONFIG_TEE)
> +	{ "tee", &tee_trusted_key_ops },
> +#endif
>  };
>  
>  DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
> diff --git a/security/keys/trusted-keys/trusted_tee.c b/security/keys/trusted-keys/trusted_tee.c
> new file mode 100644
> index 0000000..da8785a
> --- /dev/null
> +++ b/security/keys/trusted-keys/trusted_tee.c
> @@ -0,0 +1,278 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2019-2020 Linaro Ltd.
> + *
> + * Author:
> + * Sumit Garg <sumit.garg@linaro.org>
> + */
> +
> +#include <linux/err.h>
> +#include <linux/key-type.h>
> +#include <linux/slab.h>
> +#include <linux/string.h>
> +#include <linux/uuid.h>
> +
> +#include <keys/trusted-type.h>
> +#include <keys/trusted_tee.h>
> +
> +static struct trusted_key_private pvt_data;
> +
> +/*
> + * Have the TEE seal(encrypt) the symmetric key
> + */
> +static int trusted_tee_seal(struct trusted_key_payload *p, char *datablob)
> +{
> +	int ret;
> +	struct tee_ioctl_invoke_arg inv_arg;
> +	struct tee_param param[4];
> +	struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
> +
> +	memset(&inv_arg, 0, sizeof(inv_arg));
> +	memset(&param, 0, sizeof(param));
> +
> +	reg_shm_in = tee_shm_register(pvt_data.ctx, (unsigned long)p->key,
> +				      p->key_len, TEE_SHM_DMA_BUF |
> +				      TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm_in)) {
> +		dev_err(pvt_data.dev, "key shm register failed\n");
> +		return PTR_ERR(reg_shm_in);
> +	}
> +
> +	reg_shm_out = tee_shm_register(pvt_data.ctx, (unsigned long)p->blob,
> +				       sizeof(p->blob), TEE_SHM_DMA_BUF |
> +				       TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm_out)) {
> +		dev_err(pvt_data.dev, "blob shm register failed\n");
> +		ret = PTR_ERR(reg_shm_out);
> +		goto out;
> +	}
> +
> +	inv_arg.func = TA_CMD_SEAL;
> +	inv_arg.session = pvt_data.session_id;
> +	inv_arg.num_params = 4;
> +
> +	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
> +	param[0].u.memref.shm = reg_shm_in;
> +	param[0].u.memref.size = p->key_len;
> +	param[0].u.memref.shm_offs = 0;
> +	param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
> +	param[1].u.memref.shm = reg_shm_out;
> +	param[1].u.memref.size = sizeof(p->blob);
> +	param[1].u.memref.shm_offs = 0;
> +
> +	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
> +	if ((ret < 0) || (inv_arg.ret != 0)) {
> +		dev_err(pvt_data.dev, "TA_CMD_SEAL invoke err: %x\n",
> +			inv_arg.ret);
> +		ret = -EFAULT;
> +	} else {
> +		p->blob_len = param[1].u.memref.size;
> +	}
> +
> +out:
> +	if (reg_shm_out)
> +		tee_shm_free(reg_shm_out);
> +	if (reg_shm_in)
> +		tee_shm_free(reg_shm_in);
> +
> +	return ret;
> +}
> +
> +/*
> + * Have the TEE unseal(decrypt) the symmetric key
> + */
> +static int trusted_tee_unseal(struct trusted_key_payload *p, char *datablob)
> +{
> +	int ret;
> +	struct tee_ioctl_invoke_arg inv_arg;
> +	struct tee_param param[4];
> +	struct tee_shm *reg_shm_in = NULL, *reg_shm_out = NULL;
> +
> +	memset(&inv_arg, 0, sizeof(inv_arg));
> +	memset(&param, 0, sizeof(param));
> +
> +	reg_shm_in = tee_shm_register(pvt_data.ctx, (unsigned long)p->blob,
> +				      p->blob_len, TEE_SHM_DMA_BUF |
> +				      TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm_in)) {
> +		dev_err(pvt_data.dev, "blob shm register failed\n");
> +		return PTR_ERR(reg_shm_in);
> +	}
> +
> +	reg_shm_out = tee_shm_register(pvt_data.ctx, (unsigned long)p->key,
> +				       sizeof(p->key), TEE_SHM_DMA_BUF |
> +				       TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm_out)) {
> +		dev_err(pvt_data.dev, "key shm register failed\n");
> +		ret = PTR_ERR(reg_shm_out);
> +		goto out;
> +	}
> +
> +	inv_arg.func = TA_CMD_UNSEAL;
> +	inv_arg.session = pvt_data.session_id;
> +	inv_arg.num_params = 4;
> +
> +	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT;
> +	param[0].u.memref.shm = reg_shm_in;
> +	param[0].u.memref.size = p->blob_len;
> +	param[0].u.memref.shm_offs = 0;
> +	param[1].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
> +	param[1].u.memref.shm = reg_shm_out;
> +	param[1].u.memref.size = sizeof(p->key);
> +	param[1].u.memref.shm_offs = 0;
> +
> +	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
> +	if ((ret < 0) || (inv_arg.ret != 0)) {
> +		dev_err(pvt_data.dev, "TA_CMD_UNSEAL invoke err: %x\n",
> +			inv_arg.ret);
> +		ret = -EFAULT;
> +	} else {
> +		p->key_len = param[1].u.memref.size;
> +	}
> +
> +out:
> +	if (reg_shm_out)
> +		tee_shm_free(reg_shm_out);
> +	if (reg_shm_in)
> +		tee_shm_free(reg_shm_in);
> +
> +	return ret;
> +}
> +
> +/*
> + * Have the TEE generate random symmetric key
> + */
> +static int trusted_tee_get_random(unsigned char *key, size_t key_len)
> +{
> +	int ret;
> +	struct tee_ioctl_invoke_arg inv_arg;
> +	struct tee_param param[4];
> +	struct tee_shm *reg_shm = NULL;
> +
> +	memset(&inv_arg, 0, sizeof(inv_arg));
> +	memset(&param, 0, sizeof(param));
> +
> +	reg_shm = tee_shm_register(pvt_data.ctx, (unsigned long)key, key_len,
> +				   TEE_SHM_DMA_BUF | TEE_SHM_KERNEL_MAPPED);
> +	if (IS_ERR(reg_shm)) {
> +		dev_err(pvt_data.dev, "key shm register failed\n");
> +		return PTR_ERR(reg_shm);
> +	}
> +
> +	inv_arg.func = TA_CMD_GET_RANDOM;
> +	inv_arg.session = pvt_data.session_id;
> +	inv_arg.num_params = 4;
> +
> +	param[0].attr = TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT;
> +	param[0].u.memref.shm = reg_shm;
> +	param[0].u.memref.size = key_len;
> +	param[0].u.memref.shm_offs = 0;
> +
> +	ret = tee_client_invoke_func(pvt_data.ctx, &inv_arg, param);
> +	if ((ret < 0) || (inv_arg.ret != 0)) {
> +		dev_err(pvt_data.dev, "TA_CMD_GET_RANDOM invoke err: %x\n",
> +			inv_arg.ret);
> +		ret = -EFAULT;
> +	} else {
> +		ret = param[0].u.memref.size;
> +	}
> +
> +	tee_shm_free(reg_shm);
> +
> +	return ret;
> +}
> +
> +static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
> +{
> +	if (ver->impl_id == TEE_IMPL_ID_OPTEE)
> +		return 1;
> +	else
> +		return 0;
> +}
> +
> +static int trusted_key_probe(struct device *dev)
> +{
> +	struct tee_client_device *rng_device = to_tee_client_device(dev);
> +	int ret;
> +	struct tee_ioctl_open_session_arg sess_arg;
> +
> +	memset(&sess_arg, 0, sizeof(sess_arg));
> +
> +	pvt_data.ctx = tee_client_open_context(NULL, optee_ctx_match, NULL,
> +					       NULL);
> +	if (IS_ERR(pvt_data.ctx))
> +		return -ENODEV;
> +
> +	memcpy(sess_arg.uuid, rng_device->id.uuid.b, TEE_IOCTL_UUID_LEN);
> +	sess_arg.clnt_login = TEE_IOCTL_LOGIN_REE_KERNEL;
> +	sess_arg.num_params = 0;
> +
> +	ret = tee_client_open_session(pvt_data.ctx, &sess_arg, NULL);
> +	if ((ret < 0) || (sess_arg.ret != 0)) {
> +		dev_err(dev, "tee_client_open_session failed, err: %x\n",
> +			sess_arg.ret);
> +		ret = -EINVAL;
> +		goto out_ctx;
> +	}
> +	pvt_data.session_id = sess_arg.session;
> +
> +	ret = register_key_type(&key_type_trusted);
> +	if (ret < 0)
> +		goto out_sess;
> +
> +	pvt_data.dev = dev;
> +
> +	return 0;
> +
> +out_sess:
> +	tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
> +out_ctx:
> +	tee_client_close_context(pvt_data.ctx);
> +
> +	return ret;
> +}
> +
> +static int trusted_key_remove(struct device *dev)
> +{
> +	unregister_key_type(&key_type_trusted);
> +	tee_client_close_session(pvt_data.ctx, pvt_data.session_id);
> +	tee_client_close_context(pvt_data.ctx);
> +
> +	return 0;
> +}
> +
> +static const struct tee_client_device_id trusted_key_id_table[] = {
> +	{UUID_INIT(0xf04a0fe7, 0x1f5d, 0x4b9b,
> +		   0xab, 0xf7, 0x61, 0x9b, 0x85, 0xb4, 0xce, 0x8c)},
> +	{}
> +};
> +MODULE_DEVICE_TABLE(tee, trusted_key_id_table);
> +
> +static struct tee_client_driver trusted_key_driver = {
> +	.id_table	= trusted_key_id_table,
> +	.driver		= {
> +		.name		= DRIVER_NAME,
> +		.bus		= &tee_bus_type,
> +		.probe		= trusted_key_probe,
> +		.remove		= trusted_key_remove,
> +	},
> +};
> +
> +static int trusted_tee_init(void)
> +{
> +	return driver_register(&trusted_key_driver.driver);
> +}
> +
> +static void trusted_tee_exit(void)
> +{
> +	driver_unregister(&trusted_key_driver.driver);
> +}
> +
> +struct trusted_key_ops tee_trusted_key_ops = {
> +	.migratable = 0, /* non-migratable */
> +	.init = trusted_tee_init,
> +	.seal = trusted_tee_seal,
> +	.unseal = trusted_tee_unseal,
> +	.get_random = trusted_tee_get_random,
> +	.exit = trusted_tee_exit,
> +};
> 

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-20  7:23               ` Sumit Garg
@ 2021-01-21  0:01                 ` Jarkko Sakkinen
       [not found]                 ` <01000177223f74d3-1eef7685-4a19-40d2-ace6-d4cd7f35579d-000000@email.amazonses.com>
  1 sibling, 0 replies; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-01-21  0:01 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> > > On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > > > On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > >
> > > > > On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > > > > > Hi Jarkko,
> > > > > >
> > > > > > On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > > >
> > > > > > > On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > > > > > > Add support for TEE based trusted keys where TEE provides the functionality
> > > > > > > > to seal and unseal trusted keys using hardware unique key.
> > > > > > > >
> > > > > > > > Refer to Documentation/tee.txt for detailed information about TEE.
> > > > > > > >
> > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > >
> > > > > > > I haven't yet got QEMU environment working with aarch64, this produces
> > > > > > > just a blank screen:
> > > > > > >
> > > > > > > ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > > > > > >
> > > > > > > My BuildRoot fork for TPM and keyring testing is located over here:
> > > > > > >
> > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > > > > > >
> > > > > > > The "ARM version" is at this point in aarch64 branch. Over time I will
> > > > > > > define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > > > > > in the master branch.
> > > > > > >
> > > > > > > To create identical images you just need to
> > > > > > >
> > > > > > > $ make tpmdd_defconfig && make
> > > > > > >
> > > > > > > Can you check if you see anything obviously wrong? I'm eager to test this
> > > > > > > patch set, and in bigger picture I really need to have ready to run
> > > > > > > aarch64 environment available.
> > > > > >
> > > > > > I would rather suggest you to follow steps listed here [1] as to test
> > > > > > this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > > > > > OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > > > > > system [2]. And then it would be easier to migrate them to your
> > > > > > buildroot environment as well.
> > > > > >
> > > > > > [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > > > > > [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > > >
> > > > > > -Sumit
> > > > >
> > > > > Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> > > > >
> > > >
> > > > $ cat keyctl_change
> > > > diff --git a/common.mk b/common.mk
> > > > index aeb7b41..663e528 100644
> > > > --- a/common.mk
> > > > +++ b/common.mk
> > > > @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> > > >  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> > > >  BR2_PACKAGE_STRACE ?= y
> > > >  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > > > $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > > > +BR2_PACKAGE_KEYUTILS := y
> > > >
> > > >  # All BR2_* variables from the makefile or the environment are appended to
> > > >  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> > > > diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> > > > index 368c18a..832ab74 100644
> > > > --- a/kconfigs/qemu.conf
> > > > +++ b/kconfigs/qemu.conf
> > > > @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> > > >  CONFIG_9P_FS_POSIX_ACL=y
> > > >  CONFIG_HW_RANDOM=y
> > > >  CONFIG_HW_RANDOM_VIRTIO=y
> > > > +CONFIG_TRUSTED_KEYS=y
> > > > +CONFIG_ENCRYPTED_KEYS=y
> > > >
> > > > > After I've successfully tested 2/4, I'd suggest that you roll out one more
> > > > > version and CC the documentation patch to Elaine and Mini, and clearly
> > > > > remark in the commit message that TEE is a standard, with a link to the
> > > > > specification.
> > > > >
> > > >
> > > > Sure, I will roll out the next version after your testing.
> > >
> > > Thanks, I'll try this at instant, and give my feedback.
> >
> > I bump into this:
> >
> > $ make run-only
> > ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> > ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> > make: *** [Makefile:194: run-only] Error 1
> >
> 
> Could you check if the following directory tree is built after
> executing the below command?
> 
> $ make -j`nproc`
> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
> 
> $ tree out/bin/
> out/bin/
> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
> ├── bl31.bin ->
> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
> ├── bl32.bin ->
> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
> ├── bl32_extra1.bin ->
> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
> ├── bl32_extra2.bin ->
> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
> ├── bl33.bin ->
> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
> └── rootfs.cpio.gz ->
> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
> 
> 0 directories, 9 files
> 
> -Sumit

I actually spotted a build error that was unnoticed last time:

make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
/bin/sh: 1: python: not found

I'd prefer not to install Python2. It has been EOL over a year.

/Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
       [not found]                 ` <01000177223f74d3-1eef7685-4a19-40d2-ace6-d4cd7f35579d-000000@email.amazonses.com>
@ 2021-01-21  8:44                   ` Jerome Forissier
  2021-01-21 15:07                     ` Jarkko Sakkinen
  0 siblings, 1 reply; 52+ messages in thread
From: Jerome Forissier @ 2021-01-21  8:44 UTC (permalink / raw)
  To: Jarkko Sakkinen, Sumit Garg
  Cc: open list:SECURITY SUBSYSTEM, Daniel Thompson, op-tee,
	Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn



On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
>> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>>>
>>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
>>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
>>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>>>>>>
>>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
>>>>>>> Hi Jarkko,
>>>>>>>
>>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>>>>>>>>
>>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
>>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
>>>>>>>>> to seal and unseal trusted keys using hardware unique key.
>>>>>>>>>
>>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
>>>>>>>>
>>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
>>>>>>>> just a blank screen:
>>>>>>>>
>>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
>>>>>>>>
>>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
>>>>>>>>
>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
>>>>>>>>
>>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
>>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
>>>>>>>> in the master branch.
>>>>>>>>
>>>>>>>> To create identical images you just need to
>>>>>>>>
>>>>>>>> $ make tpmdd_defconfig && make
>>>>>>>>
>>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
>>>>>>>> patch set, and in bigger picture I really need to have ready to run
>>>>>>>> aarch64 environment available.
>>>>>>>
>>>>>>> I would rather suggest you to follow steps listed here [1] as to test
>>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
>>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
>>>>>>> system [2]. And then it would be easier to migrate them to your
>>>>>>> buildroot environment as well.
>>>>>>>
>>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
>>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
>>>>>>>
>>>>>>> -Sumit
>>>>>>
>>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
>>>>>>
>>>>>
>>>>> $ cat keyctl_change
>>>>> diff --git a/common.mk b/common.mk
>>>>> index aeb7b41..663e528 100644
>>>>> --- a/common.mk
>>>>> +++ b/common.mk
>>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
>>>>>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
>>>>>  BR2_PACKAGE_STRACE ?= y
>>>>>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
>>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
>>>>> +BR2_PACKAGE_KEYUTILS := y
>>>>>
>>>>>  # All BR2_* variables from the makefile or the environment are appended to
>>>>>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
>>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
>>>>> index 368c18a..832ab74 100644
>>>>> --- a/kconfigs/qemu.conf
>>>>> +++ b/kconfigs/qemu.conf
>>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
>>>>>  CONFIG_9P_FS_POSIX_ACL=y
>>>>>  CONFIG_HW_RANDOM=y
>>>>>  CONFIG_HW_RANDOM_VIRTIO=y
>>>>> +CONFIG_TRUSTED_KEYS=y
>>>>> +CONFIG_ENCRYPTED_KEYS=y
>>>>>
>>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
>>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
>>>>>> remark in the commit message that TEE is a standard, with a link to the
>>>>>> specification.
>>>>>>
>>>>>
>>>>> Sure, I will roll out the next version after your testing.
>>>>
>>>> Thanks, I'll try this at instant, and give my feedback.
>>>
>>> I bump into this:
>>>
>>> $ make run-only
>>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
>>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
>>> make: *** [Makefile:194: run-only] Error 1
>>>
>>
>> Could you check if the following directory tree is built after
>> executing the below command?
>>
>> $ make -j`nproc`
>> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
>>
>> $ tree out/bin/
>> out/bin/
>> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
>> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
>> ├── bl31.bin ->
>> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
>> ├── bl32.bin ->
>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
>> ├── bl32_extra1.bin ->
>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
>> ├── bl32_extra2.bin ->
>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
>> ├── bl33.bin ->
>> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
>> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
>> └── rootfs.cpio.gz ->
>> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
>>
>> 0 directories, 9 files
>>
>> -Sumit
> 
> I actually spotted a build error that was unnoticed last time:
> 
> make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> /bin/sh: 1: python: not found
> 
> I'd prefer not to install Python2. It has been EOL over a year.

AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
machine, this is accomplished by installing package "python-is-python3"
(after uninstalling "python-is-python2" if need be).

$ ls -l /usr/bin/python
lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3

-- 
Jerome

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-21  8:44                   ` Jerome Forissier
@ 2021-01-21 15:07                     ` Jarkko Sakkinen
  2021-01-21 15:24                       ` Jarkko Sakkinen
  0 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-01-21 15:07 UTC (permalink / raw)
  To: Jerome Forissier
  Cc: Sumit Garg, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn

On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
> 
> 
> On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> > On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> >> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >>>
> >>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> >>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> >>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >>>>>>
> >>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> >>>>>>> Hi Jarkko,
> >>>>>>>
> >>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >>>>>>>>
> >>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> >>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
> >>>>>>>>> to seal and unseal trusted keys using hardware unique key.
> >>>>>>>>>
> >>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
> >>>>>>>>>
> >>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> >>>>>>>>
> >>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
> >>>>>>>> just a blank screen:
> >>>>>>>>
> >>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> >>>>>>>>
> >>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
> >>>>>>>>
> >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> >>>>>>>>
> >>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
> >>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> >>>>>>>> in the master branch.
> >>>>>>>>
> >>>>>>>> To create identical images you just need to
> >>>>>>>>
> >>>>>>>> $ make tpmdd_defconfig && make
> >>>>>>>>
> >>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
> >>>>>>>> patch set, and in bigger picture I really need to have ready to run
> >>>>>>>> aarch64 environment available.
> >>>>>>>
> >>>>>>> I would rather suggest you to follow steps listed here [1] as to test
> >>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> >>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> >>>>>>> system [2]. And then it would be easier to migrate them to your
> >>>>>>> buildroot environment as well.
> >>>>>>>
> >>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> >>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> >>>>>>>
> >>>>>>> -Sumit
> >>>>>>
> >>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> >>>>>>
> >>>>>
> >>>>> $ cat keyctl_change
> >>>>> diff --git a/common.mk b/common.mk
> >>>>> index aeb7b41..663e528 100644
> >>>>> --- a/common.mk
> >>>>> +++ b/common.mk
> >>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> >>>>>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> >>>>>  BR2_PACKAGE_STRACE ?= y
> >>>>>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> >>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> >>>>> +BR2_PACKAGE_KEYUTILS := y
> >>>>>
> >>>>>  # All BR2_* variables from the makefile or the environment are appended to
> >>>>>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> >>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> >>>>> index 368c18a..832ab74 100644
> >>>>> --- a/kconfigs/qemu.conf
> >>>>> +++ b/kconfigs/qemu.conf
> >>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> >>>>>  CONFIG_9P_FS_POSIX_ACL=y
> >>>>>  CONFIG_HW_RANDOM=y
> >>>>>  CONFIG_HW_RANDOM_VIRTIO=y
> >>>>> +CONFIG_TRUSTED_KEYS=y
> >>>>> +CONFIG_ENCRYPTED_KEYS=y
> >>>>>
> >>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
> >>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
> >>>>>> remark in the commit message that TEE is a standard, with a link to the
> >>>>>> specification.
> >>>>>>
> >>>>>
> >>>>> Sure, I will roll out the next version after your testing.
> >>>>
> >>>> Thanks, I'll try this at instant, and give my feedback.
> >>>
> >>> I bump into this:
> >>>
> >>> $ make run-only
> >>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> >>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> >>> make: *** [Makefile:194: run-only] Error 1
> >>>
> >>
> >> Could you check if the following directory tree is built after
> >> executing the below command?
> >>
> >> $ make -j`nproc`
> >> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
> >>
> >> $ tree out/bin/
> >> out/bin/
> >> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
> >> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
> >> ├── bl31.bin ->
> >> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
> >> ├── bl32.bin ->
> >> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
> >> ├── bl32_extra1.bin ->
> >> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
> >> ├── bl32_extra2.bin ->
> >> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
> >> ├── bl33.bin ->
> >> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
> >> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
> >> └── rootfs.cpio.gz ->
> >> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
> >>
> >> 0 directories, 9 files
> >>
> >> -Sumit
> > 
> > I actually spotted a build error that was unnoticed last time:
> > 
> > make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> > /bin/sh: 1: python: not found
> > 
> > I'd prefer not to install Python2. It has been EOL over a year.
> 
> AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
> machine, this is accomplished by installing package "python-is-python3"
> (after uninstalling "python-is-python2" if need be).
> 
> $ ls -l /usr/bin/python
> lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3

Right, just found about this in unrelated context :-) [*]

Hope this will work out...

[*] https://github.com/surge-synthesizer/surge/pull/3655

/Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-21 15:07                     ` Jarkko Sakkinen
@ 2021-01-21 15:24                       ` Jarkko Sakkinen
  2021-01-21 16:23                         ` Jerome Forissier
  0 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-01-21 15:24 UTC (permalink / raw)
  To: Jerome Forissier
  Cc: Sumit Garg, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn

On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote:
> On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
> > 
> > 
> > On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> > > On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> > >> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >>>
> > >>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> > >>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > >>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >>>>>>
> > >>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > >>>>>>> Hi Jarkko,
> > >>>>>>>
> > >>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >>>>>>>>
> > >>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > >>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
> > >>>>>>>>> to seal and unseal trusted keys using hardware unique key.
> > >>>>>>>>>
> > >>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
> > >>>>>>>>>
> > >>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > >>>>>>>>
> > >>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
> > >>>>>>>> just a blank screen:
> > >>>>>>>>
> > >>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > >>>>>>>>
> > >>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
> > >>>>>>>>
> > >>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > >>>>>>>>
> > >>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
> > >>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > >>>>>>>> in the master branch.
> > >>>>>>>>
> > >>>>>>>> To create identical images you just need to
> > >>>>>>>>
> > >>>>>>>> $ make tpmdd_defconfig && make
> > >>>>>>>>
> > >>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
> > >>>>>>>> patch set, and in bigger picture I really need to have ready to run
> > >>>>>>>> aarch64 environment available.
> > >>>>>>>
> > >>>>>>> I would rather suggest you to follow steps listed here [1] as to test
> > >>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > >>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > >>>>>>> system [2]. And then it would be easier to migrate them to your
> > >>>>>>> buildroot environment as well.
> > >>>>>>>
> > >>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > >>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > >>>>>>>
> > >>>>>>> -Sumit
> > >>>>>>
> > >>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> > >>>>>>
> > >>>>>
> > >>>>> $ cat keyctl_change
> > >>>>> diff --git a/common.mk b/common.mk
> > >>>>> index aeb7b41..663e528 100644
> > >>>>> --- a/common.mk
> > >>>>> +++ b/common.mk
> > >>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> > >>>>>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> > >>>>>  BR2_PACKAGE_STRACE ?= y
> > >>>>>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > >>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > >>>>> +BR2_PACKAGE_KEYUTILS := y
> > >>>>>
> > >>>>>  # All BR2_* variables from the makefile or the environment are appended to
> > >>>>>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> > >>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> > >>>>> index 368c18a..832ab74 100644
> > >>>>> --- a/kconfigs/qemu.conf
> > >>>>> +++ b/kconfigs/qemu.conf
> > >>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> > >>>>>  CONFIG_9P_FS_POSIX_ACL=y
> > >>>>>  CONFIG_HW_RANDOM=y
> > >>>>>  CONFIG_HW_RANDOM_VIRTIO=y
> > >>>>> +CONFIG_TRUSTED_KEYS=y
> > >>>>> +CONFIG_ENCRYPTED_KEYS=y
> > >>>>>
> > >>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
> > >>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
> > >>>>>> remark in the commit message that TEE is a standard, with a link to the
> > >>>>>> specification.
> > >>>>>>
> > >>>>>
> > >>>>> Sure, I will roll out the next version after your testing.
> > >>>>
> > >>>> Thanks, I'll try this at instant, and give my feedback.
> > >>>
> > >>> I bump into this:
> > >>>
> > >>> $ make run-only
> > >>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> > >>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> > >>> make: *** [Makefile:194: run-only] Error 1
> > >>>
> > >>
> > >> Could you check if the following directory tree is built after
> > >> executing the below command?
> > >>
> > >> $ make -j`nproc`
> > >> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
> > >>
> > >> $ tree out/bin/
> > >> out/bin/
> > >> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
> > >> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
> > >> ├── bl31.bin ->
> > >> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
> > >> ├── bl32.bin ->
> > >> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
> > >> ├── bl32_extra1.bin ->
> > >> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
> > >> ├── bl32_extra2.bin ->
> > >> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
> > >> ├── bl33.bin ->
> > >> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
> > >> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
> > >> └── rootfs.cpio.gz ->
> > >> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
> > >>
> > >> 0 directories, 9 files
> > >>
> > >> -Sumit
> > > 
> > > I actually spotted a build error that was unnoticed last time:
> > > 
> > > make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> > > /bin/sh: 1: python: not found
> > > 
> > > I'd prefer not to install Python2. It has been EOL over a year.
> > 
> > AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
> > machine, this is accomplished by installing package "python-is-python3"
> > (after uninstalling "python-is-python2" if need be).
> > 
> > $ ls -l /usr/bin/python
> > lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3
> 
> Right, just found about this in unrelated context :-) [*]
> 
> Hope this will work out...
> 
> [*] https://github.com/surge-synthesizer/surge/pull/3655

Now I get

Traceback (most recent call last):
  File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 36, in <module>
    allTests = GetAllTestsSuite()
  File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 33, in GetAllTestsSuite
    return unittest.TestSuite([GetCTestSuite(), GetPythonTestSuite()])
  File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 25, in GetCTestSuite
    import CToolsTests
  File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/CToolsTests.py", line 22, in <module>
    import TianoCompress
  File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TianoCompress.py", line 69, in <module>
    TheTestSuite = TestTools.MakeTheTestSuite(locals())
  File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TestTools.py", line 43, in MakeTheTestSuite
    for name, item in localItems.iteritems():
AttributeError: 'dict' object has no attribute 'iteritems'

/Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-21 15:24                       ` Jarkko Sakkinen
@ 2021-01-21 16:23                         ` Jerome Forissier
  2021-01-22 18:12                           ` Jarkko Sakkinen
  0 siblings, 1 reply; 52+ messages in thread
From: Jerome Forissier @ 2021-01-21 16:23 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Sumit Garg, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn



On 1/21/21 4:24 PM, Jarkko Sakkinen wrote:
> On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote:
>> On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
>>>
>>>
>>> On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
>>>> On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
>>>>> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>>>>>>
>>>>>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
>>>>>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
>>>>>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>>>>>>>>>
>>>>>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
>>>>>>>>>> Hi Jarkko,
>>>>>>>>>>
>>>>>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>>>>>>>>>>>
>>>>>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
>>>>>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
>>>>>>>>>>>> to seal and unseal trusted keys using hardware unique key.
>>>>>>>>>>>>
>>>>>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
>>>>>>>>>>>
>>>>>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
>>>>>>>>>>> just a blank screen:
>>>>>>>>>>>
>>>>>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
>>>>>>>>>>>
>>>>>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
>>>>>>>>>>>
>>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
>>>>>>>>>>>
>>>>>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
>>>>>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
>>>>>>>>>>> in the master branch.
>>>>>>>>>>>
>>>>>>>>>>> To create identical images you just need to
>>>>>>>>>>>
>>>>>>>>>>> $ make tpmdd_defconfig && make
>>>>>>>>>>>
>>>>>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
>>>>>>>>>>> patch set, and in bigger picture I really need to have ready to run
>>>>>>>>>>> aarch64 environment available.
>>>>>>>>>>
>>>>>>>>>> I would rather suggest you to follow steps listed here [1] as to test
>>>>>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
>>>>>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
>>>>>>>>>> system [2]. And then it would be easier to migrate them to your
>>>>>>>>>> buildroot environment as well.
>>>>>>>>>>
>>>>>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
>>>>>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
>>>>>>>>>>
>>>>>>>>>> -Sumit
>>>>>>>>>
>>>>>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
>>>>>>>>>
>>>>>>>>
>>>>>>>> $ cat keyctl_change
>>>>>>>> diff --git a/common.mk b/common.mk
>>>>>>>> index aeb7b41..663e528 100644
>>>>>>>> --- a/common.mk
>>>>>>>> +++ b/common.mk
>>>>>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
>>>>>>>>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
>>>>>>>>  BR2_PACKAGE_STRACE ?= y
>>>>>>>>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
>>>>>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
>>>>>>>> +BR2_PACKAGE_KEYUTILS := y
>>>>>>>>
>>>>>>>>  # All BR2_* variables from the makefile or the environment are appended to
>>>>>>>>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
>>>>>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
>>>>>>>> index 368c18a..832ab74 100644
>>>>>>>> --- a/kconfigs/qemu.conf
>>>>>>>> +++ b/kconfigs/qemu.conf
>>>>>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
>>>>>>>>  CONFIG_9P_FS_POSIX_ACL=y
>>>>>>>>  CONFIG_HW_RANDOM=y
>>>>>>>>  CONFIG_HW_RANDOM_VIRTIO=y
>>>>>>>> +CONFIG_TRUSTED_KEYS=y
>>>>>>>> +CONFIG_ENCRYPTED_KEYS=y
>>>>>>>>
>>>>>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
>>>>>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
>>>>>>>>> remark in the commit message that TEE is a standard, with a link to the
>>>>>>>>> specification.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Sure, I will roll out the next version after your testing.
>>>>>>>
>>>>>>> Thanks, I'll try this at instant, and give my feedback.
>>>>>>
>>>>>> I bump into this:
>>>>>>
>>>>>> $ make run-only
>>>>>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
>>>>>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
>>>>>> make: *** [Makefile:194: run-only] Error 1
>>>>>>
>>>>>
>>>>> Could you check if the following directory tree is built after
>>>>> executing the below command?
>>>>>
>>>>> $ make -j`nproc`
>>>>> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
>>>>>
>>>>> $ tree out/bin/
>>>>> out/bin/
>>>>> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
>>>>> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
>>>>> ├── bl31.bin ->
>>>>> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
>>>>> ├── bl32.bin ->
>>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
>>>>> ├── bl32_extra1.bin ->
>>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
>>>>> ├── bl32_extra2.bin ->
>>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
>>>>> ├── bl33.bin ->
>>>>> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
>>>>> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
>>>>> └── rootfs.cpio.gz ->
>>>>> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
>>>>>
>>>>> 0 directories, 9 files
>>>>>
>>>>> -Sumit
>>>>
>>>> I actually spotted a build error that was unnoticed last time:
>>>>
>>>> make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
>>>> /bin/sh: 1: python: not found
>>>>
>>>> I'd prefer not to install Python2. It has been EOL over a year.
>>>
>>> AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
>>> machine, this is accomplished by installing package "python-is-python3"
>>> (after uninstalling "python-is-python2" if need be).
>>>
>>> $ ls -l /usr/bin/python
>>> lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3
>>
>> Right, just found about this in unrelated context :-) [*]
>>
>> Hope this will work out...
>>
>> [*] https://github.com/surge-synthesizer/surge/pull/3655
> 
> Now I get
> 
> Traceback (most recent call last):
>   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 36, in <module>
>     allTests = GetAllTestsSuite()
>   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 33, in GetAllTestsSuite
>     return unittest.TestSuite([GetCTestSuite(), GetPythonTestSuite()])
>   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 25, in GetCTestSuite
>     import CToolsTests
>   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/CToolsTests.py", line 22, in <module>
>     import TianoCompress
>   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TianoCompress.py", line 69, in <module>
>     TheTestSuite = TestTools.MakeTheTestSuite(locals())
>   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TestTools.py", line 43, in MakeTheTestSuite
>     for name, item in localItems.iteritems():
> AttributeError: 'dict' object has no attribute 'iteritems'

Right. Same here after removing all traces of Python2 from my system :-/

A couple of fixes are needed:
1. EDK2 needs to be upgraded to tag or later [1]
2. The PYTHON3_ENABLE environment variable needs to be set to TRUE [2]

[1] https://github.com/OP-TEE/manifest/pull/177
[2] https://github.com/OP-TEE/build/pull/450

HTH,
-- 
Jerome

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-21 16:23                         ` Jerome Forissier
@ 2021-01-22 18:12                           ` Jarkko Sakkinen
  2021-01-25  9:17                             ` Sumit Garg
  0 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-01-22 18:12 UTC (permalink / raw)
  To: Jerome Forissier
  Cc: Sumit Garg, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn

On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> 
> 
> On 1/21/21 4:24 PM, Jarkko Sakkinen wrote:
> > On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote:
> >> On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
> >>>
> >>>
> >>> On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> >>>> On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> >>>>> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >>>>>>
> >>>>>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> >>>>>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> >>>>>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >>>>>>>>>
> >>>>>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> >>>>>>>>>> Hi Jarkko,
> >>>>>>>>>>
> >>>>>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> >>>>>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
> >>>>>>>>>>>> to seal and unseal trusted keys using hardware unique key.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> >>>>>>>>>>>
> >>>>>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
> >>>>>>>>>>> just a blank screen:
> >>>>>>>>>>>
> >>>>>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> >>>>>>>>>>>
> >>>>>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
> >>>>>>>>>>>
> >>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> >>>>>>>>>>>
> >>>>>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
> >>>>>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> >>>>>>>>>>> in the master branch.
> >>>>>>>>>>>
> >>>>>>>>>>> To create identical images you just need to
> >>>>>>>>>>>
> >>>>>>>>>>> $ make tpmdd_defconfig && make
> >>>>>>>>>>>
> >>>>>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
> >>>>>>>>>>> patch set, and in bigger picture I really need to have ready to run
> >>>>>>>>>>> aarch64 environment available.
> >>>>>>>>>>
> >>>>>>>>>> I would rather suggest you to follow steps listed here [1] as to test
> >>>>>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> >>>>>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> >>>>>>>>>> system [2]. And then it would be easier to migrate them to your
> >>>>>>>>>> buildroot environment as well.
> >>>>>>>>>>
> >>>>>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> >>>>>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> >>>>>>>>>>
> >>>>>>>>>> -Sumit
> >>>>>>>>>
> >>>>>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> $ cat keyctl_change
> >>>>>>>> diff --git a/common.mk b/common.mk
> >>>>>>>> index aeb7b41..663e528 100644
> >>>>>>>> --- a/common.mk
> >>>>>>>> +++ b/common.mk
> >>>>>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> >>>>>>>>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> >>>>>>>>  BR2_PACKAGE_STRACE ?= y
> >>>>>>>>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> >>>>>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> >>>>>>>> +BR2_PACKAGE_KEYUTILS := y
> >>>>>>>>
> >>>>>>>>  # All BR2_* variables from the makefile or the environment are appended to
> >>>>>>>>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> >>>>>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> >>>>>>>> index 368c18a..832ab74 100644
> >>>>>>>> --- a/kconfigs/qemu.conf
> >>>>>>>> +++ b/kconfigs/qemu.conf
> >>>>>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> >>>>>>>>  CONFIG_9P_FS_POSIX_ACL=y
> >>>>>>>>  CONFIG_HW_RANDOM=y
> >>>>>>>>  CONFIG_HW_RANDOM_VIRTIO=y
> >>>>>>>> +CONFIG_TRUSTED_KEYS=y
> >>>>>>>> +CONFIG_ENCRYPTED_KEYS=y
> >>>>>>>>
> >>>>>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
> >>>>>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
> >>>>>>>>> remark in the commit message that TEE is a standard, with a link to the
> >>>>>>>>> specification.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> Sure, I will roll out the next version after your testing.
> >>>>>>>
> >>>>>>> Thanks, I'll try this at instant, and give my feedback.
> >>>>>>
> >>>>>> I bump into this:
> >>>>>>
> >>>>>> $ make run-only
> >>>>>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> >>>>>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> >>>>>> make: *** [Makefile:194: run-only] Error 1
> >>>>>>
> >>>>>
> >>>>> Could you check if the following directory tree is built after
> >>>>> executing the below command?
> >>>>>
> >>>>> $ make -j`nproc`
> >>>>> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
> >>>>>
> >>>>> $ tree out/bin/
> >>>>> out/bin/
> >>>>> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
> >>>>> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
> >>>>> ├── bl31.bin ->
> >>>>> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
> >>>>> ├── bl32.bin ->
> >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
> >>>>> ├── bl32_extra1.bin ->
> >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
> >>>>> ├── bl32_extra2.bin ->
> >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
> >>>>> ├── bl33.bin ->
> >>>>> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
> >>>>> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
> >>>>> └── rootfs.cpio.gz ->
> >>>>> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
> >>>>>
> >>>>> 0 directories, 9 files
> >>>>>
> >>>>> -Sumit
> >>>>
> >>>> I actually spotted a build error that was unnoticed last time:
> >>>>
> >>>> make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> >>>> /bin/sh: 1: python: not found
> >>>>
> >>>> I'd prefer not to install Python2. It has been EOL over a year.
> >>>
> >>> AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
> >>> machine, this is accomplished by installing package "python-is-python3"
> >>> (after uninstalling "python-is-python2" if need be).
> >>>
> >>> $ ls -l /usr/bin/python
> >>> lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3
> >>
> >> Right, just found about this in unrelated context :-) [*]
> >>
> >> Hope this will work out...
> >>
> >> [*] https://github.com/surge-synthesizer/surge/pull/3655
> > 
> > Now I get
> > 
> > Traceback (most recent call last):
> >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 36, in <module>
> >     allTests = GetAllTestsSuite()
> >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 33, in GetAllTestsSuite
> >     return unittest.TestSuite([GetCTestSuite(), GetPythonTestSuite()])
> >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 25, in GetCTestSuite
> >     import CToolsTests
> >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/CToolsTests.py", line 22, in <module>
> >     import TianoCompress
> >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TianoCompress.py", line 69, in <module>
> >     TheTestSuite = TestTools.MakeTheTestSuite(locals())
> >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TestTools.py", line 43, in MakeTheTestSuite
> >     for name, item in localItems.iteritems():
> > AttributeError: 'dict' object has no attribute 'iteritems'
> 
> Right. Same here after removing all traces of Python2 from my system :-/
> 
> A couple of fixes are needed:
> 1. EDK2 needs to be upgraded to tag or later [1]
> 2. The PYTHON3_ENABLE environment variable needs to be set to TRUE [2]
> 
> [1] https://github.com/OP-TEE/manifest/pull/177
> [2] https://github.com/OP-TEE/build/pull/450
 
BTW, Is to *really* impossible to test this with plain BuildRoot.  It's
obvious that this forks BR internally.

I mean even if I get this working once, this will feels like a clumsy way
to test Aarch64 regularly. I use BuildRoot extensively for x86 testing. And
it would be nice to be able to start doing regular ARM testing.

The mainline BuildRoot does have bunch of BR2_PACKAGE_OPTEE_* included.
Are they all broken?

Here's a reference where I got with that endeavour:

https://lore.kernel.org/linux-integrity/X%2Fx+N0fgrzIZTeNi@kernel.org/

/Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-22 18:12                           ` Jarkko Sakkinen
@ 2021-01-25  9:17                             ` Sumit Garg
  2021-01-27 17:14                               ` Jarkko Sakkinen
                                                 ` (3 more replies)
  0 siblings, 4 replies; 52+ messages in thread
From: Sumit Garg @ 2021-01-25  9:17 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jerome Forissier, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn

[-- Attachment #1: Type: text/plain, Size: 10727 bytes --]

Hi Jarkko,

On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> >
> >
> > On 1/21/21 4:24 PM, Jarkko Sakkinen wrote:
> > > On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote:
> > >> On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
> > >>>
> > >>>
> > >>> On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> > >>>> On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> > >>>>> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >>>>>>
> > >>>>>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> > >>>>>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > >>>>>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >>>>>>>>>
> > >>>>>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > >>>>>>>>>> Hi Jarkko,
> > >>>>>>>>>>
> > >>>>>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > >>>>>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
> > >>>>>>>>>>>> to seal and unseal trusted keys using hardware unique key.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > >>>>>>>>>>>
> > >>>>>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
> > >>>>>>>>>>> just a blank screen:
> > >>>>>>>>>>>
> > >>>>>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > >>>>>>>>>>>
> > >>>>>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
> > >>>>>>>>>>>
> > >>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > >>>>>>>>>>>
> > >>>>>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
> > >>>>>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > >>>>>>>>>>> in the master branch.
> > >>>>>>>>>>>
> > >>>>>>>>>>> To create identical images you just need to
> > >>>>>>>>>>>
> > >>>>>>>>>>> $ make tpmdd_defconfig && make
> > >>>>>>>>>>>
> > >>>>>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
> > >>>>>>>>>>> patch set, and in bigger picture I really need to have ready to run
> > >>>>>>>>>>> aarch64 environment available.
> > >>>>>>>>>>
> > >>>>>>>>>> I would rather suggest you to follow steps listed here [1] as to test
> > >>>>>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > >>>>>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > >>>>>>>>>> system [2]. And then it would be easier to migrate them to your
> > >>>>>>>>>> buildroot environment as well.
> > >>>>>>>>>>
> > >>>>>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > >>>>>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > >>>>>>>>>>
> > >>>>>>>>>> -Sumit
> > >>>>>>>>>
> > >>>>>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> $ cat keyctl_change
> > >>>>>>>> diff --git a/common.mk b/common.mk
> > >>>>>>>> index aeb7b41..663e528 100644
> > >>>>>>>> --- a/common.mk
> > >>>>>>>> +++ b/common.mk
> > >>>>>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> > >>>>>>>>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> > >>>>>>>>  BR2_PACKAGE_STRACE ?= y
> > >>>>>>>>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > >>>>>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > >>>>>>>> +BR2_PACKAGE_KEYUTILS := y
> > >>>>>>>>
> > >>>>>>>>  # All BR2_* variables from the makefile or the environment are appended to
> > >>>>>>>>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> > >>>>>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> > >>>>>>>> index 368c18a..832ab74 100644
> > >>>>>>>> --- a/kconfigs/qemu.conf
> > >>>>>>>> +++ b/kconfigs/qemu.conf
> > >>>>>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> > >>>>>>>>  CONFIG_9P_FS_POSIX_ACL=y
> > >>>>>>>>  CONFIG_HW_RANDOM=y
> > >>>>>>>>  CONFIG_HW_RANDOM_VIRTIO=y
> > >>>>>>>> +CONFIG_TRUSTED_KEYS=y
> > >>>>>>>> +CONFIG_ENCRYPTED_KEYS=y
> > >>>>>>>>
> > >>>>>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
> > >>>>>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
> > >>>>>>>>> remark in the commit message that TEE is a standard, with a link to the
> > >>>>>>>>> specification.
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Sure, I will roll out the next version after your testing.
> > >>>>>>>
> > >>>>>>> Thanks, I'll try this at instant, and give my feedback.
> > >>>>>>
> > >>>>>> I bump into this:
> > >>>>>>
> > >>>>>> $ make run-only
> > >>>>>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> > >>>>>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> > >>>>>> make: *** [Makefile:194: run-only] Error 1
> > >>>>>>
> > >>>>>
> > >>>>> Could you check if the following directory tree is built after
> > >>>>> executing the below command?
> > >>>>>
> > >>>>> $ make -j`nproc`
> > >>>>> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
> > >>>>>
> > >>>>> $ tree out/bin/
> > >>>>> out/bin/
> > >>>>> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
> > >>>>> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
> > >>>>> ├── bl31.bin ->
> > >>>>> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
> > >>>>> ├── bl32.bin ->
> > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
> > >>>>> ├── bl32_extra1.bin ->
> > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
> > >>>>> ├── bl32_extra2.bin ->
> > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
> > >>>>> ├── bl33.bin ->
> > >>>>> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
> > >>>>> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
> > >>>>> └── rootfs.cpio.gz ->
> > >>>>> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
> > >>>>>
> > >>>>> 0 directories, 9 files
> > >>>>>
> > >>>>> -Sumit
> > >>>>
> > >>>> I actually spotted a build error that was unnoticed last time:
> > >>>>
> > >>>> make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> > >>>> /bin/sh: 1: python: not found
> > >>>>
> > >>>> I'd prefer not to install Python2. It has been EOL over a year.
> > >>>
> > >>> AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
> > >>> machine, this is accomplished by installing package "python-is-python3"
> > >>> (after uninstalling "python-is-python2" if need be).
> > >>>
> > >>> $ ls -l /usr/bin/python
> > >>> lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3
> > >>
> > >> Right, just found about this in unrelated context :-) [*]
> > >>
> > >> Hope this will work out...
> > >>
> > >> [*] https://github.com/surge-synthesizer/surge/pull/3655
> > >
> > > Now I get
> > >
> > > Traceback (most recent call last):
> > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 36, in <module>
> > >     allTests = GetAllTestsSuite()
> > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 33, in GetAllTestsSuite
> > >     return unittest.TestSuite([GetCTestSuite(), GetPythonTestSuite()])
> > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 25, in GetCTestSuite
> > >     import CToolsTests
> > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/CToolsTests.py", line 22, in <module>
> > >     import TianoCompress
> > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TianoCompress.py", line 69, in <module>
> > >     TheTestSuite = TestTools.MakeTheTestSuite(locals())
> > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TestTools.py", line 43, in MakeTheTestSuite
> > >     for name, item in localItems.iteritems():
> > > AttributeError: 'dict' object has no attribute 'iteritems'
> >
> > Right. Same here after removing all traces of Python2 from my system :-/
> >
> > A couple of fixes are needed:
> > 1. EDK2 needs to be upgraded to tag or later [1]
> > 2. The PYTHON3_ENABLE environment variable needs to be set to TRUE [2]
> >
> > [1] https://github.com/OP-TEE/manifest/pull/177
> > [2] https://github.com/OP-TEE/build/pull/450
>
> BTW, Is to *really* impossible to test this with plain BuildRoot.  It's
> obvious that this forks BR internally.
>
> I mean even if I get this working once, this will feels like a clumsy way
> to test Aarch64 regularly. I use BuildRoot extensively for x86 testing. And
> it would be nice to be able to start doing regular ARM testing.

The main reason to guide you towards the OP-TEE build system is that
you will be able to build all the firmwares (TF-A, OP-TEE, edk2 etc.)
from source. If you don't need to rebuild those then I have prepared a
flash firmware binary blob for your testing (attached flash.bin). So
Qemu cmdline will look like:

$ qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu
cortex-a57 -kernel out/bin/Image -no-acpi -append
'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2' -initrd
out/bin/rootfs.cpio.gz -smp 2 -m 1024 -bios flash.bin -d unimp

Here you can use "Image" and "rootfs.cpio.gz" from your plain BR builds.

Give it a try and let me know if this works for you.

>
> The mainline BuildRoot does have bunch of BR2_PACKAGE_OPTEE_* included.
> Are they all broken?

These aren't broken but they are used to package OP-TEE user-space
components into rootfs but they aren't required to test Trusted Keys
as it uses kernel interface to OP-TEE instead.

-Sumit

>
> Here's a reference where I got with that endeavour:
>
> https://lore.kernel.org/linux-integrity/X%2Fx+N0fgrzIZTeNi@kernel.org/
>
> /Jarkko

[-- Attachment #2: flash.bin --]
[-- Type: application/octet-stream, Size: 4152932 bytes --]

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-25  9:17                             ` Sumit Garg
@ 2021-01-27 17:14                               ` Jarkko Sakkinen
  2021-01-27 17:19                               ` Jarkko Sakkinen
                                                 ` (2 subsequent siblings)
  3 siblings, 0 replies; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-01-27 17:14 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jerome Forissier, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn

On Mon, 2021-01-25 at 14:47 +0530, Sumit Garg wrote:
> Hi Jarkko,
> 
> On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > 
> > On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> > > 
> > > 
> > > On 1/21/21 4:24 PM, Jarkko Sakkinen wrote:
> > > > On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote:
> > > > > On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
> > > > > > 
> > > > > > 
> > > > > > On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> > > > > > > On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> > > > > > > > On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > > > > > 
> > > > > > > > > On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> > > > > > > > > > On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > > > > > > > > > > On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > > > > > > > > > > > > Hi Jarkko,
> > > > > > > > > > > > > 
> > > > > > > > > > > > > On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > > > > > > > > > > > > > Add support for TEE based trusted keys where TEE provides the functionality
> > > > > > > > > > > > > > > to seal and unseal trusted keys using hardware unique key.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Refer to Documentation/tee.txt for detailed information about TEE.
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > I haven't yet got QEMU environment working with aarch64, this produces
> > > > > > > > > > > > > > just a blank screen:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > My BuildRoot fork for TPM and keyring testing is located over here:
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > The "ARM version" is at this point in aarch64 branch. Over time I will
> > > > > > > > > > > > > > define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > > > > > > > > > > > > in the master branch.
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > To create identical images you just need to
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > $ make tpmdd_defconfig && make
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Can you check if you see anything obviously wrong? I'm eager to test this
> > > > > > > > > > > > > > patch set, and in bigger picture I really need to have ready to run
> > > > > > > > > > > > > > aarch64 environment available.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > I would rather suggest you to follow steps listed here [1] as to test
> > > > > > > > > > > > > this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > > > > > > > > > > > > OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > > > > > > > > > > > > system [2]. And then it would be easier to migrate them to your
> > > > > > > > > > > > > buildroot environment as well.
> > > > > > > > > > > > > 
> > > > > > > > > > > > > [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > > > > > > > > > > > > [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > > > > > > > > > > 
> > > > > > > > > > > > > -Sumit
> > > > > > > > > > > > 
> > > > > > > > > > > > Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > $ cat keyctl_change
> > > > > > > > > > > diff --git a/common.mk b/common.mk
> > > > > > > > > > > index aeb7b41..663e528 100644
> > > > > > > > > > > --- a/common.mk
> > > > > > > > > > > +++ b/common.mk
> > > > > > > > > > > @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> > > > > > > > > > >  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> > > > > > > > > > >  BR2_PACKAGE_STRACE ?= y
> > > > > > > > > > >  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > > > > > > > > > > $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > > > > > > > > > > +BR2_PACKAGE_KEYUTILS := y
> > > > > > > > > > > 
> > > > > > > > > > >  # All BR2_* variables from the makefile or the environment are appended to
> > > > > > > > > > >  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> > > > > > > > > > > diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> > > > > > > > > > > index 368c18a..832ab74 100644
> > > > > > > > > > > --- a/kconfigs/qemu.conf
> > > > > > > > > > > +++ b/kconfigs/qemu.conf
> > > > > > > > > > > @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> > > > > > > > > > >  CONFIG_9P_FS_POSIX_ACL=y
> > > > > > > > > > >  CONFIG_HW_RANDOM=y
> > > > > > > > > > >  CONFIG_HW_RANDOM_VIRTIO=y
> > > > > > > > > > > +CONFIG_TRUSTED_KEYS=y
> > > > > > > > > > > +CONFIG_ENCRYPTED_KEYS=y
> > > > > > > > > > > 
> > > > > > > > > > > > After I've successfully tested 2/4, I'd suggest that you roll out one more
> > > > > > > > > > > > version and CC the documentation patch to Elaine and Mini, and clearly
> > > > > > > > > > > > remark in the commit message that TEE is a standard, with a link to the
> > > > > > > > > > > > specification.
> > > > > > > > > > > > 
> > > > > > > > > > > 
> > > > > > > > > > > Sure, I will roll out the next version after your testing.
> > > > > > > > > > 
> > > > > > > > > > Thanks, I'll try this at instant, and give my feedback.
> > > > > > > > > 
> > > > > > > > > I bump into this:
> > > > > > > > > 
> > > > > > > > > $ make run-only
> > > > > > > > > ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> > > > > > > > > ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> > > > > > > > > make: *** [Makefile:194: run-only] Error 1
> > > > > > > > > 
> > > > > > > > 
> > > > > > > > Could you check if the following directory tree is built after
> > > > > > > > executing the below command?
> > > > > > > > 
> > > > > > > > $ make -j`nproc`
> > > > > > > > CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
> > > > > > > > 
> > > > > > > > $ tree out/bin/
> > > > > > > > out/bin/
> > > > > > > > ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
> > > > > > > > ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
> > > > > > > > ├── bl31.bin ->
> > > > > > > > /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
> > > > > > > > ├── bl32.bin ->
> > > > > > > > /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
> > > > > > > > ├── bl32_extra1.bin ->
> > > > > > > > /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
> > > > > > > > ├── bl32_extra2.bin ->
> > > > > > > > /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
> > > > > > > > ├── bl33.bin ->
> > > > > > > > /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
> > > > > > > > ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
> > > > > > > > └── rootfs.cpio.gz ->
> > > > > > > > /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
> > > > > > > > 
> > > > > > > > 0 directories, 9 files
> > > > > > > > 
> > > > > > > > -Sumit
> > > > > > > 
> > > > > > > I actually spotted a build error that was unnoticed last time:
> > > > > > > 
> > > > > > > make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> > > > > > > /bin/sh: 1: python: not found
> > > > > > > 
> > > > > > > I'd prefer not to install Python2. It has been EOL over a year.
> > > > > > 
> > > > > > AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
> > > > > > machine, this is accomplished by installing package "python-is-python3"
> > > > > > (after uninstalling "python-is-python2" if need be).
> > > > > > 
> > > > > > $ ls -l /usr/bin/python
> > > > > > lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3
> > > > > 
> > > > > Right, just found about this in unrelated context :-) [*]
> > > > > 
> > > > > Hope this will work out...
> > > > > 
> > > > > [*] https://github.com/surge-synthesizer/surge/pull/3655
> > > > 
> > > > Now I get
> > > > 
> > > > Traceback (most recent call last):
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 36, in <module>
> > > >     allTests = GetAllTestsSuite()
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 33, in GetAllTestsSuite
> > > >     return unittest.TestSuite([GetCTestSuite(), GetPythonTestSuite()])
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 25, in GetCTestSuite
> > > >     import CToolsTests
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/CToolsTests.py", line 22, in <module>
> > > >     import TianoCompress
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TianoCompress.py", line 69, in <module>
> > > >     TheTestSuite = TestTools.MakeTheTestSuite(locals())
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TestTools.py", line 43, in MakeTheTestSuite
> > > >     for name, item in localItems.iteritems():
> > > > AttributeError: 'dict' object has no attribute 'iteritems'
> > > 
> > > Right. Same here after removing all traces of Python2 from my system :-/
> > > 
> > > A couple of fixes are needed:
> > > 1. EDK2 needs to be upgraded to tag or later [1]
> > > 2. The PYTHON3_ENABLE environment variable needs to be set to TRUE [2]
> > > 
> > > [1] https://github.com/OP-TEE/manifest/pull/177
> > > [2] https://github.com/OP-TEE/build/pull/450
> > 
> > BTW, Is to *really* impossible to test this with plain BuildRoot.  It's
> > obvious that this forks BR internally.
> > 
> > I mean even if I get this working once, this will feels like a clumsy way
> > to test Aarch64 regularly. I use BuildRoot extensively for x86 testing. And
> > it would be nice to be able to start doing regular ARM testing.
> 
> The main reason to guide you towards the OP-TEE build system is that
> you will be able to build all the firmwares (TF-A, OP-TEE, edk2 etc.)
> from source. If you don't need to rebuild those then I have prepared a
> flash firmware binary blob for your testing (attached flash.bin). So
> Qemu cmdline will look like:
> 
> $ qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu
> cortex-a57 -kernel out/bin/Image -no-acpi -append
> 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2' -initrd
> out/bin/rootfs.cpio.gz -smp 2 -m 1024 -bios flash.bin -d unimp
> 
> Here you can use "Image" and "rootfs.cpio.gz" from your plain BR builds.
> 
> Give it a try and let me know if this works for you.
> 
> > 
> > The mainline BuildRoot does have bunch of BR2_PACKAGE_OPTEE_* included.
> > Are they all broken?
> 
> These aren't broken but they are used to package OP-TEE user-space
> components into rootfs but they aren't required to test Trusted Keys
> as it uses kernel interface to OP-TEE instead.
> 
> -Sumit
> 
> > 
> > Here's a reference where I got with that endeavour:
> > 
> > https://lore.kernel.org/linux-integrity/X%2Fx+N0fgrzIZTeNi@kernel.org/
> > 
> > /Jarkko


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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-25  9:17                             ` Sumit Garg
  2021-01-27 17:14                               ` Jarkko Sakkinen
@ 2021-01-27 17:19                               ` Jarkko Sakkinen
  2021-02-04  0:05                               ` Jarkko Sakkinen
  2021-02-11 23:34                               ` Jarkko Sakkinen
  3 siblings, 0 replies; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-01-27 17:19 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jerome Forissier, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn

On Mon, Jan 25, 2021 at 02:47:38PM +0530, Sumit Garg wrote:
> Hi Jarkko,
> 
> On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> > >
> > >
> > > On 1/21/21 4:24 PM, Jarkko Sakkinen wrote:
> > > > On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote:
> > > >> On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
> > > >>>
> > > >>>
> > > >>> On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> > > >>>> On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> > > >>>>> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >>>>>>
> > > >>>>>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> > > >>>>>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > > >>>>>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > > >>>>>>>>>> Hi Jarkko,
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > >>>>>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
> > > >>>>>>>>>>>> to seal and unseal trusted keys using hardware unique key.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
> > > >>>>>>>>>>> just a blank screen:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
> > > >>>>>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > >>>>>>>>>>> in the master branch.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> To create identical images you just need to
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> $ make tpmdd_defconfig && make
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
> > > >>>>>>>>>>> patch set, and in bigger picture I really need to have ready to run
> > > >>>>>>>>>>> aarch64 environment available.
> > > >>>>>>>>>>
> > > >>>>>>>>>> I would rather suggest you to follow steps listed here [1] as to test
> > > >>>>>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > > >>>>>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > > >>>>>>>>>> system [2]. And then it would be easier to migrate them to your
> > > >>>>>>>>>> buildroot environment as well.
> > > >>>>>>>>>>
> > > >>>>>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > > >>>>>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > >>>>>>>>>>
> > > >>>>>>>>>> -Sumit
> > > >>>>>>>>>
> > > >>>>>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> $ cat keyctl_change
> > > >>>>>>>> diff --git a/common.mk b/common.mk
> > > >>>>>>>> index aeb7b41..663e528 100644
> > > >>>>>>>> --- a/common.mk
> > > >>>>>>>> +++ b/common.mk
> > > >>>>>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> > > >>>>>>>>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> > > >>>>>>>>  BR2_PACKAGE_STRACE ?= y
> > > >>>>>>>>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > > >>>>>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > > >>>>>>>> +BR2_PACKAGE_KEYUTILS := y
> > > >>>>>>>>
> > > >>>>>>>>  # All BR2_* variables from the makefile or the environment are appended to
> > > >>>>>>>>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> > > >>>>>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> > > >>>>>>>> index 368c18a..832ab74 100644
> > > >>>>>>>> --- a/kconfigs/qemu.conf
> > > >>>>>>>> +++ b/kconfigs/qemu.conf
> > > >>>>>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> > > >>>>>>>>  CONFIG_9P_FS_POSIX_ACL=y
> > > >>>>>>>>  CONFIG_HW_RANDOM=y
> > > >>>>>>>>  CONFIG_HW_RANDOM_VIRTIO=y
> > > >>>>>>>> +CONFIG_TRUSTED_KEYS=y
> > > >>>>>>>> +CONFIG_ENCRYPTED_KEYS=y
> > > >>>>>>>>
> > > >>>>>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
> > > >>>>>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
> > > >>>>>>>>> remark in the commit message that TEE is a standard, with a link to the
> > > >>>>>>>>> specification.
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Sure, I will roll out the next version after your testing.
> > > >>>>>>>
> > > >>>>>>> Thanks, I'll try this at instant, and give my feedback.
> > > >>>>>>
> > > >>>>>> I bump into this:
> > > >>>>>>
> > > >>>>>> $ make run-only
> > > >>>>>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> > > >>>>>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> > > >>>>>> make: *** [Makefile:194: run-only] Error 1
> > > >>>>>>
> > > >>>>>
> > > >>>>> Could you check if the following directory tree is built after
> > > >>>>> executing the below command?
> > > >>>>>
> > > >>>>> $ make -j`nproc`
> > > >>>>> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
> > > >>>>>
> > > >>>>> $ tree out/bin/
> > > >>>>> out/bin/
> > > >>>>> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
> > > >>>>> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
> > > >>>>> ├── bl31.bin ->
> > > >>>>> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
> > > >>>>> ├── bl32.bin ->
> > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
> > > >>>>> ├── bl32_extra1.bin ->
> > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
> > > >>>>> ├── bl32_extra2.bin ->
> > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
> > > >>>>> ├── bl33.bin ->
> > > >>>>> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
> > > >>>>> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
> > > >>>>> └── rootfs.cpio.gz ->
> > > >>>>> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
> > > >>>>>
> > > >>>>> 0 directories, 9 files
> > > >>>>>
> > > >>>>> -Sumit
> > > >>>>
> > > >>>> I actually spotted a build error that was unnoticed last time:
> > > >>>>
> > > >>>> make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> > > >>>> /bin/sh: 1: python: not found
> > > >>>>
> > > >>>> I'd prefer not to install Python2. It has been EOL over a year.
> > > >>>
> > > >>> AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
> > > >>> machine, this is accomplished by installing package "python-is-python3"
> > > >>> (after uninstalling "python-is-python2" if need be).
> > > >>>
> > > >>> $ ls -l /usr/bin/python
> > > >>> lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3
> > > >>
> > > >> Right, just found about this in unrelated context :-) [*]
> > > >>
> > > >> Hope this will work out...
> > > >>
> > > >> [*] https://github.com/surge-synthesizer/surge/pull/3655
> > > >
> > > > Now I get
> > > >
> > > > Traceback (most recent call last):
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 36, in <module>
> > > >     allTests = GetAllTestsSuite()
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 33, in GetAllTestsSuite
> > > >     return unittest.TestSuite([GetCTestSuite(), GetPythonTestSuite()])
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 25, in GetCTestSuite
> > > >     import CToolsTests
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/CToolsTests.py", line 22, in <module>
> > > >     import TianoCompress
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TianoCompress.py", line 69, in <module>
> > > >     TheTestSuite = TestTools.MakeTheTestSuite(locals())
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TestTools.py", line 43, in MakeTheTestSuite
> > > >     for name, item in localItems.iteritems():
> > > > AttributeError: 'dict' object has no attribute 'iteritems'
> > >
> > > Right. Same here after removing all traces of Python2 from my system :-/
> > >
> > > A couple of fixes are needed:
> > > 1. EDK2 needs to be upgraded to tag or later [1]
> > > 2. The PYTHON3_ENABLE environment variable needs to be set to TRUE [2]
> > >
> > > [1] https://github.com/OP-TEE/manifest/pull/177
> > > [2] https://github.com/OP-TEE/build/pull/450
> >
> > BTW, Is to *really* impossible to test this with plain BuildRoot.  It's
> > obvious that this forks BR internally.
> >
> > I mean even if I get this working once, this will feels like a clumsy way
> > to test Aarch64 regularly. I use BuildRoot extensively for x86 testing. And
> > it would be nice to be able to start doing regular ARM testing.
> 
> The main reason to guide you towards the OP-TEE build system is that
> you will be able to build all the firmwares (TF-A, OP-TEE, edk2 etc.)
> from source. If you don't need to rebuild those then I have prepared a
> flash firmware binary blob for your testing (attached flash.bin). So
> Qemu cmdline will look like:
> 
> $ qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu
> cortex-a57 -kernel out/bin/Image -no-acpi -append
> 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2' -initrd
> out/bin/rootfs.cpio.gz -smp 2 -m 1024 -bios flash.bin -d unimp
> 
> Here you can use "Image" and "rootfs.cpio.gz" from your plain BR builds.
> 
> Give it a try and let me know if this works for you.

Hi, sorry something happened with Evolution that I don't understand
and it just sent the message quoted without my response. Should
always stick to mutt.

There's a bug in BuildRoot that prevents me testing right now, when
you use LINUX_OVERRIDE_SRCDIR. BR developers are looking into that.

I'll test this once there's a resolution for that.

/Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-25  9:17                             ` Sumit Garg
  2021-01-27 17:14                               ` Jarkko Sakkinen
  2021-01-27 17:19                               ` Jarkko Sakkinen
@ 2021-02-04  0:05                               ` Jarkko Sakkinen
  2021-02-11 23:34                               ` Jarkko Sakkinen
  3 siblings, 0 replies; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-02-04  0:05 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jerome Forissier, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn,
	Yann E. MORIN

On Mon, Jan 25, 2021 at 02:47:38PM +0530, Sumit Garg wrote:
> The main reason to guide you towards the OP-TEE build system is that
> you will be able to build all the firmwares (TF-A, OP-TEE, edk2 etc.)
> from source. If you don't need to rebuild those then I have prepared a
> flash firmware binary blob for your testing (attached flash.bin). So
> Qemu cmdline will look like:
> 
> $ qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu
> cortex-a57 -kernel out/bin/Image -no-acpi -append
> 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2' -initrd
> out/bin/rootfs.cpio.gz -smp 2 -m 1024 -bios flash.bin -d unimp
> 
> Here you can use "Image" and "rootfs.cpio.gz" from your plain BR builds.
> 
> Give it a try and let me know if this works for you.

Sumit, I can try this again now :-) Thanks Yann for fixing the issue!

https://git.busybox.net/buildroot/commit/?id=b9e7adc152b5811b20724d8c05f0f2117254919c

/Jarkko

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

* Re: [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework
  2020-11-03 16:01 ` [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework Sumit Garg
  2020-11-24  3:42   ` Jarkko Sakkinen
@ 2021-02-10 17:00   ` Jarkko Sakkinen
  2021-02-11 10:34     ` Ahmad Fatoum
  2021-02-15 13:15     ` Sumit Garg
  1 sibling, 2 replies; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-02-10 17:00 UTC (permalink / raw)
  To: Sumit Garg
  Cc: jarkko.sakkinen, zohar, jejb, dhowells, jens.wiklander, corbet,
	jmorris, serge, casey, janne.karhunen, daniel.thompson,
	Markus.Wamser, lhinds, keyrings, linux-integrity,
	linux-security-module, linux-doc, linux-kernel, linux-arm-kernel,
	op-tee

On Tue, Nov 03, 2020 at 09:31:43PM +0530, Sumit Garg wrote:
> +	case Opt_new:
> +		key_len = payload->key_len;
> +		ret = static_call(trusted_key_get_random)(payload->key,
> +							  key_len);
> +		if (ret != key_len) {
> +			pr_info("trusted_key: key_create failed (%d)\n", ret);
> +			goto out;
> +		}

This repeats a regression in existing code, i.e. does not check
"ret < 0" condition. I noticed this now when I rebased the code
on top of my fixes.

I.e. it's fixed in my master branch, which caused a merge conflict,
and I found this.

/Jarkko

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

* Re: [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework
  2021-02-10 17:00   ` Jarkko Sakkinen
@ 2021-02-11 10:34     ` Ahmad Fatoum
  2021-02-12 12:22       ` Jarkko Sakkinen
  2021-02-15 13:15     ` Sumit Garg
  1 sibling, 1 reply; 52+ messages in thread
From: Ahmad Fatoum @ 2021-02-11 10:34 UTC (permalink / raw)
  To: Jarkko Sakkinen, Sumit Garg
  Cc: linux-security-module, daniel.thompson, op-tee, corbet, jejb,
	janne.karhunen, linux-doc, jmorris, zohar, linux-kernel,
	dhowells, lhinds, keyrings, jarkko.sakkinen, Markus.Wamser,
	casey, linux-integrity, jens.wiklander, linux-arm-kernel, serge

Hello Jarkko,

On 10.02.21 18:00, Jarkko Sakkinen wrote:
> On Tue, Nov 03, 2020 at 09:31:43PM +0530, Sumit Garg wrote:
>> +	case Opt_new:
>> +		key_len = payload->key_len;
>> +		ret = static_call(trusted_key_get_random)(payload->key,
>> +							  key_len);
>> +		if (ret != key_len) {
>> +			pr_info("trusted_key: key_create failed (%d)\n", ret);
>> +			goto out;
>> +		}
> 
> This repeats a regression in existing code, i.e. does not check
> "ret < 0" condition. I noticed this now when I rebased the code
> on top of my fixes.
> 
> I.e. it's fixed in my master branch, which caused a merge conflict,
> and I found this.

Does that mean this series will go out for the next merge window?
Can you point me where your git tree is, so I can rebase on top?

> 
> /Jarkko
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-01-25  9:17                             ` Sumit Garg
                                                 ` (2 preceding siblings ...)
  2021-02-04  0:05                               ` Jarkko Sakkinen
@ 2021-02-11 23:34                               ` Jarkko Sakkinen
  2021-02-11 23:35                                 ` Jarkko Sakkinen
  2021-02-15 13:07                                 ` Sumit Garg
  3 siblings, 2 replies; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-02-11 23:34 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jerome Forissier, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn, dave.hansen

On Mon, Jan 25, 2021 at 02:47:38PM +0530, Sumit Garg wrote:
> Hi Jarkko,
> 
> On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> > >
> > >
> > > On 1/21/21 4:24 PM, Jarkko Sakkinen wrote:
> > > > On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote:
> > > >> On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
> > > >>>
> > > >>>
> > > >>> On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> > > >>>> On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> > > >>>>> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >>>>>>
> > > >>>>>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> > > >>>>>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > > >>>>>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > > >>>>>>>>>> Hi Jarkko,
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > >>>>>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
> > > >>>>>>>>>>>> to seal and unseal trusted keys using hardware unique key.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
> > > >>>>>>>>>>> just a blank screen:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
> > > >>>>>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > >>>>>>>>>>> in the master branch.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> To create identical images you just need to
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> $ make tpmdd_defconfig && make
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
> > > >>>>>>>>>>> patch set, and in bigger picture I really need to have ready to run
> > > >>>>>>>>>>> aarch64 environment available.
> > > >>>>>>>>>>
> > > >>>>>>>>>> I would rather suggest you to follow steps listed here [1] as to test
> > > >>>>>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > > >>>>>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > > >>>>>>>>>> system [2]. And then it would be easier to migrate them to your
> > > >>>>>>>>>> buildroot environment as well.
> > > >>>>>>>>>>
> > > >>>>>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > > >>>>>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > >>>>>>>>>>
> > > >>>>>>>>>> -Sumit
> > > >>>>>>>>>
> > > >>>>>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> $ cat keyctl_change
> > > >>>>>>>> diff --git a/common.mk b/common.mk
> > > >>>>>>>> index aeb7b41..663e528 100644
> > > >>>>>>>> --- a/common.mk
> > > >>>>>>>> +++ b/common.mk
> > > >>>>>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> > > >>>>>>>>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> > > >>>>>>>>  BR2_PACKAGE_STRACE ?= y
> > > >>>>>>>>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > > >>>>>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > > >>>>>>>> +BR2_PACKAGE_KEYUTILS := y
> > > >>>>>>>>
> > > >>>>>>>>  # All BR2_* variables from the makefile or the environment are appended to
> > > >>>>>>>>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> > > >>>>>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> > > >>>>>>>> index 368c18a..832ab74 100644
> > > >>>>>>>> --- a/kconfigs/qemu.conf
> > > >>>>>>>> +++ b/kconfigs/qemu.conf
> > > >>>>>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> > > >>>>>>>>  CONFIG_9P_FS_POSIX_ACL=y
> > > >>>>>>>>  CONFIG_HW_RANDOM=y
> > > >>>>>>>>  CONFIG_HW_RANDOM_VIRTIO=y
> > > >>>>>>>> +CONFIG_TRUSTED_KEYS=y
> > > >>>>>>>> +CONFIG_ENCRYPTED_KEYS=y
> > > >>>>>>>>
> > > >>>>>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
> > > >>>>>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
> > > >>>>>>>>> remark in the commit message that TEE is a standard, with a link to the
> > > >>>>>>>>> specification.
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> Sure, I will roll out the next version after your testing.
> > > >>>>>>>
> > > >>>>>>> Thanks, I'll try this at instant, and give my feedback.
> > > >>>>>>
> > > >>>>>> I bump into this:
> > > >>>>>>
> > > >>>>>> $ make run-only
> > > >>>>>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> > > >>>>>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> > > >>>>>> make: *** [Makefile:194: run-only] Error 1
> > > >>>>>>
> > > >>>>>
> > > >>>>> Could you check if the following directory tree is built after
> > > >>>>> executing the below command?
> > > >>>>>
> > > >>>>> $ make -j`nproc`
> > > >>>>> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
> > > >>>>>
> > > >>>>> $ tree out/bin/
> > > >>>>> out/bin/
> > > >>>>> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
> > > >>>>> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
> > > >>>>> ├── bl31.bin ->
> > > >>>>> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
> > > >>>>> ├── bl32.bin ->
> > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
> > > >>>>> ├── bl32_extra1.bin ->
> > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
> > > >>>>> ├── bl32_extra2.bin ->
> > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
> > > >>>>> ├── bl33.bin ->
> > > >>>>> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
> > > >>>>> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
> > > >>>>> └── rootfs.cpio.gz ->
> > > >>>>> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
> > > >>>>>
> > > >>>>> 0 directories, 9 files
> > > >>>>>
> > > >>>>> -Sumit
> > > >>>>
> > > >>>> I actually spotted a build error that was unnoticed last time:
> > > >>>>
> > > >>>> make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> > > >>>> /bin/sh: 1: python: not found
> > > >>>>
> > > >>>> I'd prefer not to install Python2. It has been EOL over a year.
> > > >>>
> > > >>> AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
> > > >>> machine, this is accomplished by installing package "python-is-python3"
> > > >>> (after uninstalling "python-is-python2" if need be).
> > > >>>
> > > >>> $ ls -l /usr/bin/python
> > > >>> lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3
> > > >>
> > > >> Right, just found about this in unrelated context :-) [*]
> > > >>
> > > >> Hope this will work out...
> > > >>
> > > >> [*] https://github.com/surge-synthesizer/surge/pull/3655
> > > >
> > > > Now I get
> > > >
> > > > Traceback (most recent call last):
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 36, in <module>
> > > >     allTests = GetAllTestsSuite()
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 33, in GetAllTestsSuite
> > > >     return unittest.TestSuite([GetCTestSuite(), GetPythonTestSuite()])
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 25, in GetCTestSuite
> > > >     import CToolsTests
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/CToolsTests.py", line 22, in <module>
> > > >     import TianoCompress
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TianoCompress.py", line 69, in <module>
> > > >     TheTestSuite = TestTools.MakeTheTestSuite(locals())
> > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TestTools.py", line 43, in MakeTheTestSuite
> > > >     for name, item in localItems.iteritems():
> > > > AttributeError: 'dict' object has no attribute 'iteritems'
> > >
> > > Right. Same here after removing all traces of Python2 from my system :-/
> > >
> > > A couple of fixes are needed:
> > > 1. EDK2 needs to be upgraded to tag or later [1]
> > > 2. The PYTHON3_ENABLE environment variable needs to be set to TRUE [2]
> > >
> > > [1] https://github.com/OP-TEE/manifest/pull/177
> > > [2] https://github.com/OP-TEE/build/pull/450
> >
> > BTW, Is to *really* impossible to test this with plain BuildRoot.  It's
> > obvious that this forks BR internally.
> >
> > I mean even if I get this working once, this will feels like a clumsy way
> > to test Aarch64 regularly. I use BuildRoot extensively for x86 testing. And
> > it would be nice to be able to start doing regular ARM testing.
> 
> The main reason to guide you towards the OP-TEE build system is that
> you will be able to build all the firmwares (TF-A, OP-TEE, edk2 etc.)
> from source. If you don't need to rebuild those then I have prepared a
> flash firmware binary blob for your testing (attached flash.bin). So
> Qemu cmdline will look like:
> 
> $ qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu
> cortex-a57 -kernel out/bin/Image -no-acpi -append
> 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2' -initrd
> out/bin/rootfs.cpio.gz -smp 2 -m 1024 -bios flash.bin -d unimp

I spentt couple of days to try to get this running.

Here's the log:

❯ ./qemu.sh
NOTICE:  Booting Trusted Firmware
NOTICE:  BL1: v2.3():v2.3
NOTICE:  BL1: Built : 13:28:04, Jan 25 2021
NOTICE:  BL1: Booting BL2
NOTICE:  BL2: v2.3():v2.3
NOTICE:  BL2: Built : 13:28:06, Jan 25 2021
NOTICE:  BL1: Booting BL31
NOTICE:  BL31: v2.3():v2.3
NOTICE:  BL31: Built : 13:28:08, Jan 25 2021
UEFI firmware (version  built at 18:49:27 on Nov 18 2019)
pflash_write: Write to buffer emulation is flawed
pflash_write: Write to buffer emulation is flawed
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
Booting Linux on physical CPU 0x0000000000 [0x411fd070]
Linux version 5.11.0-rc5 (jarkko@suppilovahvero) (aarch64-buildroot-linux-uclibc-gcc.br_real (Buildroot 2021.02-rc1-10-ga72c90b972) 9.3.0, GNU ld (GNU Binutils) 2.35.2) #1 SMP Thu Feb 11 22:04:53 EET 2021
Machine model: linux,dummy-virt
efi: EFI v2.70 by EDK II
efi: SMBIOS=0x7f520000 SMBIOS 3.0=0x7f500000 MEMATTR=0x7e59b018 MEMRESERVE=0x7c143f18
Zone ranges:
  DMA      [mem 0x0000000040000000-0x000000007fffffff]
  DMA32    empty
  Normal   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x0000000040000000-0x0000000041ffffff]
  node   0: [mem 0x0000000042200000-0x000000007be3ffff]
  node   0: [mem 0x000000007be40000-0x000000007c13ffff]
  node   0: [mem 0x000000007c140000-0x000000007f41ffff]
  node   0: [mem 0x000000007f420000-0x000000007f4affff]
  node   0: [mem 0x000000007f4b0000-0x000000007f4cffff]
  node   0: [mem 0x000000007f4d0000-0x000000007f5dffff]
  node   0: [mem 0x000000007f5e0000-0x000000007fffffff]
Zeroed struct page in unavailable ranges: 864 pages
Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff]
psci: probing for conduit method from DT.
psci: PSCIv1.1 detected in firmware.
psci: Using standard PSCI v0.2 function IDs
psci: Trusted OS migration not required
psci: SMC Calling Convention v1.2
percpu: Embedded 21 pages/cpu s48024 r8192 d29800 u86016
Detected PIPT I-cache on CPU0
CPU features: detected: ARM erratum 832075
CPU features: detected: Spectre-v2
CPU features: detected: ARM errata 1165522, 1319367, or 1530923
Built 1 zonelists, mobility grouping on.  Total pages: 257536
Kernel command line: root=/dev/vda rw console=ttyAMA0,115200
Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
mem auto-init: stack:off, heap alloc:off, heap free:off
Memory: 1011284K/1046528K available (6592K kernel code, 804K rwdata, 1460K rodata, 1088K init, 321K bss, 35244K reserved, 0K cma-reserved)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
rcu: Hierarchical RCU implementation.
rcu:    RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=1.
rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
random: get_random_bytes called from start_kernel+0x340/0x53c with crng_init=0
arch_timer: cp15 timer(s) running at 62.50MHz (virt).
clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
Console: colour dummy device 80x25
Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=250000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
rcu: Hierarchical SRCU implementation.
Remapping and enabling EFI services.
smp: Bringing up secondary CPUs ...
smp: Brought up 1 node, 1 CPU
SMP: Total of 1 processors activated.
CPU features: detected: 32-bit EL0 Support
CPU features: detected: CRC32 instructions
CPU: All CPU(s) started at EL1
alternatives: patching kernel code
devtmpfs: initialized
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
futex hash table entries: 256 (order: 2, 16384 bytes, linear)
SMBIOS 3.0.0 present.
DMI: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
NET: Registered protocol family 16
DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
ASID allocator initialised with 65536 entries
Serial: AMBA PL011 UART driver
9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 46, base_baud = 0) is a PL011 rev1
printk: console [ttyAMA0] enabled
iommu: Default domain type: Translated
vgaarb: loaded
SCSI subsystem initialized
Registered efivars operations
clocksource: Switched to clocksource arch_sys_counter
NET: Registered protocol family 2
tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)
TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
TCP bind hash table entries: 8192 (order: 5, 131072 bytes, linear)
TCP: Hash tables configured (established 8192 bind 8192)
UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
NET: Registered protocol family 1
PCI: CLS 0 bytes, default 64
hw perfevents: enabled with armv8_pmuv3 PMU driver, 5 counters available
workingset: timestamp_bits=62 max_order=18 bucket_order=0
fuse: init (API version 7.33)
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler mq-deadline registered
io scheduler kyber registered
pci-host-generic 4010000000.pcie: host bridge /pcie@10000000 ranges:
pci-host-generic 4010000000.pcie:       IO 0x003eff0000..0x003effffff -> 0x0000000000
pci-host-generic 4010000000.pcie:      MEM 0x0010000000..0x003efeffff -> 0x0010000000
pci-host-generic 4010000000.pcie:      MEM 0x8000000000..0xffffffffff -> 0x8000000000
pci-host-generic 4010000000.pcie: Memory resource size exceeds max for 32 bits
pci-host-generic 4010000000.pcie: ECAM at [mem 0x4010000000-0x401fffffff] for [bus 00-ff]
pci-host-generic 4010000000.pcie: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff]
pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff]
pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
pci 0000:00:01.0: [1af4:1000] type 00 class 0x020000
pci 0000:00:01.0: reg 0x10: [io  0x0080-0x009f]
pci 0000:00:01.0: reg 0x14: [mem 0x10001000-0x10001fff]
pci 0000:00:01.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
pci 0000:00:01.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
pci 0000:00:02.0: [1af4:1001] type 00 class 0x010000
pci 0000:00:02.0: reg 0x10: [io  0x0000-0x007f]
pci 0000:00:02.0: reg 0x14: [mem 0x10000000-0x10000fff]
pci 0000:00:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
pci 0000:00:01.0: BAR 6: assigned [mem 0x10000000-0x1003ffff pref]
pci 0000:00:01.0: BAR 4: assigned [mem 0x8000000000-0x8000003fff 64bit pref]
pci 0000:00:02.0: BAR 4: assigned [mem 0x8000004000-0x8000007fff 64bit pref]
pci 0000:00:01.0: BAR 1: assigned [mem 0x10040000-0x10040fff]
pci 0000:00:02.0: BAR 1: assigned [mem 0x10041000-0x10041fff]
pci 0000:00:02.0: BAR 0: assigned [io  0x1000-0x107f]
pci 0000:00:01.0: BAR 0: assigned [io  0x1080-0x109f]
virtio-pci 0000:00:01.0: enabling device (0000 -> 0003)
virtio-pci 0000:00:02.0: enabling device (0000 -> 0003)
cacheinfo: Unable to detect cache hierarchy for CPU 0
virtio_blk virtio1: [vda] 122880 512-byte logical blocks (62.9 MB/60.0 MiB)
SMCCC: SOC_ID: ARCH_FEATURES(ARCH_SOC_ID) returned error: fffffffffffffffd
NET: Registered protocol family 10
Segment Routing with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
NET: Registered protocol family 15
NET: Registered protocol family 40
registered taskstats version 1
EXT4-fs (vda): recovery complete
EXT4-fs (vda): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
VFS: Mounted root (ext4 filesystem) on device 254:0.
devtmpfs: mounted
Freeing unused kernel memory: 1088K
Run /sbin/init as init process
mount: you must be root
mount: you must be root
mkdir: can't create directory '/dev/pts': Permission denied
mkdir: can't create directory '/dev/shm': Permission denied
mount: you must be root
hostname: sethostname: Operation not permitted
Starting syslogd: OK
Starting klogd: OK
Running sysctl: OK
Initializing random number generator: OK
Saving random seed: random: dd: uninitialized urandom read (512 bytes read)
OK
Starting network: ip: RTNETLINK answers: Operation not permitted
ip: SIOCSIFFLAGS: Operation not permitted
sed: /proc/mounts: No such file or directory
Waiting for interface eth0 to appear............... timeout!
run-parts: /etc/network/if-pre-up.d/wait_iface: exit status 1
FAIL
can't open /dev/ttyAMA0: Permission denied
can't open /dev/ttyAMA0: Permission denied
can't open /dev/ttyAMA0: Permission denied
can't open /dev/ttyAMA0: Permission denied

And it continues...

The qemu command I got did not work "as it is" and because I'm neither too
proficient with qemu nor aarch64, it took a while to get something usable.
This is my current qemu command:

qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu cortex-a57 \
                    -kernel ~/Projects/tpm/buildroot/output/images/Image \
		    -no-acpi \
		    -append 'root=/dev/vda rw console=ttyAMA0,115200 ' \
                    -drive file=~/Projects/tpm/buildroot/output/images/rootfs.ext4,format=raw \
                    -smp 1 \
		    -monitor telnet:127.0.0.1:55555,server,nowait \
		    -m 1024 -bios ~/Projects/tpm/fw/aarch64-fw.bin -d unimp

Then I start QEMU monitor from another terminal with:

socat tcp-connect:127.0.0.1:55555 file:`tty`,raw,echo=0

So... what could be the issue with permissions?

/Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-02-11 23:34                               ` Jarkko Sakkinen
@ 2021-02-11 23:35                                 ` Jarkko Sakkinen
  2021-02-15 13:07                                 ` Sumit Garg
  1 sibling, 0 replies; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-02-11 23:35 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jerome Forissier, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn, dave.hansen

On Fri, Feb 12, 2021 at 01:34:31AM +0200, Jarkko Sakkinen wrote:
> On Mon, Jan 25, 2021 at 02:47:38PM +0530, Sumit Garg wrote:
> > Hi Jarkko,
> > 
> > On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >
> > > On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> > > >
> > > >
> > > > On 1/21/21 4:24 PM, Jarkko Sakkinen wrote:
> > > > > On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote:
> > > > >> On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
> > > > >>>
> > > > >>>
> > > > >>> On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> > > > >>>> On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> > > > >>>>> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > >>>>>>
> > > > >>>>>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> > > > >>>>>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > > > >>>>>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > > > >>>>>>>>>> Hi Jarkko,
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > > >>>>>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
> > > > >>>>>>>>>>>> to seal and unseal trusted keys using hardware unique key.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
> > > > >>>>>>>>>>> just a blank screen:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
> > > > >>>>>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > > >>>>>>>>>>> in the master branch.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> To create identical images you just need to
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> $ make tpmdd_defconfig && make
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
> > > > >>>>>>>>>>> patch set, and in bigger picture I really need to have ready to run
> > > > >>>>>>>>>>> aarch64 environment available.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> I would rather suggest you to follow steps listed here [1] as to test
> > > > >>>>>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > > > >>>>>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > > > >>>>>>>>>> system [2]. And then it would be easier to migrate them to your
> > > > >>>>>>>>>> buildroot environment as well.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > > > >>>>>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> -Sumit
> > > > >>>>>>>>>
> > > > >>>>>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> $ cat keyctl_change
> > > > >>>>>>>> diff --git a/common.mk b/common.mk
> > > > >>>>>>>> index aeb7b41..663e528 100644
> > > > >>>>>>>> --- a/common.mk
> > > > >>>>>>>> +++ b/common.mk
> > > > >>>>>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> > > > >>>>>>>>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> > > > >>>>>>>>  BR2_PACKAGE_STRACE ?= y
> > > > >>>>>>>>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > > > >>>>>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > > > >>>>>>>> +BR2_PACKAGE_KEYUTILS := y
> > > > >>>>>>>>
> > > > >>>>>>>>  # All BR2_* variables from the makefile or the environment are appended to
> > > > >>>>>>>>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> > > > >>>>>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> > > > >>>>>>>> index 368c18a..832ab74 100644
> > > > >>>>>>>> --- a/kconfigs/qemu.conf
> > > > >>>>>>>> +++ b/kconfigs/qemu.conf
> > > > >>>>>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> > > > >>>>>>>>  CONFIG_9P_FS_POSIX_ACL=y
> > > > >>>>>>>>  CONFIG_HW_RANDOM=y
> > > > >>>>>>>>  CONFIG_HW_RANDOM_VIRTIO=y
> > > > >>>>>>>> +CONFIG_TRUSTED_KEYS=y
> > > > >>>>>>>> +CONFIG_ENCRYPTED_KEYS=y
> > > > >>>>>>>>
> > > > >>>>>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
> > > > >>>>>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
> > > > >>>>>>>>> remark in the commit message that TEE is a standard, with a link to the
> > > > >>>>>>>>> specification.
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> Sure, I will roll out the next version after your testing.
> > > > >>>>>>>
> > > > >>>>>>> Thanks, I'll try this at instant, and give my feedback.
> > > > >>>>>>
> > > > >>>>>> I bump into this:
> > > > >>>>>>
> > > > >>>>>> $ make run-only
> > > > >>>>>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> > > > >>>>>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> > > > >>>>>> make: *** [Makefile:194: run-only] Error 1
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>> Could you check if the following directory tree is built after
> > > > >>>>> executing the below command?
> > > > >>>>>
> > > > >>>>> $ make -j`nproc`
> > > > >>>>> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
> > > > >>>>>
> > > > >>>>> $ tree out/bin/
> > > > >>>>> out/bin/
> > > > >>>>> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
> > > > >>>>> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
> > > > >>>>> ├── bl31.bin ->
> > > > >>>>> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
> > > > >>>>> ├── bl32.bin ->
> > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
> > > > >>>>> ├── bl32_extra1.bin ->
> > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
> > > > >>>>> ├── bl32_extra2.bin ->
> > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
> > > > >>>>> ├── bl33.bin ->
> > > > >>>>> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
> > > > >>>>> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
> > > > >>>>> └── rootfs.cpio.gz ->
> > > > >>>>> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
> > > > >>>>>
> > > > >>>>> 0 directories, 9 files
> > > > >>>>>
> > > > >>>>> -Sumit
> > > > >>>>
> > > > >>>> I actually spotted a build error that was unnoticed last time:
> > > > >>>>
> > > > >>>> make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> > > > >>>> /bin/sh: 1: python: not found
> > > > >>>>
> > > > >>>> I'd prefer not to install Python2. It has been EOL over a year.
> > > > >>>
> > > > >>> AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
> > > > >>> machine, this is accomplished by installing package "python-is-python3"
> > > > >>> (after uninstalling "python-is-python2" if need be).
> > > > >>>
> > > > >>> $ ls -l /usr/bin/python
> > > > >>> lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3
> > > > >>
> > > > >> Right, just found about this in unrelated context :-) [*]
> > > > >>
> > > > >> Hope this will work out...
> > > > >>
> > > > >> [*] https://github.com/surge-synthesizer/surge/pull/3655
> > > > >
> > > > > Now I get
> > > > >
> > > > > Traceback (most recent call last):
> > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 36, in <module>
> > > > >     allTests = GetAllTestsSuite()
> > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 33, in GetAllTestsSuite
> > > > >     return unittest.TestSuite([GetCTestSuite(), GetPythonTestSuite()])
> > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 25, in GetCTestSuite
> > > > >     import CToolsTests
> > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/CToolsTests.py", line 22, in <module>
> > > > >     import TianoCompress
> > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TianoCompress.py", line 69, in <module>
> > > > >     TheTestSuite = TestTools.MakeTheTestSuite(locals())
> > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TestTools.py", line 43, in MakeTheTestSuite
> > > > >     for name, item in localItems.iteritems():
> > > > > AttributeError: 'dict' object has no attribute 'iteritems'
> > > >
> > > > Right. Same here after removing all traces of Python2 from my system :-/
> > > >
> > > > A couple of fixes are needed:
> > > > 1. EDK2 needs to be upgraded to tag or later [1]
> > > > 2. The PYTHON3_ENABLE environment variable needs to be set to TRUE [2]
> > > >
> > > > [1] https://github.com/OP-TEE/manifest/pull/177
> > > > [2] https://github.com/OP-TEE/build/pull/450
> > >
> > > BTW, Is to *really* impossible to test this with plain BuildRoot.  It's
> > > obvious that this forks BR internally.
> > >
> > > I mean even if I get this working once, this will feels like a clumsy way
> > > to test Aarch64 regularly. I use BuildRoot extensively for x86 testing. And
> > > it would be nice to be able to start doing regular ARM testing.
> > 
> > The main reason to guide you towards the OP-TEE build system is that
> > you will be able to build all the firmwares (TF-A, OP-TEE, edk2 etc.)
> > from source. If you don't need to rebuild those then I have prepared a
> > flash firmware binary blob for your testing (attached flash.bin). So
> > Qemu cmdline will look like:
> > 
> > $ qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu
> > cortex-a57 -kernel out/bin/Image -no-acpi -append
> > 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2' -initrd
> > out/bin/rootfs.cpio.gz -smp 2 -m 1024 -bios flash.bin -d unimp
> 
> I spentt couple of days to try to get this running.
> 
> Here's the log:
> 
> ❯ ./qemu.sh
> NOTICE:  Booting Trusted Firmware
> NOTICE:  BL1: v2.3():v2.3
> NOTICE:  BL1: Built : 13:28:04, Jan 25 2021
> NOTICE:  BL1: Booting BL2
> NOTICE:  BL2: v2.3():v2.3
> NOTICE:  BL2: Built : 13:28:06, Jan 25 2021
> NOTICE:  BL1: Booting BL31
> NOTICE:  BL31: v2.3():v2.3
> NOTICE:  BL31: Built : 13:28:08, Jan 25 2021
> UEFI firmware (version  built at 18:49:27 on Nov 18 2019)
> pflash_write: Write to buffer emulation is flawed
> pflash_write: Write to buffer emulation is flawed
> EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> Booting Linux on physical CPU 0x0000000000 [0x411fd070]
> Linux version 5.11.0-rc5 (jarkko@suppilovahvero) (aarch64-buildroot-linux-uclibc-gcc.br_real (Buildroot 2021.02-rc1-10-ga72c90b972) 9.3.0, GNU ld (GNU Binutils) 2.35.2) #1 SMP Thu Feb 11 22:04:53 EET 2021
> Machine model: linux,dummy-virt
> efi: EFI v2.70 by EDK II
> efi: SMBIOS=0x7f520000 SMBIOS 3.0=0x7f500000 MEMATTR=0x7e59b018 MEMRESERVE=0x7c143f18
> Zone ranges:
>   DMA      [mem 0x0000000040000000-0x000000007fffffff]
>   DMA32    empty
>   Normal   empty
> Movable zone start for each node
> Early memory node ranges
>   node   0: [mem 0x0000000040000000-0x0000000041ffffff]
>   node   0: [mem 0x0000000042200000-0x000000007be3ffff]
>   node   0: [mem 0x000000007be40000-0x000000007c13ffff]
>   node   0: [mem 0x000000007c140000-0x000000007f41ffff]
>   node   0: [mem 0x000000007f420000-0x000000007f4affff]
>   node   0: [mem 0x000000007f4b0000-0x000000007f4cffff]
>   node   0: [mem 0x000000007f4d0000-0x000000007f5dffff]
>   node   0: [mem 0x000000007f5e0000-0x000000007fffffff]
> Zeroed struct page in unavailable ranges: 864 pages
> Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff]
> psci: probing for conduit method from DT.
> psci: PSCIv1.1 detected in firmware.
> psci: Using standard PSCI v0.2 function IDs
> psci: Trusted OS migration not required
> psci: SMC Calling Convention v1.2
> percpu: Embedded 21 pages/cpu s48024 r8192 d29800 u86016
> Detected PIPT I-cache on CPU0
> CPU features: detected: ARM erratum 832075
> CPU features: detected: Spectre-v2
> CPU features: detected: ARM errata 1165522, 1319367, or 1530923
> Built 1 zonelists, mobility grouping on.  Total pages: 257536
> Kernel command line: root=/dev/vda rw console=ttyAMA0,115200
> Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
> Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
> mem auto-init: stack:off, heap alloc:off, heap free:off
> Memory: 1011284K/1046528K available (6592K kernel code, 804K rwdata, 1460K rodata, 1088K init, 321K bss, 35244K reserved, 0K cma-reserved)
> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> rcu: Hierarchical RCU implementation.
> rcu:    RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=1.
> rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
> rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
> NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
> GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
> random: get_random_bytes called from start_kernel+0x340/0x53c with crng_init=0
> arch_timer: cp15 timer(s) running at 62.50MHz (virt).
> clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
> sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
> Console: colour dummy device 80x25
> Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=250000)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
> Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
> rcu: Hierarchical SRCU implementation.
> Remapping and enabling EFI services.
> smp: Bringing up secondary CPUs ...
> smp: Brought up 1 node, 1 CPU
> SMP: Total of 1 processors activated.
> CPU features: detected: 32-bit EL0 Support
> CPU features: detected: CRC32 instructions
> CPU: All CPU(s) started at EL1
> alternatives: patching kernel code
> devtmpfs: initialized
> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> SMBIOS 3.0.0 present.
> DMI: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
> NET: Registered protocol family 16
> DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
> DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
> DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
> hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
> ASID allocator initialised with 65536 entries
> Serial: AMBA PL011 UART driver
> 9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 46, base_baud = 0) is a PL011 rev1
> printk: console [ttyAMA0] enabled
> iommu: Default domain type: Translated
> vgaarb: loaded
> SCSI subsystem initialized
> Registered efivars operations
> clocksource: Switched to clocksource arch_sys_counter
> NET: Registered protocol family 2
> tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)
> TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
> TCP bind hash table entries: 8192 (order: 5, 131072 bytes, linear)
> TCP: Hash tables configured (established 8192 bind 8192)
> UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
> NET: Registered protocol family 1
> PCI: CLS 0 bytes, default 64
> hw perfevents: enabled with armv8_pmuv3 PMU driver, 5 counters available
> workingset: timestamp_bits=62 max_order=18 bucket_order=0
> fuse: init (API version 7.33)
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
> io scheduler mq-deadline registered
> io scheduler kyber registered
> pci-host-generic 4010000000.pcie: host bridge /pcie@10000000 ranges:
> pci-host-generic 4010000000.pcie:       IO 0x003eff0000..0x003effffff -> 0x0000000000
> pci-host-generic 4010000000.pcie:      MEM 0x0010000000..0x003efeffff -> 0x0010000000
> pci-host-generic 4010000000.pcie:      MEM 0x8000000000..0xffffffffff -> 0x8000000000
> pci-host-generic 4010000000.pcie: Memory resource size exceeds max for 32 bits
> pci-host-generic 4010000000.pcie: ECAM at [mem 0x4010000000-0x401fffffff] for [bus 00-ff]
> pci-host-generic 4010000000.pcie: PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [bus 00-ff]
> pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff]
> pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff]
> pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
> pci 0000:00:01.0: [1af4:1000] type 00 class 0x020000
> pci 0000:00:01.0: reg 0x10: [io  0x0080-0x009f]
> pci 0000:00:01.0: reg 0x14: [mem 0x10001000-0x10001fff]
> pci 0000:00:01.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
> pci 0000:00:01.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
> pci 0000:00:02.0: [1af4:1001] type 00 class 0x010000
> pci 0000:00:02.0: reg 0x10: [io  0x0000-0x007f]
> pci 0000:00:02.0: reg 0x14: [mem 0x10000000-0x10000fff]
> pci 0000:00:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
> pci 0000:00:01.0: BAR 6: assigned [mem 0x10000000-0x1003ffff pref]
> pci 0000:00:01.0: BAR 4: assigned [mem 0x8000000000-0x8000003fff 64bit pref]
> pci 0000:00:02.0: BAR 4: assigned [mem 0x8000004000-0x8000007fff 64bit pref]
> pci 0000:00:01.0: BAR 1: assigned [mem 0x10040000-0x10040fff]
> pci 0000:00:02.0: BAR 1: assigned [mem 0x10041000-0x10041fff]
> pci 0000:00:02.0: BAR 0: assigned [io  0x1000-0x107f]
> pci 0000:00:01.0: BAR 0: assigned [io  0x1080-0x109f]
> virtio-pci 0000:00:01.0: enabling device (0000 -> 0003)
> virtio-pci 0000:00:02.0: enabling device (0000 -> 0003)
> cacheinfo: Unable to detect cache hierarchy for CPU 0
> virtio_blk virtio1: [vda] 122880 512-byte logical blocks (62.9 MB/60.0 MiB)
> SMCCC: SOC_ID: ARCH_FEATURES(ARCH_SOC_ID) returned error: fffffffffffffffd
> NET: Registered protocol family 10
> Segment Routing with IPv6
> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> NET: Registered protocol family 40
> registered taskstats version 1
> EXT4-fs (vda): recovery complete
> EXT4-fs (vda): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
> VFS: Mounted root (ext4 filesystem) on device 254:0.
> devtmpfs: mounted
> Freeing unused kernel memory: 1088K
> Run /sbin/init as init process
> mount: you must be root
> mount: you must be root
> mkdir: can't create directory '/dev/pts': Permission denied
> mkdir: can't create directory '/dev/shm': Permission denied
> mount: you must be root
> hostname: sethostname: Operation not permitted
> Starting syslogd: OK
> Starting klogd: OK
> Running sysctl: OK
> Initializing random number generator: OK
> Saving random seed: random: dd: uninitialized urandom read (512 bytes read)
> OK
> Starting network: ip: RTNETLINK answers: Operation not permitted
> ip: SIOCSIFFLAGS: Operation not permitted
> sed: /proc/mounts: No such file or directory
> Waiting for interface eth0 to appear............... timeout!
> run-parts: /etc/network/if-pre-up.d/wait_iface: exit status 1
> FAIL
> can't open /dev/ttyAMA0: Permission denied
> can't open /dev/ttyAMA0: Permission denied
> can't open /dev/ttyAMA0: Permission denied
> can't open /dev/ttyAMA0: Permission denied
> 
> And it continues...
> 
> The qemu command I got did not work "as it is" and because I'm neither too
> proficient with qemu nor aarch64, it took a while to get something usable.
> This is my current qemu command:
> 
> qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu cortex-a57 \
>                     -kernel ~/Projects/tpm/buildroot/output/images/Image \
> 		    -no-acpi \
> 		    -append 'root=/dev/vda rw console=ttyAMA0,115200 ' \
>                     -drive file=~/Projects/tpm/buildroot/output/images/rootfs.ext4,format=raw \
>                     -smp 1 \
> 		    -monitor telnet:127.0.0.1:55555,server,nowait \
> 		    -m 1024 -bios ~/Projects/tpm/fw/aarch64-fw.bin -d unimp
> 
> Then I start QEMU monitor from another terminal with:
> 
> socat tcp-connect:127.0.0.1:55555 file:`tty`,raw,echo=0
> 
> So... what could be the issue with permissions?

NOTE: aarch64-fw.bin is the binary file for FW that you provided. I just renamed it.

/Jarkko

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

* Re: [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework
  2021-02-11 10:34     ` Ahmad Fatoum
@ 2021-02-12 12:22       ` Jarkko Sakkinen
  0 siblings, 0 replies; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-02-12 12:22 UTC (permalink / raw)
  To: Ahmad Fatoum
  Cc: Sumit Garg, linux-security-module, daniel.thompson, op-tee,
	corbet, jejb, janne.karhunen, linux-doc, jmorris, zohar,
	linux-kernel, dhowells, lhinds, keyrings, jarkko.sakkinen,
	Markus.Wamser, casey, linux-integrity, jens.wiklander,
	linux-arm-kernel, serge

On Thu, Feb 11, 2021 at 11:34:21AM +0100, Ahmad Fatoum wrote:
> Hello Jarkko,
> 
> On 10.02.21 18:00, Jarkko Sakkinen wrote:
> > On Tue, Nov 03, 2020 at 09:31:43PM +0530, Sumit Garg wrote:
> >> +	case Opt_new:
> >> +		key_len = payload->key_len;
> >> +		ret = static_call(trusted_key_get_random)(payload->key,
> >> +							  key_len);
> >> +		if (ret != key_len) {
> >> +			pr_info("trusted_key: key_create failed (%d)\n", ret);
> >> +			goto out;
> >> +		}
> > 
> > This repeats a regression in existing code, i.e. does not check
> > "ret < 0" condition. I noticed this now when I rebased the code
> > on top of my fixes.
> > 
> > I.e. it's fixed in my master branch, which caused a merge conflict,
> > and I found this.
> 
> Does that mean this series will go out for the next merge window?
> Can you point me where your git tree is, so I can rebase on top?

No I mean the bug that is propagated here is fixed in my master
branch, i.e. get_random() should check also '< 0' condition.

/Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-02-11 23:34                               ` Jarkko Sakkinen
  2021-02-11 23:35                                 ` Jarkko Sakkinen
@ 2021-02-15 13:07                                 ` Sumit Garg
  2021-02-16  7:29                                   ` Jarkko Sakkinen
  1 sibling, 1 reply; 52+ messages in thread
From: Sumit Garg @ 2021-02-15 13:07 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jerome Forissier, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn, dave.hansen

On Fri, 12 Feb 2021 at 05:04, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Mon, Jan 25, 2021 at 02:47:38PM +0530, Sumit Garg wrote:
> > Hi Jarkko,
> >
> > On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >
> > > On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> > > >
> > > >
> > > > On 1/21/21 4:24 PM, Jarkko Sakkinen wrote:
> > > > > On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote:
> > > > >> On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
> > > > >>>
> > > > >>>
> > > > >>> On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> > > > >>>> On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> > > > >>>>> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > >>>>>>
> > > > >>>>>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> > > > >>>>>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > > > >>>>>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > > > >>>>>>>>>> Hi Jarkko,
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > > >>>>>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
> > > > >>>>>>>>>>>> to seal and unseal trusted keys using hardware unique key.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
> > > > >>>>>>>>>>> just a blank screen:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
> > > > >>>>>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > > >>>>>>>>>>> in the master branch.
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> To create identical images you just need to
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> $ make tpmdd_defconfig && make
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
> > > > >>>>>>>>>>> patch set, and in bigger picture I really need to have ready to run
> > > > >>>>>>>>>>> aarch64 environment available.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> I would rather suggest you to follow steps listed here [1] as to test
> > > > >>>>>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > > > >>>>>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > > > >>>>>>>>>> system [2]. And then it would be easier to migrate them to your
> > > > >>>>>>>>>> buildroot environment as well.
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > > > >>>>>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> -Sumit
> > > > >>>>>>>>>
> > > > >>>>>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> $ cat keyctl_change
> > > > >>>>>>>> diff --git a/common.mk b/common.mk
> > > > >>>>>>>> index aeb7b41..663e528 100644
> > > > >>>>>>>> --- a/common.mk
> > > > >>>>>>>> +++ b/common.mk
> > > > >>>>>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> > > > >>>>>>>>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> > > > >>>>>>>>  BR2_PACKAGE_STRACE ?= y
> > > > >>>>>>>>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > > > >>>>>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > > > >>>>>>>> +BR2_PACKAGE_KEYUTILS := y
> > > > >>>>>>>>
> > > > >>>>>>>>  # All BR2_* variables from the makefile or the environment are appended to
> > > > >>>>>>>>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> > > > >>>>>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> > > > >>>>>>>> index 368c18a..832ab74 100644
> > > > >>>>>>>> --- a/kconfigs/qemu.conf
> > > > >>>>>>>> +++ b/kconfigs/qemu.conf
> > > > >>>>>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> > > > >>>>>>>>  CONFIG_9P_FS_POSIX_ACL=y
> > > > >>>>>>>>  CONFIG_HW_RANDOM=y
> > > > >>>>>>>>  CONFIG_HW_RANDOM_VIRTIO=y
> > > > >>>>>>>> +CONFIG_TRUSTED_KEYS=y
> > > > >>>>>>>> +CONFIG_ENCRYPTED_KEYS=y
> > > > >>>>>>>>
> > > > >>>>>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
> > > > >>>>>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
> > > > >>>>>>>>> remark in the commit message that TEE is a standard, with a link to the
> > > > >>>>>>>>> specification.
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>> Sure, I will roll out the next version after your testing.
> > > > >>>>>>>
> > > > >>>>>>> Thanks, I'll try this at instant, and give my feedback.
> > > > >>>>>>
> > > > >>>>>> I bump into this:
> > > > >>>>>>
> > > > >>>>>> $ make run-only
> > > > >>>>>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> > > > >>>>>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> > > > >>>>>> make: *** [Makefile:194: run-only] Error 1
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>> Could you check if the following directory tree is built after
> > > > >>>>> executing the below command?
> > > > >>>>>
> > > > >>>>> $ make -j`nproc`
> > > > >>>>> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
> > > > >>>>>
> > > > >>>>> $ tree out/bin/
> > > > >>>>> out/bin/
> > > > >>>>> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
> > > > >>>>> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
> > > > >>>>> ├── bl31.bin ->
> > > > >>>>> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
> > > > >>>>> ├── bl32.bin ->
> > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
> > > > >>>>> ├── bl32_extra1.bin ->
> > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
> > > > >>>>> ├── bl32_extra2.bin ->
> > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
> > > > >>>>> ├── bl33.bin ->
> > > > >>>>> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
> > > > >>>>> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
> > > > >>>>> └── rootfs.cpio.gz ->
> > > > >>>>> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
> > > > >>>>>
> > > > >>>>> 0 directories, 9 files
> > > > >>>>>
> > > > >>>>> -Sumit
> > > > >>>>
> > > > >>>> I actually spotted a build error that was unnoticed last time:
> > > > >>>>
> > > > >>>> make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> > > > >>>> /bin/sh: 1: python: not found
> > > > >>>>
> > > > >>>> I'd prefer not to install Python2. It has been EOL over a year.
> > > > >>>
> > > > >>> AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
> > > > >>> machine, this is accomplished by installing package "python-is-python3"
> > > > >>> (after uninstalling "python-is-python2" if need be).
> > > > >>>
> > > > >>> $ ls -l /usr/bin/python
> > > > >>> lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3
> > > > >>
> > > > >> Right, just found about this in unrelated context :-) [*]
> > > > >>
> > > > >> Hope this will work out...
> > > > >>
> > > > >> [*] https://github.com/surge-synthesizer/surge/pull/3655
> > > > >
> > > > > Now I get
> > > > >
> > > > > Traceback (most recent call last):
> > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 36, in <module>
> > > > >     allTests = GetAllTestsSuite()
> > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 33, in GetAllTestsSuite
> > > > >     return unittest.TestSuite([GetCTestSuite(), GetPythonTestSuite()])
> > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 25, in GetCTestSuite
> > > > >     import CToolsTests
> > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/CToolsTests.py", line 22, in <module>
> > > > >     import TianoCompress
> > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TianoCompress.py", line 69, in <module>
> > > > >     TheTestSuite = TestTools.MakeTheTestSuite(locals())
> > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TestTools.py", line 43, in MakeTheTestSuite
> > > > >     for name, item in localItems.iteritems():
> > > > > AttributeError: 'dict' object has no attribute 'iteritems'
> > > >
> > > > Right. Same here after removing all traces of Python2 from my system :-/
> > > >
> > > > A couple of fixes are needed:
> > > > 1. EDK2 needs to be upgraded to tag or later [1]
> > > > 2. The PYTHON3_ENABLE environment variable needs to be set to TRUE [2]
> > > >
> > > > [1] https://github.com/OP-TEE/manifest/pull/177
> > > > [2] https://github.com/OP-TEE/build/pull/450
> > >
> > > BTW, Is to *really* impossible to test this with plain BuildRoot.  It's
> > > obvious that this forks BR internally.
> > >
> > > I mean even if I get this working once, this will feels like a clumsy way
> > > to test Aarch64 regularly. I use BuildRoot extensively for x86 testing. And
> > > it would be nice to be able to start doing regular ARM testing.
> >
> > The main reason to guide you towards the OP-TEE build system is that
> > you will be able to build all the firmwares (TF-A, OP-TEE, edk2 etc.)
> > from source. If you don't need to rebuild those then I have prepared a
> > flash firmware binary blob for your testing (attached flash.bin). So
> > Qemu cmdline will look like:
> >
> > $ qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu
> > cortex-a57 -kernel out/bin/Image -no-acpi -append
> > 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2' -initrd
> > out/bin/rootfs.cpio.gz -smp 2 -m 1024 -bios flash.bin -d unimp
>
> I spentt couple of days to try to get this running.
>
> Here's the log:
>
> ❯ ./qemu.sh
> NOTICE:  Booting Trusted Firmware
> NOTICE:  BL1: v2.3():v2.3
> NOTICE:  BL1: Built : 13:28:04, Jan 25 2021
> NOTICE:  BL1: Booting BL2
> NOTICE:  BL2: v2.3():v2.3
> NOTICE:  BL2: Built : 13:28:06, Jan 25 2021
> NOTICE:  BL1: Booting BL31
> NOTICE:  BL31: v2.3():v2.3
> NOTICE:  BL31: Built : 13:28:08, Jan 25 2021
> UEFI firmware (version  built at 18:49:27 on Nov 18 2019)
> pflash_write: Write to buffer emulation is flawed
> pflash_write: Write to buffer emulation is flawed
> EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from configuration table
> EFI stub: Exiting boot services and installing virtual address map...
> Booting Linux on physical CPU 0x0000000000 [0x411fd070]
> Linux version 5.11.0-rc5 (jarkko@suppilovahvero) (aarch64-buildroot-linux-uclibc-gcc.br_real (Buildroot 2021.02-rc1-10-ga72c90b972) 9.3.0, GNU ld (GNU Binutils) 2.35.2) #1 SMP Thu Feb 11 22:04:53 EET 2021
> Machine model: linux,dummy-virt
> efi: EFI v2.70 by EDK II
> efi: SMBIOS=0x7f520000 SMBIOS 3.0=0x7f500000 MEMATTR=0x7e59b018 MEMRESERVE=0x7c143f18
> Zone ranges:
>   DMA      [mem 0x0000000040000000-0x000000007fffffff]
>   DMA32    empty
>   Normal   empty
> Movable zone start for each node
> Early memory node ranges
>   node   0: [mem 0x0000000040000000-0x0000000041ffffff]
>   node   0: [mem 0x0000000042200000-0x000000007be3ffff]
>   node   0: [mem 0x000000007be40000-0x000000007c13ffff]
>   node   0: [mem 0x000000007c140000-0x000000007f41ffff]
>   node   0: [mem 0x000000007f420000-0x000000007f4affff]
>   node   0: [mem 0x000000007f4b0000-0x000000007f4cffff]
>   node   0: [mem 0x000000007f4d0000-0x000000007f5dffff]
>   node   0: [mem 0x000000007f5e0000-0x000000007fffffff]
> Zeroed struct page in unavailable ranges: 864 pages
> Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff]
> psci: probing for conduit method from DT.
> psci: PSCIv1.1 detected in firmware.
> psci: Using standard PSCI v0.2 function IDs
> psci: Trusted OS migration not required
> psci: SMC Calling Convention v1.2
> percpu: Embedded 21 pages/cpu s48024 r8192 d29800 u86016
> Detected PIPT I-cache on CPU0
> CPU features: detected: ARM erratum 832075
> CPU features: detected: Spectre-v2
> CPU features: detected: ARM errata 1165522, 1319367, or 1530923
> Built 1 zonelists, mobility grouping on.  Total pages: 257536
> Kernel command line: root=/dev/vda rw console=ttyAMA0,115200
> Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
> Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
> mem auto-init: stack:off, heap alloc:off, heap free:off
> Memory: 1011284K/1046528K available (6592K kernel code, 804K rwdata, 1460K rodata, 1088K init, 321K bss, 35244K reserved, 0K cma-reserved)
> SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> rcu: Hierarchical RCU implementation.
> rcu:    RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=1.
> rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
> rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
> NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
> GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
> random: get_random_bytes called from start_kernel+0x340/0x53c with crng_init=0
> arch_timer: cp15 timer(s) running at 62.50MHz (virt).
> clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
> sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
> Console: colour dummy device 80x25
> Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=250000)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
> Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
> rcu: Hierarchical SRCU implementation.
> Remapping and enabling EFI services.
> smp: Bringing up secondary CPUs ...
> smp: Brought up 1 node, 1 CPU
> SMP: Total of 1 processors activated.
> CPU features: detected: 32-bit EL0 Support
> CPU features: detected: CRC32 instructions
> CPU: All CPU(s) started at EL1
> alternatives: patching kernel code
> devtmpfs: initialized
> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> SMBIOS 3.0.0 present.
> DMI: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
> NET: Registered protocol family 16
> DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
> DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
> DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
> hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
> ASID allocator initialised with 65536 entries
> Serial: AMBA PL011 UART driver
> 9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 46, base_baud = 0) is a PL011 rev1
> printk: console [ttyAMA0] enabled
> iommu: Default domain type: Translated
> vgaarb: loaded
> SCSI subsystem initialized
> Registered efivars operations
> clocksource: Switched to clocksource arch_sys_counter
> NET: Registered protocol family 2
> tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)
> TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
> TCP bind hash table entries: 8192 (order: 5, 131072 bytes, linear)
> TCP: Hash tables configured (established 8192 bind 8192)
> UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
> UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
> NET: Registered protocol family 1
> PCI: CLS 0 bytes, default 64
> hw perfevents: enabled with armv8_pmuv3 PMU driver, 5 counters available
> workingset: timestamp_bits=62 max_order=18 bucket_order=0
> fuse: init (API version 7.33)
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
> io scheduler mq-deadline registered
> io scheduler kyber registered
> pci-host-generic 4010000000.pcie: host bridge /pcie@10000000 ranges:
> pci-host-generic 4010000000.pcie:       IO 0x003eff0000..0x003effffff -> 0x0000000000
> pci-host-generic 4010000000.pcie:      MEM 0x0010000000..0x003efeffff -> 0x0010000000
> pci-host-generic 4010000000.pcie:      MEM 0x8000000000..0xffffffffff -> 0x8000000000
> pci-host-generic 4010000000.pcie: Memory resource size exceeds max for 32 bits
> pci-host-generic 4010000000.pcie: ECAM at [mem 0x4010000000-0x401fffffff] for [bus 00-ff]
> pci-host-generic 4010000000.pcie: PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [bus 00-ff]
> pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff]
> pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff]
> pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
> pci 0000:00:01.0: [1af4:1000] type 00 class 0x020000
> pci 0000:00:01.0: reg 0x10: [io  0x0080-0x009f]
> pci 0000:00:01.0: reg 0x14: [mem 0x10001000-0x10001fff]
> pci 0000:00:01.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
> pci 0000:00:01.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
> pci 0000:00:02.0: [1af4:1001] type 00 class 0x010000
> pci 0000:00:02.0: reg 0x10: [io  0x0000-0x007f]
> pci 0000:00:02.0: reg 0x14: [mem 0x10000000-0x10000fff]
> pci 0000:00:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
> pci 0000:00:01.0: BAR 6: assigned [mem 0x10000000-0x1003ffff pref]
> pci 0000:00:01.0: BAR 4: assigned [mem 0x8000000000-0x8000003fff 64bit pref]
> pci 0000:00:02.0: BAR 4: assigned [mem 0x8000004000-0x8000007fff 64bit pref]
> pci 0000:00:01.0: BAR 1: assigned [mem 0x10040000-0x10040fff]
> pci 0000:00:02.0: BAR 1: assigned [mem 0x10041000-0x10041fff]
> pci 0000:00:02.0: BAR 0: assigned [io  0x1000-0x107f]
> pci 0000:00:01.0: BAR 0: assigned [io  0x1080-0x109f]
> virtio-pci 0000:00:01.0: enabling device (0000 -> 0003)
> virtio-pci 0000:00:02.0: enabling device (0000 -> 0003)
> cacheinfo: Unable to detect cache hierarchy for CPU 0
> virtio_blk virtio1: [vda] 122880 512-byte logical blocks (62.9 MB/60.0 MiB)
> SMCCC: SOC_ID: ARCH_FEATURES(ARCH_SOC_ID) returned error: fffffffffffffffd
> NET: Registered protocol family 10
> Segment Routing with IPv6
> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> NET: Registered protocol family 17
> NET: Registered protocol family 15
> NET: Registered protocol family 40
> registered taskstats version 1
> EXT4-fs (vda): recovery complete
> EXT4-fs (vda): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
> VFS: Mounted root (ext4 filesystem) on device 254:0.
> devtmpfs: mounted
> Freeing unused kernel memory: 1088K
> Run /sbin/init as init process
> mount: you must be root
> mount: you must be root
> mkdir: can't create directory '/dev/pts': Permission denied
> mkdir: can't create directory '/dev/shm': Permission denied
> mount: you must be root
> hostname: sethostname: Operation not permitted
> Starting syslogd: OK
> Starting klogd: OK
> Running sysctl: OK
> Initializing random number generator: OK
> Saving random seed: random: dd: uninitialized urandom read (512 bytes read)
> OK
> Starting network: ip: RTNETLINK answers: Operation not permitted
> ip: SIOCSIFFLAGS: Operation not permitted
> sed: /proc/mounts: No such file or directory
> Waiting for interface eth0 to appear............... timeout!
> run-parts: /etc/network/if-pre-up.d/wait_iface: exit status 1
> FAIL
> can't open /dev/ttyAMA0: Permission denied
> can't open /dev/ttyAMA0: Permission denied
> can't open /dev/ttyAMA0: Permission denied
> can't open /dev/ttyAMA0: Permission denied
>
> And it continues...
>
> The qemu command I got did not work "as it is" and because I'm neither too
> proficient with qemu nor aarch64, it took a while to get something usable.
> This is my current qemu command:
>
> qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu cortex-a57 \
>                     -kernel ~/Projects/tpm/buildroot/output/images/Image \
>                     -no-acpi \
>                     -append 'root=/dev/vda rw console=ttyAMA0,115200 ' \
>                     -drive file=~/Projects/tpm/buildroot/output/images/rootfs.ext4,format=raw \
>                     -smp 1 \
>                     -monitor telnet:127.0.0.1:55555,server,nowait \
>                     -m 1024 -bios ~/Projects/tpm/fw/aarch64-fw.bin -d unimp
>
> Then I start QEMU monitor from another terminal with:
>
> socat tcp-connect:127.0.0.1:55555 file:`tty`,raw,echo=0
>
> So... what could be the issue with permissions?
>

It mostly sounds like an issue with your buildroot filesystem.

Can you try with this [1] init ramdisk instead?

-initrd rootfs.cpio.gz

[1] https://people.linaro.org/~sumit.garg/rootfs.cpio.gz

-Sumit

> /Jarkko

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

* Re: [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework
  2020-11-24  3:42   ` Jarkko Sakkinen
@ 2021-02-15 13:13     ` Sumit Garg
  0 siblings, 0 replies; 52+ messages in thread
From: Sumit Garg @ 2021-02-15 13:13 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Tue, 24 Nov 2020 at 09:12, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Tue, Nov 03, 2020 at 09:31:43PM +0530, Sumit Garg wrote:
> > Current trusted keys framework is tightly coupled to use TPM device as
> > an underlying implementation which makes it difficult for implementations
> > like Trusted Execution Environment (TEE) etc. to provide trusted keys
> > support in case platform doesn't posses a TPM device.
> >
> > Add a generic trusted keys framework where underlying implementations
> > can be easily plugged in. Create struct trusted_key_ops to achieve this,
> > which contains necessary functions of a backend.
> >
> > Also, define a module parameter in order to select a particular trust
> > source in case a platform support multiple trust sources. In case its
> > not specified then implementation itetrates through trust sources list
> > starting with TPM and assign the first trust source as a backend which
> > has initiazed successfully during iteration.
> >
> > Note that current implementation only supports a single trust source at
> > runtime which is either selectable at compile time or during boot via
> > aforementioned module parameter.
> >
> > Suggested-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > ---
> >  Documentation/admin-guide/kernel-parameters.txt |  12 +
> >  include/keys/trusted-type.h                     |  47 ++++
>
>
>
> >  include/keys/trusted_tpm.h                      |  17 +-
> >  security/keys/trusted-keys/Makefile             |   1 +
> >  security/keys/trusted-keys/trusted_core.c       | 350 ++++++++++++++++++++++++
> >  security/keys/trusted-keys/trusted_tpm1.c       | 336 ++++-------------------
> >  6 files changed, 468 insertions(+), 295 deletions(-)
> >  create mode 100644 security/keys/trusted-keys/trusted_core.c
> >
> > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> > index 526d65d..df9b9fe 100644
> > --- a/Documentation/admin-guide/kernel-parameters.txt
> > +++ b/Documentation/admin-guide/kernel-parameters.txt
> > @@ -5392,6 +5392,18 @@
> >                       See Documentation/admin-guide/mm/transhuge.rst
> >                       for more details.
> >
> > +     trusted.source= [KEYS]
> > +                     Format: <string>
> > +                     This parameter identifies the trust source as a backend
> > +                     for trusted keys implementation. Supported trust
> > +                     sources:
> > +                     - "tpm"
> > +                     - "tee"
> > +                     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
> > +                     successfully during iteration.
> > +
> >       tsc=            Disable clocksource stability checks for TSC.
> >                       Format: <string>
> >                       [x86] reliable: mark tsc clocksource as reliable, this
> > diff --git a/include/keys/trusted-type.h b/include/keys/trusted-type.h
> > index a94c03a..a566451 100644
> > --- a/include/keys/trusted-type.h
> > +++ b/include/keys/trusted-type.h
> > @@ -40,6 +40,53 @@ struct trusted_key_options {
> >       uint32_t policyhandle;
> >  };
> >
> > +struct trusted_key_ops {
> > +     /*
> > +      * flag to indicate if trusted key implementation supports migration
> > +      * or not.
> > +      */
> > +     unsigned char migratable;
> > +
> > +     /* Initialize key interface. */
> > +     int (*init)(void);
> > +
> > +     /* Seal a key. */
> > +     int (*seal)(struct trusted_key_payload *p, char *datablob);
> > +
> > +     /* Unseal a key. */
> > +     int (*unseal)(struct trusted_key_payload *p, char *datablob);
> > +
> > +     /* Get a randomized key. */
> > +     int (*get_random)(unsigned char *key, size_t key_len);
> > +
> > +     /* Exit key interface. */
> > +     void (*exit)(void);
> > +};
> > +
> > +struct trusted_key_source {
> > +     char *name;
> > +     struct trusted_key_ops *ops;
> > +};
> > +
> >  extern struct key_type key_type_trusted;
> >
> > +#define TRUSTED_DEBUG 0
> > +
> > +#if TRUSTED_DEBUG
> > +static inline void dump_payload(struct trusted_key_payload *p)
> > +{
> > +     pr_info("trusted_key: key_len %d\n", p->key_len);
> > +     print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
> > +                    16, 1, p->key, p->key_len, 0);
> > +     pr_info("trusted_key: bloblen %d\n", p->blob_len);
> > +     print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
> > +                    16, 1, p->blob, p->blob_len, 0);
> > +     pr_info("trusted_key: migratable %d\n", p->migratable);
> > +}
> > +#else
> > +static inline void dump_payload(struct trusted_key_payload *p)
> > +{
> > +}
> > +#endif
> > +
> >  #endif /* _KEYS_TRUSTED_TYPE_H */
> > diff --git a/include/keys/trusted_tpm.h b/include/keys/trusted_tpm.h
> > index a56d8e1..fb3280a 100644
> > --- a/include/keys/trusted_tpm.h
> > +++ b/include/keys/trusted_tpm.h
> > @@ -16,6 +16,8 @@
> >  #define LOAD32N(buffer, offset)      (*(uint32_t *)&buffer[offset])
> >  #define LOAD16(buffer, offset)       (ntohs(*(uint16_t *)&buffer[offset]))
> >
> > +extern struct trusted_key_ops tpm_trusted_key_ops;
> > +
> >  struct osapsess {
> >       uint32_t handle;
> >       unsigned char secret[SHA1_DIGEST_SIZE];
> > @@ -60,17 +62,6 @@ static inline void dump_options(struct trusted_key_options *o)
> >                      16, 1, o->pcrinfo, o->pcrinfo_len, 0);
> >  }
> >
> > -static inline void dump_payload(struct trusted_key_payload *p)
> > -{
> > -     pr_info("trusted_key: key_len %d\n", p->key_len);
> > -     print_hex_dump(KERN_INFO, "key ", DUMP_PREFIX_NONE,
> > -                    16, 1, p->key, p->key_len, 0);
> > -     pr_info("trusted_key: bloblen %d\n", p->blob_len);
> > -     print_hex_dump(KERN_INFO, "blob ", DUMP_PREFIX_NONE,
> > -                    16, 1, p->blob, p->blob_len, 0);
> > -     pr_info("trusted_key: migratable %d\n", p->migratable);
> > -}
> > -
> >  static inline void dump_sess(struct osapsess *s)
> >  {
> >       print_hex_dump(KERN_INFO, "trusted-key: handle ", DUMP_PREFIX_NONE,
> > @@ -96,10 +87,6 @@ static inline void dump_options(struct trusted_key_options *o)
> >  {
> >  }
> >
> > -static inline void dump_payload(struct trusted_key_payload *p)
> > -{
> > -}
> > -
> >  static inline void dump_sess(struct osapsess *s)
> >  {
> >  }
> > diff --git a/security/keys/trusted-keys/Makefile b/security/keys/trusted-keys/Makefile
> > index 7b73ceb..49e3bcf 100644
> > --- a/security/keys/trusted-keys/Makefile
> > +++ b/security/keys/trusted-keys/Makefile
> > @@ -4,5 +4,6 @@
> >  #
> >
> >  obj-$(CONFIG_TRUSTED_KEYS) += trusted.o
> > +trusted-y += trusted_core.o
> >  trusted-y += trusted_tpm1.o
> >  trusted-y += trusted_tpm2.o
> > diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
> > new file mode 100644
> > index 0000000..aa4f2a0
> > --- /dev/null
> > +++ b/security/keys/trusted-keys/trusted_core.c
> > @@ -0,0 +1,350 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2010 IBM Corporation
> > + * Copyright (c) 2019-2020, Linaro Limited
> > + *
> > + * See Documentation/security/keys/trusted-encrypted.rst
> > + */
> > +
> > +#include <keys/user-type.h>
> > +#include <keys/trusted-type.h>
> > +#include <keys/trusted_tpm.h>
> > +#include <linux/capability.h>
> > +#include <linux/err.h>
> > +#include <linux/init.h>
> > +#include <linux/key-type.h>
> > +#include <linux/module.h>
> > +#include <linux/parser.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_key_source;
> > +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 defined(CONFIG_TCG_TPM)
> > +     { "tpm", &tpm_trusted_key_ops },
> > +#endif
> > +};
> > +
> > +DEFINE_STATIC_CALL_NULL(trusted_key_init, *trusted_key_sources[0].ops->init);
> > +DEFINE_STATIC_CALL_NULL(trusted_key_seal, *trusted_key_sources[0].ops->seal);
> > +DEFINE_STATIC_CALL_NULL(trusted_key_unseal,
> > +                     *trusted_key_sources[0].ops->unseal);
> > +DEFINE_STATIC_CALL_NULL(trusted_key_get_random,
> > +                     *trusted_key_sources[0].ops->get_random);
> > +DEFINE_STATIC_CALL_NULL(trusted_key_exit, *trusted_key_sources[0].ops->exit);
> > +static unsigned char migratable;
> > +
> > +enum {
> > +     Opt_err,
> > +     Opt_new, Opt_load, Opt_update,
> > +};
> > +
> > +static const match_table_t key_tokens = {
> > +     {Opt_new, "new"},
> > +     {Opt_load, "load"},
> > +     {Opt_update, "update"},
> > +     {Opt_err, NULL}
> > +};
> > +
> > +/*
> > + * datablob_parse - parse the keyctl data and fill in the
> > + *                  payload structure
> > + *
> > + * On success returns 0, otherwise -EINVAL.
> > + */
> > +static int datablob_parse(char *datablob, struct trusted_key_payload *p)
> > +{
> > +     substring_t args[MAX_OPT_ARGS];
> > +     long keylen;
> > +     int ret = -EINVAL;
> > +     int key_cmd;
> > +     char *c;
> > +
> > +     /* main command */
> > +     c = strsep(&datablob, " \t");
> > +     if (!c)
> > +             return -EINVAL;
> > +     key_cmd = match_token(c, key_tokens, args);
> > +     switch (key_cmd) {
> > +     case Opt_new:
> > +             /* first argument is key size */
> > +             c = strsep(&datablob, " \t");
> > +             if (!c)
> > +                     return -EINVAL;
> > +             ret = kstrtol(c, 10, &keylen);
> > +             if (ret < 0 || keylen < MIN_KEY_SIZE || keylen > MAX_KEY_SIZE)
> > +                     return -EINVAL;
> > +             p->key_len = keylen;
> > +             ret = Opt_new;
> > +             break;
> > +     case Opt_load:
> > +             /* first argument is sealed blob */
> > +             c = strsep(&datablob, " \t");
> > +             if (!c)
> > +                     return -EINVAL;
> > +             p->blob_len = strlen(c) / 2;
> > +             if (p->blob_len > MAX_BLOB_SIZE)
> > +                     return -EINVAL;
> > +             ret = hex2bin(p->blob, c, p->blob_len);
> > +             if (ret < 0)
> > +                     return -EINVAL;
> > +             ret = Opt_load;
> > +             break;
> > +     case Opt_update:
> > +             ret = Opt_update;
> > +             break;
> > +     case Opt_err:
> > +             return -EINVAL;
> > +     }
> > +     return ret;
> > +}
> > +
> > +static struct trusted_key_payload *trusted_payload_alloc(struct key *key)
> > +{
> > +     struct trusted_key_payload *p = NULL;
> > +     int ret;
> > +
> > +     ret = key_payload_reserve(key, sizeof(*p));
> > +     if (ret < 0)
> > +             return p;
> > +     p = kzalloc(sizeof(*p), GFP_KERNEL);
> > +
> > +     p->migratable = migratable;
> > +
> > +     return p;
> > +}
> > +
> > +/*
> > + * trusted_instantiate - create a new trusted key
> > + *
> > + * Unseal an existing trusted blob or, for a new key, get a
> > + * random key, then seal and create a trusted key-type key,
> > + * adding it to the specified keyring.
> > + *
> > + * On success, return 0. Otherwise return errno.
> > + */
> > +static int trusted_instantiate(struct key *key,
> > +                            struct key_preparsed_payload *prep)
> > +{
> > +     struct trusted_key_payload *payload = NULL;
> > +     size_t datalen = prep->datalen;
> > +     char *datablob;
> > +     int ret = 0;
> > +     int key_cmd;
> > +     size_t key_len;
> > +
> > +     if (datalen <= 0 || datalen > 32767 || !prep->data)
> > +             return -EINVAL;
> > +
> > +     datablob = kmalloc(datalen + 1, GFP_KERNEL);
> > +     if (!datablob)
> > +             return -ENOMEM;
> > +     memcpy(datablob, prep->data, datalen);
> > +     datablob[datalen] = '\0';
> > +
> > +     payload = trusted_payload_alloc(key);
> > +     if (!payload) {
> > +             ret = -ENOMEM;
> > +             goto out;
> > +     }
> > +
> > +     key_cmd = datablob_parse(datablob, payload);
> > +     if (key_cmd < 0) {
> > +             ret = key_cmd;
> > +             goto out;
> > +     }
> > +
> > +     dump_payload(payload);
> > +
> > +     switch (key_cmd) {
> > +     case Opt_load:
> > +             ret = static_call(trusted_key_unseal)(payload, datablob);
> > +             dump_payload(payload);
> > +             if (ret < 0)
> > +                     pr_info("trusted_key: key_unseal failed (%d)\n", ret);
> > +             break;
> > +     case Opt_new:
> > +             key_len = payload->key_len;
> > +             ret = static_call(trusted_key_get_random)(payload->key,
> > +                                                       key_len);
> > +             if (ret != key_len) {
> > +                     pr_info("trusted_key: key_create failed (%d)\n", ret);
> > +                     goto out;
> > +             }
> > +
> > +             ret = static_call(trusted_key_seal)(payload, datablob);
> > +             if (ret < 0)
> > +                     pr_info("trusted_key: key_seal failed (%d)\n", ret);
> > +             break;
> > +     default:
> > +             ret = -EINVAL;
> > +     }
> > +out:
> > +     kfree_sensitive(datablob);
> > +     if (!ret)
> > +             rcu_assign_keypointer(key, payload);
> > +     else
> > +             kfree_sensitive(payload);
> > +     return ret;
> > +}
> > +
> > +static void trusted_rcu_free(struct rcu_head *rcu)
> > +{
> > +     struct trusted_key_payload *p;
> > +
> > +     p = container_of(rcu, struct trusted_key_payload, rcu);
> > +     kfree_sensitive(p);
> > +}
> > +
> > +/*
> > + * trusted_update - reseal an existing key with new PCR values
> > + */
> > +static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
> > +{
> > +     struct trusted_key_payload *p;
> > +     struct trusted_key_payload *new_p;
> > +     size_t datalen = prep->datalen;
> > +     char *datablob;
> > +     int ret = 0;
> > +
> > +     if (key_is_negative(key))
> > +             return -ENOKEY;
> > +     p = key->payload.data[0];
> > +     if (!p->migratable)
> > +             return -EPERM;
> > +     if (datalen <= 0 || datalen > 32767 || !prep->data)
> > +             return -EINVAL;
> > +
> > +     datablob = kmalloc(datalen + 1, GFP_KERNEL);
> > +     if (!datablob)
> > +             return -ENOMEM;
> > +
> > +     new_p = trusted_payload_alloc(key);
> > +     if (!new_p) {
> > +             ret = -ENOMEM;
> > +             goto out;
> > +     }
> > +
> > +     memcpy(datablob, prep->data, datalen);
> > +     datablob[datalen] = '\0';
> > +     ret = datablob_parse(datablob, new_p);
> > +     if (ret != Opt_update) {
> > +             ret = -EINVAL;
> > +             kfree_sensitive(new_p);
> > +             goto out;
> > +     }
> > +
> > +     /* copy old key values, and reseal with new pcrs */
> > +     new_p->migratable = p->migratable;
> > +     new_p->key_len = p->key_len;
> > +     memcpy(new_p->key, p->key, p->key_len);
> > +     dump_payload(p);
> > +     dump_payload(new_p);
> > +
> > +     ret = static_call(trusted_key_seal)(new_p, datablob);
> > +     if (ret < 0) {
> > +             pr_info("trusted_key: key_seal failed (%d)\n", ret);
> > +             kfree_sensitive(new_p);
> > +             goto out;
> > +     }
> > +
> > +     rcu_assign_keypointer(key, new_p);
> > +     call_rcu(&p->rcu, trusted_rcu_free);
> > +out:
> > +     kfree_sensitive(datablob);
> > +     return ret;
> > +}
> > +
> > +/*
> > + * trusted_read - copy the sealed blob data to userspace in hex.
> > + * On success, return to userspace the trusted key datablob size.
> > + */
> > +static long trusted_read(const struct key *key, char *buffer,
> > +                      size_t buflen)
> > +{
> > +     const struct trusted_key_payload *p;
> > +     char *bufp;
> > +     int i;
> > +
> > +     p = dereference_key_locked(key);
> > +     if (!p)
> > +             return -EINVAL;
> > +
> > +     if (buffer && buflen >= 2 * p->blob_len) {
> > +             bufp = buffer;
> > +             for (i = 0; i < p->blob_len; i++)
> > +                     bufp = hex_byte_pack(bufp, p->blob[i]);
> > +     }
> > +     return 2 * p->blob_len;
> > +}
> > +
> > +/*
> > + * trusted_destroy - clear and free the key's payload
> > + */
> > +static void trusted_destroy(struct key *key)
> > +{
> > +     kfree_sensitive(key->payload.data[0]);
> > +}
> > +
> > +struct key_type key_type_trusted = {
> > +     .name = "trusted",
> > +     .instantiate = trusted_instantiate,
> > +     .update = trusted_update,
> > +     .destroy = trusted_destroy,
> > +     .describe = user_describe,
> > +     .read = trusted_read,
> > +};
> > +EXPORT_SYMBOL_GPL(key_type_trusted);
> > +
> > +static int __init init_trusted(void)
> > +{
> > +     int i, ret = 0;
> > +
> > +     for (i = 0; i < ARRAY_SIZE(trusted_key_sources); i++) {
> > +             if (trusted_key_source &&
> > +                 strncmp(trusted_key_source, trusted_key_sources[i].name,
> > +                         strlen(trusted_key_sources[i].name)))
> > +                     continue;
> > +
> > +             static_call_update(trusted_key_init,
> > +                                trusted_key_sources[i].ops->init);
> > +             static_call_update(trusted_key_seal,
> > +                                trusted_key_sources[i].ops->seal);
> > +             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);
> > +             static_call_update(trusted_key_exit,
> > +                                trusted_key_sources[i].ops->exit);
> > +             migratable = trusted_key_sources[i].ops->migratable;
> > +
> > +             ret = static_call(trusted_key_init)();
> > +             if (!ret)
> > +                     break;
> > +     }
> > +
> > +     /*
> > +      * encrypted_keys.ko depends on successful load of this module even if
> > +      * trusted key implementation is not found.
> > +      */
> > +     if (ret == -ENODEV)
> > +             return 0;
> > +
> > +     return ret;
> > +}
> > +
> > +static void __exit cleanup_trusted(void)
> > +{
> > +     static_call(trusted_key_exit)();
> > +}
> > +
> > +late_initcall(init_trusted);
> > +module_exit(cleanup_trusted);
> > +
> > +MODULE_LICENSE("GPL");
> > diff --git a/security/keys/trusted-keys/trusted_tpm1.c b/security/keys/trusted-keys/trusted_tpm1.c
> > index b9fe02e..bd03914 100644
> > --- a/security/keys/trusted-keys/trusted_tpm1.c
> > +++ b/security/keys/trusted-keys/trusted_tpm1.c
> > @@ -1,29 +1,22 @@
> >  // SPDX-License-Identifier: GPL-2.0-only
> >  /*
> >   * Copyright (C) 2010 IBM Corporation
> > - *
> > - * Author:
> > - * David Safford <safford@us.ibm.com>
> > + * Copyright (c) 2019-2020, Linaro Limited
> >   *
> >   * See Documentation/security/keys/trusted-encrypted.rst
> >   */
> >
> >  #include <crypto/hash_info.h>
> > -#include <linux/uaccess.h>
> > -#include <linux/module.h>
> >  #include <linux/init.h>
> >  #include <linux/slab.h>
> >  #include <linux/parser.h>
> >  #include <linux/string.h>
> >  #include <linux/err.h>
> > -#include <keys/user-type.h>
> >  #include <keys/trusted-type.h>
> >  #include <linux/key-type.h>
> > -#include <linux/rcupdate.h>
> >  #include <linux/crypto.h>
> >  #include <crypto/hash.h>
> >  #include <crypto/sha.h>
> > -#include <linux/capability.h>
> >  #include <linux/tpm.h>
> >  #include <linux/tpm_command.h>
> >
> > @@ -703,7 +696,6 @@ static int key_unseal(struct trusted_key_payload *p,
> >
> >  enum {
> >       Opt_err,
> > -     Opt_new, Opt_load, Opt_update,
> >       Opt_keyhandle, Opt_keyauth, Opt_blobauth,
> >       Opt_pcrinfo, Opt_pcrlock, Opt_migratable,
> >       Opt_hash,
> > @@ -712,9 +704,6 @@ enum {
> >  };
> >
> >  static const match_table_t key_tokens = {
> > -     {Opt_new, "new"},
> > -     {Opt_load, "load"},
> > -     {Opt_update, "update"},
> >       {Opt_keyhandle, "keyhandle=%s"},
> >       {Opt_keyauth, "keyauth=%s"},
> >       {Opt_blobauth, "blobauth=%s"},
> > @@ -841,71 +830,6 @@ static int getoptions(char *c, struct trusted_key_payload *pay,
> >       return 0;
> >  }
> >
> > -/*
> > - * datablob_parse - parse the keyctl data and fill in the
> > - *               payload and options structures
> > - *
> > - * On success returns 0, otherwise -EINVAL.
> > - */
> > -static int datablob_parse(char *datablob, struct trusted_key_payload *p,
> > -                       struct trusted_key_options *o)
> > -{
> > -     substring_t args[MAX_OPT_ARGS];
> > -     long keylen;
> > -     int ret = -EINVAL;
> > -     int key_cmd;
> > -     char *c;
> > -
> > -     /* main command */
> > -     c = strsep(&datablob, " \t");
> > -     if (!c)
> > -             return -EINVAL;
> > -     key_cmd = match_token(c, key_tokens, args);
> > -     switch (key_cmd) {
> > -     case Opt_new:
> > -             /* first argument is key size */
> > -             c = strsep(&datablob, " \t");
> > -             if (!c)
> > -                     return -EINVAL;
> > -             ret = kstrtol(c, 10, &keylen);
> > -             if (ret < 0 || keylen < MIN_KEY_SIZE || keylen > MAX_KEY_SIZE)
> > -                     return -EINVAL;
> > -             p->key_len = keylen;
> > -             ret = getoptions(datablob, p, o);
> > -             if (ret < 0)
> > -                     return ret;
> > -             ret = Opt_new;
> > -             break;
> > -     case Opt_load:
> > -             /* first argument is sealed blob */
> > -             c = strsep(&datablob, " \t");
> > -             if (!c)
> > -                     return -EINVAL;
> > -             p->blob_len = strlen(c) / 2;
> > -             if (p->blob_len > MAX_BLOB_SIZE)
> > -                     return -EINVAL;
> > -             ret = hex2bin(p->blob, c, p->blob_len);
> > -             if (ret < 0)
> > -                     return -EINVAL;
> > -             ret = getoptions(datablob, p, o);
> > -             if (ret < 0)
> > -                     return ret;
> > -             ret = Opt_load;
> > -             break;
> > -     case Opt_update:
> > -             /* all arguments are options */
> > -             ret = getoptions(datablob, p, o);
> > -             if (ret < 0)
> > -                     return ret;
> > -             ret = Opt_update;
> > -             break;
> > -     case Opt_err:
> > -             return -EINVAL;
> > -             break;
> > -     }
> > -     return ret;
> > -}
> > -
> >  static struct trusted_key_options *trusted_options_alloc(void)
> >  {
> >       struct trusted_key_options *options;
> > @@ -926,248 +850,99 @@ static struct trusted_key_options *trusted_options_alloc(void)
> >       return options;
> >  }
> >
> > -static struct trusted_key_payload *trusted_payload_alloc(struct key *key)
> > +static int trusted_tpm_seal(struct trusted_key_payload *p, char *datablob)
> >  {
> > -     struct trusted_key_payload *p = NULL;
> > -     int ret;
> > -
> > -     ret = key_payload_reserve(key, sizeof *p);
> > -     if (ret < 0)
> > -             return p;
> > -     p = kzalloc(sizeof *p, GFP_KERNEL);
> > -     if (p)
> > -             p->migratable = 1; /* migratable by default */
> > -     return p;
> > -}
> > -
> > -/*
> > - * trusted_instantiate - create a new trusted key
> > - *
> > - * Unseal an existing trusted blob or, for a new key, get a
> > - * random key, then seal and create a trusted key-type key,
> > - * adding it to the specified keyring.
> > - *
> > - * On success, return 0. Otherwise return errno.
> > - */
> > -static int trusted_instantiate(struct key *key,
> > -                            struct key_preparsed_payload *prep)
> > -{
> > -     struct trusted_key_payload *payload = NULL;
> >       struct trusted_key_options *options = NULL;
> > -     size_t datalen = prep->datalen;
> > -     char *datablob;
> >       int ret = 0;
> > -     int key_cmd;
> > -     size_t key_len;
> >       int tpm2;
> >
> >       tpm2 = tpm_is_tpm2(chip);
> >       if (tpm2 < 0)
> >               return tpm2;
> >
> > -     if (datalen <= 0 || datalen > 32767 || !prep->data)
> > -             return -EINVAL;
> > -
> > -     datablob = kmalloc(datalen + 1, GFP_KERNEL);
> > -     if (!datablob)
> > -             return -ENOMEM;
> > -     memcpy(datablob, prep->data, datalen);
> > -     datablob[datalen] = '\0';
> > -
> >       options = trusted_options_alloc();
> > -     if (!options) {
> > -             ret = -ENOMEM;
> > -             goto out;
> > -     }
> > -     payload = trusted_payload_alloc(key);
> > -     if (!payload) {
> > -             ret = -ENOMEM;
> > -             goto out;
> > -     }
> > +     if (!options)
> > +             return -ENOMEM;
> >
> > -     key_cmd = datablob_parse(datablob, payload, options);
> > -     if (key_cmd < 0) {
> > -             ret = key_cmd;
> > +     ret = getoptions(datablob, p, options);
> > +     if (ret < 0)
> >               goto out;
> > -     }
> > +     dump_options(options);
> >
> >       if (!options->keyhandle) {
> >               ret = -EINVAL;
> >               goto out;
> >       }
> >
> > -     dump_payload(payload);
> > -     dump_options(options);
> > +     if (tpm2)
> > +             ret = tpm2_seal_trusted(chip, p, options);
> > +     else
> > +             ret = key_seal(p, options);
> > +     if (ret < 0) {
> > +             pr_info("tpm_trusted_key: key_seal failed (%d)\n", ret);
> > +             goto out;
> > +     }
> >
> > -     switch (key_cmd) {
> > -     case Opt_load:
> > -             if (tpm2)
> > -                     ret = tpm2_unseal_trusted(chip, payload, options);
> > -             else
> > -                     ret = key_unseal(payload, options);
> > -             dump_payload(payload);
> > -             dump_options(options);
> > -             if (ret < 0)
> > -                     pr_info("trusted_key: key_unseal failed (%d)\n", ret);
> > -             break;
> > -     case Opt_new:
> > -             key_len = payload->key_len;
> > -             ret = tpm_get_random(chip, payload->key, key_len);
> > -             if (ret != key_len) {
> > -                     pr_info("trusted_key: key_create failed (%d)\n", ret);
> > +     if (options->pcrlock) {
> > +             ret = pcrlock(options->pcrlock);
> > +             if (ret < 0) {
> > +                     pr_info("tpm_trusted_key: pcrlock failed (%d)\n", ret);
> >                       goto out;
> >               }
> > -             if (tpm2)
> > -                     ret = tpm2_seal_trusted(chip, payload, options);
> > -             else
> > -                     ret = key_seal(payload, options);
> > -             if (ret < 0)
> > -                     pr_info("trusted_key: key_seal failed (%d)\n", ret);
> > -             break;
> > -     default:
> > -             ret = -EINVAL;
> > -             goto out;
> >       }
> > -     if (!ret && options->pcrlock)
> > -             ret = pcrlock(options->pcrlock);
> >  out:
> > -     kfree_sensitive(datablob);
> >       kfree_sensitive(options);
> > -     if (!ret)
> > -             rcu_assign_keypointer(key, payload);
> > -     else
> > -             kfree_sensitive(payload);
> >       return ret;
> >  }
> >
> > -static void trusted_rcu_free(struct rcu_head *rcu)
> > -{
> > -     struct trusted_key_payload *p;
> > -
> > -     p = container_of(rcu, struct trusted_key_payload, rcu);
> > -     kfree_sensitive(p);
> > -}
> > -
> > -/*
> > - * trusted_update - reseal an existing key with new PCR values
> > - */
> > -static int trusted_update(struct key *key, struct key_preparsed_payload *prep)
> > +static int trusted_tpm_unseal(struct trusted_key_payload *p, char *datablob)
> >  {
> > -     struct trusted_key_payload *p;
> > -     struct trusted_key_payload *new_p;
> > -     struct trusted_key_options *new_o;
> > -     size_t datalen = prep->datalen;
> > -     char *datablob;
> > +     struct trusted_key_options *options = NULL;
> >       int ret = 0;
> > +     int tpm2;
> >
> > -     if (key_is_negative(key))
> > -             return -ENOKEY;
> > -     p = key->payload.data[0];
> > -     if (!p->migratable)
> > -             return -EPERM;
> > -     if (datalen <= 0 || datalen > 32767 || !prep->data)
> > -             return -EINVAL;
> > +     tpm2 = tpm_is_tpm2(chip);
> > +     if (tpm2 < 0)
> > +             return tpm2;
> >
> > -     datablob = kmalloc(datalen + 1, GFP_KERNEL);
> > -     if (!datablob)
> > +     options = trusted_options_alloc();
> > +     if (!options)
> >               return -ENOMEM;
> > -     new_o = trusted_options_alloc();
> > -     if (!new_o) {
> > -             ret = -ENOMEM;
> > -             goto out;
> > -     }
> > -     new_p = trusted_payload_alloc(key);
> > -     if (!new_p) {
> > -             ret = -ENOMEM;
> > -             goto out;
> > -     }
> >
> > -     memcpy(datablob, prep->data, datalen);
> > -     datablob[datalen] = '\0';
> > -     ret = datablob_parse(datablob, new_p, new_o);
> > -     if (ret != Opt_update) {
> > -             ret = -EINVAL;
> > -             kfree_sensitive(new_p);
> > +     ret = getoptions(datablob, p, options);
> > +     if (ret < 0)
> >               goto out;
> > -     }
> > +     dump_options(options);
> >
> > -     if (!new_o->keyhandle) {
> > +     if (!options->keyhandle) {
> >               ret = -EINVAL;
> > -             kfree_sensitive(new_p);
> >               goto out;
> >       }
> >
> > -     /* copy old key values, and reseal with new pcrs */
> > -     new_p->migratable = p->migratable;
> > -     new_p->key_len = p->key_len;
> > -     memcpy(new_p->key, p->key, p->key_len);
> > -     dump_payload(p);
> > -     dump_payload(new_p);
> > +     if (tpm2)
> > +             ret = tpm2_unseal_trusted(chip, p, options);
> > +     else
> > +             ret = key_unseal(p, options);
> > +     if (ret < 0)
> > +             pr_info("tpm_trusted_key: key_unseal failed (%d)\n", ret);
> >
> > -     ret = key_seal(new_p, new_o);
> > -     if (ret < 0) {
> > -             pr_info("trusted_key: key_seal failed (%d)\n", ret);
> > -             kfree_sensitive(new_p);
> > -             goto out;
> > -     }
> > -     if (new_o->pcrlock) {
> > -             ret = pcrlock(new_o->pcrlock);
> > +     if (options->pcrlock) {
> > +             ret = pcrlock(options->pcrlock);
> >               if (ret < 0) {
> > -                     pr_info("trusted_key: pcrlock failed (%d)\n", ret);
> > -                     kfree_sensitive(new_p);
> > +                     pr_info("tpm_trusted_key: pcrlock failed (%d)\n", ret);
> >                       goto out;
> >               }
> >       }
> > -     rcu_assign_keypointer(key, new_p);
> > -     call_rcu(&p->rcu, trusted_rcu_free);
> >  out:
> > -     kfree_sensitive(datablob);
> > -     kfree_sensitive(new_o);
> > +     kfree_sensitive(options);
> >       return ret;
> >  }
> >
> > -/*
> > - * trusted_read - copy the sealed blob data to userspace in hex.
> > - * On success, return to userspace the trusted key datablob size.
> > - */
> > -static long trusted_read(const struct key *key, char *buffer,
> > -                      size_t buflen)
> > -{
> > -     const struct trusted_key_payload *p;
> > -     char *bufp;
> > -     int i;
> > -
> > -     p = dereference_key_locked(key);
> > -     if (!p)
> > -             return -EINVAL;
> > -
> > -     if (buffer && buflen >= 2 * p->blob_len) {
> > -             bufp = buffer;
> > -             for (i = 0; i < p->blob_len; i++)
> > -                     bufp = hex_byte_pack(bufp, p->blob[i]);
> > -     }
> > -     return 2 * p->blob_len;
> > -}
> > -
> > -/*
> > - * trusted_destroy - clear and free the key's payload
> > - */
> > -static void trusted_destroy(struct key *key)
> > +static int trusted_tpm_get_random(unsigned char *key, size_t key_len)
> >  {
> > -     kfree_sensitive(key->payload.data[0]);
> > +     return tpm_get_random(chip, key, key_len);
> >  }
> >
> > -struct key_type key_type_trusted = {
> > -     .name = "trusted",
> > -     .instantiate = trusted_instantiate,
> > -     .update = trusted_update,
> > -     .destroy = trusted_destroy,
> > -     .describe = user_describe,
> > -     .read = trusted_read,
> > -};
> > -
> > -EXPORT_SYMBOL_GPL(key_type_trusted);
> > -
> >  static void trusted_shash_release(void)
> >  {
> >       if (hashalg)
> > @@ -1182,14 +957,14 @@ static int __init trusted_shash_alloc(void)
> >
> >       hmacalg = crypto_alloc_shash(hmac_alg, 0, 0);
> >       if (IS_ERR(hmacalg)) {
> > -             pr_info("trusted_key: could not allocate crypto %s\n",
> > +             pr_info("tpm_trusted_key: could not allocate crypto %s\n",
> >                       hmac_alg);
> >               return PTR_ERR(hmacalg);
> >       }
> >
> >       hashalg = crypto_alloc_shash(hash_alg, 0, 0);
> >       if (IS_ERR(hashalg)) {
> > -             pr_info("trusted_key: could not allocate crypto %s\n",
> > +             pr_info("tpm_trusted_key: could not allocate crypto %s\n",
>
> Let's just add interal trusted.h file with:
>
> #undef pr_fmt
> #define pr_fmt(fmt) "trusted_key: " fmt
>
> and remove tags from these. Does not add value to have separate tags
> for backends. Makes the klog only a bit messier I think.
>

Okay makes sense, will do this in the next version.

-Sumit

>
> >                       hash_alg);
> >               ret = PTR_ERR(hashalg);
> >               goto hashalg_fail;
> > @@ -1217,16 +992,13 @@ static int __init init_digests(void)
> >       return 0;
> >  }
> >
> > -static int __init init_trusted(void)
> > +static int trusted_tpm_init(void)
> >  {
> >       int ret;
> >
> > -     /* encrypted_keys.ko depends on successful load of this module even if
> > -      * TPM is not used.
> > -      */
> >       chip = tpm_default_chip();
> >       if (!chip)
> > -             return 0;
> > +             return -ENODEV;
> >
> >       ret = init_digests();
> >       if (ret < 0)
> > @@ -1247,7 +1019,7 @@ static int __init init_trusted(void)
> >       return ret;
> >  }
> >
> > -static void __exit cleanup_trusted(void)
> > +static void trusted_tpm_exit(void)
> >  {
> >       if (chip) {
> >               put_device(&chip->dev);
> > @@ -1257,7 +1029,11 @@ static void __exit cleanup_trusted(void)
> >       }
> >  }
> >
> > -late_initcall(init_trusted);
> > -module_exit(cleanup_trusted);
> > -
> > -MODULE_LICENSE("GPL");
> > +struct trusted_key_ops tpm_trusted_key_ops = {
> > +     .migratable = 1, /* migratable by default */
> > +     .init = trusted_tpm_init,
> > +     .seal = trusted_tpm_seal,
> > +     .unseal = trusted_tpm_unseal,
> > +     .get_random = trusted_tpm_get_random,
> > +     .exit = trusted_tpm_exit,
> > +};
> > --
> > 2.7.4
> >
> >
>
> /Jarkko

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

* Re: [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework
  2021-02-10 17:00   ` Jarkko Sakkinen
  2021-02-11 10:34     ` Ahmad Fatoum
@ 2021-02-15 13:15     ` Sumit Garg
  1 sibling, 0 replies; 52+ messages in thread
From: Sumit Garg @ 2021-02-15 13:15 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jarkko Sakkinen, Mimi Zohar, James Bottomley, David Howells,
	Jens Wiklander, Jonathan Corbet, James Morris, Serge E. Hallyn,
	Casey Schaufler, Janne Karhunen, Daniel Thompson, Markus Wamser,
	Luke Hinds, open list:ASYMMETRIC KEYS, linux-integrity,
	open list:SECURITY SUBSYSTEM, Linux Doc Mailing List,
	Linux Kernel Mailing List, linux-arm-kernel, op-tee

On Wed, 10 Feb 2021 at 22:30, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Tue, Nov 03, 2020 at 09:31:43PM +0530, Sumit Garg wrote:
> > +     case Opt_new:
> > +             key_len = payload->key_len;
> > +             ret = static_call(trusted_key_get_random)(payload->key,
> > +                                                       key_len);
> > +             if (ret != key_len) {
> > +                     pr_info("trusted_key: key_create failed (%d)\n", ret);
> > +                     goto out;
> > +             }
>
> This repeats a regression in existing code, i.e. does not check
> "ret < 0" condition. I noticed this now when I rebased the code
> on top of my fixes.
>
> I.e. it's fixed in my master branch, which caused a merge conflict,
> and I found this.
>

Okay, I will rebase the next version to your master branch.

-Sumit

> /Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-02-15 13:07                                 ` Sumit Garg
@ 2021-02-16  7:29                                   ` Jarkko Sakkinen
  2021-02-22  7:15                                     ` Sumit Garg
  0 siblings, 1 reply; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-02-16  7:29 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jerome Forissier, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn, dave.hansen

On Mon, Feb 15, 2021 at 06:37:00PM +0530, Sumit Garg wrote:
> On Fri, 12 Feb 2021 at 05:04, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Mon, Jan 25, 2021 at 02:47:38PM +0530, Sumit Garg wrote:
> > > Hi Jarkko,
> > >
> > > On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >
> > > > On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> > > > >
> > > > >
> > > > > On 1/21/21 4:24 PM, Jarkko Sakkinen wrote:
> > > > > > On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote:
> > > > > >> On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
> > > > > >>>
> > > > > >>>
> > > > > >>> On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> > > > > >>>> On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> > > > > >>>>> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > >>>>>>
> > > > > >>>>>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> > > > > >>>>>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > > > > >>>>>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > > > > >>>>>>>>>> Hi Jarkko,
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > > > >>>>>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
> > > > > >>>>>>>>>>>> to seal and unseal trusted keys using hardware unique key.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
> > > > > >>>>>>>>>>> just a blank screen:
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
> > > > > >>>>>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > > > >>>>>>>>>>> in the master branch.
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> To create identical images you just need to
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> $ make tpmdd_defconfig && make
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
> > > > > >>>>>>>>>>> patch set, and in bigger picture I really need to have ready to run
> > > > > >>>>>>>>>>> aarch64 environment available.
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> I would rather suggest you to follow steps listed here [1] as to test
> > > > > >>>>>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > > > > >>>>>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > > > > >>>>>>>>>> system [2]. And then it would be easier to migrate them to your
> > > > > >>>>>>>>>> buildroot environment as well.
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > > > > >>>>>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>> -Sumit
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> $ cat keyctl_change
> > > > > >>>>>>>> diff --git a/common.mk b/common.mk
> > > > > >>>>>>>> index aeb7b41..663e528 100644
> > > > > >>>>>>>> --- a/common.mk
> > > > > >>>>>>>> +++ b/common.mk
> > > > > >>>>>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> > > > > >>>>>>>>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> > > > > >>>>>>>>  BR2_PACKAGE_STRACE ?= y
> > > > > >>>>>>>>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > > > > >>>>>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > > > > >>>>>>>> +BR2_PACKAGE_KEYUTILS := y
> > > > > >>>>>>>>
> > > > > >>>>>>>>  # All BR2_* variables from the makefile or the environment are appended to
> > > > > >>>>>>>>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> > > > > >>>>>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> > > > > >>>>>>>> index 368c18a..832ab74 100644
> > > > > >>>>>>>> --- a/kconfigs/qemu.conf
> > > > > >>>>>>>> +++ b/kconfigs/qemu.conf
> > > > > >>>>>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> > > > > >>>>>>>>  CONFIG_9P_FS_POSIX_ACL=y
> > > > > >>>>>>>>  CONFIG_HW_RANDOM=y
> > > > > >>>>>>>>  CONFIG_HW_RANDOM_VIRTIO=y
> > > > > >>>>>>>> +CONFIG_TRUSTED_KEYS=y
> > > > > >>>>>>>> +CONFIG_ENCRYPTED_KEYS=y
> > > > > >>>>>>>>
> > > > > >>>>>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
> > > > > >>>>>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
> > > > > >>>>>>>>> remark in the commit message that TEE is a standard, with a link to the
> > > > > >>>>>>>>> specification.
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>> Sure, I will roll out the next version after your testing.
> > > > > >>>>>>>
> > > > > >>>>>>> Thanks, I'll try this at instant, and give my feedback.
> > > > > >>>>>>
> > > > > >>>>>> I bump into this:
> > > > > >>>>>>
> > > > > >>>>>> $ make run-only
> > > > > >>>>>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> > > > > >>>>>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> > > > > >>>>>> make: *** [Makefile:194: run-only] Error 1
> > > > > >>>>>>
> > > > > >>>>>
> > > > > >>>>> Could you check if the following directory tree is built after
> > > > > >>>>> executing the below command?
> > > > > >>>>>
> > > > > >>>>> $ make -j`nproc`
> > > > > >>>>> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
> > > > > >>>>>
> > > > > >>>>> $ tree out/bin/
> > > > > >>>>> out/bin/
> > > > > >>>>> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
> > > > > >>>>> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
> > > > > >>>>> ├── bl31.bin ->
> > > > > >>>>> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
> > > > > >>>>> ├── bl32.bin ->
> > > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
> > > > > >>>>> ├── bl32_extra1.bin ->
> > > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
> > > > > >>>>> ├── bl32_extra2.bin ->
> > > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
> > > > > >>>>> ├── bl33.bin ->
> > > > > >>>>> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
> > > > > >>>>> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
> > > > > >>>>> └── rootfs.cpio.gz ->
> > > > > >>>>> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
> > > > > >>>>>
> > > > > >>>>> 0 directories, 9 files
> > > > > >>>>>
> > > > > >>>>> -Sumit
> > > > > >>>>
> > > > > >>>> I actually spotted a build error that was unnoticed last time:
> > > > > >>>>
> > > > > >>>> make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> > > > > >>>> /bin/sh: 1: python: not found
> > > > > >>>>
> > > > > >>>> I'd prefer not to install Python2. It has been EOL over a year.
> > > > > >>>
> > > > > >>> AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
> > > > > >>> machine, this is accomplished by installing package "python-is-python3"
> > > > > >>> (after uninstalling "python-is-python2" if need be).
> > > > > >>>
> > > > > >>> $ ls -l /usr/bin/python
> > > > > >>> lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3
> > > > > >>
> > > > > >> Right, just found about this in unrelated context :-) [*]
> > > > > >>
> > > > > >> Hope this will work out...
> > > > > >>
> > > > > >> [*] https://github.com/surge-synthesizer/surge/pull/3655
> > > > > >
> > > > > > Now I get
> > > > > >
> > > > > > Traceback (most recent call last):
> > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 36, in <module>
> > > > > >     allTests = GetAllTestsSuite()
> > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 33, in GetAllTestsSuite
> > > > > >     return unittest.TestSuite([GetCTestSuite(), GetPythonTestSuite()])
> > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 25, in GetCTestSuite
> > > > > >     import CToolsTests
> > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/CToolsTests.py", line 22, in <module>
> > > > > >     import TianoCompress
> > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TianoCompress.py", line 69, in <module>
> > > > > >     TheTestSuite = TestTools.MakeTheTestSuite(locals())
> > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TestTools.py", line 43, in MakeTheTestSuite
> > > > > >     for name, item in localItems.iteritems():
> > > > > > AttributeError: 'dict' object has no attribute 'iteritems'
> > > > >
> > > > > Right. Same here after removing all traces of Python2 from my system :-/
> > > > >
> > > > > A couple of fixes are needed:
> > > > > 1. EDK2 needs to be upgraded to tag or later [1]
> > > > > 2. The PYTHON3_ENABLE environment variable needs to be set to TRUE [2]
> > > > >
> > > > > [1] https://github.com/OP-TEE/manifest/pull/177
> > > > > [2] https://github.com/OP-TEE/build/pull/450
> > > >
> > > > BTW, Is to *really* impossible to test this with plain BuildRoot.  It's
> > > > obvious that this forks BR internally.
> > > >
> > > > I mean even if I get this working once, this will feels like a clumsy way
> > > > to test Aarch64 regularly. I use BuildRoot extensively for x86 testing. And
> > > > it would be nice to be able to start doing regular ARM testing.
> > >
> > > The main reason to guide you towards the OP-TEE build system is that
> > > you will be able to build all the firmwares (TF-A, OP-TEE, edk2 etc.)
> > > from source. If you don't need to rebuild those then I have prepared a
> > > flash firmware binary blob for your testing (attached flash.bin). So
> > > Qemu cmdline will look like:
> > >
> > > $ qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu
> > > cortex-a57 -kernel out/bin/Image -no-acpi -append
> > > 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2' -initrd
> > > out/bin/rootfs.cpio.gz -smp 2 -m 1024 -bios flash.bin -d unimp
> >
> > I spentt couple of days to try to get this running.
> >
> > Here's the log:
> >
> > ❯ ./qemu.sh
> > NOTICE:  Booting Trusted Firmware
> > NOTICE:  BL1: v2.3():v2.3
> > NOTICE:  BL1: Built : 13:28:04, Jan 25 2021
> > NOTICE:  BL1: Booting BL2
> > NOTICE:  BL2: v2.3():v2.3
> > NOTICE:  BL2: Built : 13:28:06, Jan 25 2021
> > NOTICE:  BL1: Booting BL31
> > NOTICE:  BL31: v2.3():v2.3
> > NOTICE:  BL31: Built : 13:28:08, Jan 25 2021
> > UEFI firmware (version  built at 18:49:27 on Nov 18 2019)
> > pflash_write: Write to buffer emulation is flawed
> > pflash_write: Write to buffer emulation is flawed
> > EFI stub: Booting Linux Kernel...
> > EFI stub: Using DTB from configuration table
> > EFI stub: Exiting boot services and installing virtual address map...
> > Booting Linux on physical CPU 0x0000000000 [0x411fd070]
> > Linux version 5.11.0-rc5 (jarkko@suppilovahvero) (aarch64-buildroot-linux-uclibc-gcc.br_real (Buildroot 2021.02-rc1-10-ga72c90b972) 9.3.0, GNU ld (GNU Binutils) 2.35.2) #1 SMP Thu Feb 11 22:04:53 EET 2021
> > Machine model: linux,dummy-virt
> > efi: EFI v2.70 by EDK II
> > efi: SMBIOS=0x7f520000 SMBIOS 3.0=0x7f500000 MEMATTR=0x7e59b018 MEMRESERVE=0x7c143f18
> > Zone ranges:
> >   DMA      [mem 0x0000000040000000-0x000000007fffffff]
> >   DMA32    empty
> >   Normal   empty
> > Movable zone start for each node
> > Early memory node ranges
> >   node   0: [mem 0x0000000040000000-0x0000000041ffffff]
> >   node   0: [mem 0x0000000042200000-0x000000007be3ffff]
> >   node   0: [mem 0x000000007be40000-0x000000007c13ffff]
> >   node   0: [mem 0x000000007c140000-0x000000007f41ffff]
> >   node   0: [mem 0x000000007f420000-0x000000007f4affff]
> >   node   0: [mem 0x000000007f4b0000-0x000000007f4cffff]
> >   node   0: [mem 0x000000007f4d0000-0x000000007f5dffff]
> >   node   0: [mem 0x000000007f5e0000-0x000000007fffffff]
> > Zeroed struct page in unavailable ranges: 864 pages
> > Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff]
> > psci: probing for conduit method from DT.
> > psci: PSCIv1.1 detected in firmware.
> > psci: Using standard PSCI v0.2 function IDs
> > psci: Trusted OS migration not required
> > psci: SMC Calling Convention v1.2
> > percpu: Embedded 21 pages/cpu s48024 r8192 d29800 u86016
> > Detected PIPT I-cache on CPU0
> > CPU features: detected: ARM erratum 832075
> > CPU features: detected: Spectre-v2
> > CPU features: detected: ARM errata 1165522, 1319367, or 1530923
> > Built 1 zonelists, mobility grouping on.  Total pages: 257536
> > Kernel command line: root=/dev/vda rw console=ttyAMA0,115200
> > Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
> > Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
> > mem auto-init: stack:off, heap alloc:off, heap free:off
> > Memory: 1011284K/1046528K available (6592K kernel code, 804K rwdata, 1460K rodata, 1088K init, 321K bss, 35244K reserved, 0K cma-reserved)
> > SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> > rcu: Hierarchical RCU implementation.
> > rcu:    RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=1.
> > rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
> > rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
> > NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
> > GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
> > random: get_random_bytes called from start_kernel+0x340/0x53c with crng_init=0
> > arch_timer: cp15 timer(s) running at 62.50MHz (virt).
> > clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
> > sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
> > Console: colour dummy device 80x25
> > Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=250000)
> > pid_max: default: 32768 minimum: 301
> > Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
> > Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
> > rcu: Hierarchical SRCU implementation.
> > Remapping and enabling EFI services.
> > smp: Bringing up secondary CPUs ...
> > smp: Brought up 1 node, 1 CPU
> > SMP: Total of 1 processors activated.
> > CPU features: detected: 32-bit EL0 Support
> > CPU features: detected: CRC32 instructions
> > CPU: All CPU(s) started at EL1
> > alternatives: patching kernel code
> > devtmpfs: initialized
> > clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> > futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > SMBIOS 3.0.0 present.
> > DMI: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
> > NET: Registered protocol family 16
> > DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
> > DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
> > DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
> > hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
> > ASID allocator initialised with 65536 entries
> > Serial: AMBA PL011 UART driver
> > 9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 46, base_baud = 0) is a PL011 rev1
> > printk: console [ttyAMA0] enabled
> > iommu: Default domain type: Translated
> > vgaarb: loaded
> > SCSI subsystem initialized
> > Registered efivars operations
> > clocksource: Switched to clocksource arch_sys_counter
> > NET: Registered protocol family 2
> > tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)
> > TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
> > TCP bind hash table entries: 8192 (order: 5, 131072 bytes, linear)
> > TCP: Hash tables configured (established 8192 bind 8192)
> > UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
> > UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
> > NET: Registered protocol family 1
> > PCI: CLS 0 bytes, default 64
> > hw perfevents: enabled with armv8_pmuv3 PMU driver, 5 counters available
> > workingset: timestamp_bits=62 max_order=18 bucket_order=0
> > fuse: init (API version 7.33)
> > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
> > io scheduler mq-deadline registered
> > io scheduler kyber registered
> > pci-host-generic 4010000000.pcie: host bridge /pcie@10000000 ranges:
> > pci-host-generic 4010000000.pcie:       IO 0x003eff0000..0x003effffff -> 0x0000000000
> > pci-host-generic 4010000000.pcie:      MEM 0x0010000000..0x003efeffff -> 0x0010000000
> > pci-host-generic 4010000000.pcie:      MEM 0x8000000000..0xffffffffff -> 0x8000000000
> > pci-host-generic 4010000000.pcie: Memory resource size exceeds max for 32 bits
> > pci-host-generic 4010000000.pcie: ECAM at [mem 0x4010000000-0x401fffffff] for [bus 00-ff]
> > pci-host-generic 4010000000.pcie: PCI host bridge to bus 0000:00
> > pci_bus 0000:00: root bus resource [bus 00-ff]
> > pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff]
> > pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff]
> > pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
> > pci 0000:00:01.0: [1af4:1000] type 00 class 0x020000
> > pci 0000:00:01.0: reg 0x10: [io  0x0080-0x009f]
> > pci 0000:00:01.0: reg 0x14: [mem 0x10001000-0x10001fff]
> > pci 0000:00:01.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
> > pci 0000:00:01.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
> > pci 0000:00:02.0: [1af4:1001] type 00 class 0x010000
> > pci 0000:00:02.0: reg 0x10: [io  0x0000-0x007f]
> > pci 0000:00:02.0: reg 0x14: [mem 0x10000000-0x10000fff]
> > pci 0000:00:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
> > pci 0000:00:01.0: BAR 6: assigned [mem 0x10000000-0x1003ffff pref]
> > pci 0000:00:01.0: BAR 4: assigned [mem 0x8000000000-0x8000003fff 64bit pref]
> > pci 0000:00:02.0: BAR 4: assigned [mem 0x8000004000-0x8000007fff 64bit pref]
> > pci 0000:00:01.0: BAR 1: assigned [mem 0x10040000-0x10040fff]
> > pci 0000:00:02.0: BAR 1: assigned [mem 0x10041000-0x10041fff]
> > pci 0000:00:02.0: BAR 0: assigned [io  0x1000-0x107f]
> > pci 0000:00:01.0: BAR 0: assigned [io  0x1080-0x109f]
> > virtio-pci 0000:00:01.0: enabling device (0000 -> 0003)
> > virtio-pci 0000:00:02.0: enabling device (0000 -> 0003)
> > cacheinfo: Unable to detect cache hierarchy for CPU 0
> > virtio_blk virtio1: [vda] 122880 512-byte logical blocks (62.9 MB/60.0 MiB)
> > SMCCC: SOC_ID: ARCH_FEATURES(ARCH_SOC_ID) returned error: fffffffffffffffd
> > NET: Registered protocol family 10
> > Segment Routing with IPv6
> > sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> > NET: Registered protocol family 17
> > NET: Registered protocol family 15
> > NET: Registered protocol family 40
> > registered taskstats version 1
> > EXT4-fs (vda): recovery complete
> > EXT4-fs (vda): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
> > VFS: Mounted root (ext4 filesystem) on device 254:0.
> > devtmpfs: mounted
> > Freeing unused kernel memory: 1088K
> > Run /sbin/init as init process
> > mount: you must be root
> > mount: you must be root
> > mkdir: can't create directory '/dev/pts': Permission denied
> > mkdir: can't create directory '/dev/shm': Permission denied
> > mount: you must be root
> > hostname: sethostname: Operation not permitted
> > Starting syslogd: OK
> > Starting klogd: OK
> > Running sysctl: OK
> > Initializing random number generator: OK
> > Saving random seed: random: dd: uninitialized urandom read (512 bytes read)
> > OK
> > Starting network: ip: RTNETLINK answers: Operation not permitted
> > ip: SIOCSIFFLAGS: Operation not permitted
> > sed: /proc/mounts: No such file or directory
> > Waiting for interface eth0 to appear............... timeout!
> > run-parts: /etc/network/if-pre-up.d/wait_iface: exit status 1
> > FAIL
> > can't open /dev/ttyAMA0: Permission denied
> > can't open /dev/ttyAMA0: Permission denied
> > can't open /dev/ttyAMA0: Permission denied
> > can't open /dev/ttyAMA0: Permission denied
> >
> > And it continues...
> >
> > The qemu command I got did not work "as it is" and because I'm neither too
> > proficient with qemu nor aarch64, it took a while to get something usable.
> > This is my current qemu command:
> >
> > qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu cortex-a57 \
> >                     -kernel ~/Projects/tpm/buildroot/output/images/Image \
> >                     -no-acpi \
> >                     -append 'root=/dev/vda rw console=ttyAMA0,115200 ' \
> >                     -drive file=~/Projects/tpm/buildroot/output/images/rootfs.ext4,format=raw \
> >                     -smp 1 \
> >                     -monitor telnet:127.0.0.1:55555,server,nowait \
> >                     -m 1024 -bios ~/Projects/tpm/fw/aarch64-fw.bin -d unimp
> >
> > Then I start QEMU monitor from another terminal with:
> >
> > socat tcp-connect:127.0.0.1:55555 file:`tty`,raw,echo=0
> >
> > So... what could be the issue with permissions?
> >
> 
> It mostly sounds like an issue with your buildroot filesystem.
> 
> Can you try with this [1] init ramdisk instead?
> 
> -initrd rootfs.cpio.gz
> 
> [1] https://people.linaro.org/~sumit.garg/rootfs.cpio.gz
> 
> -Sumit

That does not include my LKM's.

/Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-02-16  7:29                                   ` Jarkko Sakkinen
@ 2021-02-22  7:15                                     ` Sumit Garg
  2021-02-24 16:58                                       ` Jarkko Sakkinen
  0 siblings, 1 reply; 52+ messages in thread
From: Sumit Garg @ 2021-02-22  7:15 UTC (permalink / raw)
  To: Jarkko Sakkinen
  Cc: Jerome Forissier, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn, dave.hansen

On Tue, 16 Feb 2021 at 12:59, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Mon, Feb 15, 2021 at 06:37:00PM +0530, Sumit Garg wrote:
> > On Fri, 12 Feb 2021 at 05:04, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >
> > > On Mon, Jan 25, 2021 at 02:47:38PM +0530, Sumit Garg wrote:
> > > > Hi Jarkko,
> > > >
> > > > On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > >
> > > > > On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> > > > > >
> > > > > >
> > > > > > On 1/21/21 4:24 PM, Jarkko Sakkinen wrote:
> > > > > > > On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote:
> > > > > > >> On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> > > > > > >>>> On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> > > > > > >>>>> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > > >>>>>>
> > > > > > >>>>>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> > > > > > >>>>>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > > > > > >>>>>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > > > > > >>>>>>>>>> Hi Jarkko,
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > > > > >>>>>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
> > > > > > >>>>>>>>>>>> to seal and unseal trusted keys using hardware unique key.
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
> > > > > > >>>>>>>>>>>>
> > > > > > >>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
> > > > > > >>>>>>>>>>> just a blank screen:
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
> > > > > > >>>>>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > > > > >>>>>>>>>>> in the master branch.
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> To create identical images you just need to
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> $ make tpmdd_defconfig && make
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
> > > > > > >>>>>>>>>>> patch set, and in bigger picture I really need to have ready to run
> > > > > > >>>>>>>>>>> aarch64 environment available.
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> I would rather suggest you to follow steps listed here [1] as to test
> > > > > > >>>>>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > > > > > >>>>>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > > > > > >>>>>>>>>> system [2]. And then it would be easier to migrate them to your
> > > > > > >>>>>>>>>> buildroot environment as well.
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > > > > > >>>>>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > > > >>>>>>>>>>
> > > > > > >>>>>>>>>> -Sumit
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> $ cat keyctl_change
> > > > > > >>>>>>>> diff --git a/common.mk b/common.mk
> > > > > > >>>>>>>> index aeb7b41..663e528 100644
> > > > > > >>>>>>>> --- a/common.mk
> > > > > > >>>>>>>> +++ b/common.mk
> > > > > > >>>>>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> > > > > > >>>>>>>>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> > > > > > >>>>>>>>  BR2_PACKAGE_STRACE ?= y
> > > > > > >>>>>>>>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > > > > > >>>>>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > > > > > >>>>>>>> +BR2_PACKAGE_KEYUTILS := y
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>  # All BR2_* variables from the makefile or the environment are appended to
> > > > > > >>>>>>>>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> > > > > > >>>>>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> > > > > > >>>>>>>> index 368c18a..832ab74 100644
> > > > > > >>>>>>>> --- a/kconfigs/qemu.conf
> > > > > > >>>>>>>> +++ b/kconfigs/qemu.conf
> > > > > > >>>>>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> > > > > > >>>>>>>>  CONFIG_9P_FS_POSIX_ACL=y
> > > > > > >>>>>>>>  CONFIG_HW_RANDOM=y
> > > > > > >>>>>>>>  CONFIG_HW_RANDOM_VIRTIO=y
> > > > > > >>>>>>>> +CONFIG_TRUSTED_KEYS=y
> > > > > > >>>>>>>> +CONFIG_ENCRYPTED_KEYS=y
> > > > > > >>>>>>>>
> > > > > > >>>>>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
> > > > > > >>>>>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
> > > > > > >>>>>>>>> remark in the commit message that TEE is a standard, with a link to the
> > > > > > >>>>>>>>> specification.
> > > > > > >>>>>>>>>
> > > > > > >>>>>>>>
> > > > > > >>>>>>>> Sure, I will roll out the next version after your testing.
> > > > > > >>>>>>>
> > > > > > >>>>>>> Thanks, I'll try this at instant, and give my feedback.
> > > > > > >>>>>>
> > > > > > >>>>>> I bump into this:
> > > > > > >>>>>>
> > > > > > >>>>>> $ make run-only
> > > > > > >>>>>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> > > > > > >>>>>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> > > > > > >>>>>> make: *** [Makefile:194: run-only] Error 1
> > > > > > >>>>>>
> > > > > > >>>>>
> > > > > > >>>>> Could you check if the following directory tree is built after
> > > > > > >>>>> executing the below command?
> > > > > > >>>>>
> > > > > > >>>>> $ make -j`nproc`
> > > > > > >>>>> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
> > > > > > >>>>>
> > > > > > >>>>> $ tree out/bin/
> > > > > > >>>>> out/bin/
> > > > > > >>>>> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
> > > > > > >>>>> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
> > > > > > >>>>> ├── bl31.bin ->
> > > > > > >>>>> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
> > > > > > >>>>> ├── bl32.bin ->
> > > > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
> > > > > > >>>>> ├── bl32_extra1.bin ->
> > > > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
> > > > > > >>>>> ├── bl32_extra2.bin ->
> > > > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
> > > > > > >>>>> ├── bl33.bin ->
> > > > > > >>>>> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
> > > > > > >>>>> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
> > > > > > >>>>> └── rootfs.cpio.gz ->
> > > > > > >>>>> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
> > > > > > >>>>>
> > > > > > >>>>> 0 directories, 9 files
> > > > > > >>>>>
> > > > > > >>>>> -Sumit
> > > > > > >>>>
> > > > > > >>>> I actually spotted a build error that was unnoticed last time:
> > > > > > >>>>
> > > > > > >>>> make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> > > > > > >>>> /bin/sh: 1: python: not found
> > > > > > >>>>
> > > > > > >>>> I'd prefer not to install Python2. It has been EOL over a year.
> > > > > > >>>
> > > > > > >>> AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
> > > > > > >>> machine, this is accomplished by installing package "python-is-python3"
> > > > > > >>> (after uninstalling "python-is-python2" if need be).
> > > > > > >>>
> > > > > > >>> $ ls -l /usr/bin/python
> > > > > > >>> lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3
> > > > > > >>
> > > > > > >> Right, just found about this in unrelated context :-) [*]
> > > > > > >>
> > > > > > >> Hope this will work out...
> > > > > > >>
> > > > > > >> [*] https://github.com/surge-synthesizer/surge/pull/3655
> > > > > > >
> > > > > > > Now I get
> > > > > > >
> > > > > > > Traceback (most recent call last):
> > > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 36, in <module>
> > > > > > >     allTests = GetAllTestsSuite()
> > > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 33, in GetAllTestsSuite
> > > > > > >     return unittest.TestSuite([GetCTestSuite(), GetPythonTestSuite()])
> > > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 25, in GetCTestSuite
> > > > > > >     import CToolsTests
> > > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/CToolsTests.py", line 22, in <module>
> > > > > > >     import TianoCompress
> > > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TianoCompress.py", line 69, in <module>
> > > > > > >     TheTestSuite = TestTools.MakeTheTestSuite(locals())
> > > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TestTools.py", line 43, in MakeTheTestSuite
> > > > > > >     for name, item in localItems.iteritems():
> > > > > > > AttributeError: 'dict' object has no attribute 'iteritems'
> > > > > >
> > > > > > Right. Same here after removing all traces of Python2 from my system :-/
> > > > > >
> > > > > > A couple of fixes are needed:
> > > > > > 1. EDK2 needs to be upgraded to tag or later [1]
> > > > > > 2. The PYTHON3_ENABLE environment variable needs to be set to TRUE [2]
> > > > > >
> > > > > > [1] https://github.com/OP-TEE/manifest/pull/177
> > > > > > [2] https://github.com/OP-TEE/build/pull/450
> > > > >
> > > > > BTW, Is to *really* impossible to test this with plain BuildRoot.  It's
> > > > > obvious that this forks BR internally.
> > > > >
> > > > > I mean even if I get this working once, this will feels like a clumsy way
> > > > > to test Aarch64 regularly. I use BuildRoot extensively for x86 testing. And
> > > > > it would be nice to be able to start doing regular ARM testing.
> > > >
> > > > The main reason to guide you towards the OP-TEE build system is that
> > > > you will be able to build all the firmwares (TF-A, OP-TEE, edk2 etc.)
> > > > from source. If you don't need to rebuild those then I have prepared a
> > > > flash firmware binary blob for your testing (attached flash.bin). So
> > > > Qemu cmdline will look like:
> > > >
> > > > $ qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu
> > > > cortex-a57 -kernel out/bin/Image -no-acpi -append
> > > > 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2' -initrd
> > > > out/bin/rootfs.cpio.gz -smp 2 -m 1024 -bios flash.bin -d unimp
> > >
> > > I spentt couple of days to try to get this running.
> > >
> > > Here's the log:
> > >
> > > ❯ ./qemu.sh
> > > NOTICE:  Booting Trusted Firmware
> > > NOTICE:  BL1: v2.3():v2.3
> > > NOTICE:  BL1: Built : 13:28:04, Jan 25 2021
> > > NOTICE:  BL1: Booting BL2
> > > NOTICE:  BL2: v2.3():v2.3
> > > NOTICE:  BL2: Built : 13:28:06, Jan 25 2021
> > > NOTICE:  BL1: Booting BL31
> > > NOTICE:  BL31: v2.3():v2.3
> > > NOTICE:  BL31: Built : 13:28:08, Jan 25 2021
> > > UEFI firmware (version  built at 18:49:27 on Nov 18 2019)
> > > pflash_write: Write to buffer emulation is flawed
> > > pflash_write: Write to buffer emulation is flawed
> > > EFI stub: Booting Linux Kernel...
> > > EFI stub: Using DTB from configuration table
> > > EFI stub: Exiting boot services and installing virtual address map...
> > > Booting Linux on physical CPU 0x0000000000 [0x411fd070]
> > > Linux version 5.11.0-rc5 (jarkko@suppilovahvero) (aarch64-buildroot-linux-uclibc-gcc.br_real (Buildroot 2021.02-rc1-10-ga72c90b972) 9.3.0, GNU ld (GNU Binutils) 2.35.2) #1 SMP Thu Feb 11 22:04:53 EET 2021
> > > Machine model: linux,dummy-virt
> > > efi: EFI v2.70 by EDK II
> > > efi: SMBIOS=0x7f520000 SMBIOS 3.0=0x7f500000 MEMATTR=0x7e59b018 MEMRESERVE=0x7c143f18
> > > Zone ranges:
> > >   DMA      [mem 0x0000000040000000-0x000000007fffffff]
> > >   DMA32    empty
> > >   Normal   empty
> > > Movable zone start for each node
> > > Early memory node ranges
> > >   node   0: [mem 0x0000000040000000-0x0000000041ffffff]
> > >   node   0: [mem 0x0000000042200000-0x000000007be3ffff]
> > >   node   0: [mem 0x000000007be40000-0x000000007c13ffff]
> > >   node   0: [mem 0x000000007c140000-0x000000007f41ffff]
> > >   node   0: [mem 0x000000007f420000-0x000000007f4affff]
> > >   node   0: [mem 0x000000007f4b0000-0x000000007f4cffff]
> > >   node   0: [mem 0x000000007f4d0000-0x000000007f5dffff]
> > >   node   0: [mem 0x000000007f5e0000-0x000000007fffffff]
> > > Zeroed struct page in unavailable ranges: 864 pages
> > > Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff]
> > > psci: probing for conduit method from DT.
> > > psci: PSCIv1.1 detected in firmware.
> > > psci: Using standard PSCI v0.2 function IDs
> > > psci: Trusted OS migration not required
> > > psci: SMC Calling Convention v1.2
> > > percpu: Embedded 21 pages/cpu s48024 r8192 d29800 u86016
> > > Detected PIPT I-cache on CPU0
> > > CPU features: detected: ARM erratum 832075
> > > CPU features: detected: Spectre-v2
> > > CPU features: detected: ARM errata 1165522, 1319367, or 1530923
> > > Built 1 zonelists, mobility grouping on.  Total pages: 257536
> > > Kernel command line: root=/dev/vda rw console=ttyAMA0,115200
> > > Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
> > > Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
> > > mem auto-init: stack:off, heap alloc:off, heap free:off
> > > Memory: 1011284K/1046528K available (6592K kernel code, 804K rwdata, 1460K rodata, 1088K init, 321K bss, 35244K reserved, 0K cma-reserved)
> > > SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> > > rcu: Hierarchical RCU implementation.
> > > rcu:    RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=1.
> > > rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
> > > rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
> > > NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
> > > GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
> > > random: get_random_bytes called from start_kernel+0x340/0x53c with crng_init=0
> > > arch_timer: cp15 timer(s) running at 62.50MHz (virt).
> > > clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
> > > sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
> > > Console: colour dummy device 80x25
> > > Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=250000)
> > > pid_max: default: 32768 minimum: 301
> > > Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
> > > Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
> > > rcu: Hierarchical SRCU implementation.
> > > Remapping and enabling EFI services.
> > > smp: Bringing up secondary CPUs ...
> > > smp: Brought up 1 node, 1 CPU
> > > SMP: Total of 1 processors activated.
> > > CPU features: detected: 32-bit EL0 Support
> > > CPU features: detected: CRC32 instructions
> > > CPU: All CPU(s) started at EL1
> > > alternatives: patching kernel code
> > > devtmpfs: initialized
> > > clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> > > futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > > SMBIOS 3.0.0 present.
> > > DMI: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
> > > NET: Registered protocol family 16
> > > DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
> > > DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
> > > DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
> > > hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
> > > ASID allocator initialised with 65536 entries
> > > Serial: AMBA PL011 UART driver
> > > 9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 46, base_baud = 0) is a PL011 rev1
> > > printk: console [ttyAMA0] enabled
> > > iommu: Default domain type: Translated
> > > vgaarb: loaded
> > > SCSI subsystem initialized
> > > Registered efivars operations
> > > clocksource: Switched to clocksource arch_sys_counter
> > > NET: Registered protocol family 2
> > > tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)
> > > TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
> > > TCP bind hash table entries: 8192 (order: 5, 131072 bytes, linear)
> > > TCP: Hash tables configured (established 8192 bind 8192)
> > > UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
> > > UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
> > > NET: Registered protocol family 1
> > > PCI: CLS 0 bytes, default 64
> > > hw perfevents: enabled with armv8_pmuv3 PMU driver, 5 counters available
> > > workingset: timestamp_bits=62 max_order=18 bucket_order=0
> > > fuse: init (API version 7.33)
> > > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
> > > io scheduler mq-deadline registered
> > > io scheduler kyber registered
> > > pci-host-generic 4010000000.pcie: host bridge /pcie@10000000 ranges:
> > > pci-host-generic 4010000000.pcie:       IO 0x003eff0000..0x003effffff -> 0x0000000000
> > > pci-host-generic 4010000000.pcie:      MEM 0x0010000000..0x003efeffff -> 0x0010000000
> > > pci-host-generic 4010000000.pcie:      MEM 0x8000000000..0xffffffffff -> 0x8000000000
> > > pci-host-generic 4010000000.pcie: Memory resource size exceeds max for 32 bits
> > > pci-host-generic 4010000000.pcie: ECAM at [mem 0x4010000000-0x401fffffff] for [bus 00-ff]
> > > pci-host-generic 4010000000.pcie: PCI host bridge to bus 0000:00
> > > pci_bus 0000:00: root bus resource [bus 00-ff]
> > > pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff]
> > > pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff]
> > > pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
> > > pci 0000:00:01.0: [1af4:1000] type 00 class 0x020000
> > > pci 0000:00:01.0: reg 0x10: [io  0x0080-0x009f]
> > > pci 0000:00:01.0: reg 0x14: [mem 0x10001000-0x10001fff]
> > > pci 0000:00:01.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
> > > pci 0000:00:01.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
> > > pci 0000:00:02.0: [1af4:1001] type 00 class 0x010000
> > > pci 0000:00:02.0: reg 0x10: [io  0x0000-0x007f]
> > > pci 0000:00:02.0: reg 0x14: [mem 0x10000000-0x10000fff]
> > > pci 0000:00:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
> > > pci 0000:00:01.0: BAR 6: assigned [mem 0x10000000-0x1003ffff pref]
> > > pci 0000:00:01.0: BAR 4: assigned [mem 0x8000000000-0x8000003fff 64bit pref]
> > > pci 0000:00:02.0: BAR 4: assigned [mem 0x8000004000-0x8000007fff 64bit pref]
> > > pci 0000:00:01.0: BAR 1: assigned [mem 0x10040000-0x10040fff]
> > > pci 0000:00:02.0: BAR 1: assigned [mem 0x10041000-0x10041fff]
> > > pci 0000:00:02.0: BAR 0: assigned [io  0x1000-0x107f]
> > > pci 0000:00:01.0: BAR 0: assigned [io  0x1080-0x109f]
> > > virtio-pci 0000:00:01.0: enabling device (0000 -> 0003)
> > > virtio-pci 0000:00:02.0: enabling device (0000 -> 0003)
> > > cacheinfo: Unable to detect cache hierarchy for CPU 0
> > > virtio_blk virtio1: [vda] 122880 512-byte logical blocks (62.9 MB/60.0 MiB)
> > > SMCCC: SOC_ID: ARCH_FEATURES(ARCH_SOC_ID) returned error: fffffffffffffffd
> > > NET: Registered protocol family 10
> > > Segment Routing with IPv6
> > > sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> > > NET: Registered protocol family 17
> > > NET: Registered protocol family 15
> > > NET: Registered protocol family 40
> > > registered taskstats version 1
> > > EXT4-fs (vda): recovery complete
> > > EXT4-fs (vda): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
> > > VFS: Mounted root (ext4 filesystem) on device 254:0.
> > > devtmpfs: mounted
> > > Freeing unused kernel memory: 1088K
> > > Run /sbin/init as init process
> > > mount: you must be root
> > > mount: you must be root
> > > mkdir: can't create directory '/dev/pts': Permission denied
> > > mkdir: can't create directory '/dev/shm': Permission denied
> > > mount: you must be root
> > > hostname: sethostname: Operation not permitted
> > > Starting syslogd: OK
> > > Starting klogd: OK
> > > Running sysctl: OK
> > > Initializing random number generator: OK
> > > Saving random seed: random: dd: uninitialized urandom read (512 bytes read)
> > > OK
> > > Starting network: ip: RTNETLINK answers: Operation not permitted
> > > ip: SIOCSIFFLAGS: Operation not permitted
> > > sed: /proc/mounts: No such file or directory
> > > Waiting for interface eth0 to appear............... timeout!
> > > run-parts: /etc/network/if-pre-up.d/wait_iface: exit status 1
> > > FAIL
> > > can't open /dev/ttyAMA0: Permission denied
> > > can't open /dev/ttyAMA0: Permission denied
> > > can't open /dev/ttyAMA0: Permission denied
> > > can't open /dev/ttyAMA0: Permission denied
> > >
> > > And it continues...
> > >
> > > The qemu command I got did not work "as it is" and because I'm neither too
> > > proficient with qemu nor aarch64, it took a while to get something usable.
> > > This is my current qemu command:
> > >
> > > qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu cortex-a57 \
> > >                     -kernel ~/Projects/tpm/buildroot/output/images/Image \
> > >                     -no-acpi \
> > >                     -append 'root=/dev/vda rw console=ttyAMA0,115200 ' \
> > >                     -drive file=~/Projects/tpm/buildroot/output/images/rootfs.ext4,format=raw \
> > >                     -smp 1 \
> > >                     -monitor telnet:127.0.0.1:55555,server,nowait \
> > >                     -m 1024 -bios ~/Projects/tpm/fw/aarch64-fw.bin -d unimp
> > >
> > > Then I start QEMU monitor from another terminal with:
> > >
> > > socat tcp-connect:127.0.0.1:55555 file:`tty`,raw,echo=0
> > >
> > > So... what could be the issue with permissions?
> > >
> >
> > It mostly sounds like an issue with your buildroot filesystem.
> >
> > Can you try with this [1] init ramdisk instead?
> >
> > -initrd rootfs.cpio.gz
> >
> > [1] https://people.linaro.org/~sumit.garg/rootfs.cpio.gz
> >
> > -Sumit
>
> That does not include my LKM's.
>

You can give a try with my kernel image [1] which has required built
in kernel modules. Also, you should be able to build a similar kernel
image.

[1] https://people.linaro.org/~sumit.garg/Image

-Sumit

> /Jarkko

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

* Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
  2021-02-22  7:15                                     ` Sumit Garg
@ 2021-02-24 16:58                                       ` Jarkko Sakkinen
  0 siblings, 0 replies; 52+ messages in thread
From: Jarkko Sakkinen @ 2021-02-24 16:58 UTC (permalink / raw)
  To: Sumit Garg
  Cc: Jerome Forissier, open list:SECURITY SUBSYSTEM, Daniel Thompson,
	op-tee, Jonathan Corbet, James Bottomley, Janne Karhunen,
	Linux Doc Mailing List, James Morris, Mimi Zohar,
	Linux Kernel Mailing List, David Howells, Luke Hinds,
	open list:ASYMMETRIC KEYS, Jarkko Sakkinen, Casey Schaufler,
	linux-integrity, linux-arm-kernel, Serge E. Hallyn, dave.hansen

On Mon, Feb 22, 2021 at 12:45:18PM +0530, Sumit Garg wrote:
> On Tue, 16 Feb 2021 at 12:59, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > On Mon, Feb 15, 2021 at 06:37:00PM +0530, Sumit Garg wrote:
> > > On Fri, 12 Feb 2021 at 05:04, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > >
> > > > On Mon, Jan 25, 2021 at 02:47:38PM +0530, Sumit Garg wrote:
> > > > > Hi Jarkko,
> > > > >
> > > > > On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > >
> > > > > > On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 1/21/21 4:24 PM, Jarkko Sakkinen wrote:
> > > > > > > > On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote:
> > > > > > > >> On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote:
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote:
> > > > > > > >>>> On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote:
> > > > > > > >>>>> On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > > > >>>>>>
> > > > > > > >>>>>> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen wrote:
> > > > > > > >>>>>>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote:
> > > > > > > >>>>>>>> On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>> On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg wrote:
> > > > > > > >>>>>>>>>> Hi Jarkko,
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>>> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg wrote:
> > > > > > > >>>>>>>>>>>> Add support for TEE based trusted keys where TEE provides the functionality
> > > > > > > >>>>>>>>>>>> to seal and unseal trusted keys using hardware unique key.
> > > > > > > >>>>>>>>>>>>
> > > > > > > >>>>>>>>>>>> Refer to Documentation/tee.txt for detailed information about TEE.
> > > > > > > >>>>>>>>>>>>
> > > > > > > >>>>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>> I haven't yet got QEMU environment working with aarch64, this produces
> > > > > > > >>>>>>>>>>> just a blank screen:
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu cortex-a53 -smp 1 -kernel output/images/Image -initrd output/images/rootfs.cpio -serial stdio
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>> My BuildRoot fork for TPM and keyring testing is located over here:
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>> The "ARM version" is at this point in aarch64 branch. Over time I will
> > > > > > > >>>>>>>>>>> define tpmdd-x86_64 and tpmdd-aarch64 boards and everything will be then
> > > > > > > >>>>>>>>>>> in the master branch.
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>> To create identical images you just need to
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>> $ make tpmdd_defconfig && make
> > > > > > > >>>>>>>>>>>
> > > > > > > >>>>>>>>>>> Can you check if you see anything obviously wrong? I'm eager to test this
> > > > > > > >>>>>>>>>>> patch set, and in bigger picture I really need to have ready to run
> > > > > > > >>>>>>>>>>> aarch64 environment available.
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>>> I would rather suggest you to follow steps listed here [1] as to test
> > > > > > > >>>>>>>>>> this feature on Qemu aarch64 we need to build firmwares such as TF-A,
> > > > > > > >>>>>>>>>> OP-TEE, UEFI etc. which are all integrated into OP-TEE Qemu build
> > > > > > > >>>>>>>>>> system [2]. And then it would be easier to migrate them to your
> > > > > > > >>>>>>>>>> buildroot environment as well.
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>>> [1] https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/000027.html
> > > > > > > >>>>>>>>>> [2] https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8
> > > > > > > >>>>>>>>>>
> > > > > > > >>>>>>>>>> -Sumit
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>> Can you provide 'keyctl_change'? Otherwise, the steps are easy to follow.
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> $ cat keyctl_change
> > > > > > > >>>>>>>> diff --git a/common.mk b/common.mk
> > > > > > > >>>>>>>> index aeb7b41..663e528 100644
> > > > > > > >>>>>>>> --- a/common.mk
> > > > > > > >>>>>>>> +++ b/common.mk
> > > > > > > >>>>>>>> @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= $(OPTEE_OS_TA_DEV_KIT_DIR)
> > > > > > > >>>>>>>>  BR2_PACKAGE_OPTEE_TEST_SITE ?= $(OPTEE_TEST_PATH)
> > > > > > > >>>>>>>>  BR2_PACKAGE_STRACE ?= y
> > > > > > > >>>>>>>>  BR2_TARGET_GENERIC_GETTY_PORT ?= $(if
> > > > > > > >>>>>>>> $(CFG_NW_CONSOLE_UART),ttyAMA$(CFG_NW_CONSOLE_UART),ttyAMA0)
> > > > > > > >>>>>>>> +BR2_PACKAGE_KEYUTILS := y
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>  # All BR2_* variables from the makefile or the environment are appended to
> > > > > > > >>>>>>>>  # ../out-br/extra.conf. All values are quoted "..." except y and n.
> > > > > > > >>>>>>>> diff --git a/kconfigs/qemu.conf b/kconfigs/qemu.conf
> > > > > > > >>>>>>>> index 368c18a..832ab74 100644
> > > > > > > >>>>>>>> --- a/kconfigs/qemu.conf
> > > > > > > >>>>>>>> +++ b/kconfigs/qemu.conf
> > > > > > > >>>>>>>> @@ -20,3 +20,5 @@ CONFIG_9P_FS=y
> > > > > > > >>>>>>>>  CONFIG_9P_FS_POSIX_ACL=y
> > > > > > > >>>>>>>>  CONFIG_HW_RANDOM=y
> > > > > > > >>>>>>>>  CONFIG_HW_RANDOM_VIRTIO=y
> > > > > > > >>>>>>>> +CONFIG_TRUSTED_KEYS=y
> > > > > > > >>>>>>>> +CONFIG_ENCRYPTED_KEYS=y
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>>> After I've successfully tested 2/4, I'd suggest that you roll out one more
> > > > > > > >>>>>>>>> version and CC the documentation patch to Elaine and Mini, and clearly
> > > > > > > >>>>>>>>> remark in the commit message that TEE is a standard, with a link to the
> > > > > > > >>>>>>>>> specification.
> > > > > > > >>>>>>>>>
> > > > > > > >>>>>>>>
> > > > > > > >>>>>>>> Sure, I will roll out the next version after your testing.
> > > > > > > >>>>>>>
> > > > > > > >>>>>>> Thanks, I'll try this at instant, and give my feedback.
> > > > > > > >>>>>>
> > > > > > > >>>>>> I bump into this:
> > > > > > > >>>>>>
> > > > > > > >>>>>> $ make run-only
> > > > > > > >>>>>> ln -sf /home/jarkko/devel/tpm/optee/build/../out-br/images/rootfs.cpio.gz /home/jarkko/devel/tpm/optee/build/../out/bin/
> > > > > > > >>>>>> ln: failed to create symbolic link '/home/jarkko/devel/tpm/optee/build/../out/bin/': No such file or directory
> > > > > > > >>>>>> make: *** [Makefile:194: run-only] Error 1
> > > > > > > >>>>>>
> > > > > > > >>>>>
> > > > > > > >>>>> Could you check if the following directory tree is built after
> > > > > > > >>>>> executing the below command?
> > > > > > > >>>>>
> > > > > > > >>>>> $ make -j`nproc`
> > > > > > > >>>>> CFG_IN_TREE_EARLY_TAS=trusted_keys/f04a0fe7-1f5d-4b9b-abf7-619b85b4ce8c
> > > > > > > >>>>>
> > > > > > > >>>>> $ tree out/bin/
> > > > > > > >>>>> out/bin/
> > > > > > > >>>>> ├── bl1.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl1.bin
> > > > > > > >>>>> ├── bl2.bin -> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl2.bin
> > > > > > > >>>>> ├── bl31.bin ->
> > > > > > > >>>>> /home/sumit/build/optee/build/../trusted-firmware-a/build/qemu/release/bl31.bin
> > > > > > > >>>>> ├── bl32.bin ->
> > > > > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-header_v2.bin
> > > > > > > >>>>> ├── bl32_extra1.bin ->
> > > > > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pager_v2.bin
> > > > > > > >>>>> ├── bl32_extra2.bin ->
> > > > > > > >>>>> /home/sumit/build/optee/build/../optee_os/out/arm/core/tee-pageable_v2.bin
> > > > > > > >>>>> ├── bl33.bin ->
> > > > > > > >>>>> /home/sumit/build/optee/build/../edk2/Build/ArmVirtQemuKernel-AARCH64/RELEASE_GCC49/FV/QEMU_EFI.fd
> > > > > > > >>>>> ├── Image -> /home/sumit/build/optee/build/../linux/arch/arm64/boot/Image
> > > > > > > >>>>> └── rootfs.cpio.gz ->
> > > > > > > >>>>> /home/sumit/build/optee/build/../out-br/images/rootfs.cpio.gz
> > > > > > > >>>>>
> > > > > > > >>>>> 0 directories, 9 files
> > > > > > > >>>>>
> > > > > > > >>>>> -Sumit
> > > > > > > >>>>
> > > > > > > >>>> I actually spotted a build error that was unnoticed last time:
> > > > > > > >>>>
> > > > > > > >>>> make[2]: Entering directory '/home/jarkko/devel/tpm/optee/edk2/BaseTools/Tests'
> > > > > > > >>>> /bin/sh: 1: python: not found
> > > > > > > >>>>
> > > > > > > >>>> I'd prefer not to install Python2. It has been EOL over a year.
> > > > > > > >>>
> > > > > > > >>> AFAIK, everything should build fine with Python3. On my Ubuntu 20.04
> > > > > > > >>> machine, this is accomplished by installing package "python-is-python3"
> > > > > > > >>> (after uninstalling "python-is-python2" if need be).
> > > > > > > >>>
> > > > > > > >>> $ ls -l /usr/bin/python
> > > > > > > >>> lrwxrwxrwx 1 root root 7 Apr 15  2020 /usr/bin/python -> python3
> > > > > > > >>
> > > > > > > >> Right, just found about this in unrelated context :-) [*]
> > > > > > > >>
> > > > > > > >> Hope this will work out...
> > > > > > > >>
> > > > > > > >> [*] https://github.com/surge-synthesizer/surge/pull/3655
> > > > > > > >
> > > > > > > > Now I get
> > > > > > > >
> > > > > > > > Traceback (most recent call last):
> > > > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 36, in <module>
> > > > > > > >     allTests = GetAllTestsSuite()
> > > > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 33, in GetAllTestsSuite
> > > > > > > >     return unittest.TestSuite([GetCTestSuite(), GetPythonTestSuite()])
> > > > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/RunTests.py", line 25, in GetCTestSuite
> > > > > > > >     import CToolsTests
> > > > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/CToolsTests.py", line 22, in <module>
> > > > > > > >     import TianoCompress
> > > > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TianoCompress.py", line 69, in <module>
> > > > > > > >     TheTestSuite = TestTools.MakeTheTestSuite(locals())
> > > > > > > >   File "/home/jarkko/Projects/tpm/optee/edk2/BaseTools/Tests/TestTools.py", line 43, in MakeTheTestSuite
> > > > > > > >     for name, item in localItems.iteritems():
> > > > > > > > AttributeError: 'dict' object has no attribute 'iteritems'
> > > > > > >
> > > > > > > Right. Same here after removing all traces of Python2 from my system :-/
> > > > > > >
> > > > > > > A couple of fixes are needed:
> > > > > > > 1. EDK2 needs to be upgraded to tag or later [1]
> > > > > > > 2. The PYTHON3_ENABLE environment variable needs to be set to TRUE [2]
> > > > > > >
> > > > > > > [1] https://github.com/OP-TEE/manifest/pull/177
> > > > > > > [2] https://github.com/OP-TEE/build/pull/450
> > > > > >
> > > > > > BTW, Is to *really* impossible to test this with plain BuildRoot.  It's
> > > > > > obvious that this forks BR internally.
> > > > > >
> > > > > > I mean even if I get this working once, this will feels like a clumsy way
> > > > > > to test Aarch64 regularly. I use BuildRoot extensively for x86 testing. And
> > > > > > it would be nice to be able to start doing regular ARM testing.
> > > > >
> > > > > The main reason to guide you towards the OP-TEE build system is that
> > > > > you will be able to build all the firmwares (TF-A, OP-TEE, edk2 etc.)
> > > > > from source. If you don't need to rebuild those then I have prepared a
> > > > > flash firmware binary blob for your testing (attached flash.bin). So
> > > > > Qemu cmdline will look like:
> > > > >
> > > > > $ qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu
> > > > > cortex-a57 -kernel out/bin/Image -no-acpi -append
> > > > > 'console=ttyAMA0,38400 keep_bootcon root=/dev/vda2' -initrd
> > > > > out/bin/rootfs.cpio.gz -smp 2 -m 1024 -bios flash.bin -d unimp
> > > >
> > > > I spentt couple of days to try to get this running.
> > > >
> > > > Here's the log:
> > > >
> > > > ❯ ./qemu.sh
> > > > NOTICE:  Booting Trusted Firmware
> > > > NOTICE:  BL1: v2.3():v2.3
> > > > NOTICE:  BL1: Built : 13:28:04, Jan 25 2021
> > > > NOTICE:  BL1: Booting BL2
> > > > NOTICE:  BL2: v2.3():v2.3
> > > > NOTICE:  BL2: Built : 13:28:06, Jan 25 2021
> > > > NOTICE:  BL1: Booting BL31
> > > > NOTICE:  BL31: v2.3():v2.3
> > > > NOTICE:  BL31: Built : 13:28:08, Jan 25 2021
> > > > UEFI firmware (version  built at 18:49:27 on Nov 18 2019)
> > > > pflash_write: Write to buffer emulation is flawed
> > > > pflash_write: Write to buffer emulation is flawed
> > > > EFI stub: Booting Linux Kernel...
> > > > EFI stub: Using DTB from configuration table
> > > > EFI stub: Exiting boot services and installing virtual address map...
> > > > Booting Linux on physical CPU 0x0000000000 [0x411fd070]
> > > > Linux version 5.11.0-rc5 (jarkko@suppilovahvero) (aarch64-buildroot-linux-uclibc-gcc.br_real (Buildroot 2021.02-rc1-10-ga72c90b972) 9.3.0, GNU ld (GNU Binutils) 2.35.2) #1 SMP Thu Feb 11 22:04:53 EET 2021
> > > > Machine model: linux,dummy-virt
> > > > efi: EFI v2.70 by EDK II
> > > > efi: SMBIOS=0x7f520000 SMBIOS 3.0=0x7f500000 MEMATTR=0x7e59b018 MEMRESERVE=0x7c143f18
> > > > Zone ranges:
> > > >   DMA      [mem 0x0000000040000000-0x000000007fffffff]
> > > >   DMA32    empty
> > > >   Normal   empty
> > > > Movable zone start for each node
> > > > Early memory node ranges
> > > >   node   0: [mem 0x0000000040000000-0x0000000041ffffff]
> > > >   node   0: [mem 0x0000000042200000-0x000000007be3ffff]
> > > >   node   0: [mem 0x000000007be40000-0x000000007c13ffff]
> > > >   node   0: [mem 0x000000007c140000-0x000000007f41ffff]
> > > >   node   0: [mem 0x000000007f420000-0x000000007f4affff]
> > > >   node   0: [mem 0x000000007f4b0000-0x000000007f4cffff]
> > > >   node   0: [mem 0x000000007f4d0000-0x000000007f5dffff]
> > > >   node   0: [mem 0x000000007f5e0000-0x000000007fffffff]
> > > > Zeroed struct page in unavailable ranges: 864 pages
> > > > Initmem setup node 0 [mem 0x0000000040000000-0x000000007fffffff]
> > > > psci: probing for conduit method from DT.
> > > > psci: PSCIv1.1 detected in firmware.
> > > > psci: Using standard PSCI v0.2 function IDs
> > > > psci: Trusted OS migration not required
> > > > psci: SMC Calling Convention v1.2
> > > > percpu: Embedded 21 pages/cpu s48024 r8192 d29800 u86016
> > > > Detected PIPT I-cache on CPU0
> > > > CPU features: detected: ARM erratum 832075
> > > > CPU features: detected: Spectre-v2
> > > > CPU features: detected: ARM errata 1165522, 1319367, or 1530923
> > > > Built 1 zonelists, mobility grouping on.  Total pages: 257536
> > > > Kernel command line: root=/dev/vda rw console=ttyAMA0,115200
> > > > Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes, linear)
> > > > Inode-cache hash table entries: 65536 (order: 7, 524288 bytes, linear)
> > > > mem auto-init: stack:off, heap alloc:off, heap free:off
> > > > Memory: 1011284K/1046528K available (6592K kernel code, 804K rwdata, 1460K rodata, 1088K init, 321K bss, 35244K reserved, 0K cma-reserved)
> > > > SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> > > > rcu: Hierarchical RCU implementation.
> > > > rcu:    RCU restricting CPUs from NR_CPUS=256 to nr_cpu_ids=1.
> > > > rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
> > > > rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
> > > > NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
> > > > GICv2m: range[mem 0x08020000-0x08020fff], SPI[80:143]
> > > > random: get_random_bytes called from start_kernel+0x340/0x53c with crng_init=0
> > > > arch_timer: cp15 timer(s) running at 62.50MHz (virt).
> > > > clocksource: arch_sys_counter: mask: 0xffffffffffffff max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns
> > > > sched_clock: 56 bits at 62MHz, resolution 16ns, wraps every 4398046511096ns
> > > > Console: colour dummy device 80x25
> > > > Calibrating delay loop (skipped), value calculated using timer frequency.. 125.00 BogoMIPS (lpj=250000)
> > > > pid_max: default: 32768 minimum: 301
> > > > Mount-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
> > > > Mountpoint-cache hash table entries: 2048 (order: 2, 16384 bytes, linear)
> > > > rcu: Hierarchical SRCU implementation.
> > > > Remapping and enabling EFI services.
> > > > smp: Bringing up secondary CPUs ...
> > > > smp: Brought up 1 node, 1 CPU
> > > > SMP: Total of 1 processors activated.
> > > > CPU features: detected: 32-bit EL0 Support
> > > > CPU features: detected: CRC32 instructions
> > > > CPU: All CPU(s) started at EL1
> > > > alternatives: patching kernel code
> > > > devtmpfs: initialized
> > > > clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
> > > > futex hash table entries: 256 (order: 2, 16384 bytes, linear)
> > > > SMBIOS 3.0.0 present.
> > > > DMI: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
> > > > NET: Registered protocol family 16
> > > > DMA: preallocated 128 KiB GFP_KERNEL pool for atomic allocations
> > > > DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA pool for atomic allocations
> > > > DMA: preallocated 128 KiB GFP_KERNEL|GFP_DMA32 pool for atomic allocations
> > > > hw-breakpoint: found 6 breakpoint and 4 watchpoint registers.
> > > > ASID allocator initialised with 65536 entries
> > > > Serial: AMBA PL011 UART driver
> > > > 9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 46, base_baud = 0) is a PL011 rev1
> > > > printk: console [ttyAMA0] enabled
> > > > iommu: Default domain type: Translated
> > > > vgaarb: loaded
> > > > SCSI subsystem initialized
> > > > Registered efivars operations
> > > > clocksource: Switched to clocksource arch_sys_counter
> > > > NET: Registered protocol family 2
> > > > tcp_listen_portaddr_hash hash table entries: 512 (order: 1, 8192 bytes, linear)
> > > > TCP established hash table entries: 8192 (order: 4, 65536 bytes, linear)
> > > > TCP bind hash table entries: 8192 (order: 5, 131072 bytes, linear)
> > > > TCP: Hash tables configured (established 8192 bind 8192)
> > > > UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
> > > > UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
> > > > NET: Registered protocol family 1
> > > > PCI: CLS 0 bytes, default 64
> > > > hw perfevents: enabled with armv8_pmuv3 PMU driver, 5 counters available
> > > > workingset: timestamp_bits=62 max_order=18 bucket_order=0
> > > > fuse: init (API version 7.33)
> > > > Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
> > > > io scheduler mq-deadline registered
> > > > io scheduler kyber registered
> > > > pci-host-generic 4010000000.pcie: host bridge /pcie@10000000 ranges:
> > > > pci-host-generic 4010000000.pcie:       IO 0x003eff0000..0x003effffff -> 0x0000000000
> > > > pci-host-generic 4010000000.pcie:      MEM 0x0010000000..0x003efeffff -> 0x0010000000
> > > > pci-host-generic 4010000000.pcie:      MEM 0x8000000000..0xffffffffff -> 0x8000000000
> > > > pci-host-generic 4010000000.pcie: Memory resource size exceeds max for 32 bits
> > > > pci-host-generic 4010000000.pcie: ECAM at [mem 0x4010000000-0x401fffffff] for [bus 00-ff]
> > > > pci-host-generic 4010000000.pcie: PCI host bridge to bus 0000:00
> > > > pci_bus 0000:00: root bus resource [bus 00-ff]
> > > > pci_bus 0000:00: root bus resource [io  0x0000-0xffff]
> > > > pci_bus 0000:00: root bus resource [mem 0x10000000-0x3efeffff]
> > > > pci_bus 0000:00: root bus resource [mem 0x8000000000-0xffffffffff]
> > > > pci 0000:00:00.0: [1b36:0008] type 00 class 0x060000
> > > > pci 0000:00:01.0: [1af4:1000] type 00 class 0x020000
> > > > pci 0000:00:01.0: reg 0x10: [io  0x0080-0x009f]
> > > > pci 0000:00:01.0: reg 0x14: [mem 0x10001000-0x10001fff]
> > > > pci 0000:00:01.0: reg 0x20: [mem 0x8000000000-0x8000003fff 64bit pref]
> > > > pci 0000:00:01.0: reg 0x30: [mem 0xfffc0000-0xffffffff pref]
> > > > pci 0000:00:02.0: [1af4:1001] type 00 class 0x010000
> > > > pci 0000:00:02.0: reg 0x10: [io  0x0000-0x007f]
> > > > pci 0000:00:02.0: reg 0x14: [mem 0x10000000-0x10000fff]
> > > > pci 0000:00:02.0: reg 0x20: [mem 0x8000004000-0x8000007fff 64bit pref]
> > > > pci 0000:00:01.0: BAR 6: assigned [mem 0x10000000-0x1003ffff pref]
> > > > pci 0000:00:01.0: BAR 4: assigned [mem 0x8000000000-0x8000003fff 64bit pref]
> > > > pci 0000:00:02.0: BAR 4: assigned [mem 0x8000004000-0x8000007fff 64bit pref]
> > > > pci 0000:00:01.0: BAR 1: assigned [mem 0x10040000-0x10040fff]
> > > > pci 0000:00:02.0: BAR 1: assigned [mem 0x10041000-0x10041fff]
> > > > pci 0000:00:02.0: BAR 0: assigned [io  0x1000-0x107f]
> > > > pci 0000:00:01.0: BAR 0: assigned [io  0x1080-0x109f]
> > > > virtio-pci 0000:00:01.0: enabling device (0000 -> 0003)
> > > > virtio-pci 0000:00:02.0: enabling device (0000 -> 0003)
> > > > cacheinfo: Unable to detect cache hierarchy for CPU 0
> > > > virtio_blk virtio1: [vda] 122880 512-byte logical blocks (62.9 MB/60.0 MiB)
> > > > SMCCC: SOC_ID: ARCH_FEATURES(ARCH_SOC_ID) returned error: fffffffffffffffd
> > > > NET: Registered protocol family 10
> > > > Segment Routing with IPv6
> > > > sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> > > > NET: Registered protocol family 17
> > > > NET: Registered protocol family 15
> > > > NET: Registered protocol family 40
> > > > registered taskstats version 1
> > > > EXT4-fs (vda): recovery complete
> > > > EXT4-fs (vda): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
> > > > VFS: Mounted root (ext4 filesystem) on device 254:0.
> > > > devtmpfs: mounted
> > > > Freeing unused kernel memory: 1088K
> > > > Run /sbin/init as init process
> > > > mount: you must be root
> > > > mount: you must be root
> > > > mkdir: can't create directory '/dev/pts': Permission denied
> > > > mkdir: can't create directory '/dev/shm': Permission denied
> > > > mount: you must be root
> > > > hostname: sethostname: Operation not permitted
> > > > Starting syslogd: OK
> > > > Starting klogd: OK
> > > > Running sysctl: OK
> > > > Initializing random number generator: OK
> > > > Saving random seed: random: dd: uninitialized urandom read (512 bytes read)
> > > > OK
> > > > Starting network: ip: RTNETLINK answers: Operation not permitted
> > > > ip: SIOCSIFFLAGS: Operation not permitted
> > > > sed: /proc/mounts: No such file or directory
> > > > Waiting for interface eth0 to appear............... timeout!
> > > > run-parts: /etc/network/if-pre-up.d/wait_iface: exit status 1
> > > > FAIL
> > > > can't open /dev/ttyAMA0: Permission denied
> > > > can't open /dev/ttyAMA0: Permission denied
> > > > can't open /dev/ttyAMA0: Permission denied
> > > > can't open /dev/ttyAMA0: Permission denied
> > > >
> > > > And it continues...
> > > >
> > > > The qemu command I got did not work "as it is" and because I'm neither too
> > > > proficient with qemu nor aarch64, it took a while to get something usable.
> > > > This is my current qemu command:
> > > >
> > > > qemu-system-aarch64 -nographic -s -machine virt,secure=on -cpu cortex-a57 \
> > > >                     -kernel ~/Projects/tpm/buildroot/output/images/Image \
> > > >                     -no-acpi \
> > > >                     -append 'root=/dev/vda rw console=ttyAMA0,115200 ' \
> > > >                     -drive file=~/Projects/tpm/buildroot/output/images/rootfs.ext4,format=raw \
> > > >                     -smp 1 \
> > > >                     -monitor telnet:127.0.0.1:55555,server,nowait \
> > > >                     -m 1024 -bios ~/Projects/tpm/fw/aarch64-fw.bin -d unimp
> > > >
> > > > Then I start QEMU monitor from another terminal with:
> > > >
> > > > socat tcp-connect:127.0.0.1:55555 file:`tty`,raw,echo=0
> > > >
> > > > So... what could be the issue with permissions?
> > > >
> > >
> > > It mostly sounds like an issue with your buildroot filesystem.
> > >
> > > Can you try with this [1] init ramdisk instead?
> > >
> > > -initrd rootfs.cpio.gz
> > >
> > > [1] https://people.linaro.org/~sumit.garg/rootfs.cpio.gz
> > >
> > > -Sumit
> >
> > That does not include my LKM's.
> >
> 
> You can give a try with my kernel image [1] which has required built
> in kernel modules. Also, you should be able to build a similar kernel
> image.
> 
> [1] https://people.linaro.org/~sumit.garg/Image

It comes down to that I need to be able to build my own kernel and user
space.

I need to be able to build my own kernel. There's been some bugs that I've
reported back to BuildRoot with the latest kernel tree and also with
binutils [*].

I'll retry once they are fixed, and try to find out what it causing the
problem.

[*] https://bugs.busybox.net/show_bug.cgi?id=13546

/Jarkko

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

end of thread, other threads:[~2021-02-24 17:02 UTC | newest]

Thread overview: 52+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-03 16:01 [PATCH v8 0/4] Introduce TEE based Trusted Keys support Sumit Garg
2020-11-03 16:01 ` [PATCH v8 1/4] KEYS: trusted: Add generic trusted keys framework Sumit Garg
2020-11-24  3:42   ` Jarkko Sakkinen
2021-02-15 13:13     ` Sumit Garg
2021-02-10 17:00   ` Jarkko Sakkinen
2021-02-11 10:34     ` Ahmad Fatoum
2021-02-12 12:22       ` Jarkko Sakkinen
2021-02-15 13:15     ` Sumit Garg
2020-11-03 16:01 ` [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys Sumit Garg
2020-11-24  3:46   ` Jarkko Sakkinen
2021-01-11 16:35   ` Jarkko Sakkinen
2021-01-13 11:17     ` Sumit Garg
2021-01-14  2:05       ` Jarkko Sakkinen
2021-01-15  6:02         ` Sumit Garg
2021-01-19 10:30           ` Jarkko Sakkinen
2021-01-20  1:31             ` Jarkko Sakkinen
2021-01-20  7:23               ` Sumit Garg
2021-01-21  0:01                 ` Jarkko Sakkinen
     [not found]                 ` <01000177223f74d3-1eef7685-4a19-40d2-ace6-d4cd7f35579d-000000@email.amazonses.com>
2021-01-21  8:44                   ` Jerome Forissier
2021-01-21 15:07                     ` Jarkko Sakkinen
2021-01-21 15:24                       ` Jarkko Sakkinen
2021-01-21 16:23                         ` Jerome Forissier
2021-01-22 18:12                           ` Jarkko Sakkinen
2021-01-25  9:17                             ` Sumit Garg
2021-01-27 17:14                               ` Jarkko Sakkinen
2021-01-27 17:19                               ` Jarkko Sakkinen
2021-02-04  0:05                               ` Jarkko Sakkinen
2021-02-11 23:34                               ` Jarkko Sakkinen
2021-02-11 23:35                                 ` Jarkko Sakkinen
2021-02-15 13:07                                 ` Sumit Garg
2021-02-16  7:29                                   ` Jarkko Sakkinen
2021-02-22  7:15                                     ` Sumit Garg
2021-02-24 16:58                                       ` Jarkko Sakkinen
2021-01-20 13:36   ` Ahmad Fatoum
2020-11-03 16:01 ` [PATCH v8 3/4] doc: trusted-encrypted: updates with TEE as a new trust source Sumit Garg
2020-12-02 19:34   ` gmail Elaine Palmer
2020-12-04 15:30     ` Jarkko Sakkinen
2020-12-08 15:02       ` Mimi Zohar
2020-12-08 17:49         ` Jarkko Sakkinen
2020-12-09 16:50           ` Mimi Zohar
2020-12-11 10:36             ` Jarkko Sakkinen
2020-12-11 15:29               ` Mimi Zohar
2020-12-06 18:51   ` Randy Dunlap
2020-12-08 15:55   ` Mimi Zohar
2020-12-08 17:07     ` Mimi Zohar
2020-11-03 16:01 ` [PATCH v8 4/4] MAINTAINERS: Add myself as Trusted Keys co-maintainer Sumit Garg
2020-11-24  3:46   ` Jarkko Sakkinen
2020-11-05  5:07 ` [PATCH v8 0/4] Introduce TEE based Trusted Keys support Jarkko Sakkinen
2020-11-06  9:32   ` Sumit Garg
2020-11-06 14:52     ` Jarkko Sakkinen
2020-12-04  5:16       ` Jarkko Sakkinen
2020-12-08 11:51         ` Sumit Garg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).