LinuxLists.cc - [PATCH v7 0/4] Replay Protected Memory Block (RPMB) subsystem

[permalink] [raw]

Subject: [PATCH v7 1/4] rpmb: add Replay Protected Memory Block (RPMB) subsystem

A number of storage technologies support a specialised hardware
partition designed to be resistant to replay attacks. The underlying
HW protocols differ but the operations are common. The RPMB partition
cannot be accessed via standard block layer, but by a set of specific
RPMB commands. Such a partition provides authenticated and replay
protected access, hence suitable as a secure storage.

The initial aim of this patch is to provide a simple RPMB driver
interface which can be accessed by the optee driver to facilitate early
RPMB access to OP-TEE OS (secure OS) during the boot time.

A TEE device driver can claim the RPMB interface, for example, via
rpmb_interface_register() or rpmb_dev_find_device(). The RPMB driver
provides a callback to route RPMB frames to the RPMB device accessible
via rpmb_route_frames().

The detailed operation of implementing the access is left to the TEE
device driver itself.

Signed-off-by: Tomas Winkler <[email protected]>
Signed-off-by: Alex Bennée <[email protected]>
Signed-off-by: Shyam Saini <[email protected]>
Signed-off-by: Jens Wiklander <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Tested-by: Manuel Traut <[email protected]>
---
MAINTAINERS | 7 ++
drivers/misc/Kconfig | 10 ++
drivers/misc/Makefile | 1 +
drivers/misc/rpmb-core.c | 233 +++++++++++++++++++++++++++++++++++++++
include/linux/rpmb.h | 136 +++++++++++++++++++++++
5 files changed, 387 insertions(+)
create mode 100644 drivers/misc/rpmb-core.c
create mode 100644 include/linux/rpmb.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 28e20975c26f..4c671827a08b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19163,6 +19163,13 @@ T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/allwinner,sun8i-a83t-de2-rotate.yaml
F: drivers/media/platform/sunxi/sun8i-rotate/

+RPMB SUBSYSTEM
+M: Jens Wiklander <[email protected]>
+L: [email protected]
+S: Supported
+F: drivers/misc/rpmb-core.c
+F: include/linux/rpmb.h
+
RPMSG TTY DRIVER
M: Arnaud Pouliquen <[email protected]>
L: [email protected]
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 4fb291f0bf7c..dbff9e8c3a03 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -104,6 +104,16 @@ config PHANTOM
If you choose to build module, its name will be phantom. If unsure,
say N here.

+config RPMB
+ tristate "RPMB partition interface"
+ depends on MMC
+ help
+ Unified RPMB unit interface for RPMB capable devices such as eMMC and
+ UFS. Provides interface for in-kernel security controllers to access
+ RPMB unit.
+
+ If unsure, select N.
+
config TIFM_CORE
tristate "TI Flash Media interface support"
depends on PCI
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index ea6ea5bbbc9c..8af058ad1df4 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_LKDTM) += lkdtm/
obj-$(CONFIG_TIFM_CORE) += tifm_core.o
obj-$(CONFIG_TIFM_7XX1) += tifm_7xx1.o
obj-$(CONFIG_PHANTOM) += phantom.o
+obj-$(CONFIG_RPMB) += rpmb-core.o
obj-$(CONFIG_QCOM_COINCELL) += qcom-coincell.o
obj-$(CONFIG_QCOM_FASTRPC) += fastrpc.o
obj-$(CONFIG_SENSORS_BH1770) += bh1770glc.o
diff --git a/drivers/misc/rpmb-core.c b/drivers/misc/rpmb-core.c
new file mode 100644
index 000000000000..e42a45debc76
--- /dev/null
+++ b/drivers/misc/rpmb-core.c
@@ -0,0 +1,233 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright(c) 2015 - 2019 Intel Corporation. All rights reserved.
+ * Copyright(c) 2021 - 2024 Linaro Ltd.
+ */
+#include <linux/device.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/list.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/rpmb.h>
+#include <linux/slab.h>
+
+static struct list_head rpmb_dev_list;
+static DEFINE_MUTEX(rpmb_mutex);
+static struct blocking_notifier_head rpmb_interface =
+ BLOCKING_NOTIFIER_INIT(rpmb_interface);
+
+/**
+ * rpmb_dev_get() - increase rpmb device ref counter
+ * @rdev: rpmb device
+ */
+struct rpmb_dev *rpmb_dev_get(struct rpmb_dev *rdev)
+{
+ if (rdev)
+ get_device(rdev->parent_dev);
+ return rdev;
+}
+EXPORT_SYMBOL_GPL(rpmb_dev_get);
+
+/**
+ * rpmb_dev_put() - decrease rpmb device ref counter
+ * @rdev: rpmb device
+ */
+void rpmb_dev_put(struct rpmb_dev *rdev)
+{
+ if (rdev)
+ put_device(rdev->parent_dev);
+}
+EXPORT_SYMBOL_GPL(rpmb_dev_put);
+
+/**
+ * rpmb_route_frames() - route rpmb frames to rpmb device
+ * @rdev: rpmb device
+ * @req: rpmb request frames
+ * @req_len: length of rpmb request frames in bytes
+ * @rsp: rpmb response frames
+ * @rsp_len: length of rpmb response frames in bytes
+ *
+ * Returns: < 0 on failure
+ */
+int rpmb_route_frames(struct rpmb_dev *rdev, u8 *req,
+ unsigned int req_len, u8 *rsp, unsigned int rsp_len)
+{
+ if (!req || !req_len || !rsp || !rsp_len)
+ return -EINVAL;
+
+ return rdev->descr.route_frames(rdev->parent_dev, req, req_len,
+ rsp, rsp_len);
+}
+EXPORT_SYMBOL_GPL(rpmb_route_frames);
+
+/**
+ * rpmb_dev_find_device() - return first matching rpmb device
+ * @data: data for the match function
+ * @match: the matching function
+ *
+ * Iterate over registered RPMB devices, and call @match() for each passing
+ * it the RPMB device and @data.
+ *
+ * The return value of @match() is checked for each call. If it returns
+ * anything other 0, break and return the found RPMB device.
+ *
+ * It's the callers responsibility to call rpmb_dev_put() on the returned
+ * device, when it's done with it.
+ *
+ * Returns: a matching rpmb device or NULL on failure
+ */
+struct rpmb_dev *rpmb_dev_find_device(const void *data,
+ const struct rpmb_dev *start,
+ int (*match)(struct rpmb_dev *rdev,
+ const void *data))
+{
+ struct rpmb_dev *rdev;
+ struct list_head *pos;
+
+ mutex_lock(&rpmb_mutex);
+ if (start)
+ pos = start->list_node.next;
+ else
+ pos = rpmb_dev_list.next;
+
+ while (pos != &rpmb_dev_list) {
+ rdev = container_of(pos, struct rpmb_dev, list_node);
+ if (match(rdev, data)) {
+ rpmb_dev_get(rdev);
+ goto out;
+ }
+ pos = pos->next;
+ }
+ rdev = NULL;
+
+out:
+ mutex_unlock(&rpmb_mutex);
+
+ return rdev;
+}
+EXPORT_SYMBOL_GPL(rpmb_dev_find_device);
+
+/**
+ * rpmb_dev_unregister() - unregister RPMB partition from the RPMB subsystem
+ * @rdev: the rpmb device to unregister
+ *
+ * This function should be called from the release function of the
+ * underlying device used when the RPMB device was registered.
+ *
+ * Returns: < 0 on failure
+ */
+int rpmb_dev_unregister(struct rpmb_dev *rdev)
+{
+ if (!rdev)
+ return -EINVAL;
+
+ mutex_lock(&rpmb_mutex);
+ list_del(&rdev->list_node);
+ mutex_unlock(&rpmb_mutex);
+ kfree(rdev->descr.dev_id);
+ kfree(rdev);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(rpmb_dev_unregister);
+
+/**
+ * rpmb_dev_register - register RPMB partition with the RPMB subsystem
+ * @dev: storage device of the rpmb device
+ * @ops: device specific operations
+ *
+ * While registering the RPMB partition extract needed device information
+ * while needed resources are available.
+ *
+ * Returns: a pointer to a 'struct rpmb_dev' or an ERR_PTR on failure
+ */
+struct rpmb_dev *rpmb_dev_register(struct device *dev,
+ struct rpmb_descr *descr)
+{
+ struct rpmb_dev *rdev;
+
+ if (!dev || !descr || !descr->route_frames || !descr->dev_id ||
+ !descr->dev_id_len)
+ return ERR_PTR(-EINVAL);
+
+ rdev = kzalloc(sizeof(*rdev), GFP_KERNEL);
+ if (!rdev)
+ return ERR_PTR(-ENOMEM);
+ rdev->descr = *descr;
+ rdev->descr.dev_id = kmemdup(descr->dev_id, descr->dev_id_len,
+ GFP_KERNEL);
+ if (!rdev->descr.dev_id) {
+ kfree(rdev);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ rdev->parent_dev = dev;
+
+ dev_dbg(rdev->parent_dev, "registered device\n");
+
+ mutex_lock(&rpmb_mutex);
+ list_add_tail(&rdev->list_node, &rpmb_dev_list);
+ blocking_notifier_call_chain(&rpmb_interface, RPMB_NOTIFY_ADD_DEVICE,
+ rdev);
+ mutex_unlock(&rpmb_mutex);
+
+ return rdev;
+}
+EXPORT_SYMBOL_GPL(rpmb_dev_register);
+
+/**
+ * rpmb_interface_register() - register for new device notifications
+ *
+ * @nb : New entry in notifier chain
+ *
+ * Returns: 0 on success -EEXIST on error.
+ */
+int rpmb_interface_register(struct notifier_block *nb)
+{
+ struct rpmb_dev *rdev;
+ int ret;
+
+ ret = blocking_notifier_chain_register(&rpmb_interface, nb);
+ if (ret)
+ return ret;
+
+ mutex_lock(&rpmb_mutex);
+ list_for_each_entry(rdev, &rpmb_dev_list, list_node)
+ nb->notifier_call(nb, RPMB_NOTIFY_ADD_DEVICE, rdev);
+ mutex_unlock(&rpmb_mutex);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(rpmb_interface_register);
+
+/**
+ * rpmb_interface_unregister() - unregister from new device notifications
+ *
+ * @nb : Entry to remove from notifier chain
+ *
+ * Returns: 0 on success or -ENOENT on failure.
+ */
+int rpmb_interface_unregister(struct notifier_block *nb)
+{
+ return blocking_notifier_chain_unregister(&rpmb_interface, nb);
+}
+EXPORT_SYMBOL_GPL(rpmb_interface_unregister);
+
+static int __init rpmb_init(void)
+{
+ INIT_LIST_HEAD(&rpmb_dev_list);
+ return 0;
+}
+
+static void __exit rpmb_exit(void)
+{
+ mutex_destroy(&rpmb_mutex);
+}
+
+subsys_initcall(rpmb_init);
+module_exit(rpmb_exit);
+
+MODULE_AUTHOR("Jens Wiklander <[email protected]>");
+MODULE_DESCRIPTION("RPMB class");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/rpmb.h b/include/linux/rpmb.h
new file mode 100644
index 000000000000..3ced206fdc17
--- /dev/null
+++ b/include/linux/rpmb.h
@@ -0,0 +1,136 @@
+/* SPDX-License-Identifier: BSD-3-Clause OR GPL-2.0 */
+/*
+ * Copyright (C) 2015-2019 Intel Corp. All rights reserved
+ * Copyright (C) 2021-2022 Linaro Ltd
+ */
+#ifndef __RPMB_H__
+#define __RPMB_H__
+
+#include <linux/types.h>
+#include <linux/device.h>
+#include <linux/notifier.h>
+
+/**
+ * enum rpmb_type - type of underlying storage technology
+ *
+ * @RPMB_TYPE_EMMC : emmc (JESD84-B50.1)
+ * @RPMB_TYPE_UFS : UFS (JESD220)
+ * @RPMB_TYPE_NVME : NVM Express
+ */
+enum rpmb_type {
+ RPMB_TYPE_EMMC,
+ RPMB_TYPE_UFS,
+ RPMB_TYPE_NVME,
+};
+
+/**
+ * struct rpmb_descr - RPMB description provided by the underlying block device
+ *
+ * @type : block device type
+ * @route_frames : routes frames to and from the RPMB device
+ * @dev_id : unique device identifier read from the hardware
+ * @dev_id_len : length of unique device identifier
+ * @reliable_wr_count: number of sectors that can be written in one access
+ * @capacity : capacity of the device in units of 128K
+ *
+ * @dev_id is intended to be used as input when deriving the authenticaion key.
+ */
+struct rpmb_descr {
+ enum rpmb_type type;
+ int (*route_frames)(struct device *dev, u8 *req, unsigned int req_len,
+ u8 *resp, unsigned int resp_len);
+ u8 *dev_id;
+ size_t dev_id_len;
+ u16 reliable_wr_count;
+ u16 capacity;
+};
+
+/**
+ * struct rpmb_dev - device which can support RPMB partition
+ *
+ * @parent_dev : parent device
+ * @list_node : linked list node
+ * @descr : RPMB description
+ */
+struct rpmb_dev {
+ struct device *parent_dev;
+ struct list_head list_node;
+ struct rpmb_descr descr;
+};
+
+enum rpmb_interface_action {
+ RPMB_NOTIFY_ADD_DEVICE,
+};
+
+/**
+ * struct rpmb_interface - subscribe to new RPMB devices
+ *
+ * @list_node : linked list node
+ * @add_rdev : notifies that a new RPMB device has been found
+ */
+struct rpmb_interface {
+ struct list_head list_node;
+ void (*add_rdev)(struct rpmb_interface *intf, struct rpmb_dev *rdev);
+};
+
+#if IS_ENABLED(CONFIG_RPMB)
+struct rpmb_dev *rpmb_dev_get(struct rpmb_dev *rdev);
+void rpmb_dev_put(struct rpmb_dev *rdev);
+struct rpmb_dev *rpmb_dev_find_device(const void *data,
+ const struct rpmb_dev *start,
+ int (*match)(struct rpmb_dev *rdev,
+ const void *data));
+struct rpmb_dev *rpmb_dev_register(struct device *dev,
+ struct rpmb_descr *descr);
+int rpmb_dev_unregister(struct rpmb_dev *rdev);
+
+int rpmb_route_frames(struct rpmb_dev *rdev, u8 *req,
+ unsigned int req_len, u8 *resp, unsigned int resp_len);
+
+int rpmb_interface_register(struct notifier_block *nb);
+int rpmb_interface_unregister(struct notifier_block *nb);
+#else
+static inline struct rpmb_dev *rpmb_dev_get(struct rpmb_dev *rdev)
+{
+ return NULL;
+}
+
+static inline void rpmb_dev_put(struct rpmb_dev *rdev) { }
+
+static inline struct rpmb_dev *
+rpmb_dev_find_device(const void *data, const struct rpmb_dev *start,
+ int (*match)(struct rpmb_dev *rdev, const void *data))
+{
+ return NULL;
+}
+
+static inline struct rpmb_dev *
+rpmb_dev_register(struct device *dev, const struct rpmb_ops *ops)
+{
+ return NULL;
+}
+
+static inline int rpmb_dev_unregister(struct rpmb_dev *dev)
+{
+ return 0;
+}
+
+static inline int rpmb_route_frames(struct rpmb_dev *rdev, u8 *req,
+ unsigned int req_len, u8 *resp,
+ unsigned int resp_len)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int rpmb_interface_register(struct notifier_block *nb)
+{
+ return -EOPNOTSUPP;
+}
+
+static inline int rpmb_interface_unregister(struct notifier_block *nb)
+{
+ return -EOPNOTSUPP;
+}
+#endif /* CONFIG_RPMB */
+
+#endif /* __RPMB_H__ */
--
2.34.1

2024-05-27 12:26:26

[permalink] [raw]

Subject: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
use an RPMB device via the RPMB subsystem instead of passing the RPMB
frames via tee-supplicant in user space. A fallback mechanism is kept to
route RPMB frames via tee-supplicant if the RPMB subsystem isn't
available.

The OP-TEE RPC ABI is extended to support iterating over all RPMB
devices until one is found with the expected RPMB key already
programmed.

Signed-off-by: Jens Wiklander <[email protected]>
Tested-by: Manuel Traut <[email protected]>
---
Documentation/ABI/testing/sysfs-class-tee | 15 ++
MAINTAINERS | 1 +
drivers/tee/optee/core.c | 96 +++++++++++-
drivers/tee/optee/device.c | 7 +
drivers/tee/optee/ffa_abi.c | 14 ++
drivers/tee/optee/optee_ffa.h | 2 +
drivers/tee/optee/optee_private.h | 26 +++-
drivers/tee/optee/optee_rpc_cmd.h | 35 +++++
drivers/tee/optee/optee_smc.h | 2 +
drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++
drivers/tee/optee/smc_abi.c | 14 ++
11 files changed, 387 insertions(+), 2 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-class-tee

diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee
new file mode 100644
index 000000000000..c9144d16003e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-tee
@@ -0,0 +1,15 @@
+What: /sys/class/tee/tee{,priv}X/rpmb_routing_model
+Date: May 2024
+KernelVersion: 6.10
+Contact: [email protected]
+Description:
+ RPMB frames can be routed to the RPMB device via the
+ user-space daemon tee-supplicant or the RPMB subsystem
+ in the kernel. The value "user" means that the driver
+ will route the RPMB frames via user space. Conversely,
+ "kernel" means that the frames are routed via the RPMB
+ subsystem without assistance from tee-supplicant. It
+ should be assumed that RPMB frames are routed via user
+ space if the variable is absent. The primary purpose
+ of this variable is to let systemd know whether
+ tee-supplicant is needed in the early boot with initramfs.
diff --git a/MAINTAINERS b/MAINTAINERS
index 4c671827a08b..0d0bc01fd3eb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21709,6 +21709,7 @@ M: Jens Wiklander <[email protected]>
R: Sumit Garg <[email protected]>
L: [email protected]
S: Maintained
+F: Documentation/ABI/testing/sysfs-class-tee
F: Documentation/driver-api/tee.rst
F: Documentation/tee/
F: Documentation/userspace-api/tee.rst
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 3aed554bc8d8..3194c071a175 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -11,12 +11,28 @@
#include <linux/io.h>
#include <linux/mm.h>
#include <linux/module.h>
+#include <linux/rpmb.h>
#include <linux/slab.h>
#include <linux/string.h>
#include <linux/tee_drv.h>
#include <linux/types.h>
#include "optee_private.h"

+struct blocking_notifier_head optee_rpmb_intf_added =
+ BLOCKING_NOTIFIER_INIT(optee_rpmb_intf_added);
+
+static int rpmb_add_dev(struct device *dev)
+{
+ blocking_notifier_call_chain(&optee_rpmb_intf_added, 0,
+ to_rpmb_dev(dev));
+
+ return 0;
+}
+
+static struct class_interface rpmb_class_intf = {
+ .add_dev = rpmb_add_dev,
+};
+
int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
size_t size, size_t align,
int (*shm_register)(struct tee_context *ctx,
@@ -80,11 +96,63 @@ void optee_pool_op_free_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
shm->pages = NULL;
}

+void optee_bus_scan_rpmb(struct work_struct *work)
+{
+ struct optee *optee = container_of(work, struct optee,
+ rpmb_scan_bus_work);
+ int ret;
+
+ if (!optee->rpmb_scan_bus_done) {
+ ret = optee_enumerate_devices(PTA_CMD_GET_DEVICES_RPMB);
+ optee->rpmb_scan_bus_done = !ret;
+ if (ret && ret != -ENODEV)
+ pr_info("Scanning for RPMB device: ret %d\n", ret);
+ }
+}
+
+int optee_rpmb_intf_rdev(struct notifier_block *intf, unsigned long action,
+ void *data)
+{
+ struct optee *optee = container_of(intf, struct optee, rpmb_intf);
+
+ schedule_work(&optee->rpmb_scan_bus_work);
+
+ return 0;
+}
+
static void optee_bus_scan(struct work_struct *work)
{
WARN_ON(optee_enumerate_devices(PTA_CMD_GET_DEVICES_SUPP));
}

+static ssize_t rpmb_routing_model_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct optee *optee = dev_get_drvdata(dev);
+ const char *s;
+
+ if (optee->in_kernel_rpmb_routing)
+ s = "kernel";
+ else
+ s = "user";
+
+ return scnprintf(buf, PAGE_SIZE, "%s\n", s);
+}
+static DEVICE_ATTR_RO(rpmb_routing_model);
+
+static struct attribute *optee_dev_attrs[] = {
+ &dev_attr_rpmb_routing_model.attr,
+ NULL
+};
+
+ATTRIBUTE_GROUPS(optee_dev);
+
+void optee_set_dev_group(struct optee *optee)
+{
+ tee_device_set_dev_groups(optee->teedev, optee_dev_groups);
+ tee_device_set_dev_groups(optee->supp_teedev, optee_dev_groups);
+}
+
int optee_open(struct tee_context *ctx, bool cap_memref_null)
{
struct optee_context_data *ctxdata;
@@ -161,6 +229,9 @@ void optee_release_supp(struct tee_context *ctx)

void optee_remove_common(struct optee *optee)
{
+ blocking_notifier_chain_unregister(&optee_rpmb_intf_added,
+ &optee->rpmb_intf);
+ cancel_work_sync(&optee->rpmb_scan_bus_work);
/* Unregister OP-TEE specific client devices on TEE bus */
optee_unregister_devices();

@@ -177,13 +248,18 @@ void optee_remove_common(struct optee *optee)
tee_shm_pool_free(optee->pool);
optee_supp_uninit(&optee->supp);
mutex_destroy(&optee->call_queue.mutex);
+ rpmb_dev_put(optee->rpmb_dev);
+ mutex_destroy(&optee->rpmb_dev_mutex);
}

static int smc_abi_rc;
static int ffa_abi_rc;
+static bool intf_is_regged;

static int __init optee_core_init(void)
{
+ int rc;
+
/*
* The kernel may have crashed at the same time that all available
* secure world threads were suspended and we cannot reschedule the
@@ -194,18 +270,36 @@ static int __init optee_core_init(void)
if (is_kdump_kernel())
return -ENODEV;

+ if (IS_ENABLED(CONFIG_RPMB)) {
+ rc = rpmb_interface_register(&rpmb_class_intf);
+ if (rc)
+ return rc;
+ intf_is_regged = true;
+ }
+
smc_abi_rc = optee_smc_abi_register();
ffa_abi_rc = optee_ffa_abi_register();

/* If both failed there's no point with this module */
- if (smc_abi_rc && ffa_abi_rc)
+ if (smc_abi_rc && ffa_abi_rc) {
+ if (IS_ENABLED(CONFIG_RPMB)) {
+ rpmb_interface_unregister(&rpmb_class_intf);
+ intf_is_regged = false;
+ }
return smc_abi_rc;
+ }
+
return 0;
}
module_init(optee_core_init);

static void __exit optee_core_exit(void)
{
+ if (IS_ENABLED(CONFIG_RPMB) && intf_is_regged) {
+ rpmb_interface_unregister(&rpmb_class_intf);
+ intf_is_regged = false;
+ }
+
if (!smc_abi_rc)
optee_smc_abi_unregister();
if (!ffa_abi_rc)
diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c
index 1892e49a8e6a..ff26850f704f 100644
--- a/drivers/tee/optee/device.c
+++ b/drivers/tee/optee/device.c
@@ -43,6 +43,13 @@ static int get_devices(struct tee_context *ctx, u32 session,
ret = tee_client_invoke_func(ctx, &inv_arg, param);
if ((ret < 0) || ((inv_arg.ret != TEEC_SUCCESS) &&
(inv_arg.ret != TEEC_ERROR_SHORT_BUFFER))) {
+ /*
+ * TEE_ERROR_STORAGE_NOT_AVAILABLE is returned when getting
+ * the list of device TAs that depends on RPMB but a usable
+ * RPMB device isn't found.
+ */
+ if (inv_arg.ret == TEE_ERROR_STORAGE_NOT_AVAILABLE)
+ return -ENODEV;
pr_err("PTA_CMD_GET_DEVICES invoke function err: %x\n",
inv_arg.ret);
return -EINVAL;
diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c
index ecb5eb079408..b3b87e49f7fb 100644
--- a/drivers/tee/optee/ffa_abi.c
+++ b/drivers/tee/optee/ffa_abi.c
@@ -7,6 +7,7 @@

#include <linux/arm_ffa.h>
#include <linux/errno.h>
+#include <linux/rpmb.h>
#include <linux/scatterlist.h>
#include <linux/sched.h>
#include <linux/slab.h>
@@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
optee->ffa.bottom_half_value = U32_MAX;
optee->rpc_param_count = rpc_param_count;

+ if (IS_REACHABLE(CONFIG_RPMB) &&
+ (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE))
+ optee->in_kernel_rpmb_routing = true;
+
teedev = tee_device_alloc(&optee_ffa_clnt_desc, NULL, optee->pool,
optee);
if (IS_ERR(teedev)) {
@@ -919,6 +924,8 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
}
optee->supp_teedev = teedev;

+ optee_set_dev_group(optee);
+
rc = tee_device_register(optee->teedev);
if (rc)
goto err_unreg_supp_teedev;
@@ -934,6 +941,7 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
optee_cq_init(&optee->call_queue, 0);
optee_supp_init(&optee->supp);
optee_shm_arg_cache_init(optee, arg_cache_flags);
+ mutex_init(&optee->rpmb_dev_mutex);
ffa_dev_set_drvdata(ffa_dev, optee);
ctx = teedev_open(optee->teedev);
if (IS_ERR(ctx)) {
@@ -955,6 +963,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
if (rc)
goto err_unregister_devices;

+ INIT_WORK(&optee->rpmb_scan_bus_work, optee_bus_scan_rpmb);
+ optee->rpmb_intf.notifier_call = optee_rpmb_intf_rdev;
+ blocking_notifier_chain_register(&optee_rpmb_intf_added,
+ &optee->rpmb_intf);
pr_info("initialized driver\n");
return 0;

@@ -968,6 +980,8 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
teedev_close_context(ctx);
err_rhashtable_free:
rhashtable_free_and_destroy(&optee->ffa.global_ids, rh_free_fn, NULL);
+ rpmb_dev_put(optee->rpmb_dev);
+ mutex_destroy(&optee->rpmb_dev_mutex);
optee_supp_uninit(&optee->supp);
mutex_destroy(&optee->call_queue.mutex);
mutex_destroy(&optee->ffa.mutex);
diff --git a/drivers/tee/optee/optee_ffa.h b/drivers/tee/optee/optee_ffa.h
index 5db779dc00de..257735ae5b56 100644
--- a/drivers/tee/optee/optee_ffa.h
+++ b/drivers/tee/optee/optee_ffa.h
@@ -92,6 +92,8 @@
#define OPTEE_FFA_SEC_CAP_ARG_OFFSET BIT(0)
/* OP-TEE supports asynchronous notification via FF-A */
#define OPTEE_FFA_SEC_CAP_ASYNC_NOTIF BIT(1)
+/* OP-TEE supports probing for RPMB device if needed */
+#define OPTEE_FFA_SEC_CAP_RPMB_PROBE BIT(2)

#define OPTEE_FFA_EXCHANGE_CAPABILITIES OPTEE_FFA_BLOCKING_CALL(2)

diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h
index 7a5243c78b55..1a41d4736bf8 100644
--- a/drivers/tee/optee/optee_private.h
+++ b/drivers/tee/optee/optee_private.h
@@ -7,7 +7,9 @@
#define OPTEE_PRIVATE_H

#include <linux/arm-smccc.h>
+#include <linux/notifier.h>
#include <linux/rhashtable.h>
+#include <linux/rpmb.h>
#include <linux/semaphore.h>
#include <linux/tee_drv.h>
#include <linux/types.h>
@@ -20,11 +22,13 @@
/* Some Global Platform error codes used in this driver */
#define TEEC_SUCCESS 0x00000000
#define TEEC_ERROR_BAD_PARAMETERS 0xFFFF0006
+#define TEEC_ERROR_ITEM_NOT_FOUND 0xFFFF0008
#define TEEC_ERROR_NOT_SUPPORTED 0xFFFF000A
#define TEEC_ERROR_COMMUNICATION 0xFFFF000E
#define TEEC_ERROR_OUT_OF_MEMORY 0xFFFF000C
#define TEEC_ERROR_BUSY 0xFFFF000D
#define TEEC_ERROR_SHORT_BUFFER 0xFFFF0010
+#define TEE_ERROR_STORAGE_NOT_AVAILABLE 0xF0100003

#define TEEC_ORIGIN_COMMS 0x00000002

@@ -197,6 +201,12 @@ struct optee_ops {
* @notif: notification synchronization struct
* @supp: supplicant synchronization struct for RPC to supplicant
* @pool: shared memory pool
+ * @mutex: mutex protecting @rpmb_dev
+ * @rpmb_dev: current RPMB device or NULL
+ * @rpmb_scan_bus_done flag if device registation of RPMB dependent devices
+ * was already done
+ * @rpmb_scan_bus_work workq to for an RPMB device and to scan optee bus
+ * and register RPMB dependent optee drivers
* @rpc_param_count: If > 0 number of RPC parameters to make room for
* @scan_bus_done flag if device registation was already done.
* @scan_bus_work workq to scan optee bus and register optee drivers
@@ -215,9 +225,16 @@ struct optee {
struct optee_notif notif;
struct optee_supp supp;
struct tee_shm_pool *pool;
+ /* Protects rpmb_dev pointer */
+ struct mutex rpmb_dev_mutex;
+ struct rpmb_dev *rpmb_dev;
+ struct notifier_block rpmb_intf;
unsigned int rpc_param_count;
- bool scan_bus_done;
+ bool scan_bus_done;
+ bool rpmb_scan_bus_done;
+ bool in_kernel_rpmb_routing;
struct work_struct scan_bus_work;
+ struct work_struct rpmb_scan_bus_work;
};

struct optee_session {
@@ -250,6 +267,8 @@ struct optee_call_ctx {
size_t num_entries;
};

+extern struct blocking_notifier_head optee_rpmb_intf_added;
+
int optee_notif_init(struct optee *optee, u_int max_key);
void optee_notif_uninit(struct optee *optee);
int optee_notif_wait(struct optee *optee, u_int key);
@@ -280,8 +299,12 @@ int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session);

#define PTA_CMD_GET_DEVICES 0x0
#define PTA_CMD_GET_DEVICES_SUPP 0x1
+#define PTA_CMD_GET_DEVICES_RPMB 0x2
int optee_enumerate_devices(u32 func);
void optee_unregister_devices(void);
+void optee_bus_scan_rpmb(struct work_struct *work);
+int optee_rpmb_intf_rdev(struct notifier_block *intf, unsigned long action,
+ void *data);

int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
size_t size, size_t align,
@@ -295,6 +318,7 @@ void optee_pool_op_free_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
struct tee_shm *shm));

+void optee_set_dev_group(struct optee *optee);
void optee_remove_common(struct optee *optee);
int optee_open(struct tee_context *ctx, bool cap_memref_null);
void optee_release(struct tee_context *ctx);
diff --git a/drivers/tee/optee/optee_rpc_cmd.h b/drivers/tee/optee/optee_rpc_cmd.h
index f3f06e0994a7..4a3c02914f9c 100644
--- a/drivers/tee/optee/optee_rpc_cmd.h
+++ b/drivers/tee/optee/optee_rpc_cmd.h
@@ -103,4 +103,39 @@
/* I2C master control flags */
#define OPTEE_RPC_I2C_FLAGS_TEN_BIT BIT(0)

+/*
+ * Reset RPMB probing
+ *
+ * Releases an eventually already used RPMB devices and starts over searching
+ * for RPMB devices. Returns the kind of shared memory to use in subsequent
+ * OPTEE_RPC_CMD_RPMB_PROBE_NEXT and OPTEE_RPC_CMD_RPMB calls.
+ *
+ * [out] value[0].a OPTEE_RPC_SHM_TYPE_*, the parameter for
+ * OPTEE_RPC_CMD_SHM_ALLOC
+ */
+#define OPTEE_RPC_CMD_RPMB_PROBE_RESET 22
+
+/*
+ * Probe next RPMB device
+ *
+ * [out] value[0].a Type of RPMB device, OPTEE_RPC_RPMB_*
+ * [out] value[0].b EXT CSD-slice 168 "RPMB Size"
+ * [out] value[0].c EXT CSD-slice 222 "Reliable Write Sector Count"
+ * [out] memref[1] Buffer with the raw CID
+ */
+#define OPTEE_RPC_CMD_RPMB_PROBE_NEXT 23
+
+/* Type of RPMB device */
+#define OPTEE_RPC_RPMB_EMMC 0
+#define OPTEE_RPC_RPMB_UFS 1
+#define OPTEE_RPC_RPMB_NVME 2
+
+/*
+ * Replay Protected Memory Block access
+ *
+ * [in] memref[0] Frames to device
+ * [out] memref[1] Frames from device
+ */
+#define OPTEE_RPC_CMD_RPMB_FRAMES 24
+
#endif /*__OPTEE_RPC_CMD_H*/
diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h
index 7d9fa426505b..879426300821 100644
--- a/drivers/tee/optee/optee_smc.h
+++ b/drivers/tee/optee/optee_smc.h
@@ -278,6 +278,8 @@ struct optee_smc_get_shm_config_result {
#define OPTEE_SMC_SEC_CAP_ASYNC_NOTIF BIT(5)
/* Secure world supports pre-allocating RPC arg struct */
#define OPTEE_SMC_SEC_CAP_RPC_ARG BIT(6)
+/* Secure world supports probing for RPMB device if needed */
+#define OPTEE_SMC_SEC_CAP_RPMB_PROBE BIT(7)

#define OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES 9
#define OPTEE_SMC_EXCHANGE_CAPABILITIES \
diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
index e69bc6380683..cf6a4b97549c 100644
--- a/drivers/tee/optee/rpc.c
+++ b/drivers/tee/optee/rpc.c
@@ -7,6 +7,7 @@

#include <linux/delay.h>
#include <linux/i2c.h>
+#include <linux/rpmb.h>
#include <linux/slab.h>
#include <linux/tee_drv.h>
#include "optee_private.h"
@@ -255,6 +256,154 @@ void optee_rpc_cmd_free_suppl(struct tee_context *ctx, struct tee_shm *shm)
optee_supp_thrd_req(ctx, OPTEE_RPC_CMD_SHM_FREE, 1, &param);
}

+static void handle_rpc_func_rpmb_probe_reset(struct tee_context *ctx,
+ struct optee *optee,
+ struct optee_msg_arg *arg)
+{
+ struct tee_param params[1];
+
+ if (arg->num_params != ARRAY_SIZE(params) ||
+ optee->ops->from_msg_param(optee, params, arg->num_params,
+ arg->params) ||
+ params[0].attr != TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT) {
+ arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+ return;
+ }
+
+ params[0].u.value.a = OPTEE_RPC_SHM_TYPE_KERNEL;
+ params[0].u.value.b = 0;
+ params[0].u.value.c = 0;
+ if (optee->ops->to_msg_param(optee, arg->params,
+ arg->num_params, params)) {
+ arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+ return;
+ }
+
+ mutex_lock(&optee->rpmb_dev_mutex);
+ rpmb_dev_put(optee->rpmb_dev);
+ optee->rpmb_dev = NULL;
+ mutex_unlock(&optee->rpmb_dev_mutex);
+
+ arg->ret = TEEC_SUCCESS;
+}
+
+static int rpmb_type_to_rpc_type(enum rpmb_type rtype)
+{
+ switch (rtype) {
+ case RPMB_TYPE_EMMC:
+ return OPTEE_RPC_RPMB_EMMC;
+ case RPMB_TYPE_UFS:
+ return OPTEE_RPC_RPMB_UFS;
+ case RPMB_TYPE_NVME:
+ return OPTEE_RPC_RPMB_NVME;
+ default:
+ return -1;
+ }
+}
+
+static int rpc_rpmb_match(struct device *dev, const void *data)
+{
+ struct rpmb_dev *rdev = to_rpmb_dev(dev);
+
+ return rpmb_type_to_rpc_type(rdev->descr.type) >= 0;
+}
+
+static void handle_rpc_func_rpmb_probe_next(struct tee_context *ctx,
+ struct optee *optee,
+ struct optee_msg_arg *arg)
+{
+ struct rpmb_dev *rdev;
+ struct tee_param params[2];
+ void *buf;
+
+ if (arg->num_params != ARRAY_SIZE(params) ||
+ optee->ops->from_msg_param(optee, params, arg->num_params,
+ arg->params) ||
+ params[0].attr != TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT ||
+ params[1].attr != TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT) {
+ arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+ return;
+ }
+ buf = tee_shm_get_va(params[1].u.memref.shm,
+ params[1].u.memref.shm_offs);
+ if (!buf) {
+ arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+ return;
+ }
+
+ mutex_lock(&optee->rpmb_dev_mutex);
+ rdev = rpmb_dev_find_device(NULL, optee->rpmb_dev, rpc_rpmb_match);
+ rpmb_dev_put(optee->rpmb_dev);
+ optee->rpmb_dev = rdev;
+ mutex_unlock(&optee->rpmb_dev_mutex);
+
+ if (!rdev) {
+ arg->ret = TEEC_ERROR_ITEM_NOT_FOUND;
+ return;
+ }
+
+ if (params[1].u.memref.size < rdev->descr.dev_id_len) {
+ arg->ret = TEEC_ERROR_SHORT_BUFFER;
+ return;
+ }
+ memcpy(buf, rdev->descr.dev_id, rdev->descr.dev_id_len);
+ params[1].u.memref.size = rdev->descr.dev_id_len;
+ params[0].u.value.a = rpmb_type_to_rpc_type(rdev->descr.type);
+ params[0].u.value.b = rdev->descr.capacity;
+ params[0].u.value.c = rdev->descr.reliable_wr_count;
+ if (optee->ops->to_msg_param(optee, arg->params,
+ arg->num_params, params)) {
+ arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+ return;
+ }
+
+ arg->ret = TEEC_SUCCESS;
+}
+
+static void handle_rpc_func_rpmb_frames(struct tee_context *ctx,
+ struct optee *optee,
+ struct optee_msg_arg *arg)
+{
+ struct tee_param params[2];
+ struct rpmb_dev *rdev;
+ void *p0, *p1;
+
+ mutex_lock(&optee->rpmb_dev_mutex);
+ rdev = rpmb_dev_get(optee->rpmb_dev);
+ mutex_unlock(&optee->rpmb_dev_mutex);
+ if (!rdev) {
+ arg->ret = TEEC_ERROR_ITEM_NOT_FOUND;
+ return;
+ }
+
+ if (arg->num_params != ARRAY_SIZE(params) ||
+ optee->ops->from_msg_param(optee, params, arg->num_params,
+ arg->params) ||
+ params[0].attr != TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT ||
+ params[1].attr != TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT) {
+ arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+ goto out;
+ }
+
+ p0 = tee_shm_get_va(params[0].u.memref.shm,
+ params[0].u.memref.shm_offs);
+ p1 = tee_shm_get_va(params[1].u.memref.shm,
+ params[1].u.memref.shm_offs);
+ if (rpmb_route_frames(rdev, p0, params[0].u.memref.size, p1,
+ params[1].u.memref.size)) {
+ arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+ goto out;
+ }
+ if (optee->ops->to_msg_param(optee, arg->params,
+ arg->num_params, params)) {
+ arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+ goto out;
+ }
+ arg->ret = TEEC_SUCCESS;
+out:
+ rpmb_dev_put(rdev);
+}
+
void optee_rpc_cmd(struct tee_context *ctx, struct optee *optee,
struct optee_msg_arg *arg)
{
@@ -271,6 +420,34 @@ void optee_rpc_cmd(struct tee_context *ctx, struct optee *optee,
case OPTEE_RPC_CMD_I2C_TRANSFER:
handle_rpc_func_cmd_i2c_transfer(ctx, arg);
break;
+ /*
+ * optee->in_kernel_rpmb_routing true means that OP-TEE supports
+ * in-kernel RPMB routing _and_ that the RPMB subsystem is
+ * reachable. This is reported to user space with
+ * rpmb_routing_model=kernel in sysfs.
+ *
+ * rpmb_routing_model=kernel is also a promise to user space that
+ * RPMB access will not require supplicant support, hence the
+ * checks below.
+ */
+ case OPTEE_RPC_CMD_RPMB_PROBE_RESET:
+ if (optee->in_kernel_rpmb_routing)
+ handle_rpc_func_rpmb_probe_reset(ctx, optee, arg);
+ else
+ handle_rpc_supp_cmd(ctx, optee, arg);
+ break;
+ case OPTEE_RPC_CMD_RPMB_PROBE_NEXT:
+ if (optee->in_kernel_rpmb_routing)
+ handle_rpc_func_rpmb_probe_next(ctx, optee, arg);
+ else
+ handle_rpc_supp_cmd(ctx, optee, arg);
+ break;
+ case OPTEE_RPC_CMD_RPMB_FRAMES:
+ if (optee->in_kernel_rpmb_routing)
+ handle_rpc_func_rpmb_frames(ctx, optee, arg);
+ else
+ handle_rpc_supp_cmd(ctx, optee, arg);
+ break;
default:
handle_rpc_supp_cmd(ctx, optee, arg);
}
diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c
index a37f87087e5c..fd689dfb5697 100644
--- a/drivers/tee/optee/smc_abi.c
+++ b/drivers/tee/optee/smc_abi.c
@@ -20,6 +20,7 @@
#include <linux/of_irq.h>
#include <linux/of_platform.h>
#include <linux/platform_device.h>
+#include <linux/rpmb.h>
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/string.h>
@@ -1688,6 +1689,10 @@ static int optee_probe(struct platform_device *pdev)
optee->smc.sec_caps = sec_caps;
optee->rpc_param_count = rpc_param_count;

+ if (IS_REACHABLE(CONFIG_RPMB) &&
+ (sec_caps & OPTEE_SMC_SEC_CAP_RPMB_PROBE))
+ optee->in_kernel_rpmb_routing = true;
+
teedev = tee_device_alloc(&optee_clnt_desc, NULL, pool, optee);
if (IS_ERR(teedev)) {
rc = PTR_ERR(teedev);
@@ -1702,6 +1707,8 @@ static int optee_probe(struct platform_device *pdev)
}
optee->supp_teedev = teedev;

+ optee_set_dev_group(optee);
+
rc = tee_device_register(optee->teedev);
if (rc)
goto err_unreg_supp_teedev;
@@ -1715,6 +1722,7 @@ static int optee_probe(struct platform_device *pdev)
optee->smc.memremaped_shm = memremaped_shm;
optee->pool = pool;
optee_shm_arg_cache_init(optee, arg_cache_flags);
+ mutex_init(&optee->rpmb_dev_mutex);

platform_set_drvdata(pdev, optee);
ctx = teedev_open(optee->teedev);
@@ -1769,6 +1777,10 @@ static int optee_probe(struct platform_device *pdev)
if (rc)
goto err_disable_shm_cache;

+ INIT_WORK(&optee->rpmb_scan_bus_work, optee_bus_scan_rpmb);
+ optee->rpmb_intf.notifier_call = optee_rpmb_intf_rdev;
+ blocking_notifier_chain_register(&optee_rpmb_intf_added,
+ &optee->rpmb_intf);
pr_info("initialized driver\n");
return 0;

@@ -1782,6 +1794,8 @@ static int optee_probe(struct platform_device *pdev)
err_close_ctx:
teedev_close_context(ctx);
err_supp_uninit:
+ rpmb_dev_put(optee->rpmb_dev);
+ mutex_destroy(&optee->rpmb_dev_mutex);
optee_shm_arg_cache_uninit(optee);
optee_supp_uninit(&optee->supp);
mutex_destroy(&optee->call_queue.mutex);
--
2.34.1

2024-05-27 13:05:41

by Jerome Forissier

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

On 5/27/24 14:13, Jens Wiklander wrote:
> Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
> use an RPMB device via the RPMB subsystem instead of passing the RPMB
> frames via tee-supplicant in user space. A fallback mechanism is kept to
> route RPMB frames via tee-supplicant if the RPMB subsystem isn't
> available.
>
> The OP-TEE RPC ABI is extended to support iterating over all RPMB
> devices until one is found with the expected RPMB key already
> programmed.
>
> Signed-off-by: Jens Wiklander <[email protected]>
> Tested-by: Manuel Traut <[email protected]>
> ---
> Documentation/ABI/testing/sysfs-class-tee | 15 ++
> MAINTAINERS | 1 +
> drivers/tee/optee/core.c | 96 +++++++++++-
> drivers/tee/optee/device.c | 7 +
> drivers/tee/optee/ffa_abi.c | 14 ++
> drivers/tee/optee/optee_ffa.h | 2 +
> drivers/tee/optee/optee_private.h | 26 +++-
> drivers/tee/optee/optee_rpc_cmd.h | 35 +++++
> drivers/tee/optee/optee_smc.h | 2 +
> drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++
> drivers/tee/optee/smc_abi.c | 14 ++
> 11 files changed, 387 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-class-tee
>
> diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee
> new file mode 100644
> index 000000000000..c9144d16003e
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-tee
> @@ -0,0 +1,15 @@
> +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model

Wouldn't /sys/class/tee/teeX/rpmb_routing_model be good enough?

Thanks,
--
Jerome

2024-05-27 13:24:42

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

On Mon, May 27, 2024 at 3:00 PM Jerome Forissier
<[email protected]> wrote:
>
> On 5/27/24 14:13, Jens Wiklander wrote:
> > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
> > use an RPMB device via the RPMB subsystem instead of passing the RPMB
> > frames via tee-supplicant in user space. A fallback mechanism is kept to
> > route RPMB frames via tee-supplicant if the RPMB subsystem isn't
> > available.
> >
> > The OP-TEE RPC ABI is extended to support iterating over all RPMB
> > devices until one is found with the expected RPMB key already
> > programmed.
> >
> > Signed-off-by: Jens Wiklander <[email protected]>
> > Tested-by: Manuel Traut <[email protected]>
> > ---
> > Documentation/ABI/testing/sysfs-class-tee | 15 ++
> > MAINTAINERS | 1 +
> > drivers/tee/optee/core.c | 96 +++++++++++-
> > drivers/tee/optee/device.c | 7 +
> > drivers/tee/optee/ffa_abi.c | 14 ++
> > drivers/tee/optee/optee_ffa.h | 2 +
> > drivers/tee/optee/optee_private.h | 26 +++-
> > drivers/tee/optee/optee_rpc_cmd.h | 35 +++++
> > drivers/tee/optee/optee_smc.h | 2 +
> > drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++
> > drivers/tee/optee/smc_abi.c | 14 ++
> > 11 files changed, 387 insertions(+), 2 deletions(-)
> > create mode 100644 Documentation/ABI/testing/sysfs-class-tee
> >
> > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee
> > new file mode 100644
> > index 000000000000..c9144d16003e
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-class-tee
> > @@ -0,0 +1,15 @@
> > +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model
>
> Wouldn't /sys/class/tee/teeX/rpmb_routing_model be good enough?

Doesn't the routing model concern tee-supplicant more than a TEE
client? Then it might make more sense to have
/sys/class/tee/teeprivX/rpmb_routing_model only. Keeping it for both
devices representing the same internal struct optee makes it easier to
find. Anyway, I don't mind removing one. Mikko, what do you prefer?

Cheers,
Jens

2024-05-27 15:13:08

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

On Mon, 27 May 2024 at 17:44, Jens Wiklander <[email protected]> wrote:
>
> Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
> use an RPMB device via the RPMB subsystem instead of passing the RPMB
> frames via tee-supplicant in user space. A fallback mechanism is kept to
> route RPMB frames via tee-supplicant if the RPMB subsystem isn't
> available.
>
> The OP-TEE RPC ABI is extended to support iterating over all RPMB
> devices until one is found with the expected RPMB key already
> programmed.
>
> Signed-off-by: Jens Wiklander <[email protected]>
> Tested-by: Manuel Traut <[email protected]>
> ---
> Documentation/ABI/testing/sysfs-class-tee | 15 ++
> MAINTAINERS | 1 +
> drivers/tee/optee/core.c | 96 +++++++++++-
> drivers/tee/optee/device.c | 7 +
> drivers/tee/optee/ffa_abi.c | 14 ++
> drivers/tee/optee/optee_ffa.h | 2 +
> drivers/tee/optee/optee_private.h | 26 +++-
> drivers/tee/optee/optee_rpc_cmd.h | 35 +++++
> drivers/tee/optee/optee_smc.h | 2 +
> drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++
> drivers/tee/optee/smc_abi.c | 14 ++
> 11 files changed, 387 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-class-tee
>
> diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee
> new file mode 100644
> index 000000000000..c9144d16003e
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-class-tee
> @@ -0,0 +1,15 @@
> +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model
> +Date: May 2024
> +KernelVersion: 6.10
> +Contact: [email protected]
> +Description:
> + RPMB frames can be routed to the RPMB device via the
> + user-space daemon tee-supplicant or the RPMB subsystem
> + in the kernel. The value "user" means that the driver
> + will route the RPMB frames via user space. Conversely,
> + "kernel" means that the frames are routed via the RPMB
> + subsystem without assistance from tee-supplicant. It
> + should be assumed that RPMB frames are routed via user
> + space if the variable is absent. The primary purpose
> + of this variable is to let systemd know whether
> + tee-supplicant is needed in the early boot with initramfs.

Why do we need this if we already have [1] [2]? AFAICS, whichever
devices like fTPM etc. systemd depends upon, it can be easily known
via existing sysfs property.

[1] https://docs.kernel.org/admin-guide/abi-testing.html?highlight=optee#abi-sys-bus-tee-devices-optee-ta-uuid-need-supplicant
[2] Documentation/ABI/testing/sysfs-bus-optee-devices

-Sumit

> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4c671827a08b..0d0bc01fd3eb 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -21709,6 +21709,7 @@ M: Jens Wiklander <[email protected]>
> R: Sumit Garg <[email protected]>
> L: [email protected]
> S: Maintained
> +F: Documentation/ABI/testing/sysfs-class-tee
> F: Documentation/driver-api/tee.rst
> F: Documentation/tee/
> F: Documentation/userspace-api/tee.rst
> diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
> index 3aed554bc8d8..3194c071a175 100644
> --- a/drivers/tee/optee/core.c
> +++ b/drivers/tee/optee/core.c
> @@ -11,12 +11,28 @@
> #include <linux/io.h>
> #include <linux/mm.h>
> #include <linux/module.h>
> +#include <linux/rpmb.h>
> #include <linux/slab.h>
> #include <linux/string.h>
> #include <linux/tee_drv.h>
> #include <linux/types.h>
> #include "optee_private.h"
>
> +struct blocking_notifier_head optee_rpmb_intf_added =
> + BLOCKING_NOTIFIER_INIT(optee_rpmb_intf_added);
> +
> +static int rpmb_add_dev(struct device *dev)
> +{
> + blocking_notifier_call_chain(&optee_rpmb_intf_added, 0,
> + to_rpmb_dev(dev));
> +
> + return 0;
> +}
> +
> +static struct class_interface rpmb_class_intf = {
> + .add_dev = rpmb_add_dev,
> +};
> +
> int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
> size_t size, size_t align,
> int (*shm_register)(struct tee_context *ctx,
> @@ -80,11 +96,63 @@ void optee_pool_op_free_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
> shm->pages = NULL;
> }
>
> +void optee_bus_scan_rpmb(struct work_struct *work)
> +{
> + struct optee *optee = container_of(work, struct optee,
> + rpmb_scan_bus_work);
> + int ret;
> +
> + if (!optee->rpmb_scan_bus_done) {
> + ret = optee_enumerate_devices(PTA_CMD_GET_DEVICES_RPMB);
> + optee->rpmb_scan_bus_done = !ret;
> + if (ret && ret != -ENODEV)
> + pr_info("Scanning for RPMB device: ret %d\n", ret);
> + }
> +}
> +
> +int optee_rpmb_intf_rdev(struct notifier_block *intf, unsigned long action,
> + void *data)
> +{
> + struct optee *optee = container_of(intf, struct optee, rpmb_intf);
> +
> + schedule_work(&optee->rpmb_scan_bus_work);
> +
> + return 0;
> +}
> +
> static void optee_bus_scan(struct work_struct *work)
> {
> WARN_ON(optee_enumerate_devices(PTA_CMD_GET_DEVICES_SUPP));
> }
>
> +static ssize_t rpmb_routing_model_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct optee *optee = dev_get_drvdata(dev);
> + const char *s;
> +
> + if (optee->in_kernel_rpmb_routing)
> + s = "kernel";
> + else
> + s = "user";
> +
> + return scnprintf(buf, PAGE_SIZE, "%s\n", s);
> +}
> +static DEVICE_ATTR_RO(rpmb_routing_model);
> +
> +static struct attribute *optee_dev_attrs[] = {
> + &dev_attr_rpmb_routing_model.attr,
> + NULL
> +};
> +
> +ATTRIBUTE_GROUPS(optee_dev);
> +
> +void optee_set_dev_group(struct optee *optee)
> +{
> + tee_device_set_dev_groups(optee->teedev, optee_dev_groups);
> + tee_device_set_dev_groups(optee->supp_teedev, optee_dev_groups);
> +}
> +
> int optee_open(struct tee_context *ctx, bool cap_memref_null)
> {
> struct optee_context_data *ctxdata;
> @@ -161,6 +229,9 @@ void optee_release_supp(struct tee_context *ctx)
>
> void optee_remove_common(struct optee *optee)
> {
> + blocking_notifier_chain_unregister(&optee_rpmb_intf_added,
> + &optee->rpmb_intf);
> + cancel_work_sync(&optee->rpmb_scan_bus_work);
> /* Unregister OP-TEE specific client devices on TEE bus */
> optee_unregister_devices();
>
> @@ -177,13 +248,18 @@ void optee_remove_common(struct optee *optee)
> tee_shm_pool_free(optee->pool);
> optee_supp_uninit(&optee->supp);
> mutex_destroy(&optee->call_queue.mutex);
> + rpmb_dev_put(optee->rpmb_dev);
> + mutex_destroy(&optee->rpmb_dev_mutex);
> }
>
> static int smc_abi_rc;
> static int ffa_abi_rc;
> +static bool intf_is_regged;
>
> static int __init optee_core_init(void)
> {
> + int rc;
> +
> /*
> * The kernel may have crashed at the same time that all available
> * secure world threads were suspended and we cannot reschedule the
> @@ -194,18 +270,36 @@ static int __init optee_core_init(void)
> if (is_kdump_kernel())
> return -ENODEV;
>
> + if (IS_ENABLED(CONFIG_RPMB)) {
> + rc = rpmb_interface_register(&rpmb_class_intf);
> + if (rc)
> + return rc;
> + intf_is_regged = true;
> + }
> +
> smc_abi_rc = optee_smc_abi_register();
> ffa_abi_rc = optee_ffa_abi_register();
>
> /* If both failed there's no point with this module */
> - if (smc_abi_rc && ffa_abi_rc)
> + if (smc_abi_rc && ffa_abi_rc) {
> + if (IS_ENABLED(CONFIG_RPMB)) {
> + rpmb_interface_unregister(&rpmb_class_intf);
> + intf_is_regged = false;
> + }
> return smc_abi_rc;
> + }
> +
> return 0;
> }
> module_init(optee_core_init);
>
> static void __exit optee_core_exit(void)
> {
> + if (IS_ENABLED(CONFIG_RPMB) && intf_is_regged) {
> + rpmb_interface_unregister(&rpmb_class_intf);
> + intf_is_regged = false;
> + }
> +
> if (!smc_abi_rc)
> optee_smc_abi_unregister();
> if (!ffa_abi_rc)
> diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c
> index 1892e49a8e6a..ff26850f704f 100644
> --- a/drivers/tee/optee/device.c
> +++ b/drivers/tee/optee/device.c
> @@ -43,6 +43,13 @@ static int get_devices(struct tee_context *ctx, u32 session,
> ret = tee_client_invoke_func(ctx, &inv_arg, param);
> if ((ret < 0) || ((inv_arg.ret != TEEC_SUCCESS) &&
> (inv_arg.ret != TEEC_ERROR_SHORT_BUFFER))) {
> + /*
> + * TEE_ERROR_STORAGE_NOT_AVAILABLE is returned when getting
> + * the list of device TAs that depends on RPMB but a usable
> + * RPMB device isn't found.
> + */
> + if (inv_arg.ret == TEE_ERROR_STORAGE_NOT_AVAILABLE)
> + return -ENODEV;
> pr_err("PTA_CMD_GET_DEVICES invoke function err: %x\n",
> inv_arg.ret);
> return -EINVAL;
> diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c
> index ecb5eb079408..b3b87e49f7fb 100644
> --- a/drivers/tee/optee/ffa_abi.c
> +++ b/drivers/tee/optee/ffa_abi.c
> @@ -7,6 +7,7 @@
>
> #include <linux/arm_ffa.h>
> #include <linux/errno.h>
> +#include <linux/rpmb.h>
> #include <linux/scatterlist.h>
> #include <linux/sched.h>
> #include <linux/slab.h>
> @@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
> optee->ffa.bottom_half_value = U32_MAX;
> optee->rpc_param_count = rpc_param_count;
>
> + if (IS_REACHABLE(CONFIG_RPMB) &&
> + (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE))
> + optee->in_kernel_rpmb_routing = true;
> +
> teedev = tee_device_alloc(&optee_ffa_clnt_desc, NULL, optee->pool,
> optee);
> if (IS_ERR(teedev)) {
> @@ -919,6 +924,8 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
> }
> optee->supp_teedev = teedev;
>
> + optee_set_dev_group(optee);
> +
> rc = tee_device_register(optee->teedev);
> if (rc)
> goto err_unreg_supp_teedev;
> @@ -934,6 +941,7 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
> optee_cq_init(&optee->call_queue, 0);
> optee_supp_init(&optee->supp);
> optee_shm_arg_cache_init(optee, arg_cache_flags);
> + mutex_init(&optee->rpmb_dev_mutex);
> ffa_dev_set_drvdata(ffa_dev, optee);
> ctx = teedev_open(optee->teedev);
> if (IS_ERR(ctx)) {
> @@ -955,6 +963,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
> if (rc)
> goto err_unregister_devices;
>
> + INIT_WORK(&optee->rpmb_scan_bus_work, optee_bus_scan_rpmb);
> + optee->rpmb_intf.notifier_call = optee_rpmb_intf_rdev;
> + blocking_notifier_chain_register(&optee_rpmb_intf_added,
> + &optee->rpmb_intf);
> pr_info("initialized driver\n");
> return 0;
>
> @@ -968,6 +980,8 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
> teedev_close_context(ctx);
> err_rhashtable_free:
> rhashtable_free_and_destroy(&optee->ffa.global_ids, rh_free_fn, NULL);
> + rpmb_dev_put(optee->rpmb_dev);
> + mutex_destroy(&optee->rpmb_dev_mutex);
> optee_supp_uninit(&optee->supp);
> mutex_destroy(&optee->call_queue.mutex);
> mutex_destroy(&optee->ffa.mutex);
> diff --git a/drivers/tee/optee/optee_ffa.h b/drivers/tee/optee/optee_ffa.h
> index 5db779dc00de..257735ae5b56 100644
> --- a/drivers/tee/optee/optee_ffa.h
> +++ b/drivers/tee/optee/optee_ffa.h
> @@ -92,6 +92,8 @@
> #define OPTEE_FFA_SEC_CAP_ARG_OFFSET BIT(0)
> /* OP-TEE supports asynchronous notification via FF-A */
> #define OPTEE_FFA_SEC_CAP_ASYNC_NOTIF BIT(1)
> +/* OP-TEE supports probing for RPMB device if needed */
> +#define OPTEE_FFA_SEC_CAP_RPMB_PROBE BIT(2)
>
> #define OPTEE_FFA_EXCHANGE_CAPABILITIES OPTEE_FFA_BLOCKING_CALL(2)
>
> diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h
> index 7a5243c78b55..1a41d4736bf8 100644
> --- a/drivers/tee/optee/optee_private.h
> +++ b/drivers/tee/optee/optee_private.h
> @@ -7,7 +7,9 @@
> #define OPTEE_PRIVATE_H
>
> #include <linux/arm-smccc.h>
> +#include <linux/notifier.h>
> #include <linux/rhashtable.h>
> +#include <linux/rpmb.h>
> #include <linux/semaphore.h>
> #include <linux/tee_drv.h>
> #include <linux/types.h>
> @@ -20,11 +22,13 @@
> /* Some Global Platform error codes used in this driver */
> #define TEEC_SUCCESS 0x00000000
> #define TEEC_ERROR_BAD_PARAMETERS 0xFFFF0006
> +#define TEEC_ERROR_ITEM_NOT_FOUND 0xFFFF0008
> #define TEEC_ERROR_NOT_SUPPORTED 0xFFFF000A
> #define TEEC_ERROR_COMMUNICATION 0xFFFF000E
> #define TEEC_ERROR_OUT_OF_MEMORY 0xFFFF000C
> #define TEEC_ERROR_BUSY 0xFFFF000D
> #define TEEC_ERROR_SHORT_BUFFER 0xFFFF0010
> +#define TEE_ERROR_STORAGE_NOT_AVAILABLE 0xF0100003
>
> #define TEEC_ORIGIN_COMMS 0x00000002
>
> @@ -197,6 +201,12 @@ struct optee_ops {
> * @notif: notification synchronization struct
> * @supp: supplicant synchronization struct for RPC to supplicant
> * @pool: shared memory pool
> + * @mutex: mutex protecting @rpmb_dev
> + * @rpmb_dev: current RPMB device or NULL
> + * @rpmb_scan_bus_done flag if device registation of RPMB dependent devices
> + * was already done
> + * @rpmb_scan_bus_work workq to for an RPMB device and to scan optee bus
> + * and register RPMB dependent optee drivers
> * @rpc_param_count: If > 0 number of RPC parameters to make room for
> * @scan_bus_done flag if device registation was already done.
> * @scan_bus_work workq to scan optee bus and register optee drivers
> @@ -215,9 +225,16 @@ struct optee {
> struct optee_notif notif;
> struct optee_supp supp;
> struct tee_shm_pool *pool;
> + /* Protects rpmb_dev pointer */
> + struct mutex rpmb_dev_mutex;
> + struct rpmb_dev *rpmb_dev;
> + struct notifier_block rpmb_intf;
> unsigned int rpc_param_count;
> - bool scan_bus_done;
> + bool scan_bus_done;
> + bool rpmb_scan_bus_done;
> + bool in_kernel_rpmb_routing;
> struct work_struct scan_bus_work;
> + struct work_struct rpmb_scan_bus_work;
> };
>
> struct optee_session {
> @@ -250,6 +267,8 @@ struct optee_call_ctx {
> size_t num_entries;
> };
>
> +extern struct blocking_notifier_head optee_rpmb_intf_added;
> +
> int optee_notif_init(struct optee *optee, u_int max_key);
> void optee_notif_uninit(struct optee *optee);
> int optee_notif_wait(struct optee *optee, u_int key);
> @@ -280,8 +299,12 @@ int optee_cancel_req(struct tee_context *ctx, u32 cancel_id, u32 session);
>
> #define PTA_CMD_GET_DEVICES 0x0
> #define PTA_CMD_GET_DEVICES_SUPP 0x1
> +#define PTA_CMD_GET_DEVICES_RPMB 0x2
> int optee_enumerate_devices(u32 func);
> void optee_unregister_devices(void);
> +void optee_bus_scan_rpmb(struct work_struct *work);
> +int optee_rpmb_intf_rdev(struct notifier_block *intf, unsigned long action,
> + void *data);
>
> int optee_pool_op_alloc_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
> size_t size, size_t align,
> @@ -295,6 +318,7 @@ void optee_pool_op_free_helper(struct tee_shm_pool *pool, struct tee_shm *shm,
> struct tee_shm *shm));
>
>
> +void optee_set_dev_group(struct optee *optee);
> void optee_remove_common(struct optee *optee);
> int optee_open(struct tee_context *ctx, bool cap_memref_null);
> void optee_release(struct tee_context *ctx);
> diff --git a/drivers/tee/optee/optee_rpc_cmd.h b/drivers/tee/optee/optee_rpc_cmd.h
> index f3f06e0994a7..4a3c02914f9c 100644
> --- a/drivers/tee/optee/optee_rpc_cmd.h
> +++ b/drivers/tee/optee/optee_rpc_cmd.h
> @@ -103,4 +103,39 @@
> /* I2C master control flags */
> #define OPTEE_RPC_I2C_FLAGS_TEN_BIT BIT(0)
>
> +/*
> + * Reset RPMB probing
> + *
> + * Releases an eventually already used RPMB devices and starts over searching
> + * for RPMB devices. Returns the kind of shared memory to use in subsequent
> + * OPTEE_RPC_CMD_RPMB_PROBE_NEXT and OPTEE_RPC_CMD_RPMB calls.
> + *
> + * [out] value[0].a OPTEE_RPC_SHM_TYPE_*, the parameter for
> + * OPTEE_RPC_CMD_SHM_ALLOC
> + */
> +#define OPTEE_RPC_CMD_RPMB_PROBE_RESET 22
> +
> +/*
> + * Probe next RPMB device
> + *
> + * [out] value[0].a Type of RPMB device, OPTEE_RPC_RPMB_*
> + * [out] value[0].b EXT CSD-slice 168 "RPMB Size"
> + * [out] value[0].c EXT CSD-slice 222 "Reliable Write Sector Count"
> + * [out] memref[1] Buffer with the raw CID
> + */
> +#define OPTEE_RPC_CMD_RPMB_PROBE_NEXT 23
> +
> +/* Type of RPMB device */
> +#define OPTEE_RPC_RPMB_EMMC 0
> +#define OPTEE_RPC_RPMB_UFS 1
> +#define OPTEE_RPC_RPMB_NVME 2
> +
> +/*
> + * Replay Protected Memory Block access
> + *
> + * [in] memref[0] Frames to device
> + * [out] memref[1] Frames from device
> + */
> +#define OPTEE_RPC_CMD_RPMB_FRAMES 24
> +
> #endif /*__OPTEE_RPC_CMD_H*/
> diff --git a/drivers/tee/optee/optee_smc.h b/drivers/tee/optee/optee_smc.h
> index 7d9fa426505b..879426300821 100644
> --- a/drivers/tee/optee/optee_smc.h
> +++ b/drivers/tee/optee/optee_smc.h
> @@ -278,6 +278,8 @@ struct optee_smc_get_shm_config_result {
> #define OPTEE_SMC_SEC_CAP_ASYNC_NOTIF BIT(5)
> /* Secure world supports pre-allocating RPC arg struct */
> #define OPTEE_SMC_SEC_CAP_RPC_ARG BIT(6)
> +/* Secure world supports probing for RPMB device if needed */
> +#define OPTEE_SMC_SEC_CAP_RPMB_PROBE BIT(7)
>
> #define OPTEE_SMC_FUNCID_EXCHANGE_CAPABILITIES 9
> #define OPTEE_SMC_EXCHANGE_CAPABILITIES \
> diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
> index e69bc6380683..cf6a4b97549c 100644
> --- a/drivers/tee/optee/rpc.c
> +++ b/drivers/tee/optee/rpc.c
> @@ -7,6 +7,7 @@
>
> #include <linux/delay.h>
> #include <linux/i2c.h>
> +#include <linux/rpmb.h>
> #include <linux/slab.h>
> #include <linux/tee_drv.h>
> #include "optee_private.h"
> @@ -255,6 +256,154 @@ void optee_rpc_cmd_free_suppl(struct tee_context *ctx, struct tee_shm *shm)
> optee_supp_thrd_req(ctx, OPTEE_RPC_CMD_SHM_FREE, 1, &param);
> }
>
> +static void handle_rpc_func_rpmb_probe_reset(struct tee_context *ctx,
> + struct optee *optee,
> + struct optee_msg_arg *arg)
> +{
> + struct tee_param params[1];
> +
> + if (arg->num_params != ARRAY_SIZE(params) ||
> + optee->ops->from_msg_param(optee, params, arg->num_params,
> + arg->params) ||
> + params[0].attr != TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT) {
> + arg->ret = TEEC_ERROR_BAD_PARAMETERS;
> + return;
> + }
> +
> + params[0].u.value.a = OPTEE_RPC_SHM_TYPE_KERNEL;
> + params[0].u.value.b = 0;
> + params[0].u.value.c = 0;
> + if (optee->ops->to_msg_param(optee, arg->params,
> + arg->num_params, params)) {
> + arg->ret = TEEC_ERROR_BAD_PARAMETERS;
> + return;
> + }
> +
> + mutex_lock(&optee->rpmb_dev_mutex);
> + rpmb_dev_put(optee->rpmb_dev);
> + optee->rpmb_dev = NULL;
> + mutex_unlock(&optee->rpmb_dev_mutex);
> +
> + arg->ret = TEEC_SUCCESS;
> +}
> +
> +static int rpmb_type_to_rpc_type(enum rpmb_type rtype)
> +{
> + switch (rtype) {
> + case RPMB_TYPE_EMMC:
> + return OPTEE_RPC_RPMB_EMMC;
> + case RPMB_TYPE_UFS:
> + return OPTEE_RPC_RPMB_UFS;
> + case RPMB_TYPE_NVME:
> + return OPTEE_RPC_RPMB_NVME;
> + default:
> + return -1;
> + }
> +}
> +
> +static int rpc_rpmb_match(struct device *dev, const void *data)
> +{
> + struct rpmb_dev *rdev = to_rpmb_dev(dev);
> +
> + return rpmb_type_to_rpc_type(rdev->descr.type) >= 0;
> +}
> +
> +static void handle_rpc_func_rpmb_probe_next(struct tee_context *ctx,
> + struct optee *optee,
> + struct optee_msg_arg *arg)
> +{
> + struct rpmb_dev *rdev;
> + struct tee_param params[2];
> + void *buf;
> +
> + if (arg->num_params != ARRAY_SIZE(params) ||
> + optee->ops->from_msg_param(optee, params, arg->num_params,
> + arg->params) ||
> + params[0].attr != TEE_IOCTL_PARAM_ATTR_TYPE_VALUE_OUTPUT ||
> + params[1].attr != TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT) {
> + arg->ret = TEEC_ERROR_BAD_PARAMETERS;
> + return;
> + }
> + buf = tee_shm_get_va(params[1].u.memref.shm,
> + params[1].u.memref.shm_offs);
> + if (!buf) {
> + arg->ret = TEEC_ERROR_BAD_PARAMETERS;
> + return;
> + }
> +
> + mutex_lock(&optee->rpmb_dev_mutex);
> + rdev = rpmb_dev_find_device(NULL, optee->rpmb_dev, rpc_rpmb_match);
> + rpmb_dev_put(optee->rpmb_dev);
> + optee->rpmb_dev = rdev;
> + mutex_unlock(&optee->rpmb_dev_mutex);
> +
> + if (!rdev) {
> + arg->ret = TEEC_ERROR_ITEM_NOT_FOUND;
> + return;
> + }
> +
> + if (params[1].u.memref.size < rdev->descr.dev_id_len) {
> + arg->ret = TEEC_ERROR_SHORT_BUFFER;
> + return;
> + }
> + memcpy(buf, rdev->descr.dev_id, rdev->descr.dev_id_len);
> + params[1].u.memref.size = rdev->descr.dev_id_len;
> + params[0].u.value.a = rpmb_type_to_rpc_type(rdev->descr.type);
> + params[0].u.value.b = rdev->descr.capacity;
> + params[0].u.value.c = rdev->descr.reliable_wr_count;
> + if (optee->ops->to_msg_param(optee, arg->params,
> + arg->num_params, params)) {
> + arg->ret = TEEC_ERROR_BAD_PARAMETERS;
> + return;
> + }
> +
> + arg->ret = TEEC_SUCCESS;
> +}
> +
> +static void handle_rpc_func_rpmb_frames(struct tee_context *ctx,
> + struct optee *optee,
> + struct optee_msg_arg *arg)
> +{
> + struct tee_param params[2];
> + struct rpmb_dev *rdev;
> + void *p0, *p1;
> +
> + mutex_lock(&optee->rpmb_dev_mutex);
> + rdev = rpmb_dev_get(optee->rpmb_dev);
> + mutex_unlock(&optee->rpmb_dev_mutex);
> + if (!rdev) {
> + arg->ret = TEEC_ERROR_ITEM_NOT_FOUND;
> + return;
> + }
> +
> + if (arg->num_params != ARRAY_SIZE(params) ||
> + optee->ops->from_msg_param(optee, params, arg->num_params,
> + arg->params) ||
> + params[0].attr != TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_INPUT ||
> + params[1].attr != TEE_IOCTL_PARAM_ATTR_TYPE_MEMREF_OUTPUT) {
> + arg->ret = TEEC_ERROR_BAD_PARAMETERS;
> + goto out;
> + }
> +
> + p0 = tee_shm_get_va(params[0].u.memref.shm,
> + params[0].u.memref.shm_offs);
> + p1 = tee_shm_get_va(params[1].u.memref.shm,
> + params[1].u.memref.shm_offs);
> + if (rpmb_route_frames(rdev, p0, params[0].u.memref.size, p1,
> + params[1].u.memref.size)) {
> + arg->ret = TEEC_ERROR_BAD_PARAMETERS;
> + goto out;
> + }
> + if (optee->ops->to_msg_param(optee, arg->params,
> + arg->num_params, params)) {
> + arg->ret = TEEC_ERROR_BAD_PARAMETERS;
> + goto out;
> + }
> + arg->ret = TEEC_SUCCESS;
> +out:
> + rpmb_dev_put(rdev);
> +}
> +
> void optee_rpc_cmd(struct tee_context *ctx, struct optee *optee,
> struct optee_msg_arg *arg)
> {
> @@ -271,6 +420,34 @@ void optee_rpc_cmd(struct tee_context *ctx, struct optee *optee,
> case OPTEE_RPC_CMD_I2C_TRANSFER:
> handle_rpc_func_cmd_i2c_transfer(ctx, arg);
> break;
> + /*
> + * optee->in_kernel_rpmb_routing true means that OP-TEE supports
> + * in-kernel RPMB routing _and_ that the RPMB subsystem is
> + * reachable. This is reported to user space with
> + * rpmb_routing_model=kernel in sysfs.
> + *
> + * rpmb_routing_model=kernel is also a promise to user space that
> + * RPMB access will not require supplicant support, hence the
> + * checks below.
> + */
> + case OPTEE_RPC_CMD_RPMB_PROBE_RESET:
> + if (optee->in_kernel_rpmb_routing)
> + handle_rpc_func_rpmb_probe_reset(ctx, optee, arg);
> + else
> + handle_rpc_supp_cmd(ctx, optee, arg);
> + break;
> + case OPTEE_RPC_CMD_RPMB_PROBE_NEXT:
> + if (optee->in_kernel_rpmb_routing)
> + handle_rpc_func_rpmb_probe_next(ctx, optee, arg);
> + else
> + handle_rpc_supp_cmd(ctx, optee, arg);
> + break;
> + case OPTEE_RPC_CMD_RPMB_FRAMES:
> + if (optee->in_kernel_rpmb_routing)
> + handle_rpc_func_rpmb_frames(ctx, optee, arg);
> + else
> + handle_rpc_supp_cmd(ctx, optee, arg);
> + break;
> default:
> handle_rpc_supp_cmd(ctx, optee, arg);
> }
> diff --git a/drivers/tee/optee/smc_abi.c b/drivers/tee/optee/smc_abi.c
> index a37f87087e5c..fd689dfb5697 100644
> --- a/drivers/tee/optee/smc_abi.c
> +++ b/drivers/tee/optee/smc_abi.c
> @@ -20,6 +20,7 @@
> #include <linux/of_irq.h>
> #include <linux/of_platform.h>
> #include <linux/platform_device.h>
> +#include <linux/rpmb.h>
> #include <linux/sched.h>
> #include <linux/slab.h>
> #include <linux/string.h>
> @@ -1688,6 +1689,10 @@ static int optee_probe(struct platform_device *pdev)
> optee->smc.sec_caps = sec_caps;
> optee->rpc_param_count = rpc_param_count;
>
> + if (IS_REACHABLE(CONFIG_RPMB) &&
> + (sec_caps & OPTEE_SMC_SEC_CAP_RPMB_PROBE))
> + optee->in_kernel_rpmb_routing = true;
> +
> teedev = tee_device_alloc(&optee_clnt_desc, NULL, pool, optee);
> if (IS_ERR(teedev)) {
> rc = PTR_ERR(teedev);
> @@ -1702,6 +1707,8 @@ static int optee_probe(struct platform_device *pdev)
> }
> optee->supp_teedev = teedev;
>
> + optee_set_dev_group(optee);
> +
> rc = tee_device_register(optee->teedev);
> if (rc)
> goto err_unreg_supp_teedev;
> @@ -1715,6 +1722,7 @@ static int optee_probe(struct platform_device *pdev)
> optee->smc.memremaped_shm = memremaped_shm;
> optee->pool = pool;
> optee_shm_arg_cache_init(optee, arg_cache_flags);
> + mutex_init(&optee->rpmb_dev_mutex);
>
> platform_set_drvdata(pdev, optee);
> ctx = teedev_open(optee->teedev);
> @@ -1769,6 +1777,10 @@ static int optee_probe(struct platform_device *pdev)
> if (rc)
> goto err_disable_shm_cache;
>
> + INIT_WORK(&optee->rpmb_scan_bus_work, optee_bus_scan_rpmb);
> + optee->rpmb_intf.notifier_call = optee_rpmb_intf_rdev;
> + blocking_notifier_chain_register(&optee_rpmb_intf_added,
> + &optee->rpmb_intf);
> pr_info("initialized driver\n");
> return 0;
>
> @@ -1782,6 +1794,8 @@ static int optee_probe(struct platform_device *pdev)
> err_close_ctx:
> teedev_close_context(ctx);
> err_supp_uninit:
> + rpmb_dev_put(optee->rpmb_dev);
> + mutex_destroy(&optee->rpmb_dev_mutex);
> optee_shm_arg_cache_uninit(optee);
> optee_supp_uninit(&optee->supp);
> mutex_destroy(&optee->call_queue.mutex);
> --
> 2.34.1
>

2024-05-28 09:08:43

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

Hi Sumit,

On Mon, May 27, 2024 at 4:38 PM Sumit Garg <[email protected]> wrote:
>
> On Mon, 27 May 2024 at 17:44, Jens Wiklander <[email protected]> wrote:
> >
> > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
> > use an RPMB device via the RPMB subsystem instead of passing the RPMB
> > frames via tee-supplicant in user space. A fallback mechanism is kept to
> > route RPMB frames via tee-supplicant if the RPMB subsystem isn't
> > available.
> >
> > The OP-TEE RPC ABI is extended to support iterating over all RPMB
> > devices until one is found with the expected RPMB key already
> > programmed.
> >
> > Signed-off-by: Jens Wiklander <[email protected]>
> > Tested-by: Manuel Traut <[email protected]>
> > ---
> > Documentation/ABI/testing/sysfs-class-tee | 15 ++
> > MAINTAINERS | 1 +
> > drivers/tee/optee/core.c | 96 +++++++++++-
> > drivers/tee/optee/device.c | 7 +
> > drivers/tee/optee/ffa_abi.c | 14 ++
> > drivers/tee/optee/optee_ffa.h | 2 +
> > drivers/tee/optee/optee_private.h | 26 +++-
> > drivers/tee/optee/optee_rpc_cmd.h | 35 +++++
> > drivers/tee/optee/optee_smc.h | 2 +
> > drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++
> > drivers/tee/optee/smc_abi.c | 14 ++
> > 11 files changed, 387 insertions(+), 2 deletions(-)
> > create mode 100644 Documentation/ABI/testing/sysfs-class-tee
> >
> > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee
> > new file mode 100644
> > index 000000000000..c9144d16003e
> > --- /dev/null
> > +++ b/Documentation/ABI/testing/sysfs-class-tee
> > @@ -0,0 +1,15 @@
> > +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model
> > +Date: May 2024
> > +KernelVersion: 6.10
> > +Contact: [email protected]
> > +Description:
> > + RPMB frames can be routed to the RPMB device via the
> > + user-space daemon tee-supplicant or the RPMB subsystem
> > + in the kernel. The value "user" means that the driver
> > + will route the RPMB frames via user space. Conversely,
> > + "kernel" means that the frames are routed via the RPMB
> > + subsystem without assistance from tee-supplicant. It
> > + should be assumed that RPMB frames are routed via user
> > + space if the variable is absent. The primary purpose
> > + of this variable is to let systemd know whether
> > + tee-supplicant is needed in the early boot with initramfs.
>
> Why do we need this if we already have [1] [2]? AFAICS, whichever
> devices like fTPM etc. systemd depends upon, it can be easily known
> via existing sysfs property.
>
> [1] https://docs.kernel.org/admin-guide/abi-testing.html?highlight=optee#abi-sys-bus-tee-devices-optee-ta-uuid-need-supplicant
> [2] Documentation/ABI/testing/sysfs-bus-optee-devices

The dependency is reversed. A TA depending on tee-supplicant will not
be loaded until tee-supplicant is ready. rpmb_routing_model is used as
one of the inputs to determine if tee-supplicant must be started early
or if it can wait until the real rootfs is available.

Thanks,
Jens

2024-05-28 09:31:02

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

Hi,

On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote:
> On Mon, May 27, 2024 at 3:00 PM Jerome Forissier
> <[email protected]> wrote:
> >
> > On 5/27/24 14:13, Jens Wiklander wrote:
> > > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
> > > use an RPMB device via the RPMB subsystem instead of passing the RPMB
> > > frames via tee-supplicant in user space. A fallback mechanism is kept to
> > > route RPMB frames via tee-supplicant if the RPMB subsystem isn't
> > > available.
> > >
> > > The OP-TEE RPC ABI is extended to support iterating over all RPMB
> > > devices until one is found with the expected RPMB key already
> > > programmed.
> > >
> > > Signed-off-by: Jens Wiklander <[email protected]>
> > > Tested-by: Manuel Traut <[email protected]>
> > > ---
> > > Documentation/ABI/testing/sysfs-class-tee | 15 ++
> > > MAINTAINERS | 1 +
> > > drivers/tee/optee/core.c | 96 +++++++++++-
> > > drivers/tee/optee/device.c | 7 +
> > > drivers/tee/optee/ffa_abi.c | 14 ++
> > > drivers/tee/optee/optee_ffa.h | 2 +
> > > drivers/tee/optee/optee_private.h | 26 +++-
> > > drivers/tee/optee/optee_rpc_cmd.h | 35 +++++
> > > drivers/tee/optee/optee_smc.h | 2 +
> > > drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++
> > > drivers/tee/optee/smc_abi.c | 14 ++
> > > 11 files changed, 387 insertions(+), 2 deletions(-)
> > > create mode 100644 Documentation/ABI/testing/sysfs-class-tee
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee
> > > new file mode 100644
> > > index 000000000000..c9144d16003e
> > > --- /dev/null
> > > +++ b/Documentation/ABI/testing/sysfs-class-tee
> > > @@ -0,0 +1,15 @@
> > > +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model
> >
> > Wouldn't /sys/class/tee/teeX/rpmb_routing_model be good enough?
>
> Doesn't the routing model concern tee-supplicant more than a TEE
> client? Then it might make more sense to have
> /sys/class/tee/teeprivX/rpmb_routing_model only. Keeping it for both
> devices representing the same internal struct optee makes it easier to
> find. Anyway, I don't mind removing one. Mikko, what do you prefer?

As simple as possible. A single sysfs file is enough. Even the existence of the sysfs file
could be the needed indicator for userspace to queue tee-supplicant startup.

Outside of these patches, I think the optee RPC setup with fTPM TA is one area which
currently requires tee-supplicant to be started. Detecting the existence of TPM before
kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel
or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too.

In userspace and systemd it's just important to know that service need to wait for a TPM2
device to appear in early initrd and when can things be postponed to main rootfs and later
stages. Kernel and udev will bring up the device then once discovered.
Knowledge about the RPMB backend is important when something like TPM2 device
depends on it.

Hope this helps,

-Mikko

2024-05-29 05:05:20

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

On Tue, 28 May 2024 at 14:38, Jens Wiklander <[email protected]> wrote:
>
> Hi Sumit,
>
> On Mon, May 27, 2024 at 4:38 PM Sumit Garg <[email protected]> wrote:
> >
> > On Mon, 27 May 2024 at 17:44, Jens Wiklander <[email protected]> wrote:
> > >
> > > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
> > > use an RPMB device via the RPMB subsystem instead of passing the RPMB
> > > frames via tee-supplicant in user space. A fallback mechanism is kept to
> > > route RPMB frames via tee-supplicant if the RPMB subsystem isn't
> > > available.
> > >
> > > The OP-TEE RPC ABI is extended to support iterating over all RPMB
> > > devices until one is found with the expected RPMB key already
> > > programmed.
> > >
> > > Signed-off-by: Jens Wiklander <[email protected]>
> > > Tested-by: Manuel Traut <[email protected]>
> > > ---
> > > Documentation/ABI/testing/sysfs-class-tee | 15 ++
> > > MAINTAINERS | 1 +
> > > drivers/tee/optee/core.c | 96 +++++++++++-
> > > drivers/tee/optee/device.c | 7 +
> > > drivers/tee/optee/ffa_abi.c | 14 ++
> > > drivers/tee/optee/optee_ffa.h | 2 +
> > > drivers/tee/optee/optee_private.h | 26 +++-
> > > drivers/tee/optee/optee_rpc_cmd.h | 35 +++++
> > > drivers/tee/optee/optee_smc.h | 2 +
> > > drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++
> > > drivers/tee/optee/smc_abi.c | 14 ++
> > > 11 files changed, 387 insertions(+), 2 deletions(-)
> > > create mode 100644 Documentation/ABI/testing/sysfs-class-tee
> > >
> > > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee
> > > new file mode 100644
> > > index 000000000000..c9144d16003e
> > > --- /dev/null
> > > +++ b/Documentation/ABI/testing/sysfs-class-tee
> > > @@ -0,0 +1,15 @@
> > > +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model
> > > +Date: May 2024
> > > +KernelVersion: 6.10
> > > +Contact: [email protected]
> > > +Description:
> > > + RPMB frames can be routed to the RPMB device via the
> > > + user-space daemon tee-supplicant or the RPMB subsystem
> > > + in the kernel. The value "user" means that the driver
> > > + will route the RPMB frames via user space. Conversely,
> > > + "kernel" means that the frames are routed via the RPMB
> > > + subsystem without assistance from tee-supplicant. It
> > > + should be assumed that RPMB frames are routed via user
> > > + space if the variable is absent. The primary purpose
> > > + of this variable is to let systemd know whether
> > > + tee-supplicant is needed in the early boot with initramfs.
> >
> > Why do we need this if we already have [1] [2]? AFAICS, whichever
> > devices like fTPM etc. systemd depends upon, it can be easily known
> > via existing sysfs property.
> >
> > [1] https://docs.kernel.org/admin-guide/abi-testing.html?highlight=optee#abi-sys-bus-tee-devices-optee-ta-uuid-need-supplicant
> > [2] Documentation/ABI/testing/sysfs-bus-optee-devices
>
> The dependency is reversed. A TA depending on tee-supplicant will not
> be loaded until tee-supplicant is ready. rpmb_routing_model is used as
> one of the inputs to determine if tee-supplicant must be started early
> or if it can wait until the real rootfs is available.
>

Okay but I am still not able to understand the reasoning as to why
tee-supplicant can't be started unconditionally. If it's available in
the initrd then systemd should be able to launch it unconditionally.
Or is there any dependency I am missing for the tee-supplicant to be
started? RPMB routing isn't the only service offered by tee-supplcant,
so gating it behind that for no real reason isn't making sense to me.

IOW, why do we need to defer starting tee-supplicant until the real
rootfs is available?

-Sumit

2024-05-29 05:26:27

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

Hi Mikko,

On Tue, 28 May 2024 at 15:00, Mikko Rapeli <[email protected]> wrote:
>
> Hi,
>
> On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote:
> > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier
> > <[email protected]> wrote:
> > >
> > > On 5/27/24 14:13, Jens Wiklander wrote:
> > > > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
> > > > use an RPMB device via the RPMB subsystem instead of passing the RPMB
> > > > frames via tee-supplicant in user space. A fallback mechanism is kept to
> > > > route RPMB frames via tee-supplicant if the RPMB subsystem isn't
> > > > available.
> > > >
> > > > The OP-TEE RPC ABI is extended to support iterating over all RPMB
> > > > devices until one is found with the expected RPMB key already
> > > > programmed.
> > > >
> > > > Signed-off-by: Jens Wiklander <[email protected]>
> > > > Tested-by: Manuel Traut <[email protected]>
> > > > ---
> > > > Documentation/ABI/testing/sysfs-class-tee | 15 ++
> > > > MAINTAINERS | 1 +
> > > > drivers/tee/optee/core.c | 96 +++++++++++-
> > > > drivers/tee/optee/device.c | 7 +
> > > > drivers/tee/optee/ffa_abi.c | 14 ++
> > > > drivers/tee/optee/optee_ffa.h | 2 +
> > > > drivers/tee/optee/optee_private.h | 26 +++-
> > > > drivers/tee/optee/optee_rpc_cmd.h | 35 +++++
> > > > drivers/tee/optee/optee_smc.h | 2 +
> > > > drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++
> > > > drivers/tee/optee/smc_abi.c | 14 ++
> > > > 11 files changed, 387 insertions(+), 2 deletions(-)
> > > > create mode 100644 Documentation/ABI/testing/sysfs-class-tee
> > > >
> > > > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee
> > > > new file mode 100644
> > > > index 000000000000..c9144d16003e
> > > > --- /dev/null
> > > > +++ b/Documentation/ABI/testing/sysfs-class-tee
> > > > @@ -0,0 +1,15 @@
> > > > +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model
> > >
> > > Wouldn't /sys/class/tee/teeX/rpmb_routing_model be good enough?
> >
> > Doesn't the routing model concern tee-supplicant more than a TEE
> > client? Then it might make more sense to have
> > /sys/class/tee/teeprivX/rpmb_routing_model only. Keeping it for both
> > devices representing the same internal struct optee makes it easier to
> > find. Anyway, I don't mind removing one. Mikko, what do you prefer?
>
> As simple as possible. A single sysfs file is enough. Even the existence of the sysfs file
> could be the needed indicator for userspace to queue tee-supplicant startup.
>
> Outside of these patches, I think the optee RPC setup with fTPM TA is one area which
> currently requires tee-supplicant to be started. Detecting the existence of TPM before
> kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel
> or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too.

One thing I am trying to find an answer about is why do we need to
defer tee-supplicant launch if it's bundled into initrd? Once you
detect OP-TEE then tee-supplicant should be launched unconditionally.
As per your example below, the motivation here seems to be the TPM2
device dependent on RPMB backend but what if other future systemd
services come up and depend on other services offered by
tee-supplicant?

-Sumit

>
> In userspace and systemd it's just important to know that service need to wait for a TPM2
> device to appear in early initrd and when can things be postponed to main rootfs and later
> stages. Kernel and udev will bring up the device then once discovered.
> Knowledge about the RPMB backend is important when something like TPM2 device
> depends on it.
>
> Hope this helps,
>
> -Mikko

2024-05-29 07:10:14

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

Hi,

On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote:
> Hi Mikko,
>
> On Tue, 28 May 2024 at 15:00, Mikko Rapeli <[email protected]> wrote:
> >
> > Hi,
> >
> > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote:
> > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier
> > > <[email protected]> wrote:
> > > >
> > > > On 5/27/24 14:13, Jens Wiklander wrote:
> > > > > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
> > > > > use an RPMB device via the RPMB subsystem instead of passing the RPMB
> > > > > frames via tee-supplicant in user space. A fallback mechanism is kept to
> > > > > route RPMB frames via tee-supplicant if the RPMB subsystem isn't
> > > > > available.
> > > > >
> > > > > The OP-TEE RPC ABI is extended to support iterating over all RPMB
> > > > > devices until one is found with the expected RPMB key already
> > > > > programmed.
> > > > >
> > > > > Signed-off-by: Jens Wiklander <[email protected]>
> > > > > Tested-by: Manuel Traut <[email protected]>
> > > > > ---
> > > > > Documentation/ABI/testing/sysfs-class-tee | 15 ++
> > > > > MAINTAINERS | 1 +
> > > > > drivers/tee/optee/core.c | 96 +++++++++++-
> > > > > drivers/tee/optee/device.c | 7 +
> > > > > drivers/tee/optee/ffa_abi.c | 14 ++
> > > > > drivers/tee/optee/optee_ffa.h | 2 +
> > > > > drivers/tee/optee/optee_private.h | 26 +++-
> > > > > drivers/tee/optee/optee_rpc_cmd.h | 35 +++++
> > > > > drivers/tee/optee/optee_smc.h | 2 +
> > > > > drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++
> > > > > drivers/tee/optee/smc_abi.c | 14 ++
> > > > > 11 files changed, 387 insertions(+), 2 deletions(-)
> > > > > create mode 100644 Documentation/ABI/testing/sysfs-class-tee
> > > > >
> > > > > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee
> > > > > new file mode 100644
> > > > > index 000000000000..c9144d16003e
> > > > > --- /dev/null
> > > > > +++ b/Documentation/ABI/testing/sysfs-class-tee
> > > > > @@ -0,0 +1,15 @@
> > > > > +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model
> > > >
> > > > Wouldn't /sys/class/tee/teeX/rpmb_routing_model be good enough?
> > >
> > > Doesn't the routing model concern tee-supplicant more than a TEE
> > > client? Then it might make more sense to have
> > > /sys/class/tee/teeprivX/rpmb_routing_model only. Keeping it for both
> > > devices representing the same internal struct optee makes it easier to
> > > find. Anyway, I don't mind removing one. Mikko, what do you prefer?
> >
> > As simple as possible. A single sysfs file is enough. Even the existence of the sysfs file
> > could be the needed indicator for userspace to queue tee-supplicant startup.
> >
> > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which
> > currently requires tee-supplicant to be started. Detecting the existence of TPM before
> > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel
> > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too.
>
> One thing I am trying to find an answer about is why do we need to
> defer tee-supplicant launch if it's bundled into initrd? Once you
> detect OP-TEE then tee-supplicant should be launched unconditionally.
> As per your example below, the motivation here seems to be the TPM2
> device dependent on RPMB backend but what if other future systemd
> services come up and depend on other services offered by
> tee-supplicant?

There is an annoying depedency between firmware side optee and TAs, and kernel optee driver,
tee-supplicant in userspace and kernel TA drivers like fTPM.

Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc.

This patch series is adding kernel side support for RPMB handling so that the dependency to
tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC
buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic.

So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers
and firmware optee trusted applications would not depend on tee-supplicant running in userspace.
The startup sequence is really tricky to get right. My fTPM use case is using the TPM device
to encrypt rootfs and thus all SW components including tee-supplicant need to run early in
initramfs. Currently also switch from initramfs to main rootfs requires unloading
fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant
and loading fTPM kernel driver from main rootfs. udev and automatic module loading for
fTPM can not be used due to the tee-supplicant userspace dependency.

As an example, here is v6 of this series on rockpi4b using fTPM TA with systemd based initrd
without tee-supplicant and fTPM TA panics because the RPC setup is missing:

https://ledge.validation.linaro.org/scheduler/job/87488

[[0;32m OK [0m] Finished [0;1;39mFile System Check on /dev/mapper/usr[0m.
E/TC:? 0 get_rpc_alloc_res:645 RPC allocation failed. Non-secure world result: ret=0xffff000c ret_origin=0x2
E/TC:? 0
E/TC:? 0 TA panicked with code 0xffff000c
E/LD: Status of TA bc50d971-d4c9-42c4-82cb-343fb7f37896
E/LD: arch: aarch64
E/LD: region 0: va 0x40005000 pa 0x3061b000 size 0x002000 flags rw-s (ldelf)
E/LD: region 1: va 0x40007000 pa 0x3061d000 size 0x008000 flags r-xs (ldelf)
E/LD: region 2: va 0x4000f000 pa 0x30625000 size 0x001000 flags rw-s (ldelf)
E/LD: region 3: va 0x40010000 pa 0x30626000 size 0x004000 flags rw-s (ldelf)
E/LD: region 4: va 0x40014000 pa 0x3062a000 size 0x001000 flags r--s
E/LD: region 5: va 0x40015000 pa 0x306b2000 size 0x011000 flags rw-s (stack)
E/LD: region 6: va 0x40026000 pa 0xe50ce000 size 0x002000 flags rw-- (param)
E/LD: region 7: va 0x40062000 pa 0x00001000 size 0x068000 flags r-xs [0]
E/LD: region 8: va 0x400ca000 pa 0x00069000 size 0x01f000 flags rw-s [0]
E/LD: [0] bc50d971-d4c9-42c4-82cb-343fb7f37896 @ 0x40062000
E/LD: Call stack:
E/LD: 0x400a00c0
E/LD: 0x40062b40
E/LD: 0x400631b8
E/LD: 0x40081f44
E/LD: 0x4009b060
E/LD: 0x40063a2c
E/LD: 0x400a6298
E/LD: 0x4009b214
[ 7.212584] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024
[ 7.213281] tpm tpm0: tpm_try_transmit: send(): error -53212
[ 7.213820] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024
[ 7.214493] tpm tpm0: tpm_try_transmit: send(): error -53212
[ 7.214996] optee-ftpm optee-ta-bc50d971-d4c9-42c4-82cb-343fb7f37896: ftpm_tee_probe: tpm_chip_register failed with rc=-53212
Mounting [0;1;39m/sysusr/usr[0m...

This series adds the RPMB support in kernel, if HW supports it, but some HW doesn't and the
tee-supplicant is emulating it as fall back. Userspace needs to know if tee-supplicant start
is needed. Thus to me, exporting the RPMB routing details is useful for userspace.

It's one thing to have a full control of HW and SW and force a policy, like always
waiting for a specific TPM device to appear, but then again distros should be able
to have automatic detection of TPM devices if firmware used them too and then
start the needed bits in userspace, which depend on the firmware and HW configuration,
like which SW components are needed for RPMB storage, kernel or tee-supplicant in userspace.

These could possibly be just bugs in fTPM kernel driver and fTPM TA in optee world,
which should be able to handle missing RPC and RPMB too and retry later on. Right now
without tee-supplicant they panic early in boot and become unusable for the rest of the
power cycle.

Cheers,

-Mikko

2024-05-29 08:21:11

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

On Wed, 29 May 2024 at 12:39, Mikko Rapeli <[email protected]> wrote:
>
> Hi,
>
> On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote:
> > Hi Mikko,
> >
> > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <[email protected]> wrote:
> > >
> > > Hi,
> > >
> > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote:
> > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier
> > > > <[email protected]> wrote:
> > > > >
> > > > > On 5/27/24 14:13, Jens Wiklander wrote:
> > > > > > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
> > > > > > use an RPMB device via the RPMB subsystem instead of passing the RPMB
> > > > > > frames via tee-supplicant in user space. A fallback mechanism is kept to
> > > > > > route RPMB frames via tee-supplicant if the RPMB subsystem isn't
> > > > > > available.
> > > > > >
> > > > > > The OP-TEE RPC ABI is extended to support iterating over all RPMB
> > > > > > devices until one is found with the expected RPMB key already
> > > > > > programmed.
> > > > > >
> > > > > > Signed-off-by: Jens Wiklander <[email protected]>
> > > > > > Tested-by: Manuel Traut <[email protected]>
> > > > > > ---
> > > > > > Documentation/ABI/testing/sysfs-class-tee | 15 ++
> > > > > > MAINTAINERS | 1 +
> > > > > > drivers/tee/optee/core.c | 96 +++++++++++-
> > > > > > drivers/tee/optee/device.c | 7 +
> > > > > > drivers/tee/optee/ffa_abi.c | 14 ++
> > > > > > drivers/tee/optee/optee_ffa.h | 2 +
> > > > > > drivers/tee/optee/optee_private.h | 26 +++-
> > > > > > drivers/tee/optee/optee_rpc_cmd.h | 35 +++++
> > > > > > drivers/tee/optee/optee_smc.h | 2 +
> > > > > > drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++
> > > > > > drivers/tee/optee/smc_abi.c | 14 ++
> > > > > > 11 files changed, 387 insertions(+), 2 deletions(-)
> > > > > > create mode 100644 Documentation/ABI/testing/sysfs-class-tee
> > > > > >
> > > > > > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee
> > > > > > new file mode 100644
> > > > > > index 000000000000..c9144d16003e
> > > > > > --- /dev/null
> > > > > > +++ b/Documentation/ABI/testing/sysfs-class-tee
> > > > > > @@ -0,0 +1,15 @@
> > > > > > +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model
> > > > >
> > > > > Wouldn't /sys/class/tee/teeX/rpmb_routing_model be good enough?
> > > >
> > > > Doesn't the routing model concern tee-supplicant more than a TEE
> > > > client? Then it might make more sense to have
> > > > /sys/class/tee/teeprivX/rpmb_routing_model only. Keeping it for both
> > > > devices representing the same internal struct optee makes it easier to
> > > > find. Anyway, I don't mind removing one. Mikko, what do you prefer?
> > >
> > > As simple as possible. A single sysfs file is enough. Even the existence of the sysfs file
> > > could be the needed indicator for userspace to queue tee-supplicant startup.
> > >
> > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which
> > > currently requires tee-supplicant to be started. Detecting the existence of TPM before
> > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel
> > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too.
> >
> > One thing I am trying to find an answer about is why do we need to
> > defer tee-supplicant launch if it's bundled into initrd? Once you
> > detect OP-TEE then tee-supplicant should be launched unconditionally.
> > As per your example below, the motivation here seems to be the TPM2
> > device dependent on RPMB backend but what if other future systemd
> > services come up and depend on other services offered by
> > tee-supplicant?
>
> There is an annoying depedency between firmware side optee and TAs, and kernel optee driver,
> tee-supplicant in userspace and kernel TA drivers like fTPM.
>
> Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc.
>
> This patch series is adding kernel side support for RPMB handling so that the dependency to
> tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC
> buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic.
>
> So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers
> and firmware optee trusted applications would not depend on tee-supplicant running in userspace.

Agree, we are aligned here. With this patch-set we aim to achieve
that, the user-space dependency for kernel drivers is hard to manage
and it's better to get rid of it. However, backwards compatibility for
distros will still require starting tee-supplicant.

> The startup sequence is really tricky to get right. My fTPM use case is using the TPM device
> to encrypt rootfs and thus all SW components including tee-supplicant need to run early in
> initramfs. Currently also switch from initramfs to main rootfs requires unloading
> fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant
> and loading fTPM kernel driver from main rootfs. udev and automatic module loading for
> fTPM can not be used due to the tee-supplicant userspace dependency.

This is one of the reasons for gating tee-supplicant loading which I
was looking for. What happens if we want to keep tee-supplicant alive
when we migrate from initramfs to real rootfs? Does it work?

>
> As an example, here is v6 of this series on rockpi4b using fTPM TA with systemd based initrd
> without tee-supplicant and fTPM TA panics because the RPC setup is missing:

I think this is due to RPC allocation requested from tee-supplicant
during RPMB operations. Can you try following untested optee-os diff
and see if it resolves the problem for you?

diff --git a/core/tee/tee_rpmb_fs.c b/core/tee/tee_rpmb_fs.c
index 0ed30933b..b3d4d077a 100644
--- a/core/tee/tee_rpmb_fs.c
+++ b/core/tee/tee_rpmb_fs.c
@@ -418,11 +418,11 @@ static void tee_rpmb_free(struct tee_rpmb_mem *mem)
return;

if (mem->phreq_mobj) {
- thread_rpc_free_payload(mem->phreq_mobj);
+ thread_rpc_free_kernel_payload(mem->phreq_mobj);
mem->phreq_mobj = NULL;
}
if (mem->phresp_mobj) {
- thread_rpc_free_payload(mem->phresp_mobj);
+ thread_rpc_free_kernel_payload(mem->phresp_mobj);
mem->phresp_mobj = NULL;
}
}
@@ -440,8 +440,8 @@ static TEE_Result tee_rpmb_alloc(size_t req_size,
size_t resp_size,

memset(mem, 0, sizeof(*mem));

- mem->phreq_mobj = thread_rpc_alloc_payload(req_s);
- mem->phresp_mobj = thread_rpc_alloc_payload(resp_s);
+ mem->phreq_mobj = thread_rpc_alloc_kernel_payload(req_s);
+ mem->phresp_mobj = thread_rpc_alloc_kernel_payload(resp_s);

if (!mem->phreq_mobj || !mem->phresp_mobj) {
res = TEE_ERROR_OUT_OF_MEMORY;

>
> https://ledge.validation.linaro.org/scheduler/job/87488
>
> [[0;32m OK [0m] Finished [0;1;39mFile System Check on /dev/mapper/usr[0m.
> E/TC:? 0 get_rpc_alloc_res:645 RPC allocation failed. Non-secure world result: ret=0xffff000c ret_origin=0x2
> E/TC:? 0
> E/TC:? 0 TA panicked with code 0xffff000c
> E/LD: Status of TA bc50d971-d4c9-42c4-82cb-343fb7f37896
> E/LD: arch: aarch64
> E/LD: region 0: va 0x40005000 pa 0x3061b000 size 0x002000 flags rw-s (ldelf)
> E/LD: region 1: va 0x40007000 pa 0x3061d000 size 0x008000 flags r-xs (ldelf)
> E/LD: region 2: va 0x4000f000 pa 0x30625000 size 0x001000 flags rw-s (ldelf)
> E/LD: region 3: va 0x40010000 pa 0x30626000 size 0x004000 flags rw-s (ldelf)
> E/LD: region 4: va 0x40014000 pa 0x3062a000 size 0x001000 flags r--s
> E/LD: region 5: va 0x40015000 pa 0x306b2000 size 0x011000 flags rw-s (stack)
> E/LD: region 6: va 0x40026000 pa 0xe50ce000 size 0x002000 flags rw-- (param)
> E/LD: region 7: va 0x40062000 pa 0x00001000 size 0x068000 flags r-xs [0]
> E/LD: region 8: va 0x400ca000 pa 0x00069000 size 0x01f000 flags rw-s [0]
> E/LD: [0] bc50d971-d4c9-42c4-82cb-343fb7f37896 @ 0x40062000
> E/LD: Call stack:
> E/LD: 0x400a00c0
> E/LD: 0x40062b40
> E/LD: 0x400631b8
> E/LD: 0x40081f44
> E/LD: 0x4009b060
> E/LD: 0x40063a2c
> E/LD: 0x400a6298
> E/LD: 0x4009b214
> [ 7.212584] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024
> [ 7.213281] tpm tpm0: tpm_try_transmit: send(): error -53212
> [ 7.213820] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024
> [ 7.214493] tpm tpm0: tpm_try_transmit: send(): error -53212
> [ 7.214996] optee-ftpm optee-ta-bc50d971-d4c9-42c4-82cb-343fb7f37896: ftpm_tee_probe: tpm_chip_register failed with rc=-53212
> Mounting [0;1;39m/sysusr/usr[0m...
>
> This series adds the RPMB support in kernel, if HW supports it, but some HW doesn't and the
> tee-supplicant is emulating it as fall back.

That's just for testing purposes, right? It won't be used to implement
disk encryption for that HW.

> Userspace needs to know if tee-supplicant start
> is needed. Thus to me, exporting the RPMB routing details is useful for userspace.
>
> It's one thing to have a full control of HW and SW and force a policy, like always
> waiting for a specific TPM device to appear, but then again distros should be able
> to have automatic detection of TPM devices if firmware used them too and then
> start the needed bits in userspace, which depend on the firmware and HW configuration,
> like which SW components are needed for RPMB storage, kernel or tee-supplicant in userspace.
>
> These could possibly be just bugs in fTPM kernel driver and fTPM TA in optee world,
> which should be able to handle missing RPC and RPMB too and retry later on. Right now
> without tee-supplicant they panic early in boot and become unusable for the rest of the
> power cycle.

I very much would like to see fTPM working without dependency on
tee-supplicant. If there are any further problems you see then please
feel free to report.

-Sumit

>
> Cheers,
>
> -Mikko

2024-05-29 08:51:48

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

On Wed, 29 May 2024 at 13:36, Sumit Garg <[email protected]> wrote:
>
> On Wed, 29 May 2024 at 12:39, Mikko Rapeli <[email protected]> wrote:
> >
> > Hi,
> >
> > On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote:
> > > Hi Mikko,
> > >
> > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <[email protected]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote:
> > > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier
> > > > > <[email protected]> wrote:
> > > > > >
> > > > > > On 5/27/24 14:13, Jens Wiklander wrote:
> > > > > > > Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
> > > > > > > use an RPMB device via the RPMB subsystem instead of passing the RPMB
> > > > > > > frames via tee-supplicant in user space. A fallback mechanism is kept to
> > > > > > > route RPMB frames via tee-supplicant if the RPMB subsystem isn't
> > > > > > > available.
> > > > > > >
> > > > > > > The OP-TEE RPC ABI is extended to support iterating over all RPMB
> > > > > > > devices until one is found with the expected RPMB key already
> > > > > > > programmed.
> > > > > > >
> > > > > > > Signed-off-by: Jens Wiklander <[email protected]>
> > > > > > > Tested-by: Manuel Traut <[email protected]>
> > > > > > > ---
> > > > > > > Documentation/ABI/testing/sysfs-class-tee | 15 ++
> > > > > > > MAINTAINERS | 1 +
> > > > > > > drivers/tee/optee/core.c | 96 +++++++++++-
> > > > > > > drivers/tee/optee/device.c | 7 +
> > > > > > > drivers/tee/optee/ffa_abi.c | 14 ++
> > > > > > > drivers/tee/optee/optee_ffa.h | 2 +
> > > > > > > drivers/tee/optee/optee_private.h | 26 +++-
> > > > > > > drivers/tee/optee/optee_rpc_cmd.h | 35 +++++
> > > > > > > drivers/tee/optee/optee_smc.h | 2 +
> > > > > > > drivers/tee/optee/rpc.c | 177 ++++++++++++++++++++++
> > > > > > > drivers/tee/optee/smc_abi.c | 14 ++
> > > > > > > 11 files changed, 387 insertions(+), 2 deletions(-)
> > > > > > > create mode 100644 Documentation/ABI/testing/sysfs-class-tee
> > > > > > >
> > > > > > > diff --git a/Documentation/ABI/testing/sysfs-class-tee b/Documentation/ABI/testing/sysfs-class-tee
> > > > > > > new file mode 100644
> > > > > > > index 000000000000..c9144d16003e
> > > > > > > --- /dev/null
> > > > > > > +++ b/Documentation/ABI/testing/sysfs-class-tee
> > > > > > > @@ -0,0 +1,15 @@
> > > > > > > +What: /sys/class/tee/tee{,priv}X/rpmb_routing_model
> > > > > >
> > > > > > Wouldn't /sys/class/tee/teeX/rpmb_routing_model be good enough?
> > > > >
> > > > > Doesn't the routing model concern tee-supplicant more than a TEE
> > > > > client? Then it might make more sense to have
> > > > > /sys/class/tee/teeprivX/rpmb_routing_model only. Keeping it for both
> > > > > devices representing the same internal struct optee makes it easier to
> > > > > find. Anyway, I don't mind removing one. Mikko, what do you prefer?
> > > >
> > > > As simple as possible. A single sysfs file is enough. Even the existence of the sysfs file
> > > > could be the needed indicator for userspace to queue tee-supplicant startup.
> > > >
> > > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which
> > > > currently requires tee-supplicant to be started. Detecting the existence of TPM before
> > > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel
> > > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too.
> > >
> > > One thing I am trying to find an answer about is why do we need to
> > > defer tee-supplicant launch if it's bundled into initrd? Once you
> > > detect OP-TEE then tee-supplicant should be launched unconditionally.
> > > As per your example below, the motivation here seems to be the TPM2
> > > device dependent on RPMB backend but what if other future systemd
> > > services come up and depend on other services offered by
> > > tee-supplicant?
> >
> > There is an annoying depedency between firmware side optee and TAs, and kernel optee driver,
> > tee-supplicant in userspace and kernel TA drivers like fTPM.
> >
> > Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc.
> >
> > This patch series is adding kernel side support for RPMB handling so that the dependency to
> > tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC
> > buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic.
> >
> > So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers
> > and firmware optee trusted applications would not depend on tee-supplicant running in userspace.
>
> Agree, we are aligned here. With this patch-set we aim to achieve
> that, the user-space dependency for kernel drivers is hard to manage
> and it's better to get rid of it. However, backwards compatibility for
> distros will still require starting tee-supplicant.
>
> > The startup sequence is really tricky to get right. My fTPM use case is using the TPM device
> > to encrypt rootfs and thus all SW components including tee-supplicant need to run early in
> > initramfs. Currently also switch from initramfs to main rootfs requires unloading
> > fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant
> > and loading fTPM kernel driver from main rootfs. udev and automatic module loading for
> > fTPM can not be used due to the tee-supplicant userspace dependency.
>
> This is one of the reasons for gating tee-supplicant loading which I
> was looking for. What happens if we want to keep tee-supplicant alive
> when we migrate from initramfs to real rootfs? Does it work?
>
> >
> > As an example, here is v6 of this series on rockpi4b using fTPM TA with systemd based initrd
> > without tee-supplicant and fTPM TA panics because the RPC setup is missing:
>
> I think this is due to RPC allocation requested from tee-supplicant
> during RPMB operations. Can you try following untested optee-os diff
> and see if it resolves the problem for you?

Scratch that as I can see Jens has already reworked that code here [1]
and I suppose you are running on top of that. Can you rather add
further RPC debugging prints to see which RPC gets invoked when
running fTPM TA?

[1] https://github.com/jenswi-linaro/optee_os/commits/rpmb_probe_v7/

-Sumit

>
> diff --git a/core/tee/tee_rpmb_fs.c b/core/tee/tee_rpmb_fs.c
> index 0ed30933b..b3d4d077a 100644
> --- a/core/tee/tee_rpmb_fs.c
> +++ b/core/tee/tee_rpmb_fs.c
> @@ -418,11 +418,11 @@ static void tee_rpmb_free(struct tee_rpmb_mem *mem)
> return;
>
> if (mem->phreq_mobj) {
> - thread_rpc_free_payload(mem->phreq_mobj);
> + thread_rpc_free_kernel_payload(mem->phreq_mobj);
> mem->phreq_mobj = NULL;
> }
> if (mem->phresp_mobj) {
> - thread_rpc_free_payload(mem->phresp_mobj);
> + thread_rpc_free_kernel_payload(mem->phresp_mobj);
> mem->phresp_mobj = NULL;
> }
> }
> @@ -440,8 +440,8 @@ static TEE_Result tee_rpmb_alloc(size_t req_size,
> size_t resp_size,
>
> memset(mem, 0, sizeof(*mem));
>
> - mem->phreq_mobj = thread_rpc_alloc_payload(req_s);
> - mem->phresp_mobj = thread_rpc_alloc_payload(resp_s);
> + mem->phreq_mobj = thread_rpc_alloc_kernel_payload(req_s);
> + mem->phresp_mobj = thread_rpc_alloc_kernel_payload(resp_s);
>
> if (!mem->phreq_mobj || !mem->phresp_mobj) {
> res = TEE_ERROR_OUT_OF_MEMORY;
>
> >
> > https://ledge.validation.linaro.org/scheduler/job/87488
> >
> > [[0;32m OK [0m] Finished [0;1;39mFile System Check on /dev/mapper/usr[0m.
> > E/TC:? 0 get_rpc_alloc_res:645 RPC allocation failed. Non-secure world result: ret=0xffff000c ret_origin=0x2
> > E/TC:? 0
> > E/TC:? 0 TA panicked with code 0xffff000c
> > E/LD: Status of TA bc50d971-d4c9-42c4-82cb-343fb7f37896
> > E/LD: arch: aarch64
> > E/LD: region 0: va 0x40005000 pa 0x3061b000 size 0x002000 flags rw-s (ldelf)
> > E/LD: region 1: va 0x40007000 pa 0x3061d000 size 0x008000 flags r-xs (ldelf)
> > E/LD: region 2: va 0x4000f000 pa 0x30625000 size 0x001000 flags rw-s (ldelf)
> > E/LD: region 3: va 0x40010000 pa 0x30626000 size 0x004000 flags rw-s (ldelf)
> > E/LD: region 4: va 0x40014000 pa 0x3062a000 size 0x001000 flags r--s
> > E/LD: region 5: va 0x40015000 pa 0x306b2000 size 0x011000 flags rw-s (stack)
> > E/LD: region 6: va 0x40026000 pa 0xe50ce000 size 0x002000 flags rw-- (param)
> > E/LD: region 7: va 0x40062000 pa 0x00001000 size 0x068000 flags r-xs [0]
> > E/LD: region 8: va 0x400ca000 pa 0x00069000 size 0x01f000 flags rw-s [0]
> > E/LD: [0] bc50d971-d4c9-42c4-82cb-343fb7f37896 @ 0x40062000
> > E/LD: Call stack:
> > E/LD: 0x400a00c0
> > E/LD: 0x40062b40
> > E/LD: 0x400631b8
> > E/LD: 0x40081f44
> > E/LD: 0x4009b060
> > E/LD: 0x40063a2c
> > E/LD: 0x400a6298
> > E/LD: 0x4009b214
> > [ 7.212584] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024
> > [ 7.213281] tpm tpm0: tpm_try_transmit: send(): error -53212
> > [ 7.213820] tpm tpm0: ftpm_tee_tpm_op_send: SUBMIT_COMMAND invoke error: 0xffff3024
> > [ 7.214493] tpm tpm0: tpm_try_transmit: send(): error -53212
> > [ 7.214996] optee-ftpm optee-ta-bc50d971-d4c9-42c4-82cb-343fb7f37896: ftpm_tee_probe: tpm_chip_register failed with rc=-53212
> > Mounting [0;1;39m/sysusr/usr[0m...
> >
> > This series adds the RPMB support in kernel, if HW supports it, but some HW doesn't and the
> > tee-supplicant is emulating it as fall back.
>
> That's just for testing purposes, right? It won't be used to implement
> disk encryption for that HW.
>
> > Userspace needs to know if tee-supplicant start
> > is needed. Thus to me, exporting the RPMB routing details is useful for userspace.
> >
> > It's one thing to have a full control of HW and SW and force a policy, like always
> > waiting for a specific TPM device to appear, but then again distros should be able
> > to have automatic detection of TPM devices if firmware used them too and then
> > start the needed bits in userspace, which depend on the firmware and HW configuration,
> > like which SW components are needed for RPMB storage, kernel or tee-supplicant in userspace.
> >
> > These could possibly be just bugs in fTPM kernel driver and fTPM TA in optee world,
> > which should be able to handle missing RPC and RPMB too and retry later on. Right now
> > without tee-supplicant they panic early in boot and become unusable for the rest of the
> > power cycle.
>
> I very much would like to see fTPM working without dependency on
> tee-supplicant. If there are any further problems you see then please
> feel free to report.
>
> -Sumit
>
> >
> > Cheers,
> >
> > -Mikko

2024-05-29 09:55:22

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

Hi Mikko,

On 10:09 Wed 29 May , Mikko Rapeli wrote:
> On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote:
> > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <[email protected]> wrote:
> > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote:
> > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier
> > > > <[email protected]> wrote:
> > > > > On 5/27/24 14:13, Jens Wiklander wrote:
> > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which
> > > currently requires tee-supplicant to be started. Detecting the existence of TPM before
> > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel
> > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too.
> >
> > One thing I am trying to find an answer about is why do we need to
> > defer tee-supplicant launch if it's bundled into initrd? Once you
> > detect OP-TEE then tee-supplicant should be launched unconditionally.
> > As per your example below, the motivation here seems to be the TPM2
> > device dependent on RPMB backend but what if other future systemd
> > services come up and depend on other services offered by
> > tee-supplicant?
>
> There is an annoying depedency between firmware side optee and TAs, and kernel optee driver,
> tee-supplicant in userspace and kernel TA drivers like fTPM.
>
> Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc.
>
> This patch series is adding kernel side support for RPMB handling so that the dependency to
> tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC
> buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic.
>
> So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers
> and firmware optee trusted applications would not depend on tee-supplicant running in userspace.
> The startup sequence is really tricky to get right. My fTPM use case is using the TPM device
> to encrypt rootfs and thus all SW components including tee-supplicant need to run early in
> initramfs. Currently also switch from initramfs to main rootfs requires unloading
> fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant
> and loading fTPM kernel driver from main rootfs. udev and automatic module loading for
> fTPM can not be used due to the tee-supplicant userspace dependency.

I decided to build fTPM as buildin-TA into OP-TEE. RPMB routing is already
implemented in u-boot so it can already write PCR registers.

With this series and the required changes in OP-TEE and a compiled in fTPM
kernel driver and systemd v256 it is possible to use the fTPM in the initrd
without tee-supplicant.

Maybe this information is helpful to you, regards
Manuel

2024-05-29 14:26:32

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

Hi,

On Wed, May 29, 2024 at 11:38:06AM +0200, Manuel Traut wrote:
> Hi Mikko,
>
> On 10:09 Wed 29 May , Mikko Rapeli wrote:
> > On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote:
> > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <[email protected]> wrote:
> > > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote:
> > > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier
> > > > > <[email protected]> wrote:
> > > > > > On 5/27/24 14:13, Jens Wiklander wrote:
> > > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which
> > > > currently requires tee-supplicant to be started. Detecting the existence of TPM before
> > > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel
> > > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too.
> > >
> > > One thing I am trying to find an answer about is why do we need to
> > > defer tee-supplicant launch if it's bundled into initrd? Once you
> > > detect OP-TEE then tee-supplicant should be launched unconditionally.
> > > As per your example below, the motivation here seems to be the TPM2
> > > device dependent on RPMB backend but what if other future systemd
> > > services come up and depend on other services offered by
> > > tee-supplicant?
> >
> > There is an annoying depedency between firmware side optee and TAs, and kernel optee driver,
> > tee-supplicant in userspace and kernel TA drivers like fTPM.
> >
> > Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc.
> >
> > This patch series is adding kernel side support for RPMB handling so that the dependency to
> > tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC
> > buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic.
> >
> > So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers
> > and firmware optee trusted applications would not depend on tee-supplicant running in userspace.
> > The startup sequence is really tricky to get right. My fTPM use case is using the TPM device
> > to encrypt rootfs and thus all SW components including tee-supplicant need to run early in
> > initramfs. Currently also switch from initramfs to main rootfs requires unloading
> > fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant
> > and loading fTPM kernel driver from main rootfs. udev and automatic module loading for
> > fTPM can not be used due to the tee-supplicant userspace dependency.
>
> I decided to build fTPM as buildin-TA into OP-TEE. RPMB routing is already
> implemented in u-boot so it can already write PCR registers.

Is build in TA same as early TA? I presume so.

> With this series and the required changes in OP-TEE and a compiled in fTPM
> kernel driver and systemd v256 it is possible to use the fTPM in the initrd
> without tee-supplicant.
>
> Maybe this information is helpful to you, regards

This is very interesting and I'm trying to get to the same state, though with
fTPM kernel driver as module. With v6 of this patch set and matching optee changes
I was not able to make this work as fTPM TA was crashing when loading ftpm kernel driver
due to failing RPC allocation, which tee-supplicant was setting up in the whole chain.
I'll try to get v7 patches working and test this again on my yocto based setup and kernel 6.6.y.

Cheers,

-Mikko

2024-05-30 07:35:58

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

Hi Mikko,

On Wed, May 29, 2024 at 05:26:15PM +0300, Mikko Rapeli wrote:
> Hi,
>
> On Wed, May 29, 2024 at 11:38:06AM +0200, Manuel Traut wrote:
> > Hi Mikko,
> >
> > On 10:09 Wed 29 May , Mikko Rapeli wrote:
> > > On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote:
> > > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <[email protected]> wrote:
> > > > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote:
> > > > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier
> > > > > > <[email protected]> wrote:
> > > > > > > On 5/27/24 14:13, Jens Wiklander wrote:
> > > > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which
> > > > > currently requires tee-supplicant to be started. Detecting the existence of TPM before
> > > > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel
> > > > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too.
> > > >
> > > > One thing I am trying to find an answer about is why do we need to
> > > > defer tee-supplicant launch if it's bundled into initrd? Once you
> > > > detect OP-TEE then tee-supplicant should be launched unconditionally.
> > > > As per your example below, the motivation here seems to be the TPM2
> > > > device dependent on RPMB backend but what if other future systemd
> > > > services come up and depend on other services offered by
> > > > tee-supplicant?
> > >
> > > There is an annoying depedency between firmware side optee and TAs, and kernel optee driver,
> > > tee-supplicant in userspace and kernel TA drivers like fTPM.
> > >
> > > Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc.
> > >
> > > This patch series is adding kernel side support for RPMB handling so that the dependency to
> > > tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC
> > > buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic.
> > >
> > > So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers
> > > and firmware optee trusted applications would not depend on tee-supplicant running in userspace.
> > > The startup sequence is really tricky to get right. My fTPM use case is using the TPM device
> > > to encrypt rootfs and thus all SW components including tee-supplicant need to run early in
> > > initramfs. Currently also switch from initramfs to main rootfs requires unloading
> > > fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant
> > > and loading fTPM kernel driver from main rootfs. udev and automatic module loading for
> > > fTPM can not be used due to the tee-supplicant userspace dependency.
> >
> > I decided to build fTPM as buildin-TA into OP-TEE. RPMB routing is already
> > implemented in u-boot so it can already write PCR registers.
>
> Is build in TA same as early TA? I presume so.

Indeed.. sorry for using the wrong term.

> > With this series and the required changes in OP-TEE and a compiled in fTPM
> > kernel driver and systemd v256 it is possible to use the fTPM in the initrd
> > without tee-supplicant.
> >
> > Maybe this information is helpful to you, regards
>
> This is very interesting and I'm trying to get to the same state, though with
> fTPM kernel driver as module. With v6 of this patch set and matching optee changes
> I was not able to make this work as fTPM TA was crashing when loading ftpm kernel driver
> due to failing RPC allocation, which tee-supplicant was setting up in the whole chain.
> I'll try to get v7 patches working and test this again on my yocto based setup and kernel 6.6.y.

I'll try today also with v7 and 6.10-rc1 on an i.MX8MM. It should also
work with fTPM as kernel module if you use systemd in the initrd
with the new tpm.target in systemd v256.

Regards
Manuel

2024-05-30 08:29:28

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

On Thu, May 30, 2024 at 09:35:10AM +0200, Manuel Traut wrote:
> Hi Mikko,
>
> On Wed, May 29, 2024 at 05:26:15PM +0300, Mikko Rapeli wrote:
> > Hi,
> >
> > On Wed, May 29, 2024 at 11:38:06AM +0200, Manuel Traut wrote:
> > > Hi Mikko,
> > >
> > > On 10:09 Wed 29 May , Mikko Rapeli wrote:
> > > > On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote:
> > > > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <[email protected]> wrote:
> > > > > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote:
> > > > > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier
> > > > > > > <[email protected]> wrote:
> > > > > > > > On 5/27/24 14:13, Jens Wiklander wrote:
> > > > > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which
> > > > > > currently requires tee-supplicant to be started. Detecting the existence of TPM before
> > > > > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel
> > > > > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too.
> > > > >
> > > > > One thing I am trying to find an answer about is why do we need to
> > > > > defer tee-supplicant launch if it's bundled into initrd? Once you
> > > > > detect OP-TEE then tee-supplicant should be launched unconditionally.
> > > > > As per your example below, the motivation here seems to be the TPM2
> > > > > device dependent on RPMB backend but what if other future systemd
> > > > > services come up and depend on other services offered by
> > > > > tee-supplicant?
> > > >
> > > > There is an annoying depedency between firmware side optee and TAs, and kernel optee driver,
> > > > tee-supplicant in userspace and kernel TA drivers like fTPM.
> > > >
> > > > Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc.
> > > >
> > > > This patch series is adding kernel side support for RPMB handling so that the dependency to
> > > > tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC
> > > > buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic.
> > > >
> > > > So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers
> > > > and firmware optee trusted applications would not depend on tee-supplicant running in userspace.
> > > > The startup sequence is really tricky to get right. My fTPM use case is using the TPM device
> > > > to encrypt rootfs and thus all SW components including tee-supplicant need to run early in
> > > > initramfs. Currently also switch from initramfs to main rootfs requires unloading
> > > > fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant
> > > > and loading fTPM kernel driver from main rootfs. udev and automatic module loading for
> > > > fTPM can not be used due to the tee-supplicant userspace dependency.
> > >
> > > I decided to build fTPM as buildin-TA into OP-TEE. RPMB routing is already
> > > implemented in u-boot so it can already write PCR registers.
> >
> > Is build in TA same as early TA? I presume so.
>
> Indeed.. sorry for using the wrong term.

Ok, no problem. Then we have the same fTPM TA setup. I'm using optee 4.1
with RPMB kernel support changes from Jens cherry-picked on top.

> > > With this series and the required changes in OP-TEE and a compiled in fTPM
> > > kernel driver and systemd v256 it is possible to use the fTPM in the initrd
> > > without tee-supplicant.
> > >
> > > Maybe this information is helpful to you, regards
> >
> > This is very interesting and I'm trying to get to the same state, though with
> > fTPM kernel driver as module. With v6 of this patch set and matching optee changes
> > I was not able to make this work as fTPM TA was crashing when loading ftpm kernel driver
> > due to failing RPC allocation, which tee-supplicant was setting up in the whole chain.
> > I'll try to get v7 patches working and test this again on my yocto based setup and kernel 6.6.y.
>
> I'll try today also with v7 and 6.10-rc1 on an i.MX8MM. It should also
> work with fTPM as kernel module if you use systemd in the initrd
> with the new tpm.target in systemd v256.

Thanks for the details. I'm testing on qemu, rockpi4b (Rockchip rk3399 SoC) and synquacer
(Socionext Developer Box, SC2A11:Cortex-A53 MPCore 24cores). Kernel and rootfs
are from our yocto master branch based Trusted Reference Stack distro
( https://gitlab.com/Linaro/trusted-reference-stack/trs )
with kernel 6.6.29 (porting the RPMB v7 patches currently), systemd 255.4 (tpm2.target
backported), tee-supplicant 4.1 etc. I'm switching the initramfs from shell scripts
to systemd currently, but running into various issues.

UEFI firmware is our Trusted Substrate ( https://gitlab.com/Linaro/trustedsubstrate/meta-ts/ )
ARM System Ready IR compatible with secure boot and TPM support, u-boot
2024.04 (except rockpi4b still on 2023.01), optee 4.1, fTPM etc from meta-arm
yocto layer.

Booting without tee-supplicant has so far only resulted in the fTPM TA panic'ing
because RPC setup is failing. Also the fTPM TA enumation needs to be changed
from current yocto defaults to always discoverable if there is no tee-supplicant:
https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-security/optee-ftpm/optee-ftpm/0001-add-enum-to-ta-flags.patch

I hope to get v7 of these patches into testing today.

Cheers,

-Mikko

2024-05-30 14:22:33

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

On Thu, May 30, 2024 at 11:29:11AM +0300, Mikko Rapeli wrote:
> On Thu, May 30, 2024 at 09:35:10AM +0200, Manuel Traut wrote:
> > Hi Mikko,
> >
> > On Wed, May 29, 2024 at 05:26:15PM +0300, Mikko Rapeli wrote:
> > > Hi,
> > >
> > > On Wed, May 29, 2024 at 11:38:06AM +0200, Manuel Traut wrote:
> > > > Hi Mikko,
> > > >
> > > > On 10:09 Wed 29 May , Mikko Rapeli wrote:
> > > > > On Wed, May 29, 2024 at 10:56:04AM +0530, Sumit Garg wrote:
> > > > > > On Tue, 28 May 2024 at 15:00, Mikko Rapeli <[email protected]> wrote:
> > > > > > > On Mon, May 27, 2024 at 03:24:01PM +0200, Jens Wiklander wrote:
> > > > > > > > On Mon, May 27, 2024 at 3:00 PM Jerome Forissier
> > > > > > > > <[email protected]> wrote:
> > > > > > > > > On 5/27/24 14:13, Jens Wiklander wrote:
> > > > > > > Outside of these patches, I think the optee RPC setup with fTPM TA is one area which
> > > > > > > currently requires tee-supplicant to be started. Detecting the existence of TPM before
> > > > > > > kernel drivers are loaded is possible via the exported EFI logs from firmware to kernel
> > > > > > > or ACPI TPM2 table entry, and detecting optee and thus starting tee-supplicant in userspace too.
> > > > > >
> > > > > > One thing I am trying to find an answer about is why do we need to
> > > > > > defer tee-supplicant launch if it's bundled into initrd? Once you
> > > > > > detect OP-TEE then tee-supplicant should be launched unconditionally.
> > > > > > As per your example below, the motivation here seems to be the TPM2
> > > > > > device dependent on RPMB backend but what if other future systemd
> > > > > > services come up and depend on other services offered by
> > > > > > tee-supplicant?
> > > > >
> > > > > There is an annoying depedency between firmware side optee and TAs, and kernel optee driver,
> > > > > tee-supplicant in userspace and kernel TA drivers like fTPM.
> > > > >
> > > > > Kernel fTPM driver and fTPM TA require tee-supplicant in userspace for RPMB, RPC etc.
> > > > >
> > > > > This patch series is adding kernel side support for RPMB handling so that the dependency to
> > > > > tee-supplicant in userspace can be removed. For fTPM use case, there is still the optee RPC
> > > > > buffer setup which currently requires tee-supplicant in userspace or fTPM TA will panic.
> > > > >
> > > > > So yes, currently, tee-supplicant must be started. But it would be great if kernel drivers
> > > > > and firmware optee trusted applications would not depend on tee-supplicant running in userspace.
> > > > > The startup sequence is really tricky to get right. My fTPM use case is using the TPM device
> > > > > to encrypt rootfs and thus all SW components including tee-supplicant need to run early in
> > > > > initramfs. Currently also switch from initramfs to main rootfs requires unloading
> > > > > fTPM kernel driver and stopping tee-supplicant in initrd, and then starting tee-supplicant
> > > > > and loading fTPM kernel driver from main rootfs. udev and automatic module loading for
> > > > > fTPM can not be used due to the tee-supplicant userspace dependency.
> > > >
> > > > I decided to build fTPM as buildin-TA into OP-TEE. RPMB routing is already
> > > > implemented in u-boot so it can already write PCR registers.
> > >
> > > Is build in TA same as early TA? I presume so.
> >
> > Indeed.. sorry for using the wrong term.
>
> Ok, no problem. Then we have the same fTPM TA setup. I'm using optee 4.1
> with RPMB kernel support changes from Jens cherry-picked on top.
>
> > > > With this series and the required changes in OP-TEE and a compiled in fTPM
> > > > kernel driver and systemd v256 it is possible to use the fTPM in the initrd
> > > > without tee-supplicant.
> > > >
> > > > Maybe this information is helpful to you, regards
> > >
> > > This is very interesting and I'm trying to get to the same state, though with
> > > fTPM kernel driver as module. With v6 of this patch set and matching optee changes
> > > I was not able to make this work as fTPM TA was crashing when loading ftpm kernel driver
> > > due to failing RPC allocation, which tee-supplicant was setting up in the whole chain.
> > > I'll try to get v7 patches working and test this again on my yocto based setup and kernel 6.6.y.
> >
> > I'll try today also with v7 and 6.10-rc1 on an i.MX8MM. It should also
> > work with fTPM as kernel module if you use systemd in the initrd
> > with the new tpm.target in systemd v256.
>
> Thanks for the details. I'm testing on qemu, rockpi4b (Rockchip rk3399 SoC) and synquacer
> (Socionext Developer Box, SC2A11:Cortex-A53 MPCore 24cores). Kernel and rootfs
> are from our yocto master branch based Trusted Reference Stack distro
> ( https://gitlab.com/Linaro/trusted-reference-stack/trs )
> with kernel 6.6.29 (porting the RPMB v7 patches currently), systemd 255.4 (tpm2.target
> backported), tee-supplicant 4.1 etc. I'm switching the initramfs from shell scripts
> to systemd currently, but running into various issues.

I just use a mkosi generated Debian/sid image..

> UEFI firmware is our Trusted Substrate ( https://gitlab.com/Linaro/trustedsubstrate/meta-ts/ )

This is a cool project! I was not aware of it. Thanks for sharing.

> ARM System Ready IR compatible with secure boot and TPM support, u-boot
> 2024.04 (except rockpi4b still on 2023.01), optee 4.1, fTPM etc from meta-arm
> yocto layer.

I am on a Toradex Verdin board with an i.MX8MM SoM. u-boot is still
2024.01, optee_os from Jens referenced branch, with a little change in:

lib/libutee/include/user_ta_header.h

-#define TA_FLAGS_MASK GENMASK_32(10, 0)
+#define TA_FLAGS_MASK GENMASK_32(12, 0)

fTPM is from ms-tpm-20-ref.git on github. Need to check what is in the meta-arm.
Figured out some problems with this regarding OrPolicies used by
systemd-cryptenroll..

> Booting without tee-supplicant has so far only resulted in the fTPM TA panic'ing
> because RPC setup is failing. Also the fTPM TA enumation needs to be changed
> from current yocto defaults to always discoverable if there is no tee-supplicant:
> https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-security/optee-ftpm/optee-ftpm/0001-add-enum-to-ta-flags.patch

Ah, seems to be the same change than above, just limited to the fTPM TA?
Shouldn't it be part of optee_os since it is a capability of it?

> I hope to get v7 of these patches into testing today.

Was able to test it. But ended also in TA panic. Will share the details
in another mail.

Regards
Manuel

2024-05-30 14:40:11

[permalink] [raw]

Subject: Re: [PATCH v7 0/4] Replay Protected Memory Block (RPMB) subsystem

Hi Jens,

On Mon, May 27, 2024 at 02:13:36PM +0200, Jens Wiklander wrote:
> Hi,
>
> This patch set introduces a new RPMB subsystem, based on patches from [1],
> [2], and [3]. The RPMB subsystem aims at providing access to RPMB
> partitions to other kernel drivers, in particular the OP-TEE driver. A new
> user space ABI isn't needed, we can instead continue using the already
> present ABI when writing the RPMB key during production.
>
> I've added and removed things to keep only what is needed by the OP-TEE
> driver. Since the posting of [3], there has been major changes in the MMC
> subsystem so "mmc: block: register RPMB partition with the RPMB subsystem"
> is in practice completely rewritten.
>
> With this OP-TEE can access RPMB during early boot instead of having to
> wait for user space to become available as in the current design [4].
> This will benefit the efi variables [5] since we won't rely on userspace as
> well as some TPM issues [6] that were solved.

I applied the patches to 6.10~rc1 today and tried them on a Toradex
Verdin Board with an i.MX8MM.

> The OP-TEE driver finds the correct RPMB device to interact with by
> iterating over available devices until one is found with a programmed
> authentication matching the one OP-TEE is using. This enables coexisting
> users of other RPMBs since the owner can be determined by who knows the
> authentication key.

The probing does not work for me.

> The corresponding secure world OP-TEE patches are available at [7].

I added some debug prints to see that the optee side properly detected
the need to reinit in tee_rpmb_init. The rpmb_ctx->key_verified is false
and the following call of rpmb_probe_reset fails which leads to the
panic of the TA trying to do a rpmb request.

Same codeflow can be seen earlier during probing the rpmb device but
without the panic.

I am not sure if I find time to look at it in more detail tomorrow.
Otherwise next week.

Thanks
Manuel

> I've put myself as a maintainer for the RPMB subsystem as I have an
> interest in the OP-TEE driver to keep this in good shape. However, if you'd
> rather see someone else taking the maintainership that's fine too. I'll
> help keep the subsystem updated regardless.
>
> [1] https://lore.kernel.org/lkml/[email protected]/
> [2] https://lore.kernel.org/lkml/[email protected]/
> [3] https://lore.kernel.org/linux-mmc/[email protected]/
> [4] https://optee.readthedocs.io/en/latest/architecture/secure_storage.html#rpmb-secure-storage
> [5] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c44b6be62e8dd4ee0a308c36a70620613e6fc55f
> [6] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7269cba53d906cf257c139d3b3a53ad272176bca
> [7] https://github.com/jenswi-linaro/optee_os/tree/rpmb_probe_v7
>
> Thanks,
> Jens
>
> Changes since v6:
> * Add Tested-by: Manuel Traut <[email protected]> provided for the v6
> * Add a new patch "tee: add tee_device_set_dev_groups()" needed later in
> the patch set
> * Reintroduce the rpmb_class as requested by Greg, this affects the patches
> "rpmb: add Replay Protected Memory Block (RPMB) subsystem" and
> "optee: probe RPMB device using RPMB subsystem"
> * "rpmb: add Replay Protected Memory Block (RPMB) subsystem":
> - rpmb_interface_{,un}register() are now based on
> class_interface_{,un}register()
> - Embed a separate device in struct rpmb_dev for life cycle
> management etc
> * "optee: probe RPMB device using RPMB subsystem"
> - Add an internal blocking_notifier to deal with the struct
> class_interface callback
> - Add a rpmb_routing_model variable in sysfs to help integration with
> systemd, requested by Mikko Rapeli
> - Add an RPMB probe capability flag in the ABI shared with the secure
> world, both SMC and FF-A ABI, needed to support the rpmb_routing_model
> variable
> - optee_rpc_cmd() is strict whether an RPMB RPC request should be
> forwarded to tee-supplicant or routed via the RPMB subsystem, depending
> on the reported RPMB routing model
>
> Changes since v5:
> Manuel Traut reported and investigated an error on an i.MX8MM, the root
> cause was identified as insufficient alignment on frames sent to the RPMB
> device. Fixed in the OP-TEE driver as described below.
> * "rpmb: add Replay Protected Memory Block (RPMB) subsystem"
> - Adding a missing EXPORT_SYMBOL_GPL()
> * "optee: probe RPMB device using RPMB subsystem"
> - Replacing the old OPTEE_RPC_CMD_RPMB ABI with OPTEE_RPC_CMD_RPMB_FRAMES
> to get rid of the small header struct rpmb_req (now removed) causing
> the problem.
> - Matching changes on the secure side + support for re-initializing
> RPMB in case a boot stage has used RPMB, the latter also reported by
> Manuel Traut.
>
> Changes since v4:
> * "rpmb: add Replay Protected Memory Block (RPMB) subsystem"
> - Describing struct rpmb_descr as RPMB description instead of descriptor
> * "mmc: block: register RPMB partition with the RPMB subsystem"
> - Addressing review comments
> - Adding more comments for struct rpmb_frame
> - Fixing assignment of reliable_wr_count and capacity in mmc_blk_rpmb_add()
> * "optee: probe RPMB device using RPMB subsystem"
> - Updating struct rpmb_dev_info to match changes in "rpmb: add Replay
> Protected Memory Block (RPMB) subsystem"
>
> Changes since v3:
> * Move struct rpmb_frame into the MMC driver since the format of the RPMB
> frames depend on the implementation, one format for eMMC, another for
> UFS, and so on
> * "rpmb: add Replay Protected Memory Block (RPMB) subsystem"
> - Adding Reviewed-by: Linus Walleij <[email protected]>
> - Adding more description of the API functions
> - Removing the set_dev_info() op from struct rpmb_ops, the needed information
> is supplied in the arguments to rpmb_dev_register() instead.
> - Getting rid of struct rpmb_ops since only the route_frames() op was
> remaining, store that op directly in struct rpmb_dev
> - Changed rpmb_interface_register() and rpmb_interface_unregister() to use
> notifier_block instead of implementing the same thing ourselves
> * "mmc: block: register RPMB partition with the RPMB subsystem"
> - Moving the call to rpmb_dev_register() to be done at the end of
> mmc_blk_probe() when the device is fully available
> * "optee: probe RPMB device using RPMB subsystem"
> - Use IS_REACHABLE(CONFIG_RPMB) to determine if the RPMB subsystem is
> available
> - Translate TEE_ERROR_STORAGE_NOT_AVAILABLE if encountered in get_devices()
> to recognize the error in optee_rpmb_scan()
> - Simplified optee_rpmb_scan() and optee_rpmb_intf_rdev()
>
> Changes since v2:
> * "rpmb: add Replay Protected Memory Block (RPMB) subsystem"
> - Fixing documentation issues
> - Adding a "depends on MMC" in the Kconfig
> - Removed the class-device and the embedded device, struct rpmb_dev now
> relies on the parent device for reference counting as requested
> - Removed the now unneeded rpmb_ops get_resources() and put_resources()
> since references are already taken in mmc_blk_alloc_rpmb_part() before
> rpmb_dev_register() is called
> - Added rpmb_interface_{,un}register() now that
> class_interface_{,un}register() can't be used ay longer
> * "mmc: block: register RPMB partition with the RPMB subsystem"
> - Adding the missing error cleanup in alloc_idata()
> - Taking the needed reference to md->disk in mmc_blk_alloc_rpmb_part()
> instead of in mmc_rpmb_chrdev_open() and rpmb_op_mmc_get_resources()
> * "optee: probe RPMB device using RPMB subsystem"
> - Registering to get a notification when an RPMB device comes online
> - Probes for RPMB devices each time an RPMB device comes online, until
> a usable device is found
> - When a usable RPMB device is found, call
> optee_enumerate_devices(PTA_CMD_GET_DEVICES_RPMB)
> - Pass type of rpmb in return value from OPTEE_RPC_CMD_RPMB_PROBE_NEXT
>
> Changes since Shyam's RFC:
> * Removed the remaining leftover rpmb_cdev_*() function calls
> * Refactored the struct rpmb_ops with all the previous ops replaced, in
> some sense closer to [3] with the route_frames() op
> * Added rpmb_route_frames()
> * Added struct rpmb_frame, enum rpmb_op_result, and enum rpmb_type from [3]
> * Removed all functions not needed in the OP-TEE use case
> * Added "mmc: block: register RPMB partition with the RPMB subsystem", based
> on the commit with the same name in [3]
> * Added "optee: probe RPMB device using RPMB subsystem" for integration
> with OP-TEE
> * Moved the RPMB driver into drivers/misc/rpmb-core.c
> * Added my name to MODULE_AUTHOR() in rpmb-core.c
> * Added an rpmb_mutex to serialize access to the IDA
> * Removed the target parameter from all rpmb_*() functions since it's
> currently unused
>
>
> Jens Wiklander (4):
> rpmb: add Replay Protected Memory Block (RPMB) subsystem
> mmc: block: register RPMB partition with the RPMB subsystem
> tee: add tee_device_set_dev_groups()
> optee: probe RPMB device using RPMB subsystem
>
> Documentation/ABI/testing/sysfs-class-tee | 15 ++
> MAINTAINERS | 8 +
> drivers/misc/Kconfig | 10 +
> drivers/misc/Makefile | 1 +
> drivers/misc/rpmb-core.c | 232 +++++++++++++++++++++
> drivers/mmc/core/block.c | 241 +++++++++++++++++++++-
> drivers/tee/optee/core.c | 96 ++++++++-
> drivers/tee/optee/device.c | 7 +
> drivers/tee/optee/ffa_abi.c | 14 ++
> drivers/tee/optee/optee_ffa.h | 2 +
> drivers/tee/optee/optee_private.h | 26 ++-
> drivers/tee/optee/optee_rpc_cmd.h | 35 ++++
> drivers/tee/optee/optee_smc.h | 2 +
> drivers/tee/optee/rpc.c | 177 ++++++++++++++++
> drivers/tee/optee/smc_abi.c | 14 ++
> drivers/tee/tee_core.c | 19 +-
> include/linux/rpmb.h | 123 +++++++++++
> include/linux/tee_drv.h | 12 ++
> 18 files changed, 1024 insertions(+), 10 deletions(-)
> create mode 100644 Documentation/ABI/testing/sysfs-class-tee
> create mode 100644 drivers/misc/rpmb-core.c
> create mode 100644 include/linux/rpmb.h
>
> --
> 2.34.1
>

2024-06-03 09:10:26

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

On 14:13 Mon 27 May , Jens Wiklander wrote:
> --- a/drivers/tee/optee/ffa_abi.c
> +++ b/drivers/tee/optee/ffa_abi.c
> @@ -7,6 +7,7 @@
>
> #include <linux/arm_ffa.h>
> #include <linux/errno.h>
> +#include <linux/rpmb.h>
> #include <linux/scatterlist.h>
> #include <linux/sched.h>
> #include <linux/slab.h>
> @@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
> optee->ffa.bottom_half_value = U32_MAX;
> optee->rpc_param_count = rpc_param_count;
>
> + if (IS_REACHABLE(CONFIG_RPMB) &&
> + (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE))
> + optee->in_kernel_rpmb_routing = true;

The SEC_CAP_RPMB_PROBE flag seems to be missing in optee_os at the moment.
If I remove this check here, the series works for me.

Cheers
Manuel

2024-06-10 12:52:52

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

Hi Manuel,

On Mon, Jun 3, 2024 at 11:10 AM Manuel Traut <[email protected]> wrote:
>
> On 14:13 Mon 27 May , Jens Wiklander wrote:
> > --- a/drivers/tee/optee/ffa_abi.c
> > +++ b/drivers/tee/optee/ffa_abi.c
> > @@ -7,6 +7,7 @@
> >
> > #include <linux/arm_ffa.h>
> > #include <linux/errno.h>
> > +#include <linux/rpmb.h>
> > #include <linux/scatterlist.h>
> > #include <linux/sched.h>
> > #include <linux/slab.h>
> > @@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
> > optee->ffa.bottom_half_value = U32_MAX;
> > optee->rpc_param_count = rpc_param_count;
> >
> > + if (IS_REACHABLE(CONFIG_RPMB) &&
> > + (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE))
> > + optee->in_kernel_rpmb_routing = true;
>
> The SEC_CAP_RPMB_PROBE flag seems to be missing in optee_os at the moment.
> If I remove this check here, the series works for me.

You're right, I missed pushing those flags to optee_os. I've pushed them now.

Cheers,
Jens

2024-06-11 03:12:43

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

Hi,

On Mon, Jun 10, 2024 at 02:52:31PM +0200, Jens Wiklander wrote:
> Hi Manuel,
>
> On Mon, Jun 3, 2024 at 11:10 AM Manuel Traut <[email protected]> wrote:
> >
> > On 14:13 Mon 27 May , Jens Wiklander wrote:
> > > --- a/drivers/tee/optee/ffa_abi.c
> > > +++ b/drivers/tee/optee/ffa_abi.c
> > > @@ -7,6 +7,7 @@
> > >
> > > #include <linux/arm_ffa.h>
> > > #include <linux/errno.h>
> > > +#include <linux/rpmb.h>
> > > #include <linux/scatterlist.h>
> > > #include <linux/sched.h>
> > > #include <linux/slab.h>
> > > @@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
> > > optee->ffa.bottom_half_value = U32_MAX;
> > > optee->rpc_param_count = rpc_param_count;
> > >
> > > + if (IS_REACHABLE(CONFIG_RPMB) &&
> > > + (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE))
> > > + optee->in_kernel_rpmb_routing = true;
> >
> > The SEC_CAP_RPMB_PROBE flag seems to be missing in optee_os at the moment.
> > If I remove this check here, the series works for me.
>
> You're right, I missed pushing those flags to optee_os. I've pushed them now.

Thanks! Tested with optee 4.1 and your patches from
https://github.com/jenswi-linaro/optee_os/commits/rpmb_probe_v7/
in Trusted Substrate uefi firmware
( https://gitlab.com/Linaro/trustedsubstrate/meta-ts/ )
and this series and a bunch of dependencies backported to
our Trusted Reference Stack
( https://trs.readthedocs.io/en/latest/ )
6.6.29 kernel on rockpi4b (rk3399 ARM64 SoC) with secure boot and
the optee side fTPM TA device used to create an encrypted rootfs with
systemd. Kernel side RPMB routing is in use and works for the TPM use cases.

Full boot and test log (with unrelated test failures)
https://ledge.validation.linaro.org/scheduler/job/88692

root@trs-qemuarm64:~# cat /sys/class/tee/tee0/rpmb_routing_model
...
kernel

Tested-by: Mikko Rapeli <[email protected]>

Cheers,

-Mikko

2024-06-11 10:43:45

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

On Tue, 11 Jun 2024 at 08:32, Mikko Rapeli <[email protected]> wrote:
>
> Hi,
>
> On Mon, Jun 10, 2024 at 02:52:31PM +0200, Jens Wiklander wrote:
> > Hi Manuel,
> >
> > On Mon, Jun 3, 2024 at 11:10 AM Manuel Traut <[email protected]> wrote:
> > >
> > > On 14:13 Mon 27 May , Jens Wiklander wrote:
> > > > --- a/drivers/tee/optee/ffa_abi.c
> > > > +++ b/drivers/tee/optee/ffa_abi.c
> > > > @@ -7,6 +7,7 @@
> > > >
> > > > #include <linux/arm_ffa.h>
> > > > #include <linux/errno.h>
> > > > +#include <linux/rpmb.h>
> > > > #include <linux/scatterlist.h>
> > > > #include <linux/sched.h>
> > > > #include <linux/slab.h>
> > > > @@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
> > > > optee->ffa.bottom_half_value = U32_MAX;
> > > > optee->rpc_param_count = rpc_param_count;
> > > >
> > > > + if (IS_REACHABLE(CONFIG_RPMB) &&
> > > > + (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE))
> > > > + optee->in_kernel_rpmb_routing = true;
> > >
> > > The SEC_CAP_RPMB_PROBE flag seems to be missing in optee_os at the moment.
> > > If I remove this check here, the series works for me.
> >
> > You're right, I missed pushing those flags to optee_os. I've pushed them now.
>
> Thanks! Tested with optee 4.1 and your patches from
> https://github.com/jenswi-linaro/optee_os/commits/rpmb_probe_v7/
> in Trusted Substrate uefi firmware
> ( https://gitlab.com/Linaro/trustedsubstrate/meta-ts/ )
> and this series and a bunch of dependencies backported to
> our Trusted Reference Stack
> ( https://trs.readthedocs.io/en/latest/ )
> 6.6.29 kernel on rockpi4b (rk3399 ARM64 SoC) with secure boot and
> the optee side fTPM TA device used to create an encrypted rootfs with
> systemd. Kernel side RPMB routing is in use and works for the TPM use cases.
>

Glad to see that you can get fTPM to work without tee-supplicant after
this patch-set.

> Full boot and test log (with unrelated test failures)
> https://ledge.validation.linaro.org/scheduler/job/88692
>
> root@trs-qemuarm64:~# cat /sys/class/tee/tee0/rpmb_routing_model
> ...
> kernel

So coming back to the real question, do we really need this new
rpmb_routing_model ABI? Did systemd still need it with no
tee-supplicant dependency? IMHO, a user-space ABI requires use-case
justification otherwise it's just going to add on maintenance burden.

-Sumit

>
> Tested-by: Mikko Rapeli <[email protected]>
>
> Cheers,
>
> -Mikko

2024-06-12 01:14:24

[permalink] [raw]

Subject: Re: [PATCH v7 4/4] optee: probe RPMB device using RPMB subsystem

Hi,

Adding TPM maintainers and linux-integrity since discussion relates to firmware TPM
driver tpm_ftpm_tee

On Tue, Jun 11, 2024 at 04:13:21PM +0530, Sumit Garg wrote:
> On Tue, 11 Jun 2024 at 08:32, Mikko Rapeli <[email protected]> wrote:
> >
> > Hi,
> >
> > On Mon, Jun 10, 2024 at 02:52:31PM +0200, Jens Wiklander wrote:
> > > Hi Manuel,
> > >
> > > On Mon, Jun 3, 2024 at 11:10 AM Manuel Traut <[email protected]> wrote:
> > > >
> > > > On 14:13 Mon 27 May , Jens Wiklander wrote:
> > > > > --- a/drivers/tee/optee/ffa_abi.c
> > > > > +++ b/drivers/tee/optee/ffa_abi.c
> > > > > @@ -7,6 +7,7 @@
> > > > >
> > > > > #include <linux/arm_ffa.h>
> > > > > #include <linux/errno.h>
> > > > > +#include <linux/rpmb.h>
> > > > > #include <linux/scatterlist.h>
> > > > > #include <linux/sched.h>
> > > > > #include <linux/slab.h>
> > > > > @@ -903,6 +904,10 @@ static int optee_ffa_probe(struct ffa_device *ffa_dev)
> > > > > optee->ffa.bottom_half_value = U32_MAX;
> > > > > optee->rpc_param_count = rpc_param_count;
> > > > >
> > > > > + if (IS_REACHABLE(CONFIG_RPMB) &&
> > > > > + (sec_caps & OPTEE_FFA_SEC_CAP_RPMB_PROBE))
> > > > > + optee->in_kernel_rpmb_routing = true;
> > > >
> > > > The SEC_CAP_RPMB_PROBE flag seems to be missing in optee_os at the moment.
> > > > If I remove this check here, the series works for me.
> > >
> > > You're right, I missed pushing those flags to optee_os. I've pushed them now.
> >
> > Thanks! Tested with optee 4.1 and your patches from
> > https://github.com/jenswi-linaro/optee_os/commits/rpmb_probe_v7/
> > in Trusted Substrate uefi firmware
> > ( https://gitlab.com/Linaro/trustedsubstrate/meta-ts/ )
> > and this series and a bunch of dependencies backported to
> > our Trusted Reference Stack
> > ( https://trs.readthedocs.io/en/latest/ )
> > 6.6.29 kernel on rockpi4b (rk3399 ARM64 SoC) with secure boot and
> > the optee side fTPM TA device used to create an encrypted rootfs with
> > systemd. Kernel side RPMB routing is in use and works for the TPM use cases.
> >
>
> Glad to see that you can get fTPM to work without tee-supplicant after
> this patch-set.

Sorry but the fTPM TA only works with tee-supplicant in userspace. It's needed
for RPC setup. For RPMB it is not needed or used with these patches applied.

> > Full boot and test log (with unrelated test failures)
> > https://ledge.validation.linaro.org/scheduler/job/88692
> >
> > root@trs-qemuarm64:~# cat /sys/class/tee/tee0/rpmb_routing_model
> > ...
> > kernel
>
> So coming back to the real question, do we really need this new
> rpmb_routing_model ABI? Did systemd still need it with no
> tee-supplicant dependency? IMHO, a user-space ABI requires use-case
> justification otherwise it's just going to add on maintenance burden.

Currently it is not needed, because tee-supplicant is still required to
setup RPC with fTPM. If the RPC setup were also done in kernel directly and
tee-supplicant need is removed, then this kind of ABI is important so that
userspace init knows if it needs to queue startup of tee-supplicant or not.

On a related note, the kernel tpm_ftpm_tee driver for fTPM TA really has
a hard dependency to tee-supplicant in userspace. If tee-supplicant is stopped,
restarted etc without unloading the kernel module (or otherwise disabling the TPM device),
then all TPM device actions done without tee-supplicant running will fail ane keep
failing until next reboot. The kernel driver is not crashing but all functionality
breaks.

The availability of tpm_ftpm_tee should be tied much harder to the tee-supplicant
running in userspace, e.g. optee should be in charge to start and bring tpm_ftpm_tee down
based on tee-supplicant userspace daemon availability. Or the needed tee-supplicant code
should be moved to kernel side. Currently systemd side init scripts have issues switching
from initrd to main rootfs since they need to disable tpm_ftpm_tee driver, built in or a module,
before shutting down tee-supplicant. A suspend or other inactive state in the ftpm driver
needs to be triggered, which AFAIK is not currently possible, at least from userspace
(I'd happy be proven wrong here).

An alternative for tpm_fptm_tee driver is to use optee APIs so that the calls
wait for tee-supplicant in userspace if needed:

--- a/drivers/char/tpm/tpm_ftpm_tee.c
+++ b/drivers/char/tpm/tpm_ftpm_tee.c
@@ -237,6 +237,9 @@ static int ftpm_tee_probe(struct device *dev)
return PTR_ERR(pvt_data->ctx);
}

+ /* wait for tee-supplicant in userspace, fTPM TA really depends on it */
+ pvt_data->ctx->supp_nowait = false;
+
/* Open a session with fTPM TA */
memset(&sess_arg, 0, sizeof(sess_arg));
export_uuid(sess_arg.uuid, &ftpm_ta_uuid);

This works pretty well for the tee-supplicant initrd to main rootfs switch but currently
breaks for example reboot (just hangs), and Jens doesn't approve of this as a
real solution.

So as an alternative, userspace needs to be very careful in initrd and rootfs
to start tee-supplicant earlier than loading tpm_ftpm_tee driver which can
only be supported as module and removed before shutting down tee-supplicant.
In other use cases, TPM drivers are only supported if driver is built into
the kernel (or ACPI table entry for a TPM device exists) which I'm trying
to change with

[PATCH] efi: expose TPM event log to userspace via sysfs

https://lore.kernel.org/lkml/[email protected]/

where userspace init can check if it should wait longer for the tpm device to appear,
e.g. let udev load optee etc drivers which eventually start also tee-supplicant and
thus load tpm_ftpm_tee driver (fTPM TA enumration is tied to tee-supplicant in userspace
https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-security/optee-ftpm/optee-ftpm/0001-add-enum-to-ta-flags.patch )

Cheers,

-Mikko

2024-06-12 06:56:43