All of lore.kernel.org
 help / color / mirror / Atom feed
* [U-Boot] [PATCH v4 1/1] avb: add support for named persistent values
@ 2019-01-27 14:34 Igor Opaniuk
  2019-01-31 10:04 ` Simon Glass
  2019-02-09 12:50 ` [U-Boot] [U-Boot, v4, " Tom Rini
  0 siblings, 2 replies; 13+ messages in thread
From: Igor Opaniuk @ 2019-01-27 14:34 UTC (permalink / raw)
  To: u-boot

AVB version 1.1 introduces support for named persistent values
that must be tamper evident and allows AVB to store arbitrary key-value
pairs [1].

Introduce implementation of two additional AVB operations
read_persistent_value()/write_persistent_value() for retrieving/storing
named persistent values.

Correspondent pull request in the OP-TEE OS project repo [2].

[1]: https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22
[2]: https://github.com/OP-TEE/optee_os/pull/2699

Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org>
---

v4:
- extend tee sandbox tee driver to support persistent values
- fix/re-test avb_persistent test on sandbox configuration:
$ ./test/py/test.py --bd sandbox --build -s -i avb_per

U-Boot 2019.01-06051-gd01806a-dirty (Jan 27 2019 - 11:56:41 +0200)

Model: sandbox
DRAM:  128 MiB
MMC:   MMC probed
MMC probed
MMC probed
mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD)
In:    serial
Out:   vidconsole
Err:   vidconsole
Model: sandbox
SCSI:  
Net:   eth0: eth at 10002000, eth5: eth at 10003000, eth3: sbe5, eth1: eth at 10004000
Hit any key to stop autoboot:  0 
=> => avb init 1
=> => avb write_pvalue test value_value
Wrote 12 bytes
=> => avb read_pvalue test 12
Read 12 bytes, value = value_value
=> 
test/py/tests/test_avb.py .

===== 464 tests deselected by '-kavb_per' ======
=== 1 passed, 464 deselected in 0.16 seconds ===

v3:
- fix possible mem lick in avb_read_persistent/avb_write_persistent
- add additional sanity checks
- cover avb read_pvalue/write_pvalue commands with python tests

v2:
- fix output format for avb read_pvalue/write_pvalue commands
- fix issue with named value buffer size

 cmd/avb.c                  |  78 ++++++++++++++++++++++++++++
 common/avb_verify.c        | 125 +++++++++++++++++++++++++++++++++++++++++++++
 drivers/tee/sandbox.c      |  80 +++++++++++++++++++++++++++++
 include/tee.h              |   2 +
 include/tee/optee_ta_avb.h |  16 ++++++
 test/py/tests/test_avb.py  |  16 ++++++
 6 files changed, 317 insertions(+)

diff --git a/cmd/avb.c b/cmd/avb.c
index ff00be4..c5af4a2 100644
--- a/cmd/avb.c
+++ b/cmd/avb.c
@@ -340,6 +340,76 @@ int do_avb_is_unlocked(cmd_tbl_t *cmdtp, int flag,
 	return CMD_RET_FAILURE;
 }
 
+int do_avb_read_pvalue(cmd_tbl_t *cmdtp, int flag, int argc,
+		       char * const argv[])
+{
+	const char *name;
+	size_t bytes;
+	size_t bytes_read;
+	void *buffer;
+	char *endp;
+
+	if (!avb_ops) {
+		printf("AVB 2.0 is not initialized, run 'avb init' first\n");
+		return CMD_RET_FAILURE;
+	}
+
+	if (argc != 3)
+		return CMD_RET_USAGE;
+
+	name = argv[1];
+	bytes = simple_strtoul(argv[2], &endp, 10);
+	if (*endp && *endp != '\n')
+		return CMD_RET_USAGE;
+
+	buffer = malloc(bytes);
+	if (!buffer)
+		return CMD_RET_FAILURE;
+
+	if (avb_ops->read_persistent_value(avb_ops, name, bytes, buffer,
+					   &bytes_read) == AVB_IO_RESULT_OK) {
+		printf("Read %ld bytes, value = %s\n", bytes_read,
+		       (char *)buffer);
+		free(buffer);
+		return CMD_RET_SUCCESS;
+	}
+
+	printf("Failed to read persistent value\n");
+
+	free(buffer);
+
+	return CMD_RET_FAILURE;
+}
+
+int do_avb_write_pvalue(cmd_tbl_t *cmdtp, int flag, int argc,
+			char * const argv[])
+{
+	const char *name;
+	const char *value;
+
+	if (!avb_ops) {
+		printf("AVB 2.0 is not initialized, run 'avb init' first\n");
+		return CMD_RET_FAILURE;
+	}
+
+	if (argc != 3)
+		return CMD_RET_USAGE;
+
+	name = argv[1];
+	value = argv[2];
+
+	if (avb_ops->write_persistent_value(avb_ops, name, strlen(value) + 1,
+					    (const uint8_t *)value) ==
+	    AVB_IO_RESULT_OK) {
+		printf("Wrote %ld bytes\n", strlen(value) + 1);
+		return CMD_RET_SUCCESS;
+	}
+
+	printf("Failed to write persistent value\n");
+
+	return CMD_RET_FAILURE;
+}
+
 static cmd_tbl_t cmd_avb[] = {
 	U_BOOT_CMD_MKENT(init, 2, 0, do_avb_init, "", ""),
 	U_BOOT_CMD_MKENT(read_rb, 2, 0, do_avb_read_rb, "", ""),
@@ -350,6 +420,10 @@ static cmd_tbl_t cmd_avb[] = {
 	U_BOOT_CMD_MKENT(read_part_hex, 4, 0, do_avb_read_part_hex, "", ""),
 	U_BOOT_CMD_MKENT(write_part, 5, 0, do_avb_write_part, "", ""),
 	U_BOOT_CMD_MKENT(verify, 1, 0, do_avb_verify_part, "", ""),
+#ifdef CONFIG_OPTEE_TA_AVB
+	U_BOOT_CMD_MKENT(read_pvalue, 3, 0, do_avb_read_pvalue, "", ""),
+	U_BOOT_CMD_MKENT(write_pvalue, 3, 0, do_avb_write_pvalue, "", ""),
+#endif
 };
 
 static int do_avb(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
@@ -384,6 +458,10 @@ U_BOOT_CMD(
 	"    partition <partname> and print to stdout\n"
 	"avb write_part <partname> <offset> <num> <addr> - write <num> bytes to\n"
 	"    <partname> by <offset> using data from <addr>\n"
+#ifdef CONFIG_OPTEE_TA_AVB
+	"avb read_pvalue <name> <bytes> - read a persistent value <name>\n"
+	"avb write_pvalue <name> <value> - write a persistent value <name>\n"
+#endif
 	"avb verify - run verification process using hash data\n"
 	"    from vbmeta structure\n"
 	);
diff --git a/common/avb_verify.c b/common/avb_verify.c
index a8c5a3e..32034d9 100644
--- a/common/avb_verify.c
+++ b/common/avb_verify.c
@@ -647,6 +647,10 @@ static AvbIOResult invoke_func(struct AvbOpsData *ops_data, u32 func,
 		return AVB_IO_RESULT_OK;
 	case TEE_ERROR_OUT_OF_MEMORY:
 		return AVB_IO_RESULT_ERROR_OOM;
+	case TEE_ERROR_STORAGE_NO_SPACE:
+		return AVB_IO_RESULT_ERROR_INSUFFICIENT_SPACE;
+	case TEE_ERROR_ITEM_NOT_FOUND:
+		return AVB_IO_RESULT_ERROR_NO_SUCH_VALUE;
 	case TEE_ERROR_TARGET_DEAD:
 		/*
 		 * The TA has paniced, close the session to reload the TA
@@ -847,6 +851,123 @@ static AvbIOResult get_size_of_partition(AvbOps *ops,
 	return AVB_IO_RESULT_OK;
 }
 
+static AvbIOResult read_persistent_value(AvbOps *ops,
+					 const char *name,
+					 size_t buffer_size,
+					 u8 *out_buffer,
+					 size_t *out_num_bytes_read)
+{
+	AvbIOResult rc;
+	struct tee_shm *shm_name;
+	struct tee_shm *shm_buf;
+	struct tee_param param[2];
+	struct udevice *tee;
+	size_t name_size = strlen(name) + 1;
+
+	if (get_open_session(ops->user_data))
+		return AVB_IO_RESULT_ERROR_IO;
+
+	tee = ((struct AvbOpsData *)ops->user_data)->tee;
+
+	rc = tee_shm_alloc(tee, name_size,
+			   TEE_SHM_ALLOC, &shm_name);
+	if (rc)
+		return AVB_IO_RESULT_ERROR_OOM;
+
+	rc = tee_shm_alloc(tee, buffer_size,
+			   TEE_SHM_ALLOC, &shm_buf);
+	if (rc) {
+		rc = AVB_IO_RESULT_ERROR_OOM;
+		goto free_name;
+	}
+
+	memcpy(shm_name->addr, name, name_size);
+
+	memset(param, 0, sizeof(param));
+	param[0].attr = TEE_PARAM_ATTR_TYPE_MEMREF_INPUT;
+	param[0].u.memref.shm = shm_name;
+	param[0].u.memref.size = name_size;
+	param[1].attr = TEE_PARAM_ATTR_TYPE_MEMREF_INOUT;
+	param[1].u.memref.shm = shm_buf;
+	param[1].u.memref.size = buffer_size;
+
+	rc = invoke_func(ops->user_data, TA_AVB_CMD_READ_PERSIST_VALUE,
+			 2, param);
+	if (rc)
+		goto out;
+
+	if (param[1].u.memref.size > buffer_size) {
+		rc = AVB_IO_RESULT_ERROR_NO_SUCH_VALUE;
+		goto out;
+	}
+
+	*out_num_bytes_read = param[1].u.memref.size;
+
+	memcpy(out_buffer, shm_buf->addr, *out_num_bytes_read);
+
+out:
+	tee_shm_free(shm_buf);
+free_name:
+	tee_shm_free(shm_name);
+
+	return rc;
+}
+
+static AvbIOResult write_persistent_value(AvbOps *ops,
+					  const char *name,
+					  size_t value_size,
+					  const u8 *value)
+{
+	AvbIOResult rc;
+	struct tee_shm *shm_name;
+	struct tee_shm *shm_buf;
+	struct tee_param param[2];
+	struct udevice *tee;
+	size_t name_size = strlen(name) + 1;
+
+	if (get_open_session(ops->user_data))
+		return AVB_IO_RESULT_ERROR_IO;
+
+	tee = ((struct AvbOpsData *)ops->user_data)->tee;
+
+	if (!value_size)
+		return AVB_IO_RESULT_ERROR_NO_SUCH_VALUE;
+
+	rc = tee_shm_alloc(tee, name_size,
+			   TEE_SHM_ALLOC, &shm_name);
+	if (rc)
+		return AVB_IO_RESULT_ERROR_OOM;
+
+	rc = tee_shm_alloc(tee, value_size,
+			   TEE_SHM_ALLOC, &shm_buf);
+	if (rc) {
+		rc = AVB_IO_RESULT_ERROR_OOM;
+		goto free_name;
+	}
+
+	memcpy(shm_name->addr, name, name_size);
+	memcpy(shm_buf->addr, value, value_size);
+
+	memset(param, 0, sizeof(param));
+	param[0].attr = TEE_PARAM_ATTR_TYPE_MEMREF_INPUT;
+	param[0].u.memref.shm = shm_name;
+	param[0].u.memref.size = name_size;
+	param[1].attr = TEE_PARAM_ATTR_TYPE_MEMREF_INPUT;
+	param[1].u.memref.shm = shm_buf;
+	param[1].u.memref.size = value_size;
+
+	rc = invoke_func(ops->user_data, TA_AVB_CMD_WRITE_PERSIST_VALUE,
+			 2, param);
+	if (rc)
+		goto out;
+
+out:
+	tee_shm_free(shm_buf);
+free_name:
+	tee_shm_free(shm_name);
+
+	return rc;
+}
 /**
  * ============================================================================
  * AVB2.0 AvbOps alloc/initialisation/free
@@ -870,6 +991,10 @@ AvbOps *avb_ops_alloc(int boot_device)
 	ops_data->ops.read_is_device_unlocked = read_is_device_unlocked;
 	ops_data->ops.get_unique_guid_for_partition =
 		get_unique_guid_for_partition;
+#ifdef CONFIG_OPTEE_TA_AVB
+	ops_data->ops.write_persistent_value = write_persistent_value;
+	ops_data->ops.read_persistent_value = read_persistent_value;
+#endif
 	ops_data->ops.get_size_of_partition = get_size_of_partition;
 	ops_data->mmc_dev = boot_device;
 
diff --git a/drivers/tee/sandbox.c b/drivers/tee/sandbox.c
index ccddb03..5fecce0 100644
--- a/drivers/tee/sandbox.c
+++ b/drivers/tee/sandbox.c
@@ -5,6 +5,7 @@
 #include <common.h>
 #include <dm.h>
 #include <sandboxtee.h>
+#include <search.h>
 #include <tee.h>
 #include <tee/optee_ta_avb.h>
 
@@ -61,6 +62,8 @@ bad_params:
 
 static u64 ta_avb_rollback_indexes[TA_AVB_MAX_ROLLBACK_LOCATIONS];
 static u32 ta_avb_lock_state;
+static struct hsearch_data pstorage_htab;
+static const u32 pstorage_max = 16;
 
 static u32 ta_avb_open_session(uint num_params, struct tee_param *params)
 {
@@ -76,9 +79,13 @@ static u32 ta_avb_open_session(uint num_params, struct tee_param *params)
 static u32 ta_avb_invoke_func(u32 func, uint num_params,
 			      struct tee_param *params)
 {
+	ENTRY e, *ep;
+	char *name;
 	u32 res;
 	uint slot;
 	u64 val;
+	char *value;
+	u32 value_sz;
 
 	switch (func) {
 	case TA_AVB_CMD_READ_ROLLBACK_INDEX:
@@ -151,6 +158,57 @@ static u32 ta_avb_invoke_func(u32 func, uint num_params,
 		}
 
 		return TEE_SUCCESS;
+	case TA_AVB_CMD_READ_PERSIST_VALUE:
+		res = check_params(TEE_PARAM_ATTR_TYPE_MEMREF_INPUT,
+				   TEE_PARAM_ATTR_TYPE_MEMREF_INOUT,
+				   TEE_PARAM_ATTR_TYPE_NONE,
+				   TEE_PARAM_ATTR_TYPE_NONE,
+				   num_params, params);
+		if (res)
+			return res;
+
+		name = params[0].u.memref.shm->addr;
+
+		value = params[1].u.memref.shm->addr;
+		value_sz = params[1].u.memref.size;
+
+		e.key = name;
+		e.data = NULL;
+		hsearch_r(e, FIND, &ep, &pstorage_htab, 0);
+		if (!ep)
+			return TEE_ERROR_ITEM_NOT_FOUND;
+
+		value_sz = strlen(ep->data);
+		memcpy(value, ep->data, value_sz);
+
+		return TEE_SUCCESS;
+	case TA_AVB_CMD_WRITE_PERSIST_VALUE:
+		res = check_params(TEE_PARAM_ATTR_TYPE_MEMREF_INPUT,
+				   TEE_PARAM_ATTR_TYPE_MEMREF_INPUT,
+				   TEE_PARAM_ATTR_TYPE_NONE,
+				   TEE_PARAM_ATTR_TYPE_NONE,
+				   num_params, params);
+		if (res)
+			return res;
+
+		name = params[0].u.memref.shm->addr;
+
+		value = params[1].u.memref.shm->addr;
+		value_sz = params[1].u.memref.size;
+
+		e.key = name;
+		e.data = NULL;
+		hsearch_r(e, FIND, &ep, &pstorage_htab, 0);
+		if (ep)
+			hdelete_r(e.key, &pstorage_htab, 0);
+
+		e.key = name;
+		e.data = value;
+		hsearch_r(e, ENTER, &ep, &pstorage_htab, 0);
+		if (!ep)
+			return TEE_ERROR_OUT_OF_MEMORY;
+
+		return TEE_SUCCESS;
 
 	default:
 		return TEE_ERROR_NOT_SUPPORTED;
@@ -285,6 +343,26 @@ static int sandbox_tee_shm_unregister(struct udevice *dev, struct tee_shm *shm)
 	return 0;
 }
 
+static int sandbox_tee_remove(struct udevice *dev)
+{
+	hdestroy_r(&pstorage_htab);
+
+	return 0;
+}
+
+static int sandbox_tee_probe(struct udevice *dev)
+{
+	/*
+	 * With this hastable we emulate persistent storage,
+	 * which should contain persistent values
+	 * between different sessions/command invocations.
+	 */
+	if (!hcreate_r(pstorage_max, &pstorage_htab))
+		return TEE_ERROR_OUT_OF_MEMORY;
+
+	return 0;
+}
+
 static const struct tee_driver_ops sandbox_tee_ops = {
 	.get_version = sandbox_tee_get_version,
 	.open_session = sandbox_tee_open_session,
@@ -305,4 +383,6 @@ U_BOOT_DRIVER(sandbox_tee) = {
 	.of_match = sandbox_tee_match,
 	.ops = &sandbox_tee_ops,
 	.priv_auto_alloc_size = sizeof(struct sandbox_tee_state),
+	.probe = sandbox_tee_probe,
+	.remove = sandbox_tee_remove,
 };
diff --git a/include/tee.h b/include/tee.h
index edd9f9b..02bcd9e 100644
--- a/include/tee.h
+++ b/include/tee.h
@@ -43,7 +43,9 @@
 #define TEE_ERROR_COMMUNICATION		0xffff000e
 #define TEE_ERROR_SECURITY		0xffff000f
 #define TEE_ERROR_OUT_OF_MEMORY		0xffff000c
+#define TEE_ERROR_OVERFLOW              0xffff300f
 #define TEE_ERROR_TARGET_DEAD		0xffff3024
+#define TEE_ERROR_STORAGE_NO_SPACE      0xffff3041
 
 #define TEE_ORIGIN_COMMS		0x00000002
 #define TEE_ORIGIN_TEE			0x00000003
diff --git a/include/tee/optee_ta_avb.h b/include/tee/optee_ta_avb.h
index 074386a..949875a 100644
--- a/include/tee/optee_ta_avb.h
+++ b/include/tee/optee_ta_avb.h
@@ -45,4 +45,20 @@
  */
 #define TA_AVB_CMD_WRITE_LOCK_STATE	3
 
+/*
+ * Reads a persistent value corresponding to the given name.
+ *
+ * in	params[0].u.memref:	persistent value name
+ * out	params[1].u.memref:	read persistent value buffer
+ */
+#define TA_AVB_CMD_READ_PERSIST_VALUE	4
+
+/*
+ * Writes a persistent value corresponding to the given name.
+ *
+ * in	params[0].u.memref:	persistent value name
+ * in	params[1].u.memref:	persistent value buffer to write
+ */
+#define TA_AVB_CMD_WRITE_PERSIST_VALUE	5
+
 #endif /* __TA_AVB_H */
diff --git a/test/py/tests/test_avb.py b/test/py/tests/test_avb.py
index e70a010..2bb75ed 100644
--- a/test/py/tests/test_avb.py
+++ b/test/py/tests/test_avb.py
@@ -116,3 +116,19 @@ def test_avb_mmc_read(u_boot_console):
     response = u_boot_console.run_command('cmp 0x%x 0x%x 40' %
                                           (temp_addr, temp_addr2))
     assert response.find('64 word')
+
+
+ at pytest.mark.buildconfigspec('cmd_avb')
+ at pytest.mark.buildconfigspec('optee_ta_avb')
+def test_avb_persistent_values(u_boot_console):
+    """Test reading/writing persistent storage to avb
+    """
+
+    response = u_boot_console.run_command('avb init %s' % str(mmc_dev))
+    assert response == ''
+
+    response = u_boot_console.run_command('avb write_pvalue test value_value')
+    assert response == 'Wrote 12 bytes'
+
+    response = u_boot_console.run_command('avb read_pvalue test 12')
+    assert response == 'Read 12 bytes, value = value_value'
-- 
2.7.4

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

* [U-Boot] [PATCH v4 1/1] avb: add support for named persistent values
  2019-01-27 14:34 [U-Boot] [PATCH v4 1/1] avb: add support for named persistent values Igor Opaniuk
@ 2019-01-31 10:04 ` Simon Glass
  2019-02-01 20:38   ` Igor Opaniuk
  2019-02-09 12:50 ` [U-Boot] [U-Boot, v4, " Tom Rini
  1 sibling, 1 reply; 13+ messages in thread
From: Simon Glass @ 2019-01-31 10:04 UTC (permalink / raw)
  To: u-boot

Hi Igor,

On Sun, 27 Jan 2019 at 07:34, Igor Opaniuk <igor.opaniuk@linaro.org> wrote:
>
> AVB version 1.1 introduces support for named persistent values
> that must be tamper evident and allows AVB to store arbitrary key-value
> pairs [1].
>
> Introduce implementation of two additional AVB operations
> read_persistent_value()/write_persistent_value() for retrieving/storing
> named persistent values.
>
> Correspondent pull request in the OP-TEE OS project repo [2].
>
> [1]: https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22
> [2]: https://github.com/OP-TEE/optee_os/pull/2699
>
> Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org>
> ---
>
> v4:
> - extend tee sandbox tee driver to support persistent values
> - fix/re-test avb_persistent test on sandbox configuration:
> $ ./test/py/test.py --bd sandbox --build -s -i avb_per
>
> U-Boot 2019.01-06051-gd01806a-dirty (Jan 27 2019 - 11:56:41 +0200)
>
> Model: sandbox
> DRAM:  128 MiB
> MMC:   MMC probed
> MMC probed
> MMC probed
> mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD)
> In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Model: sandbox
> SCSI:
> Net:   eth0: eth at 10002000, eth5: eth at 10003000, eth3: sbe5, eth1: eth at 10004000
> Hit any key to stop autoboot:  0
> => => avb init 1
> => => avb write_pvalue test value_value
> Wrote 12 bytes
> => => avb read_pvalue test 12
> Read 12 bytes, value = value_value
> =>
> test/py/tests/test_avb.py .
>
> ===== 464 tests deselected by '-kavb_per' ======
> === 1 passed, 464 deselected in 0.16 seconds ===
>
> v3:
> - fix possible mem lick in avb_read_persistent/avb_write_persistent
> - add additional sanity checks
> - cover avb read_pvalue/write_pvalue commands with python tests
>
> v2:
> - fix output format for avb read_pvalue/write_pvalue commands
> - fix issue with named value buffer size
>
>  cmd/avb.c                  |  78 ++++++++++++++++++++++++++++
>  common/avb_verify.c        | 125 +++++++++++++++++++++++++++++++++++++++++++++
>  drivers/tee/sandbox.c      |  80 +++++++++++++++++++++++++++++
>  include/tee.h              |   2 +
>  include/tee/optee_ta_avb.h |  16 ++++++
>  test/py/tests/test_avb.py  |  16 ++++++
>  6 files changed, 317 insertions(+)

This looks OK. My only comment is that the variables at the top of the
sandbox driver should really be in a driver-private data struct, using
priv_auto_alloc_size, etc.

Reviewed-by: Simon Glass <sjg@chromium.org>

I'm assuming that this test runs with 'make qcheck'?


- Simon

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

* [U-Boot] [PATCH v4 1/1] avb: add support for named persistent values
  2019-01-31 10:04 ` Simon Glass
@ 2019-02-01 20:38   ` Igor Opaniuk
  2019-02-02 15:00     ` Simon Glass
  0 siblings, 1 reply; 13+ messages in thread
From: Igor Opaniuk @ 2019-02-01 20:38 UTC (permalink / raw)
  To: u-boot

Hi Simon,

Thanks for reviewing!

> I'm assuming that this test runs with 'make qcheck'?

I've tested only by invoking test.py:
./test/py/test.py --bd sandbox --build


On Thu, Jan 31, 2019, 11:04 Simon Glass <sjg@chromium.org wrote:

> Hi Igor,
>
> On Sun, 27 Jan 2019 at 07:34, Igor Opaniuk <igor.opaniuk@linaro.org>
> wrote:
> >
> > AVB version 1.1 introduces support for named persistent values
> > that must be tamper evident and allows AVB to store arbitrary key-value
> > pairs [1].
> >
> > Introduce implementation of two additional AVB operations
> > read_persistent_value()/write_persistent_value() for retrieving/storing
> > named persistent values.
> >
> > Correspondent pull request in the OP-TEE OS project repo [2].
> >
> > [1]:
> https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22
> > [2]: https://github.com/OP-TEE/optee_os/pull/2699
> >
> > Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org>
> > ---
> >
> > v4:
> > - extend tee sandbox tee driver to support persistent values
> > - fix/re-test avb_persistent test on sandbox configuration:
> > $ ./test/py/test.py --bd sandbox --build -s -i avb_per
> >
> > U-Boot 2019.01-06051-gd01806a-dirty (Jan 27 2019 - 11:56:41 +0200)
> >
> > Model: sandbox
> > DRAM:  128 MiB
> > MMC:   MMC probed
> > MMC probed
> > MMC probed
> > mmc2: 2 (SD), mmc1: 1 (SD), mmc0: 0 (SD)
> > In:    serial
> > Out:   vidconsole
> > Err:   vidconsole
> > Model: sandbox
> > SCSI:
> > Net:   eth0: eth at 10002000, eth5: eth at 10003000, eth3: sbe5, eth1:
> eth at 10004000
> > Hit any key to stop autoboot:  0
> > => => avb init 1
> > => => avb write_pvalue test value_value
> > Wrote 12 bytes
> > => => avb read_pvalue test 12
> > Read 12 bytes, value = value_value
> > =>
> > test/py/tests/test_avb.py .
> >
> > ===== 464 tests deselected by '-kavb_per' ======
> > === 1 passed, 464 deselected in 0.16 seconds ===
> >
> > v3:
> > - fix possible mem lick in avb_read_persistent/avb_write_persistent
> > - add additional sanity checks
> > - cover avb read_pvalue/write_pvalue commands with python tests
> >
> > v2:
> > - fix output format for avb read_pvalue/write_pvalue commands
> > - fix issue with named value buffer size
> >
> >  cmd/avb.c                  |  78 ++++++++++++++++++++++++++++
> >  common/avb_verify.c        | 125
> +++++++++++++++++++++++++++++++++++++++++++++
> >  drivers/tee/sandbox.c      |  80 +++++++++++++++++++++++++++++
> >  include/tee.h              |   2 +
> >  include/tee/optee_ta_avb.h |  16 ++++++
> >  test/py/tests/test_avb.py  |  16 ++++++
> >  6 files changed, 317 insertions(+)
>
> This looks OK. My only comment is that the variables at the top of the
> sandbox driver should really be in a driver-private data struct, using
> priv_auto_alloc_size, etc.
>
> Reviewed-by: Simon Glass <sjg@chromium.org>
>
> I'm assuming that this test runs with 'make qcheck'?
>
>
> - Simon
>

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

* [U-Boot] [PATCH v4 1/1] avb: add support for named persistent values
  2019-02-01 20:38   ` Igor Opaniuk
@ 2019-02-02 15:00     ` Simon Glass
  0 siblings, 0 replies; 13+ messages in thread
From: Simon Glass @ 2019-02-02 15:00 UTC (permalink / raw)
  To: u-boot

Hi Igor,

On Fri, 1 Feb 2019 at 13:38, Igor Opaniuk <igor.opaniuk@linaro.org> wrote:
>
> Hi Simon,
>
> Thanks for reviewing!
>
> > I'm assuming that this test runs with 'make qcheck'?
>
> I've tested only by invoking test.py:
> ./test/py/test.py --bd sandbox --build

Yes that's fine, just wanted to make sure it is invoked in the normal way.

[..]

Regards,
Simom

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

* [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values
  2019-01-27 14:34 [U-Boot] [PATCH v4 1/1] avb: add support for named persistent values Igor Opaniuk
  2019-01-31 10:04 ` Simon Glass
@ 2019-02-09 12:50 ` Tom Rini
  2019-02-11 14:59   ` Igor Opaniuk
  1 sibling, 1 reply; 13+ messages in thread
From: Tom Rini @ 2019-02-09 12:50 UTC (permalink / raw)
  To: u-boot

On Sun, Jan 27, 2019 at 04:34:05PM +0200, Igor Opaniuk wrote:

> AVB version 1.1 introduces support for named persistent values
> that must be tamper evident and allows AVB to store arbitrary key-value
> pairs [1].
> 
> Introduce implementation of two additional AVB operations
> read_persistent_value()/write_persistent_value() for retrieving/storing
> named persistent values.
> 
> Correspondent pull request in the OP-TEE OS project repo [2].
> 
> [1]: https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22
> [2]: https://github.com/OP-TEE/optee_os/pull/2699
> 
> Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org>
> Reviewed-by: Simon Glass <sjg@chromium.org>

The test fails on some sandbox targets:
https://travis-ci.org/trini/u-boot/jobs/490809872

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190209/b718576b/attachment.sig>

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

* [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values
  2019-02-09 12:50 ` [U-Boot] [U-Boot, v4, " Tom Rini
@ 2019-02-11 14:59   ` Igor Opaniuk
  2019-02-11 15:30     ` Tom Rini
  0 siblings, 1 reply; 13+ messages in thread
From: Igor Opaniuk @ 2019-02-11 14:59 UTC (permalink / raw)
  To: u-boot

Hi Tom,

Thanks for pointing that out.
I've done a little investigation, and the interesting thing is that it
never fails when I exclude other tests, for example, running only
ut_dm subset:
./test/py/test.py --bd sandbox_flattree --build -s -k ut_dm
or even this particular test:
./test/py/test.py --bd sandbox_flattree --build -s -k ut_dm_tee

Each time it fails in the same place on trying to allocate a hashtree
(using hash tree funcs from /lib/hashtable.c) with 20 elements when
probing tee device, and seems that
it just a consequence of that fact, that some functionality, which
tested before tee, is not doing a proper cleanup (when full testing is
done).

Anyway, I can decrease the number of elements for the hashtree, but it
definitely won't fix the root cause.

Regards,
Igor

On Sat, 9 Feb 2019 at 14:50, Tom Rini <trini@konsulko.com> wrote:
>
> On Sun, Jan 27, 2019 at 04:34:05PM +0200, Igor Opaniuk wrote:
>
> > AVB version 1.1 introduces support for named persistent values
> > that must be tamper evident and allows AVB to store arbitrary key-value
> > pairs [1].
> >
> > Introduce implementation of two additional AVB operations
> > read_persistent_value()/write_persistent_value() for retrieving/storing
> > named persistent values.
> >
> > Correspondent pull request in the OP-TEE OS project repo [2].
> >
> > [1]: https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22
> > [2]: https://github.com/OP-TEE/optee_os/pull/2699
> >
> > Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org>
> > Reviewed-by: Simon Glass <sjg@chromium.org>
>
> The test fails on some sandbox targets:
> https://travis-ci.org/trini/u-boot/jobs/490809872
>
> --
> Tom



-- 
Regards,
Igor Opaniuk

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

* [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values
  2019-02-11 14:59   ` Igor Opaniuk
@ 2019-02-11 15:30     ` Tom Rini
  2019-02-12 13:53       ` Igor Opaniuk
  0 siblings, 1 reply; 13+ messages in thread
From: Tom Rini @ 2019-02-11 15:30 UTC (permalink / raw)
  To: u-boot

On Mon, Feb 11, 2019 at 04:59:54PM +0200, Igor Opaniuk wrote:
> Hi Tom,
> 
> Thanks for pointing that out.
> I've done a little investigation, and the interesting thing is that it
> never fails when I exclude other tests, for example, running only
> ut_dm subset:
> ./test/py/test.py --bd sandbox_flattree --build -s -k ut_dm
> or even this particular test:
> ./test/py/test.py --bd sandbox_flattree --build -s -k ut_dm_tee
> 
> Each time it fails in the same place on trying to allocate a hashtree
> (using hash tree funcs from /lib/hashtable.c) with 20 elements when
> probing tee device, and seems that
> it just a consequence of that fact, that some functionality, which
> tested before tee, is not doing a proper cleanup (when full testing is
> done).
> 
> Anyway, I can decrease the number of elements for the hashtree, but it
> definitely won't fix the root cause.

Can you please look into the root cause?  It sounds like you're a fair
part of the way along on that now, thanks!

> 
> Regards,
> Igor
> 
> On Sat, 9 Feb 2019 at 14:50, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Sun, Jan 27, 2019 at 04:34:05PM +0200, Igor Opaniuk wrote:
> >
> > > AVB version 1.1 introduces support for named persistent values
> > > that must be tamper evident and allows AVB to store arbitrary key-value
> > > pairs [1].
> > >
> > > Introduce implementation of two additional AVB operations
> > > read_persistent_value()/write_persistent_value() for retrieving/storing
> > > named persistent values.
> > >
> > > Correspondent pull request in the OP-TEE OS project repo [2].
> > >
> > > [1]: https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22
> > > [2]: https://github.com/OP-TEE/optee_os/pull/2699
> > >
> > > Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org>
> > > Reviewed-by: Simon Glass <sjg@chromium.org>
> >
> > The test fails on some sandbox targets:
> > https://travis-ci.org/trini/u-boot/jobs/490809872
> >
> > --
> > Tom
> 
> 
> 
> -- 
> Regards,
> Igor Opaniuk

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190211/8f1d1a30/attachment.sig>

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

* [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values
  2019-02-11 15:30     ` Tom Rini
@ 2019-02-12 13:53       ` Igor Opaniuk
  2019-02-12 15:31         ` Simon Glass
  0 siblings, 1 reply; 13+ messages in thread
From: Igor Opaniuk @ 2019-02-12 13:53 UTC (permalink / raw)
  To: u-boot

Hi Tom, Simon,

So I did a little investigation and found out that, the issue in that
hcreate_r() invocation in the tee sandbox driver fails because the
hashtable was allocated before.
Debugging showed that the sandbox tee driver is probed twice every
time (although remove() is never called, it's behaves like there are
two "tee" nodes in DT), and still haven't found the root cause (I
think Simon can help with the hint where to look).
I was assuming that those returned udevice pointers are kept in some
global state but seem that they are de-allocated at some point.
Have you ever faced the same behavior?

I've done all testing on sandbox_flattree setup (it's not reproducing
on a simple sandbox setup):
./test/py/test.py --bd sandbox_flattree --build -s --gdbserver localhost:1234

During the first probe:
Breakpoint 1, sandbox_tee_probe (dev=0x15944610) at ../drivers/tee/sandbox.c:372
372 if (!hcreate_r(pstorage_max, &pstorage_htab)) {

(gdb) info threads
 Id   Target Id                   Frame
* 1    Thread 13048.13048 "u-boot" sandbox_tee_probe (dev=0x15944610)
at ../drivers/tee/sandbox.c:372
(gdb) python print(gdb.selected_inferior().pid)
13048

(gdb) print pstorage_htab.table
$6 = (struct _ENTRY *) 0x0

(gdb) bt
#0  sandbox_tee_probe (dev=0x15944610) at ../drivers/tee/sandbox.c:372
#1  0x0000000000432a7f in device_probe (dev=0x15944610) at
../drivers/core/device.c:418
#2  0x000000000044fe29 in tee_find_device (start=start at entry=0x0,
match=match at entry=0x0, data=data at entry=0x0, vers=vers at entry=0x0) at
../drivers/tee/tee-uclass.c:164
#3  0x000000000042de59 in get_open_session
(ops_data=ops_data at entry=0x1594cf60) at ../common/avb_verify.c:615
#4  0x000000000042e0e0 in invoke_func (ops_data=0x1594cf60, func=0,
num_param=2, param=0x7fffffffd520) at ../common/avb_verify.c:636
#5  0x000000000042e53a in read_rollback_index (ops=0x1594cf60,
rollback_index_slot=1, out_rollback_index=0x7fffffffd598) at
../common/avb_verify.c:703
#6  0x00000000004188b3 in do_avb_read_rb (cmdtp=<optimized out>,
flag=<optimized out>, argc=<optimized out>, argv=<optimized out>) at
../cmd/avb.c:167
#7  0x000000000042cc43 in cmd_call (repeatable=0x7fffffffd5bc,
argv=0x1594ce40, argc=3, flag=<optimized out>, cmdtp=0x7782b0
<_u_boot_list_2_cmd_2_avb>) at ../common/command.c:565
#8  cmd_process (flag=<optimized out>, argc=3, argv=0x1594ce40,
repeatable=repeatable at entry=0x78f394 <flag_repeat>,
ticks=ticks at entry=0x0) at ../common/command.c:606
#9  0x000000000041bdcb in run_pipe_real (pi=0x1594ccf0) at
../common/cli_hush.c:1677
#10 run_list_real (pi=<optimized out>) at ../common/cli_hush.c:1875
#11 0x000000000041c1dd in run_list (pi=0x1594ccf0) at ../common/cli_hush.c:2024
#12 parse_stream_outer (inp=inp at entry=0x7fffffffd730,
flag=flag at entry=2) at ../common/cli_hush.c:3216
#13 0x000000000041c54d in parse_file_outer () at ../common/cli_hush.c:3299
#14 0x000000000042c2ce in cli_loop () at ../common/cli.c:217
#15 0x0000000000419f74 in main_loop () at ../common/main.c:63
#16 0x000000000041ccec in run_main_loop () at ../common/board_r.c:631
#17 0x000000000041cf41 in initcall_run_list (init_sequence=0x787740
<init_sequence_r>) at ../include/initcall.h:35
#18 board_init_r (new_gd=<optimized out>, dest_addr=dest_addr at entry=0)
at ../common/board_r.c:856
#19 0x00000000004025ee in main (argc=<optimized out>, argv=<optimized
out>) at ../arch/sandbox/cpu/start.c:356


Then probed is invoked from a different thread:
gdb) c
Continuing.
[New Thread 13048.13074]

Thread 1 "u-boot" hit Breakpoint 1, sandbox_tee_probe (dev=0x15edf050)
at ../drivers/tee/sandbox.c:372
372 if (!hcreate_r(pstorage_max, &pstorage_htab)) {
(gdb) print pstorage_htab.table
$7 = (struct _ENTRY *) 0x1594d010

(gdb) python print(gdb.selected_inferior().pid)
13048

(gdb) bt
#0  sandbox_tee_probe (dev=0x15edf050) at ../drivers/tee/sandbox.c:372
#1  0x0000000000432a7f in device_probe (dev=0x15edf050) at
../drivers/core/device.c:418
#2  0x000000000044fe29 in tee_find_device (start=start at entry=0x0,
match=match at entry=0x4c31c2 <match>, data=data at entry=0x0,
vers=vers at entry=0x7fffffffd42c) at ../drivers/tee/tee-uclass.c:164
#3  0x00000000004c3203 in test_tee (vars=0x7fffffffd430, uts=0x7c50a0
<global_dm_test_state>) at ../test/dm/tee.c:66
#4  dm_test_tee (uts=0x7c50a0 <global_dm_test_state>) at ../test/dm/tee.c:106
#5  0x00000000004af11f in dm_do_test (uts=0x7c50a0
<global_dm_test_state>, of_live=false, test=0x77b568
<_u_boot_list_2_dm_test_2_dm_test_tee>) at ../test/dm/test-main.c:103
#6  dm_test_main (test_name=0x1594d1a0 "tee") at ../test/dm/test-main.c:180
#7  do_ut_dm (cmdtp=<optimized out>, flag=<optimized out>,
argc=<optimized out>, argv=<optimized out>) at
../test/dm/test-main.c:206
#8  0x000000000042cc43 in cmd_call (repeatable=0x7fffffffd5bc,
argv=0x15abab30, argc=3, flag=<optimized out>, cmdtp=0x779f90
<_u_boot_list_2_cmd_2_ut>) at ../common/command.c:565
#9  cmd_process (flag=<optimized out>, argc=3, argv=0x15abab30,
repeatable=repeatable at entry=0x78f394 <flag_repeat>,
ticks=ticks at entry=0x0) at ../common/command.c:606
#10 0x000000000041bdcb in run_pipe_real (pi=0x15ab2380) at
../common/cli_hush.c:1677
#11 run_list_real (pi=<optimized out>) at ../common/cli_hush.c:1875
#12 0x000000000041c1dd in run_list (pi=0x15ab2380) at ../common/cli_hush.c:2024
#13 parse_stream_outer (inp=inp at entry=0x7fffffffd730,
flag=flag at entry=2) at ../common/cli_hush.c:3216
#14 0x000000000041c54d in parse_file_outer () at ../common/cli_hush.c:3299
#15 0x000000000042c2ce in cli_loop () at ../common/cli.c:217
#16 0x0000000000419f74 in main_loop () at ../common/main.c:63
#17 0x000000000041ccec in run_main_loop () at ../common/board_r.c:631
#18 0x000000000041cf41 in initcall_run_list (init_sequence=0x787740
<init_sequence_r>) at ../include/initcall.h:35
#19 board_init_r (new_gd=<optimized out>, dest_addr=dest_addr at entry=0)
at ../common/board_r.c:856
#20 0x00000000004025ee in main (argc=<optimized out>, argv=<optimized
out>) at ../arch/sandbox/cpu/start.c:356

(gdb) info threads
 Id   Target Id                   Frame
* 1    Thread 13048.13048 "u-boot" sandbox_tee_probe (dev=0x15edf050)
at ../drivers/tee/sandbox.c:372
 2    Thread 13048.13074 "u-boot" 0x00007ffff7667811 in __GI_ppoll
(fds=0x7c7430, nfds=3, timeout=<optimized out>, sigmask=0x0) at
../sysdeps/unix/sysv/linux/ppoll.c:50

On Mon, 11 Feb 2019 at 17:30, Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Feb 11, 2019 at 04:59:54PM +0200, Igor Opaniuk wrote:
> > Hi Tom,
> >
> > Thanks for pointing that out.
> > I've done a little investigation, and the interesting thing is that it
> > never fails when I exclude other tests, for example, running only
> > ut_dm subset:
> > ./test/py/test.py --bd sandbox_flattree --build -s -k ut_dm
> > or even this particular test:
> > ./test/py/test.py --bd sandbox_flattree --build -s -k ut_dm_tee
> >
> > Each time it fails in the same place on trying to allocate a hashtree
> > (using hash tree funcs from /lib/hashtable.c) with 20 elements when
> > probing tee device, and seems that
> > it just a consequence of that fact, that some functionality, which
> > tested before tee, is not doing a proper cleanup (when full testing is
> > done).
> >
> > Anyway, I can decrease the number of elements for the hashtree, but it
> > definitely won't fix the root cause.
>
> Can you please look into the root cause?  It sounds like you're a fair
> part of the way along on that now, thanks!
>
> >
> > Regards,
> > Igor
> >
> > On Sat, 9 Feb 2019 at 14:50, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Sun, Jan 27, 2019 at 04:34:05PM +0200, Igor Opaniuk wrote:
> > >
> > > > AVB version 1.1 introduces support for named persistent values
> > > > that must be tamper evident and allows AVB to store arbitrary key-value
> > > > pairs [1].
> > > >
> > > > Introduce implementation of two additional AVB operations
> > > > read_persistent_value()/write_persistent_value() for retrieving/storing
> > > > named persistent values.
> > > >
> > > > Correspondent pull request in the OP-TEE OS project repo [2].
> > > >
> > > > [1]: https://android.googlesource.com/platform/external/avb/+/android-9.0.0_r22
> > > > [2]: https://github.com/OP-TEE/optee_os/pull/2699
> > > >
> > > > Signed-off-by: Igor Opaniuk <igor.opaniuk@linaro.org>
> > > > Reviewed-by: Simon Glass <sjg@chromium.org>
> > >
> > > The test fails on some sandbox targets:
> > > https://travis-ci.org/trini/u-boot/jobs/490809872
> > >
> > > --
> > > Tom
> >
> >
> >
> > --
> > Regards,
> > Igor Opaniuk
>
> --
> Tom



-- 
Regards,
Igor Opaniuk

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

* [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values
  2019-02-12 13:53       ` Igor Opaniuk
@ 2019-02-12 15:31         ` Simon Glass
  2019-02-13 15:38           ` Igor Opaniuk
  0 siblings, 1 reply; 13+ messages in thread
From: Simon Glass @ 2019-02-12 15:31 UTC (permalink / raw)
  To: u-boot

Hi Igor,

On Tue, 12 Feb 2019 at 14:54, Igor Opaniuk <igor.opaniuk@linaro.org> wrote:
>
> Hi Tom, Simon,
>
> So I did a little investigation and found out that, the issue in that
> hcreate_r() invocation in the tee sandbox driver fails because the
> hashtable was allocated before.
> Debugging showed that the sandbox tee driver is probed twice every
> time (although remove() is never called, it's behaves like there are
> two "tee" nodes in DT), and still haven't found the root cause (I
> think Simon can help with the hint where to look).
> I was assuming that those returned udevice pointers are kept in some
> global state but seem that they are de-allocated at some point.
> Have you ever faced the same behavior?

Not really. If the driver is probed before relocation then it may be
probed again after relocation. You should be able to tell that by
check gd->flags.

Regards,
Simon

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

* [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values
  2019-02-12 15:31         ` Simon Glass
@ 2019-02-13 15:38           ` Igor Opaniuk
  2019-02-14 16:18             ` Igor Opaniuk
  2019-02-14 16:23             ` Simon Glass
  0 siblings, 2 replies; 13+ messages in thread
From: Igor Opaniuk @ 2019-02-13 15:38 UTC (permalink / raw)
  To: u-boot

Hi Simon,

Seems that there is an issue in dm test framework (if understood
everything correctly),

I've noticed that dm_root is updated when dm tests are being invoked,
and that's why the new tee udevice is allocated, consequently, the
second invocation of probe in tee driver occurs.
In dm_test_init() dm_root is re-inited with NULL (then it populates
new dm tree for from scratch, probing all devices), and I can't find
where it is done(or if it's done at all) a proper removal/cleanup of
devices from the previous dm tree before this dm_test initialization
is invoked (I've added a conditional breakpoint for removal of
previously allocated tee device, and it's never being called):

Hardware watchpoint 4: gd->dm_root

Old value = (struct udevice *) 0x1593c230
New value = (struct udevice *) 0x0
dm_test_init (uts=0x7c5080 <global_dm_test_state>, of_live=false) at
../test/dm/test-main.c:30
30 memset(dm_testdrv_op_count, '\0', sizeof(dm_testdrv_op_count));
(gdb) bt
#0  dm_test_init (uts=0x7c5080 <global_dm_test_state>, of_live=false)
at ../test/dm/test-main.c:30
#1  dm_do_test (uts=0x7c5080 <global_dm_test_state>, of_live=false,
test=0x77a208 <_u_boot_list_2_dm_test_2_dm_test_adc_bind>) at
../test/dm/test-main.c:86
#2  dm_test_main (test_name=0x1594ccf0 "adc_bind") at ../test/dm/test-main.c:180
#3  do_ut_dm (cmdtp=<optimized out>, flag=<optimized out>,
argc=<optimized out>, argv=<optimized out>) at
../test/dm/test-main.c:206
#4  0x000000000042cc43 in cmd_call (repeatable=0x7fffffffd58c,
argv=0x1594cd10, argc=3, flag=<optimized out>, cmdtp=0x779f90
<_u_boot_list_2_cmd_2_ut>) at ../common/command.c:565
#5  cmd_process (flag=<optimized out>, argc=3, argv=0x1594cd10,
repeatable=repeatable at entry=0x78f394 <flag_repeat>,
ticks=ticks at entry=0x0) at ../common/command.c:606
#6  0x000000000041bdcb in run_pipe_real (pi=0x1594cef0) at
../common/cli_hush.c:1677
#7  run_list_real (pi=<optimized out>) at ../common/cli_hush.c:1875
#8  0x000000000041c1dd in run_list (pi=0x1594cef0) at ../common/cli_hush.c:2024
#9  parse_stream_outer (inp=inp at entry=0x7fffffffd700,
flag=flag at entry=2) at ../common/cli_hush.c:3216
#10 0x000000000041c54d in parse_file_outer () at ../common/cli_hush.c:3299
#11 0x000000000042c2ce in cli_loop () at ../common/cli.c:217
#12 0x0000000000419f74 in main_loop () at ../common/main.c:63
#13 0x000000000041ccec in run_main_loop () at ../common/board_r.c:631
#14 0x000000000041cf41 in initcall_run_list (init_sequence=0x787740
<init_sequence_r>) at ../include/initcall.h:35
#15 board_init_r (new_gd=<optimized out>, dest_addr=dest_addr at entry=0)
at ../common/board_r.c:856
#16 0x00000000004025ee in main (argc=<optimized out>, argv=<optimized
out>) at ../arch/sandbox/cpu/start.c:356

Have I missed something?

On Tue, 12 Feb 2019 at 17:31, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Igor,
>
> On Tue, 12 Feb 2019 at 14:54, Igor Opaniuk <igor.opaniuk@linaro.org> wrote:
> >
> > Hi Tom, Simon,
> >
> > So I did a little investigation and found out that, the issue in that
> > hcreate_r() invocation in the tee sandbox driver fails because the
> > hashtable was allocated before.
> > Debugging showed that the sandbox tee driver is probed twice every
> > time (although remove() is never called, it's behaves like there are
> > two "tee" nodes in DT), and still haven't found the root cause (I
> > think Simon can help with the hint where to look).
> > I was assuming that those returned udevice pointers are kept in some
> > global state but seem that they are de-allocated at some point.
> > Have you ever faced the same behavior?
>
> Not really. If the driver is probed before relocation then it may be
> probed again after relocation. You should be able to tell that by
> check gd->flags.
>
> Regards,
> Simon



-- 
Regards,
Igor Opaniuk

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

* [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values
  2019-02-13 15:38           ` Igor Opaniuk
@ 2019-02-14 16:18             ` Igor Opaniuk
  2019-02-14 16:24               ` Simon Glass
  2019-02-14 16:23             ` Simon Glass
  1 sibling, 1 reply; 13+ messages in thread
From: Igor Opaniuk @ 2019-02-14 16:18 UTC (permalink / raw)
  To: u-boot

Hi Simon,

I've fixed failing test on sandbox_flattree by keeping all defined
global variables in a driver-private data struct(as you suggested),
which
permits to probe multiple tee sandbox devices (sent v5, kept you R-b
tag, please let me know if there are any objections from your side).

But the way how dm test framework is invoked and why dm_root is simply
re-allocated (and what happens with the previous one) is still an open
question to me.
If you can confirm that this a bug, I'll try to think about how this
can be fixed.

Thanks!


On Wed, 13 Feb 2019 at 17:38, Igor Opaniuk <igor.opaniuk@linaro.org> wrote:
>
> Hi Simon,
>
> Seems that there is an issue in dm test framework (if understood
> everything correctly),
>
> I've noticed that dm_root is updated when dm tests are being invoked,
> and that's why the new tee udevice is allocated, consequently, the
> second invocation of probe in tee driver occurs.
> In dm_test_init() dm_root is re-inited with NULL (then it populates
> new dm tree for from scratch, probing all devices), and I can't find
> where it is done(or if it's done at all) a proper removal/cleanup of
> devices from the previous dm tree before this dm_test initialization
> is invoked (I've added a conditional breakpoint for removal of
> previously allocated tee device, and it's never being called):
>
> Hardware watchpoint 4: gd->dm_root
>
> Old value = (struct udevice *) 0x1593c230
> New value = (struct udevice *) 0x0
> dm_test_init (uts=0x7c5080 <global_dm_test_state>, of_live=false) at
> ../test/dm/test-main.c:30
> 30 memset(dm_testdrv_op_count, '\0', sizeof(dm_testdrv_op_count));
> (gdb) bt
> #0  dm_test_init (uts=0x7c5080 <global_dm_test_state>, of_live=false)
> at ../test/dm/test-main.c:30
> #1  dm_do_test (uts=0x7c5080 <global_dm_test_state>, of_live=false,
> test=0x77a208 <_u_boot_list_2_dm_test_2_dm_test_adc_bind>) at
> ../test/dm/test-main.c:86
> #2  dm_test_main (test_name=0x1594ccf0 "adc_bind") at ../test/dm/test-main.c:180
> #3  do_ut_dm (cmdtp=<optimized out>, flag=<optimized out>,
> argc=<optimized out>, argv=<optimized out>) at
> ../test/dm/test-main.c:206
> #4  0x000000000042cc43 in cmd_call (repeatable=0x7fffffffd58c,
> argv=0x1594cd10, argc=3, flag=<optimized out>, cmdtp=0x779f90
> <_u_boot_list_2_cmd_2_ut>) at ../common/command.c:565
> #5  cmd_process (flag=<optimized out>, argc=3, argv=0x1594cd10,
> repeatable=repeatable at entry=0x78f394 <flag_repeat>,
> ticks=ticks at entry=0x0) at ../common/command.c:606
> #6  0x000000000041bdcb in run_pipe_real (pi=0x1594cef0) at
> ../common/cli_hush.c:1677
> #7  run_list_real (pi=<optimized out>) at ../common/cli_hush.c:1875
> #8  0x000000000041c1dd in run_list (pi=0x1594cef0) at ../common/cli_hush.c:2024
> #9  parse_stream_outer (inp=inp at entry=0x7fffffffd700,
> flag=flag at entry=2) at ../common/cli_hush.c:3216
> #10 0x000000000041c54d in parse_file_outer () at ../common/cli_hush.c:3299
> #11 0x000000000042c2ce in cli_loop () at ../common/cli.c:217
> #12 0x0000000000419f74 in main_loop () at ../common/main.c:63
> #13 0x000000000041ccec in run_main_loop () at ../common/board_r.c:631
> #14 0x000000000041cf41 in initcall_run_list (init_sequence=0x787740
> <init_sequence_r>) at ../include/initcall.h:35
> #15 board_init_r (new_gd=<optimized out>, dest_addr=dest_addr at entry=0)
> at ../common/board_r.c:856
> #16 0x00000000004025ee in main (argc=<optimized out>, argv=<optimized
> out>) at ../arch/sandbox/cpu/start.c:356
>
> Have I missed something?
>
> On Tue, 12 Feb 2019 at 17:31, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Igor,
> >
> > On Tue, 12 Feb 2019 at 14:54, Igor Opaniuk <igor.opaniuk@linaro.org> wrote:
> > >
> > > Hi Tom, Simon,
> > >
> > > So I did a little investigation and found out that, the issue in that
> > > hcreate_r() invocation in the tee sandbox driver fails because the
> > > hashtable was allocated before.
> > > Debugging showed that the sandbox tee driver is probed twice every
> > > time (although remove() is never called, it's behaves like there are
> > > two "tee" nodes in DT), and still haven't found the root cause (I
> > > think Simon can help with the hint where to look).
> > > I was assuming that those returned udevice pointers are kept in some
> > > global state but seem that they are de-allocated at some point.
> > > Have you ever faced the same behavior?
> >
> > Not really. If the driver is probed before relocation then it may be
> > probed again after relocation. You should be able to tell that by
> > check gd->flags.
> >
> > Regards,
> > Simon
>
>
>
> --
> Regards,
> Igor Opaniuk



-- 
Regards,
Igor Opaniuk

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

* [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values
  2019-02-13 15:38           ` Igor Opaniuk
  2019-02-14 16:18             ` Igor Opaniuk
@ 2019-02-14 16:23             ` Simon Glass
  1 sibling, 0 replies; 13+ messages in thread
From: Simon Glass @ 2019-02-14 16:23 UTC (permalink / raw)
  To: u-boot

HI Igor,

On Wed, 13 Feb 2019 at 16:39, Igor Opaniuk <igor.opaniuk@linaro.org> wrote:
>
> Hi Simon,
>
> Seems that there is an issue in dm test framework (if understood
> everything correctly),
>
> I've noticed that dm_root is updated when dm tests are being invoked,
> and that's why the new tee udevice is allocated, consequently, the
> second invocation of probe in tee driver occurs.
> In dm_test_init() dm_root is re-inited with NULL (then it populates
> new dm tree for from scratch, probing all devices), and I can't find
> where it is done(or if it's done at all) a proper removal/cleanup of
> devices from the previous dm tree before this dm_test initialization
> is invoked (I've added a conditional breakpoint for removal of
> previously allocated tee device, and it's never being called):

I don't believe we clean up the devices when running tests.

It looks like there are some static variables in the sandbox optee
driver. That is not correct - everything should be stored in
driver-private or uclass-private data so that it goes away.

Maybe that is the problem?

[..]

Regards,
Simon

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

* [U-Boot] [U-Boot, v4, 1/1] avb: add support for named persistent values
  2019-02-14 16:18             ` Igor Opaniuk
@ 2019-02-14 16:24               ` Simon Glass
  0 siblings, 0 replies; 13+ messages in thread
From: Simon Glass @ 2019-02-14 16:24 UTC (permalink / raw)
  To: u-boot

Hi Igor,

On Thu, 14 Feb 2019 at 17:19, Igor Opaniuk <igor.opaniuk@linaro.org> wrote:
>
> Hi Simon,
>
> I've fixed failing test on sandbox_flattree by keeping all defined
> global variables in a driver-private data struct(as you suggested),
> which
> permits to probe multiple tee sandbox devices (sent v5, kept you R-b
> tag, please let me know if there are any objections from your side).
>
> But the way how dm test framework is invoked and why dm_root is simply
> re-allocated (and what happens with the previous one) is still an open
> question to me.
> If you can confirm that this a bug, I'll try to think about how this
> can be fixed.

I don't think it is a bug, actually.

When the dm_root goes away the devices go away too since they are
no-longer accessible. Of course someone might still have a pointer to
a device that was active before the root went away. But I don't think
we should worry about devices that are implemented with static data.
That is not how things are supposed to be implemented.

Regards,
Simon

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

end of thread, other threads:[~2019-02-14 16:24 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-27 14:34 [U-Boot] [PATCH v4 1/1] avb: add support for named persistent values Igor Opaniuk
2019-01-31 10:04 ` Simon Glass
2019-02-01 20:38   ` Igor Opaniuk
2019-02-02 15:00     ` Simon Glass
2019-02-09 12:50 ` [U-Boot] [U-Boot, v4, " Tom Rini
2019-02-11 14:59   ` Igor Opaniuk
2019-02-11 15:30     ` Tom Rini
2019-02-12 13:53       ` Igor Opaniuk
2019-02-12 15:31         ` Simon Glass
2019-02-13 15:38           ` Igor Opaniuk
2019-02-14 16:18             ` Igor Opaniuk
2019-02-14 16:24               ` Simon Glass
2019-02-14 16:23             ` Simon Glass

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