* [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-01-31 17:43 [PATCH v2 0/3] Replay Protected Memory Block (RPMB) subsystem Jens Wiklander
@ 2024-01-31 17:43 ` Jens Wiklander
2024-01-31 21:13 ` Greg Kroah-Hartman
` (2 more replies)
2024-01-31 17:43 ` [PATCH v2 2/3] mmc: block: register RPMB partition with the RPMB subsystem Jens Wiklander
` (2 subsequent siblings)
3 siblings, 3 replies; 22+ messages in thread
From: Jens Wiklander @ 2024-01-31 17:43 UTC (permalink / raw)
To: linux-kernel, linux-mmc, op-tee
Cc: Shyam Saini, Ulf Hansson, Jerome Forissier, Sumit Garg,
Ilias Apalodimas, Bart Van Assche, Randy Dunlap, Ard Biesheuvel,
Arnd Bergmann, Greg Kroah-Hartman, Jens Wiklander, Tomas Winkler,
Alex Bennée
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: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. 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 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
class_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 <tomas.winkler@intel.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
---
MAINTAINERS | 7 ++
drivers/misc/Kconfig | 9 ++
drivers/misc/Makefile | 1 +
drivers/misc/rpmb-core.c | 247 +++++++++++++++++++++++++++++++++++++++
include/linux/rpmb.h | 184 +++++++++++++++++++++++++++++
5 files changed, 448 insertions(+)
create mode 100644 drivers/misc/rpmb-core.c
create mode 100644 include/linux/rpmb.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 8999497011a2..e83152c42499 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -19012,6 +19012,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 <jens.wiklander@linaro.org>
+L: linux-kernel@vger.kernel.org
+S: Supported
+F: drivers/misc/rpmb-core.c
+F: include/linux/rpmb.h
+
RPMSG TTY DRIVER
M: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
L: linux-remoteproc@vger.kernel.org
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 4fb291f0bf7c..891aa5763666 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -104,6 +104,15 @@ config PHANTOM
If you choose to build module, its name will be phantom. If unsure,
say N here.
+config RPMB
+ tristate "RPMB partition interface"
+ 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..a3c289051687
--- /dev/null
+++ b/drivers/misc/rpmb-core.c
@@ -0,0 +1,247 @@
+// 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 DEFINE_IDA(rpmb_ida);
+static DEFINE_MUTEX(rpmb_mutex);
+
+/**
+ * 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->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->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
+ *
+ * @return < 0 on failure
+ */
+int rpmb_route_frames(struct rpmb_dev *rdev, u8 *req,
+ unsigned int req_len, u8 *rsp, unsigned int rsp_len)
+{
+ struct rpmb_frame *frm = (struct rpmb_frame *)req;
+ u16 req_type;
+ bool write;
+
+ if (!req || req_len < sizeof(*frm) || !rsp || !rsp_len)
+ return -EINVAL;
+
+ req_type = be16_to_cpu(frm->req_resp);
+ switch (req_type) {
+ case RPMB_PROGRAM_KEY:
+ if (req_len != sizeof(struct rpmb_frame) ||
+ rsp_len != sizeof(struct rpmb_frame))
+ return -EINVAL;
+ write = true;
+ break;
+ case RPMB_GET_WRITE_COUNTER:
+ if (req_len != sizeof(struct rpmb_frame) ||
+ rsp_len != sizeof(struct rpmb_frame))
+ return -EINVAL;
+ write = false;
+ break;
+ case RPMB_WRITE_DATA:
+ if (req_len % sizeof(struct rpmb_frame) ||
+ rsp_len != sizeof(struct rpmb_frame))
+ return -EINVAL;
+ write = true;
+ break;
+ case RPMB_READ_DATA:
+ if (req_len != sizeof(struct rpmb_frame) ||
+ rsp_len % sizeof(struct rpmb_frame))
+ return -EINVAL;
+ write = false;
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return rdev->ops->route_frames(rdev->dev.parent, write,
+ req, req_len, rsp, rsp_len);
+}
+EXPORT_SYMBOL_GPL(rpmb_route_frames);
+
+static void rpmb_dev_release(struct device *dev)
+{
+ struct rpmb_dev *rdev = to_rpmb_dev(dev);
+
+ rdev->ops->put_resources(rdev->dev.parent);
+ mutex_lock(&rpmb_mutex);
+ ida_simple_remove(&rpmb_ida, rdev->id);
+ mutex_unlock(&rpmb_mutex);
+ kfree(rdev->dev_id);
+ kfree(rdev);
+}
+
+struct class rpmb_class = {
+ .name = "rpmb",
+ .dev_release = rpmb_dev_release,
+};
+EXPORT_SYMBOL(rpmb_class);
+
+/**
+ * rpmb_dev_find_device() - return first matching rpmb device
+ * @data: data for the match function
+ * @match: the matching function
+ *
+ * @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 device *dev,
+ const void *data))
+{
+ struct device *dev;
+ const struct device *start_dev = NULL;
+
+ if (start)
+ start_dev = &start->dev;
+ dev = class_find_device(&rpmb_class, start_dev, data, match);
+
+ return dev ? to_rpmb_dev(dev) : NULL;
+}
+
+/**
+ * rpmb_dev_unregister() - unregister RPMB partition from the RPMB subsystem
+ * @rdev: the rpmb device to unregister
+ *
+ * @returns < 0 on failure
+ */
+int rpmb_dev_unregister(struct rpmb_dev *rdev)
+{
+ if (!rdev)
+ return -EINVAL;
+
+ device_del(&rdev->dev);
+
+ rpmb_dev_put(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
+ * @target: RPMB target/region within the physical device
+ * @ops: device specific operations
+ *
+ * While registering the RPMB partition get references to needed resources
+ * with the @ops->get_resources() callback and extracts needed devices
+ * 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,
+ const struct rpmb_ops *ops)
+{
+ struct rpmb_dev *rdev;
+ int id;
+ int ret;
+
+ if (!dev || !ops || !ops->get_resources ||
+ !ops->put_resources || !ops->route_frames ||
+ !ops->set_dev_info)
+ return ERR_PTR(-EINVAL);
+
+ rdev = kzalloc(sizeof(*rdev), GFP_KERNEL);
+ if (!rdev)
+ return ERR_PTR(-ENOMEM);
+
+ mutex_lock(&rpmb_mutex);
+ id = ida_simple_get(&rpmb_ida, 0, 0, GFP_KERNEL);
+ mutex_unlock(&rpmb_mutex);
+ if (id < 0) {
+ ret = id;
+ goto exit;
+ }
+
+ rdev->ops = ops;
+ rdev->id = id;
+
+ dev_set_name(&rdev->dev, "rpmb%d", id);
+ rdev->dev.class = &rpmb_class;
+ rdev->dev.parent = dev;
+
+ ret = ops->set_dev_info(dev, rdev);
+ if (ret)
+ goto exit;
+
+ ret = device_register(&rdev->dev);
+ if (ret)
+ goto exit;
+
+ ops->get_resources(rdev->dev.parent);
+
+ dev_dbg(&rdev->dev, "registered device\n");
+
+ return rdev;
+
+exit:
+ if (id >= 0) {
+ mutex_lock(&rpmb_mutex);
+ ida_simple_remove(&rpmb_ida, id);
+ mutex_unlock(&rpmb_mutex);
+ }
+ kfree(rdev);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(rpmb_dev_register);
+
+static int __init rpmb_init(void)
+{
+ int rc;
+
+ rc = class_register(&rpmb_class);
+ if (rc) {
+ pr_err("couldn't create class\n");
+ return rc;
+ }
+ ida_init(&rpmb_ida);
+ return 0;
+}
+
+static void __exit rpmb_exit(void)
+{
+ ida_destroy(&rpmb_ida);
+ class_unregister(&rpmb_class);
+}
+
+subsys_initcall(rpmb_init);
+module_exit(rpmb_exit);
+
+MODULE_AUTHOR("Jens Wiklander <jens.wiklander@linaro.org>");
+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..45073513264a
--- /dev/null
+++ b/include/linux/rpmb.h
@@ -0,0 +1,184 @@
+/* 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>
+
+/**
+ * struct rpmb_frame - rpmb frame as defined by specs
+ *
+ * @stuff : stuff bytes
+ * @key_mac : The authentication key or the message authentication
+ * code (MAC) depending on the request/response type.
+ * The MAC will be delivered in the last (or the only)
+ * block of data.
+ * @data : Data to be written or read by signed access.
+ * @nonce : Random number generated by the host for the requests
+ * and copied to the response by the RPMB engine.
+ * @write_counter: Counter value for the total amount of the successful
+ * authenticated data write requests made by the host.
+ * @addr : Address of the data to be programmed to or read
+ * from the RPMB. Address is the serial number of
+ * the accessed block (half sector 256B).
+ * @block_count : Number of blocks (half sectors, 256B) requested to be
+ * read/programmed.
+ * @result : Includes information about the status of the write counter
+ * (valid, expired) and result of the access made to the RPMB.
+ * @req_resp : Defines the type of request and response to/from the memory.
+ */
+struct rpmb_frame {
+ u8 stuff[196];
+ u8 key_mac[32];
+ u8 data[256];
+ u8 nonce[16];
+ __be32 write_counter;
+ __be16 addr;
+ __be16 block_count;
+ __be16 result;
+ __be16 req_resp;
+} __packed;
+
+#define RPMB_PROGRAM_KEY 0x1 /* Program RPMB Authentication Key */
+#define RPMB_GET_WRITE_COUNTER 0x2 /* Read RPMB write counter */
+#define RPMB_WRITE_DATA 0x3 /* Write data to RPMB partition */
+#define RPMB_READ_DATA 0x4 /* Read data from RPMB partition */
+#define RPMB_RESULT_READ 0x5 /* Read result request (Internal) */
+
+#define RPMB_REQ2RESP(_OP) ((_OP) << 8)
+#define RPMB_RESP2REQ(_OP) ((_OP) >> 8)
+
+/**
+ * enum rpmb_op_result - rpmb operation results
+ *
+ * @RPMB_ERR_OK : operation successful
+ * @RPMB_ERR_GENERAL : general failure
+ * @RPMB_ERR_AUTH : mac doesn't match or ac calculation failure
+ * @RPMB_ERR_COUNTER : counter doesn't match or counter increment failure
+ * @RPMB_ERR_ADDRESS : address out of range or wrong address alignment
+ * @RPMB_ERR_WRITE : data, counter, or result write failure
+ * @RPMB_ERR_READ : data, counter, or result read failure
+ * @RPMB_ERR_NO_KEY : authentication key not yet programmed
+ *
+ * @RPMB_ERR_COUNTER_EXPIRED: counter expired
+ */
+enum rpmb_op_result {
+ RPMB_ERR_OK = 0x0000,
+ RPMB_ERR_GENERAL = 0x0001,
+ RPMB_ERR_AUTH = 0x0002,
+ RPMB_ERR_COUNTER = 0x0003,
+ RPMB_ERR_ADDRESS = 0x0004,
+ RPMB_ERR_WRITE = 0x0005,
+ RPMB_ERR_READ = 0x0006,
+ RPMB_ERR_NO_KEY = 0x0007,
+
+ RPMB_ERR_COUNTER_EXPIRED = 0x0080
+};
+
+/**
+ * enum rpmb_type - type of underlaying 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_dev - device which can support RPMB partition
+ *
+ * @dev : device
+ * @id : device id;
+ * @ops : operation exported by rpmb
+ * @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
+ */
+struct rpmb_dev {
+ struct device dev;
+ int id;
+ const struct rpmb_ops *ops;
+ u8 *dev_id;
+ size_t dev_id_len;
+ u16 reliable_wr_count;
+ u16 capacity;
+};
+
+#define to_rpmb_dev(x) container_of((x), struct rpmb_dev, dev)
+
+/**
+ * struct rpmb_ops - RPMB ops to be implemented by underlying block device
+ *
+ * @type : block device type
+ * @get_resources : gets references to needed resources in rpmb_dev_register()
+ * @put_resources : puts references from resources in rpmb_dev_release()
+ * @route_frames : routes frames to and from the RPMB device
+ * @get_dev_info : extracts device info from the RPMB device
+ */
+struct rpmb_ops {
+ enum rpmb_type type;
+ void (*get_resources)(struct device *dev);
+ void (*put_resources)(struct device *dev);
+ int (*set_dev_info)(struct device *dev, struct rpmb_dev *rdev);
+ int (*route_frames)(struct device *dev, bool write,
+ u8 *req, unsigned int req_len,
+ u8 *resp, unsigned int resp_len);
+};
+
+#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 device *dev,
+ const void *data));
+struct rpmb_dev *rpmb_dev_register(struct device *dev,
+ const struct rpmb_ops *ops);
+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);
+#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 device *dev, 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;
+}
+#endif /* CONFIG_RPMB */
+
+#endif /* __RPMB_H__ */
--
2.34.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-01-31 17:43 ` [PATCH v2 1/3] rpmb: add " Jens Wiklander
@ 2024-01-31 21:13 ` Greg Kroah-Hartman
2024-02-01 11:26 ` Jens Wiklander
2024-02-01 6:04 ` Randy Dunlap
2024-02-06 12:33 ` Ulf Hansson
2 siblings, 1 reply; 22+ messages in thread
From: Greg Kroah-Hartman @ 2024-01-31 21:13 UTC (permalink / raw)
To: Jens Wiklander
Cc: linux-kernel, linux-mmc, op-tee, Shyam Saini, Ulf Hansson,
Jerome Forissier, Sumit Garg, Ilias Apalodimas, Bart Van Assche,
Randy Dunlap, Ard Biesheuvel, Arnd Bergmann, Tomas Winkler,
Alex Bennée
On Wed, Jan 31, 2024 at 06:43:45PM +0100, Jens Wiklander wrote:
> +struct class rpmb_class = {
This structure should be marked as 'const', right?
> + .name = "rpmb",
> + .dev_release = rpmb_dev_release,
> +};
> +EXPORT_SYMBOL(rpmb_class);
EXPORT_SYMBOL_GPL() to match all the other exports in this file please.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-01-31 21:13 ` Greg Kroah-Hartman
@ 2024-02-01 11:26 ` Jens Wiklander
0 siblings, 0 replies; 22+ messages in thread
From: Jens Wiklander @ 2024-02-01 11:26 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, linux-mmc, op-tee, Shyam Saini, Ulf Hansson,
Jerome Forissier, Sumit Garg, Ilias Apalodimas, Bart Van Assche,
Randy Dunlap, Ard Biesheuvel, Arnd Bergmann, Tomas Winkler,
Alex Bennée
On Wed, Jan 31, 2024 at 10:13 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Wed, Jan 31, 2024 at 06:43:45PM +0100, Jens Wiklander wrote:
> > +struct class rpmb_class = {
>
> This structure should be marked as 'const', right?
You're right, of course.
>
> > + .name = "rpmb",
> > + .dev_release = rpmb_dev_release,
> > +};
> > +EXPORT_SYMBOL(rpmb_class);
>
> EXPORT_SYMBOL_GPL() to match all the other exports in this file please.
Sure, I'll fix it.
Thanks,
Jens
>
> thanks,
>
> greg k-h
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-01-31 17:43 ` [PATCH v2 1/3] rpmb: add " Jens Wiklander
2024-01-31 21:13 ` Greg Kroah-Hartman
@ 2024-02-01 6:04 ` Randy Dunlap
2024-02-01 11:39 ` Jens Wiklander
2024-02-06 12:33 ` Ulf Hansson
2 siblings, 1 reply; 22+ messages in thread
From: Randy Dunlap @ 2024-02-01 6:04 UTC (permalink / raw)
To: Jens Wiklander, linux-kernel, linux-mmc, op-tee
Cc: Shyam Saini, Ulf Hansson, Jerome Forissier, Sumit Garg,
Ilias Apalodimas, Bart Van Assche, Ard Biesheuvel, Arnd Bergmann,
Greg Kroah-Hartman, Tomas Winkler, Alex Bennée
Hi,
On 1/31/24 09:43, Jens Wiklander wrote:
> 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: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. 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 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
> class_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 <tomas.winkler@intel.com>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
> ---
> MAINTAINERS | 7 ++
> drivers/misc/Kconfig | 9 ++
> drivers/misc/Makefile | 1 +
> drivers/misc/rpmb-core.c | 247 +++++++++++++++++++++++++++++++++++++++
> include/linux/rpmb.h | 184 +++++++++++++++++++++++++++++
> 5 files changed, 448 insertions(+)
> create mode 100644 drivers/misc/rpmb-core.c
> create mode 100644 include/linux/rpmb.h
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 4fb291f0bf7c..891aa5763666 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -104,6 +104,15 @@ config PHANTOM
> If you choose to build module, its name will be phantom. If unsure,
> say N here.
>
> +config RPMB
> + tristate "RPMB partition interface"
> + help
> + Unified RPMB unit interface for RPMB capable devices such as eMMC and
> + UFS. Provides interface for in kernel security controllers to access
in-kernel
> + RPMB unit.
> +
> + If unsure, select N.
> +
> config TIFM_CORE
> tristate "TI Flash Media interface support"
> depends on PCI
> diff --git a/drivers/misc/rpmb-core.c b/drivers/misc/rpmb-core.c
> new file mode 100644
> index 000000000000..a3c289051687
> --- /dev/null
> +++ b/drivers/misc/rpmb-core.c
> @@ -0,0 +1,247 @@
> +// 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>
> +
> +/**
> + * 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
> + *
> + * @return < 0 on failure
Above needs a colon ':' after @return, although using
* Return:
is preferable IMO.
> + */
> +int rpmb_route_frames(struct rpmb_dev *rdev, u8 *req,
> + unsigned int req_len, u8 *rsp, unsigned int rsp_len)
> +{
> +/**
> + * rpmb_dev_find_device() - return first matching rpmb device
> + * @data: data for the match function
> + * @match: the matching function
> + *
> + * @returns a matching rpmb device or NULL on failure
* @returns:
or
* Returns:
> + */
> +struct rpmb_dev *rpmb_dev_find_device(const void *data,
> + const struct rpmb_dev *start,
> + int (*match)(struct device *dev,
> + const void *data))
> +{
> + struct device *dev;
> + const struct device *start_dev = NULL;
> +
> + if (start)
> + start_dev = &start->dev;
> + dev = class_find_device(&rpmb_class, start_dev, data, match);
> +
> + return dev ? to_rpmb_dev(dev) : NULL;
> +}
> +
> +/**
> + * rpmb_dev_unregister() - unregister RPMB partition from the RPMB subsystem
> + * @rdev: the rpmb device to unregister
> + *
> + * @returns < 0 on failure
Ditto.
> + */
> +int rpmb_dev_unregister(struct rpmb_dev *rdev)
> +{
> + if (!rdev)
> + return -EINVAL;
> +
> + device_del(&rdev->dev);
> +
> + rpmb_dev_put(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
> + * @target: RPMB target/region within the physical device
There is no @target function parameter.
> + * @ops: device specific operations
> + *
> + * While registering the RPMB partition get references to needed resources
> + * with the @ops->get_resources() callback and extracts needed devices
> + * information while needed resources are available.
> + *
> + * @returns a pointer to a 'struct rpmb_dev' or an ERR_PTR on failure
Ditto for Return syntax.
> + */
> +struct rpmb_dev *rpmb_dev_register(struct device *dev,
> + const struct rpmb_ops *ops)
> +{
> + struct rpmb_dev *rdev;
> + int id;
> + int ret;
> +
> + if (!dev || !ops || !ops->get_resources ||
> + !ops->put_resources || !ops->route_frames ||
> + !ops->set_dev_info)
> + return ERR_PTR(-EINVAL);
> +
> + rdev = kzalloc(sizeof(*rdev), GFP_KERNEL);
> + if (!rdev)
> + return ERR_PTR(-ENOMEM);
> +
> + mutex_lock(&rpmb_mutex);
> + id = ida_simple_get(&rpmb_ida, 0, 0, GFP_KERNEL);
> + mutex_unlock(&rpmb_mutex);
> + if (id < 0) {
> + ret = id;
> + goto exit;
> + }
> +
> + rdev->ops = ops;
> + rdev->id = id;
> +
> + dev_set_name(&rdev->dev, "rpmb%d", id);
> + rdev->dev.class = &rpmb_class;
> + rdev->dev.parent = dev;
> +
> + ret = ops->set_dev_info(dev, rdev);
> + if (ret)
> + goto exit;
> +
> + ret = device_register(&rdev->dev);
> + if (ret)
> + goto exit;
> +
> + ops->get_resources(rdev->dev.parent);
> +
> + dev_dbg(&rdev->dev, "registered device\n");
> +
> + return rdev;
> +
> +exit:
> + if (id >= 0) {
> + mutex_lock(&rpmb_mutex);
> + ida_simple_remove(&rpmb_ida, id);
> + mutex_unlock(&rpmb_mutex);
> + }
> + kfree(rdev);
> + return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL_GPL(rpmb_dev_register);
> diff --git a/include/linux/rpmb.h b/include/linux/rpmb.h
> new file mode 100644
> index 000000000000..45073513264a
> --- /dev/null
> +++ b/include/linux/rpmb.h
> @@ -0,0 +1,184 @@
> +/* 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>
> +
> +/**
> + * struct rpmb_frame - rpmb frame as defined by specs
> + *
> + * @stuff : stuff bytes
> + * @key_mac : The authentication key or the message authentication
> + * code (MAC) depending on the request/response type.
> + * The MAC will be delivered in the last (or the only)
> + * block of data.
> + * @data : Data to be written or read by signed access.
> + * @nonce : Random number generated by the host for the requests
> + * and copied to the response by the RPMB engine.
> + * @write_counter: Counter value for the total amount of the successful
> + * authenticated data write requests made by the host.
> + * @addr : Address of the data to be programmed to or read
> + * from the RPMB. Address is the serial number of
> + * the accessed block (half sector 256B).
> + * @block_count : Number of blocks (half sectors, 256B) requested to be
> + * read/programmed.
> + * @result : Includes information about the status of the write counter
> + * (valid, expired) and result of the access made to the RPMB.
> + * @req_resp : Defines the type of request and response to/from the memory.
> + */
> +struct rpmb_frame {
> + u8 stuff[196];
> + u8 key_mac[32];
> + u8 data[256];
> + u8 nonce[16];
> + __be32 write_counter;
> + __be16 addr;
> + __be16 block_count;
> + __be16 result;
> + __be16 req_resp;
> +} __packed;
> +
> +#define RPMB_PROGRAM_KEY 0x1 /* Program RPMB Authentication Key */
> +#define RPMB_GET_WRITE_COUNTER 0x2 /* Read RPMB write counter */
> +#define RPMB_WRITE_DATA 0x3 /* Write data to RPMB partition */
> +#define RPMB_READ_DATA 0x4 /* Read data from RPMB partition */
> +#define RPMB_RESULT_READ 0x5 /* Read result request (Internal) */
> +
> +#define RPMB_REQ2RESP(_OP) ((_OP) << 8)
> +#define RPMB_RESP2REQ(_OP) ((_OP) >> 8)
> +
> +/**
> + * enum rpmb_op_result - rpmb operation results
> + *
> + * @RPMB_ERR_OK : operation successful
> + * @RPMB_ERR_GENERAL : general failure
> + * @RPMB_ERR_AUTH : mac doesn't match or ac calculation failure
> + * @RPMB_ERR_COUNTER : counter doesn't match or counter increment failure
> + * @RPMB_ERR_ADDRESS : address out of range or wrong address alignment
> + * @RPMB_ERR_WRITE : data, counter, or result write failure
> + * @RPMB_ERR_READ : data, counter, or result read failure
> + * @RPMB_ERR_NO_KEY : authentication key not yet programmed
> + *
> + * @RPMB_ERR_COUNTER_EXPIRED: counter expired
> + */
> +enum rpmb_op_result {
> + RPMB_ERR_OK = 0x0000,
> + RPMB_ERR_GENERAL = 0x0001,
> + RPMB_ERR_AUTH = 0x0002,
> + RPMB_ERR_COUNTER = 0x0003,
> + RPMB_ERR_ADDRESS = 0x0004,
> + RPMB_ERR_WRITE = 0x0005,
> + RPMB_ERR_READ = 0x0006,
> + RPMB_ERR_NO_KEY = 0x0007,
> +
> + RPMB_ERR_COUNTER_EXPIRED = 0x0080
> +};
> +
> +/**
> + * enum rpmb_type - type of underlaying storage technology
underlying
> + *
> + * @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_dev - device which can support RPMB partition
> + *
> + * @dev : device
> + * @id : device id;
> + * @ops : operation exported by rpmb
> + * @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
> + */
> +struct rpmb_dev {
> + struct device dev;
> + int id;
> + const struct rpmb_ops *ops;
> + u8 *dev_id;
> + size_t dev_id_len;
> + u16 reliable_wr_count;
> + u16 capacity;
> +};
> +
> +#define to_rpmb_dev(x) container_of((x), struct rpmb_dev, dev)
> +
> +/**
> + * struct rpmb_ops - RPMB ops to be implemented by underlying block device
> + *
> + * @type : block device type
> + * @get_resources : gets references to needed resources in rpmb_dev_register()
> + * @put_resources : puts references from resources in rpmb_dev_release()
> + * @route_frames : routes frames to and from the RPMB device
> + * @get_dev_info : extracts device info from the RPMB device
set_dev_info ???
> + */
> +struct rpmb_ops {
> + enum rpmb_type type;
> + void (*get_resources)(struct device *dev);
> + void (*put_resources)(struct device *dev);
> + int (*set_dev_info)(struct device *dev, struct rpmb_dev *rdev);
> + int (*route_frames)(struct device *dev, bool write,
> + u8 *req, unsigned int req_len,
> + u8 *resp, unsigned int resp_len);
> +};
> +
thanks.
--
#Randy
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-02-01 6:04 ` Randy Dunlap
@ 2024-02-01 11:39 ` Jens Wiklander
0 siblings, 0 replies; 22+ messages in thread
From: Jens Wiklander @ 2024-02-01 11:39 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-kernel, linux-mmc, op-tee, Shyam Saini, Ulf Hansson,
Jerome Forissier, Sumit Garg, Ilias Apalodimas, Bart Van Assche,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman, Tomas Winkler,
Alex Bennée
On Thu, Feb 1, 2024 at 7:04 AM Randy Dunlap <rdunlap@infradead.org> wrote:
>
> Hi,
>
> On 1/31/24 09:43, Jens Wiklander wrote:
> > 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: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. 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 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
> > class_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 <tomas.winkler@intel.com>
> > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> > Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
> > Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
> > ---
> > MAINTAINERS | 7 ++
> > drivers/misc/Kconfig | 9 ++
> > drivers/misc/Makefile | 1 +
> > drivers/misc/rpmb-core.c | 247 +++++++++++++++++++++++++++++++++++++++
> > include/linux/rpmb.h | 184 +++++++++++++++++++++++++++++
> > 5 files changed, 448 insertions(+)
> > create mode 100644 drivers/misc/rpmb-core.c
> > create mode 100644 include/linux/rpmb.h
> >
>
>
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 4fb291f0bf7c..891aa5763666 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -104,6 +104,15 @@ config PHANTOM
> > If you choose to build module, its name will be phantom. If unsure,
> > say N here.
> >
> > +config RPMB
> > + tristate "RPMB partition interface"
> > + help
> > + Unified RPMB unit interface for RPMB capable devices such as eMMC and
> > + UFS. Provides interface for in kernel security controllers to access
>
> in-kernel
>
> > + RPMB unit.
> > +
> > + If unsure, select N.
> > +
> > config TIFM_CORE
> > tristate "TI Flash Media interface support"
> > depends on PCI
>
>
> > diff --git a/drivers/misc/rpmb-core.c b/drivers/misc/rpmb-core.c
> > new file mode 100644
> > index 000000000000..a3c289051687
> > --- /dev/null
> > +++ b/drivers/misc/rpmb-core.c
> > @@ -0,0 +1,247 @@
> > +// 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>
>
> > +
> > +/**
> > + * 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
> > + *
> > + * @return < 0 on failure
>
> Above needs a colon ':' after @return, although using
> * Return:
> is preferable IMO.
Thanks, I'll change to "* Return:" instead, everywhere in this patch.
>
> > + */
> > +int rpmb_route_frames(struct rpmb_dev *rdev, u8 *req,
> > + unsigned int req_len, u8 *rsp, unsigned int rsp_len)
> > +{
>
>
> > +/**
> > + * rpmb_dev_find_device() - return first matching rpmb device
> > + * @data: data for the match function
> > + * @match: the matching function
> > + *
> > + * @returns a matching rpmb device or NULL on failure
>
> * @returns:
> or
> * Returns:
>
> > + */
> > +struct rpmb_dev *rpmb_dev_find_device(const void *data,
> > + const struct rpmb_dev *start,
> > + int (*match)(struct device *dev,
> > + const void *data))
> > +{
> > + struct device *dev;
> > + const struct device *start_dev = NULL;
> > +
> > + if (start)
> > + start_dev = &start->dev;
> > + dev = class_find_device(&rpmb_class, start_dev, data, match);
> > +
> > + return dev ? to_rpmb_dev(dev) : NULL;
> > +}
> > +
> > +/**
> > + * rpmb_dev_unregister() - unregister RPMB partition from the RPMB subsystem
> > + * @rdev: the rpmb device to unregister
> > + *
> > + * @returns < 0 on failure
>
> Ditto.
>
> > + */
> > +int rpmb_dev_unregister(struct rpmb_dev *rdev)
> > +{
> > + if (!rdev)
> > + return -EINVAL;
> > +
> > + device_del(&rdev->dev);
> > +
> > + rpmb_dev_put(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
> > + * @target: RPMB target/region within the physical device
>
> There is no @target function parameter.
You're right, I'll remove it.
>
> > + * @ops: device specific operations
> > + *
> > + * While registering the RPMB partition get references to needed resources
> > + * with the @ops->get_resources() callback and extracts needed devices
> > + * information while needed resources are available.
> > + *
> > + * @returns a pointer to a 'struct rpmb_dev' or an ERR_PTR on failure
>
> Ditto for Return syntax.
>
> > + */
> > +struct rpmb_dev *rpmb_dev_register(struct device *dev,
> > + const struct rpmb_ops *ops)
> > +{
> > + struct rpmb_dev *rdev;
> > + int id;
> > + int ret;
> > +
> > + if (!dev || !ops || !ops->get_resources ||
> > + !ops->put_resources || !ops->route_frames ||
> > + !ops->set_dev_info)
> > + return ERR_PTR(-EINVAL);
> > +
> > + rdev = kzalloc(sizeof(*rdev), GFP_KERNEL);
> > + if (!rdev)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + mutex_lock(&rpmb_mutex);
> > + id = ida_simple_get(&rpmb_ida, 0, 0, GFP_KERNEL);
> > + mutex_unlock(&rpmb_mutex);
> > + if (id < 0) {
> > + ret = id;
> > + goto exit;
> > + }
> > +
> > + rdev->ops = ops;
> > + rdev->id = id;
> > +
> > + dev_set_name(&rdev->dev, "rpmb%d", id);
> > + rdev->dev.class = &rpmb_class;
> > + rdev->dev.parent = dev;
> > +
> > + ret = ops->set_dev_info(dev, rdev);
> > + if (ret)
> > + goto exit;
> > +
> > + ret = device_register(&rdev->dev);
> > + if (ret)
> > + goto exit;
> > +
> > + ops->get_resources(rdev->dev.parent);
> > +
> > + dev_dbg(&rdev->dev, "registered device\n");
> > +
> > + return rdev;
> > +
> > +exit:
> > + if (id >= 0) {
> > + mutex_lock(&rpmb_mutex);
> > + ida_simple_remove(&rpmb_ida, id);
> > + mutex_unlock(&rpmb_mutex);
> > + }
> > + kfree(rdev);
> > + return ERR_PTR(ret);
> > +}
> > +EXPORT_SYMBOL_GPL(rpmb_dev_register);
>
>
> > diff --git a/include/linux/rpmb.h b/include/linux/rpmb.h
> > new file mode 100644
> > index 000000000000..45073513264a
> > --- /dev/null
> > +++ b/include/linux/rpmb.h
> > @@ -0,0 +1,184 @@
> > +/* 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>
> > +
> > +/**
> > + * struct rpmb_frame - rpmb frame as defined by specs
> > + *
> > + * @stuff : stuff bytes
> > + * @key_mac : The authentication key or the message authentication
> > + * code (MAC) depending on the request/response type.
> > + * The MAC will be delivered in the last (or the only)
> > + * block of data.
> > + * @data : Data to be written or read by signed access.
> > + * @nonce : Random number generated by the host for the requests
> > + * and copied to the response by the RPMB engine.
> > + * @write_counter: Counter value for the total amount of the successful
> > + * authenticated data write requests made by the host.
> > + * @addr : Address of the data to be programmed to or read
> > + * from the RPMB. Address is the serial number of
> > + * the accessed block (half sector 256B).
> > + * @block_count : Number of blocks (half sectors, 256B) requested to be
> > + * read/programmed.
> > + * @result : Includes information about the status of the write counter
> > + * (valid, expired) and result of the access made to the RPMB.
> > + * @req_resp : Defines the type of request and response to/from the memory.
> > + */
> > +struct rpmb_frame {
> > + u8 stuff[196];
> > + u8 key_mac[32];
> > + u8 data[256];
> > + u8 nonce[16];
> > + __be32 write_counter;
> > + __be16 addr;
> > + __be16 block_count;
> > + __be16 result;
> > + __be16 req_resp;
> > +} __packed;
> > +
> > +#define RPMB_PROGRAM_KEY 0x1 /* Program RPMB Authentication Key */
> > +#define RPMB_GET_WRITE_COUNTER 0x2 /* Read RPMB write counter */
> > +#define RPMB_WRITE_DATA 0x3 /* Write data to RPMB partition */
> > +#define RPMB_READ_DATA 0x4 /* Read data from RPMB partition */
> > +#define RPMB_RESULT_READ 0x5 /* Read result request (Internal) */
> > +
> > +#define RPMB_REQ2RESP(_OP) ((_OP) << 8)
> > +#define RPMB_RESP2REQ(_OP) ((_OP) >> 8)
> > +
> > +/**
> > + * enum rpmb_op_result - rpmb operation results
> > + *
> > + * @RPMB_ERR_OK : operation successful
> > + * @RPMB_ERR_GENERAL : general failure
> > + * @RPMB_ERR_AUTH : mac doesn't match or ac calculation failure
> > + * @RPMB_ERR_COUNTER : counter doesn't match or counter increment failure
> > + * @RPMB_ERR_ADDRESS : address out of range or wrong address alignment
> > + * @RPMB_ERR_WRITE : data, counter, or result write failure
> > + * @RPMB_ERR_READ : data, counter, or result read failure
> > + * @RPMB_ERR_NO_KEY : authentication key not yet programmed
> > + *
> > + * @RPMB_ERR_COUNTER_EXPIRED: counter expired
> > + */
> > +enum rpmb_op_result {
> > + RPMB_ERR_OK = 0x0000,
> > + RPMB_ERR_GENERAL = 0x0001,
> > + RPMB_ERR_AUTH = 0x0002,
> > + RPMB_ERR_COUNTER = 0x0003,
> > + RPMB_ERR_ADDRESS = 0x0004,
> > + RPMB_ERR_WRITE = 0x0005,
> > + RPMB_ERR_READ = 0x0006,
> > + RPMB_ERR_NO_KEY = 0x0007,
> > +
> > + RPMB_ERR_COUNTER_EXPIRED = 0x0080
> > +};
> > +
> > +/**
> > + * enum rpmb_type - type of underlaying storage technology
>
> underlying
Thanks
>
> > + *
> > + * @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_dev - device which can support RPMB partition
> > + *
> > + * @dev : device
> > + * @id : device id;
> > + * @ops : operation exported by rpmb
> > + * @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
> > + */
> > +struct rpmb_dev {
> > + struct device dev;
> > + int id;
> > + const struct rpmb_ops *ops;
> > + u8 *dev_id;
> > + size_t dev_id_len;
> > + u16 reliable_wr_count;
> > + u16 capacity;
> > +};
> > +
> > +#define to_rpmb_dev(x) container_of((x), struct rpmb_dev, dev)
> > +
> > +/**
> > + * struct rpmb_ops - RPMB ops to be implemented by underlying block device
> > + *
> > + * @type : block device type
> > + * @get_resources : gets references to needed resources in rpmb_dev_register()
> > + * @put_resources : puts references from resources in rpmb_dev_release()
> > + * @route_frames : routes frames to and from the RPMB device
> > + * @get_dev_info : extracts device info from the RPMB device
>
> set_dev_info ???
Yes.
Thanks,
Jens
>
> > + */
> > +struct rpmb_ops {
> > + enum rpmb_type type;
> > + void (*get_resources)(struct device *dev);
> > + void (*put_resources)(struct device *dev);
> > + int (*set_dev_info)(struct device *dev, struct rpmb_dev *rdev);
> > + int (*route_frames)(struct device *dev, bool write,
> > + u8 *req, unsigned int req_len,
> > + u8 *resp, unsigned int resp_len);
> > +};
> > +
>
> thanks.
> --
> #Randy
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-01-31 17:43 ` [PATCH v2 1/3] rpmb: add " Jens Wiklander
2024-01-31 21:13 ` Greg Kroah-Hartman
2024-02-01 6:04 ` Randy Dunlap
@ 2024-02-06 12:33 ` Ulf Hansson
2024-02-06 15:10 ` Ilias Apalodimas
2024-02-07 8:06 ` Jens Wiklander
2 siblings, 2 replies; 22+ messages in thread
From: Ulf Hansson @ 2024-02-06 12:33 UTC (permalink / raw)
To: Jens Wiklander
Cc: linux-kernel, linux-mmc, op-tee, Shyam Saini, Jerome Forissier,
Sumit Garg, Ilias Apalodimas, Bart Van Assche, Randy Dunlap,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman, Tomas Winkler,
Alex Bennée
On Wed, 31 Jan 2024 at 18:44, Jens Wiklander <jens.wiklander@linaro.org> wrote:
>
> 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: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. 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 which
> can be accessed by the optee driver to facilitate early RPMB access to
> OP-TEE OS (secure OS) during the boot time.
How early do we expect OP-TEE to need RPMB access?
The way things work for mmc today, is that the eMMC card gets
discovered/probed via a workqueue. The work is punted by the mmc host
driver (typically a module-platform-driver), when it has probed
successfully.
The point is, it looks like we need some kind of probe deferral
mechanism too. Whether we want the OP-TEE driver to manage this itself
or whether we should let rpmb_dev_find_device() deal with it, I don't
know.
>
> A TEE device driver can claim the RPMB interface, for example, via
> class_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().
By looking at the design of the interface, I do like it. It's simple
and straightforward.
However, I wonder if you considered avoiding using a class-device
altogether? Even if it helps with lifecycle problems and the
ops-lookup, we really don't need another struct device with a sysfs
node, etc.
To deal with the lifecycle issue, we could probably just add reference
counting for the corresponding struct device that we already have at
hand, which represents the eMMC/UFS/NVME card. That together with a
simple list that contains the registered rpmb ops. But I may be
overlooking something, so perhaps it's more complicated than that?
>
> The detailed operation of implementing the access is left to the TEE
> device driver itself.
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
> ---
> MAINTAINERS | 7 ++
> drivers/misc/Kconfig | 9 ++
> drivers/misc/Makefile | 1 +
> drivers/misc/rpmb-core.c | 247 +++++++++++++++++++++++++++++++++++++++
> include/linux/rpmb.h | 184 +++++++++++++++++++++++++++++
> 5 files changed, 448 insertions(+)
> create mode 100644 drivers/misc/rpmb-core.c
> create mode 100644 include/linux/rpmb.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8999497011a2..e83152c42499 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19012,6 +19012,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 <jens.wiklander@linaro.org>
> +L: linux-kernel@vger.kernel.org
> +S: Supported
> +F: drivers/misc/rpmb-core.c
> +F: include/linux/rpmb.h
> +
> RPMSG TTY DRIVER
> M: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> L: linux-remoteproc@vger.kernel.org
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 4fb291f0bf7c..891aa5763666 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -104,6 +104,15 @@ config PHANTOM
> If you choose to build module, its name will be phantom. If unsure,
> say N here.
>
> +config RPMB
> + tristate "RPMB partition interface"
Should we add a "depends on MMC"? (We can add the other NVME and UFS
later on too).
> + 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..a3c289051687
> --- /dev/null
> +++ b/drivers/misc/rpmb-core.c
> @@ -0,0 +1,247 @@
> +// 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 DEFINE_IDA(rpmb_ida);
> +static DEFINE_MUTEX(rpmb_mutex);
> +
> +/**
> + * 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->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->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
> + *
> + * @return < 0 on failure
> + */
> +int rpmb_route_frames(struct rpmb_dev *rdev, u8 *req,
> + unsigned int req_len, u8 *rsp, unsigned int rsp_len)
> +{
> + struct rpmb_frame *frm = (struct rpmb_frame *)req;
Is there a reason why we are passing an u8 *req, in favor of a
"rpmb_frame *frame" directly as the in-parameter?
> + u16 req_type;
> + bool write;
> +
> + if (!req || req_len < sizeof(*frm) || !rsp || !rsp_len)
> + return -EINVAL;
> +
> + req_type = be16_to_cpu(frm->req_resp);
> + switch (req_type) {
> + case RPMB_PROGRAM_KEY:
> + if (req_len != sizeof(struct rpmb_frame) ||
> + rsp_len != sizeof(struct rpmb_frame))
> + return -EINVAL;
> + write = true;
> + break;
> + case RPMB_GET_WRITE_COUNTER:
> + if (req_len != sizeof(struct rpmb_frame) ||
> + rsp_len != sizeof(struct rpmb_frame))
> + return -EINVAL;
> + write = false;
> + break;
> + case RPMB_WRITE_DATA:
> + if (req_len % sizeof(struct rpmb_frame) ||
> + rsp_len != sizeof(struct rpmb_frame))
> + return -EINVAL;
> + write = true;
> + break;
> + case RPMB_READ_DATA:
> + if (req_len != sizeof(struct rpmb_frame) ||
> + rsp_len % sizeof(struct rpmb_frame))
> + return -EINVAL;
> + write = false;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + return rdev->ops->route_frames(rdev->dev.parent, write,
> + req, req_len, rsp, rsp_len);
> +}
> +EXPORT_SYMBOL_GPL(rpmb_route_frames);
[...]
> +
> +/**
> + * enum rpmb_type - type of underlaying 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,
> +};
In what way do we expect these to be useful?
Perhaps we should add some information about this, because currently
in the series they seem not to be used. Maybe the OP-TEE driver needs
it when extending support to NVME and UFS?
[...]
Kind regards
Uffe
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-02-06 12:33 ` Ulf Hansson
@ 2024-02-06 15:10 ` Ilias Apalodimas
2024-02-07 6:11 ` Sumit Garg
2024-02-07 8:06 ` Jens Wiklander
1 sibling, 1 reply; 22+ messages in thread
From: Ilias Apalodimas @ 2024-02-06 15:10 UTC (permalink / raw)
To: Ulf Hansson
Cc: Jens Wiklander, linux-kernel, linux-mmc, op-tee, Shyam Saini,
Jerome Forissier, Sumit Garg, Bart Van Assche, Randy Dunlap,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman, Tomas Winkler,
Alex Bennée
Hi Ulf,
On Tue, 6 Feb 2024 at 14:34, Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Wed, 31 Jan 2024 at 18:44, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> >
> > 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: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. 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 which
> > can be accessed by the optee driver to facilitate early RPMB access to
> > OP-TEE OS (secure OS) during the boot time.
>
> How early do we expect OP-TEE to need RPMB access?
It depends on the requested services. I am currently aware of 2
services that depend on the RPMB
- FirmwareTPM
- UEFI variables stored there via optee.
For the FirmwareTPM it depends on when you want to use it. This
typically happens when the initramfs is loaded or systemd requests
access to the TPM. I guess this is late enough to not cause problems?
For the latter, we won't need the supplicant until a write is
requested. This will only happen once the userspace is up and running.
The UEFI driver that sits behind OP-TEE has an in-memory cache of the
variables, so all the reads (the kernel invokes get_next_variable
during boot) are working without it.
Thanks
/Ilias
>
> The way things work for mmc today, is that the eMMC card gets
> discovered/probed via a workqueue. The work is punted by the mmc host
> driver (typically a module-platform-driver), when it has probed
> successfully.
>
> The point is, it looks like we need some kind of probe deferral
> mechanism too. Whether we want the OP-TEE driver to manage this itself
> or whether we should let rpmb_dev_find_device() deal with it, I don't
> know.
>
> >
> > A TEE device driver can claim the RPMB interface, for example, via
> > class_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().
>
> By looking at the design of the interface, I do like it. It's simple
> and straightforward.
>
> However, I wonder if you considered avoiding using a class-device
> altogether? Even if it helps with lifecycle problems and the
> ops-lookup, we really don't need another struct device with a sysfs
> node, etc.
>
> To deal with the lifecycle issue, we could probably just add reference
> counting for the corresponding struct device that we already have at
> hand, which represents the eMMC/UFS/NVME card. That together with a
> simple list that contains the registered rpmb ops. But I may be
> overlooking something, so perhaps it's more complicated than that?
>
> >
> > The detailed operation of implementing the access is left to the TEE
> > device driver itself.
> >
> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> > Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
> > Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
> > ---
> > MAINTAINERS | 7 ++
> > drivers/misc/Kconfig | 9 ++
> > drivers/misc/Makefile | 1 +
> > drivers/misc/rpmb-core.c | 247 +++++++++++++++++++++++++++++++++++++++
> > include/linux/rpmb.h | 184 +++++++++++++++++++++++++++++
> > 5 files changed, 448 insertions(+)
> > create mode 100644 drivers/misc/rpmb-core.c
> > create mode 100644 include/linux/rpmb.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 8999497011a2..e83152c42499 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -19012,6 +19012,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 <jens.wiklander@linaro.org>
> > +L: linux-kernel@vger.kernel.org
> > +S: Supported
> > +F: drivers/misc/rpmb-core.c
> > +F: include/linux/rpmb.h
> > +
> > RPMSG TTY DRIVER
> > M: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> > L: linux-remoteproc@vger.kernel.org
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 4fb291f0bf7c..891aa5763666 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -104,6 +104,15 @@ config PHANTOM
> > If you choose to build module, its name will be phantom. If unsure,
> > say N here.
> >
> > +config RPMB
> > + tristate "RPMB partition interface"
>
> Should we add a "depends on MMC"? (We can add the other NVME and UFS
> later on too).
>
> > + 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..a3c289051687
> > --- /dev/null
> > +++ b/drivers/misc/rpmb-core.c
> > @@ -0,0 +1,247 @@
> > +// 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 DEFINE_IDA(rpmb_ida);
> > +static DEFINE_MUTEX(rpmb_mutex);
> > +
> > +/**
> > + * 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->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->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
> > + *
> > + * @return < 0 on failure
> > + */
> > +int rpmb_route_frames(struct rpmb_dev *rdev, u8 *req,
> > + unsigned int req_len, u8 *rsp, unsigned int rsp_len)
> > +{
> > + struct rpmb_frame *frm = (struct rpmb_frame *)req;
>
> Is there a reason why we are passing an u8 *req, in favor of a
> "rpmb_frame *frame" directly as the in-parameter?
>
> > + u16 req_type;
> > + bool write;
> > +
> > + if (!req || req_len < sizeof(*frm) || !rsp || !rsp_len)
> > + return -EINVAL;
> > +
> > + req_type = be16_to_cpu(frm->req_resp);
> > + switch (req_type) {
> > + case RPMB_PROGRAM_KEY:
> > + if (req_len != sizeof(struct rpmb_frame) ||
> > + rsp_len != sizeof(struct rpmb_frame))
> > + return -EINVAL;
> > + write = true;
> > + break;
> > + case RPMB_GET_WRITE_COUNTER:
> > + if (req_len != sizeof(struct rpmb_frame) ||
> > + rsp_len != sizeof(struct rpmb_frame))
> > + return -EINVAL;
> > + write = false;
> > + break;
> > + case RPMB_WRITE_DATA:
> > + if (req_len % sizeof(struct rpmb_frame) ||
> > + rsp_len != sizeof(struct rpmb_frame))
> > + return -EINVAL;
> > + write = true;
> > + break;
> > + case RPMB_READ_DATA:
> > + if (req_len != sizeof(struct rpmb_frame) ||
> > + rsp_len % sizeof(struct rpmb_frame))
> > + return -EINVAL;
> > + write = false;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + return rdev->ops->route_frames(rdev->dev.parent, write,
> > + req, req_len, rsp, rsp_len);
> > +}
> > +EXPORT_SYMBOL_GPL(rpmb_route_frames);
>
> [...]
>
>
> > +
> > +/**
> > + * enum rpmb_type - type of underlaying 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,
> > +};
>
> In what way do we expect these to be useful?
>
> Perhaps we should add some information about this, because currently
> in the series they seem not to be used. Maybe the OP-TEE driver needs
> it when extending support to NVME and UFS?
>
> [...]
>
> Kind regards
> Uffe
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-02-06 15:10 ` Ilias Apalodimas
@ 2024-02-07 6:11 ` Sumit Garg
2024-02-07 7:25 ` Jens Wiklander
2024-02-07 7:34 ` Ilias Apalodimas
0 siblings, 2 replies; 22+ messages in thread
From: Sumit Garg @ 2024-02-07 6:11 UTC (permalink / raw)
To: Ilias Apalodimas, Ulf Hansson
Cc: Jens Wiklander, linux-kernel, linux-mmc, op-tee, Shyam Saini,
Jerome Forissier, Bart Van Assche, Randy Dunlap, Ard Biesheuvel,
Arnd Bergmann, Greg Kroah-Hartman, Tomas Winkler,
Alex Bennée
Hi Ilias, Ulf,
On Tue, 6 Feb 2024 at 20:41, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Ulf,
>
> On Tue, 6 Feb 2024 at 14:34, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Wed, 31 Jan 2024 at 18:44, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> > >
> > > 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: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. 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 which
> > > can be accessed by the optee driver to facilitate early RPMB access to
> > > OP-TEE OS (secure OS) during the boot time.
> >
> > How early do we expect OP-TEE to need RPMB access?
>
> It depends on the requested services. I am currently aware of 2
> services that depend on the RPMB
> - FirmwareTPM
> - UEFI variables stored there via optee.
>
> For the FirmwareTPM it depends on when you want to use it. This
> typically happens when the initramfs is loaded or systemd requests
> access to the TPM. I guess this is late enough to not cause problems?
Actually RPMB access is done as early as during fTPM probe, probably
to cache NVRAM from RPMB during fTPM init. Also, there is a kernel
user being IMA which would require fTPM access too. So we really need
to manage dependencies here.
>
> For the latter, we won't need the supplicant until a write is
> requested. This will only happen once the userspace is up and running.
> The UEFI driver that sits behind OP-TEE has an in-memory cache of the
> variables, so all the reads (the kernel invokes get_next_variable
> during boot) are working without it.
>
> Thanks
> /Ilias
> >
> > The way things work for mmc today, is that the eMMC card gets
> > discovered/probed via a workqueue. The work is punted by the mmc host
> > driver (typically a module-platform-driver), when it has probed
> > successfully.
It would be nice if RPMB is available as early as possible but for the
time being we can try to see if probe deferral suffices for all
use-cases.
> >
> > The point is, it looks like we need some kind of probe deferral
> > mechanism too. Whether we want the OP-TEE driver to manage this itself
> > or whether we should let rpmb_dev_find_device() deal with it, I don't
> > know.
I wouldn't like to see the OP-TEE driver probe being deferred due to
this since there are other kernel drivers like OP-TEE RNG (should be
available as early as we can) etc. which don't have any dependency on
RPMB.
How about for the time being we defer fTPM probe until RPMB is available?
-Sumit
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-02-07 6:11 ` Sumit Garg
@ 2024-02-07 7:25 ` Jens Wiklander
2024-02-07 7:49 ` Sumit Garg
2024-02-07 7:34 ` Ilias Apalodimas
1 sibling, 1 reply; 22+ messages in thread
From: Jens Wiklander @ 2024-02-07 7:25 UTC (permalink / raw)
To: Sumit Garg
Cc: Ilias Apalodimas, Ulf Hansson, linux-kernel, linux-mmc, op-tee,
Shyam Saini, Jerome Forissier, Bart Van Assche, Randy Dunlap,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman, Tomas Winkler,
Alex Bennée
H,
On Wed, Feb 7, 2024 at 7:11 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Hi Ilias, Ulf,
>
> On Tue, 6 Feb 2024 at 20:41, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > Hi Ulf,
> >
> > On Tue, 6 Feb 2024 at 14:34, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > >
> > > On Wed, 31 Jan 2024 at 18:44, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> > > >
> > > > 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: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. 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 which
> > > > can be accessed by the optee driver to facilitate early RPMB access to
> > > > OP-TEE OS (secure OS) during the boot time.
> > >
> > > How early do we expect OP-TEE to need RPMB access?
> >
> > It depends on the requested services. I am currently aware of 2
> > services that depend on the RPMB
> > - FirmwareTPM
> > - UEFI variables stored there via optee.
> >
> > For the FirmwareTPM it depends on when you want to use it. This
> > typically happens when the initramfs is loaded or systemd requests
> > access to the TPM. I guess this is late enough to not cause problems?
>
> Actually RPMB access is done as early as during fTPM probe, probably
> to cache NVRAM from RPMB during fTPM init. Also, there is a kernel
> user being IMA which would require fTPM access too. So we really need
> to manage dependencies here.
>
> >
> > For the latter, we won't need the supplicant until a write is
> > requested. This will only happen once the userspace is up and running.
> > The UEFI driver that sits behind OP-TEE has an in-memory cache of the
> > variables, so all the reads (the kernel invokes get_next_variable
> > during boot) are working without it.
> >
> > Thanks
> > /Ilias
> > >
> > > The way things work for mmc today, is that the eMMC card gets
> > > discovered/probed via a workqueue. The work is punted by the mmc host
> > > driver (typically a module-platform-driver), when it has probed
> > > successfully.
>
> It would be nice if RPMB is available as early as possible but for the
> time being we can try to see if probe deferral suffices for all
> use-cases.
>
> > >
> > > The point is, it looks like we need some kind of probe deferral
> > > mechanism too. Whether we want the OP-TEE driver to manage this itself
> > > or whether we should let rpmb_dev_find_device() deal with it, I don't
> > > know.
>
> I wouldn't like to see the OP-TEE driver probe being deferred due to
> this since there are other kernel drivers like OP-TEE RNG (should be
> available as early as we can) etc. which don't have any dependency on
> RPMB.
I agree, the optee driver itself can probe without RPMB.
>
> How about for the time being we defer fTPM probe until RPMB is available?
Sounds a bit like what we do with the
optee_enumerate_devices(PTA_CMD_GET_DEVICES_SUPP) call when
tee-supplicant has opened the supplicant device. It would perhaps work
with a PTA_CMD_GET_DEVICES_RPMB or such.
Thanks,
Jens
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-02-07 7:25 ` Jens Wiklander
@ 2024-02-07 7:49 ` Sumit Garg
2024-02-07 8:11 ` Jens Wiklander
0 siblings, 1 reply; 22+ messages in thread
From: Sumit Garg @ 2024-02-07 7:49 UTC (permalink / raw)
To: Jens Wiklander
Cc: Ilias Apalodimas, Ulf Hansson, linux-kernel, linux-mmc, op-tee,
Shyam Saini, Jerome Forissier, Bart Van Assche, Randy Dunlap,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman, Tomas Winkler,
Alex Bennée
On Wed, 7 Feb 2024 at 12:56, Jens Wiklander <jens.wiklander@linaro.org> wrote:
>
> H,
>
> On Wed, Feb 7, 2024 at 7:11 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> >
> > Hi Ilias, Ulf,
> >
> > On Tue, 6 Feb 2024 at 20:41, Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
> > >
> > > Hi Ulf,
> > >
> > > On Tue, 6 Feb 2024 at 14:34, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > >
> > > > On Wed, 31 Jan 2024 at 18:44, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> > > > >
> > > > > 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: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. 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 which
> > > > > can be accessed by the optee driver to facilitate early RPMB access to
> > > > > OP-TEE OS (secure OS) during the boot time.
> > > >
> > > > How early do we expect OP-TEE to need RPMB access?
> > >
> > > It depends on the requested services. I am currently aware of 2
> > > services that depend on the RPMB
> > > - FirmwareTPM
> > > - UEFI variables stored there via optee.
> > >
> > > For the FirmwareTPM it depends on when you want to use it. This
> > > typically happens when the initramfs is loaded or systemd requests
> > > access to the TPM. I guess this is late enough to not cause problems?
> >
> > Actually RPMB access is done as early as during fTPM probe, probably
> > to cache NVRAM from RPMB during fTPM init. Also, there is a kernel
> > user being IMA which would require fTPM access too. So we really need
> > to manage dependencies here.
> >
> > >
> > > For the latter, we won't need the supplicant until a write is
> > > requested. This will only happen once the userspace is up and running.
> > > The UEFI driver that sits behind OP-TEE has an in-memory cache of the
> > > variables, so all the reads (the kernel invokes get_next_variable
> > > during boot) are working without it.
> > >
> > > Thanks
> > > /Ilias
> > > >
> > > > The way things work for mmc today, is that the eMMC card gets
> > > > discovered/probed via a workqueue. The work is punted by the mmc host
> > > > driver (typically a module-platform-driver), when it has probed
> > > > successfully.
> >
> > It would be nice if RPMB is available as early as possible but for the
> > time being we can try to see if probe deferral suffices for all
> > use-cases.
> >
> > > >
> > > > The point is, it looks like we need some kind of probe deferral
> > > > mechanism too. Whether we want the OP-TEE driver to manage this itself
> > > > or whether we should let rpmb_dev_find_device() deal with it, I don't
> > > > know.
> >
> > I wouldn't like to see the OP-TEE driver probe being deferred due to
> > this since there are other kernel drivers like OP-TEE RNG (should be
> > available as early as we can) etc. which don't have any dependency on
> > RPMB.
>
> I agree, the optee driver itself can probe without RPMB.
>
> >
> > How about for the time being we defer fTPM probe until RPMB is available?
>
> Sounds a bit like what we do with the
> optee_enumerate_devices(PTA_CMD_GET_DEVICES_SUPP) call when
> tee-supplicant has opened the supplicant device. It would perhaps work
> with a PTA_CMD_GET_DEVICES_RPMB or such.
That sounds much better, it will be like an OP-TEE driver callback
(optee_enumerate_devices(PTA_CMD_GET_DEVICES_RPMB)) registered with
the RPMB subsystem. But we should check if all the RPMB partitions are
registered before we invoke the callbacks such that OP-TEE will have a
chance to select the right one.
-Sumit
>
> Thanks,
> Jens
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-02-07 7:49 ` Sumit Garg
@ 2024-02-07 8:11 ` Jens Wiklander
0 siblings, 0 replies; 22+ messages in thread
From: Jens Wiklander @ 2024-02-07 8:11 UTC (permalink / raw)
To: Sumit Garg
Cc: Ilias Apalodimas, Ulf Hansson, linux-kernel, linux-mmc, op-tee,
Shyam Saini, Jerome Forissier, Bart Van Assche, Randy Dunlap,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman, Tomas Winkler,
Alex Bennée
On Wed, Feb 7, 2024 at 8:49 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> On Wed, 7 Feb 2024 at 12:56, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> >
> > H,
> >
> > On Wed, Feb 7, 2024 at 7:11 AM Sumit Garg <sumit.garg@linaro.org> wrote:
> > >
> > > Hi Ilias, Ulf,
> > >
> > > On Tue, 6 Feb 2024 at 20:41, Ilias Apalodimas
> > > <ilias.apalodimas@linaro.org> wrote:
> > > >
> > > > Hi Ulf,
> > > >
> > > > On Tue, 6 Feb 2024 at 14:34, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > > >
> > > > > On Wed, 31 Jan 2024 at 18:44, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> > > > > >
> > > > > > 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: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. 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 which
> > > > > > can be accessed by the optee driver to facilitate early RPMB access to
> > > > > > OP-TEE OS (secure OS) during the boot time.
> > > > >
> > > > > How early do we expect OP-TEE to need RPMB access?
> > > >
> > > > It depends on the requested services. I am currently aware of 2
> > > > services that depend on the RPMB
> > > > - FirmwareTPM
> > > > - UEFI variables stored there via optee.
> > > >
> > > > For the FirmwareTPM it depends on when you want to use it. This
> > > > typically happens when the initramfs is loaded or systemd requests
> > > > access to the TPM. I guess this is late enough to not cause problems?
> > >
> > > Actually RPMB access is done as early as during fTPM probe, probably
> > > to cache NVRAM from RPMB during fTPM init. Also, there is a kernel
> > > user being IMA which would require fTPM access too. So we really need
> > > to manage dependencies here.
> > >
> > > >
> > > > For the latter, we won't need the supplicant until a write is
> > > > requested. This will only happen once the userspace is up and running.
> > > > The UEFI driver that sits behind OP-TEE has an in-memory cache of the
> > > > variables, so all the reads (the kernel invokes get_next_variable
> > > > during boot) are working without it.
> > > >
> > > > Thanks
> > > > /Ilias
> > > > >
> > > > > The way things work for mmc today, is that the eMMC card gets
> > > > > discovered/probed via a workqueue. The work is punted by the mmc host
> > > > > driver (typically a module-platform-driver), when it has probed
> > > > > successfully.
> > >
> > > It would be nice if RPMB is available as early as possible but for the
> > > time being we can try to see if probe deferral suffices for all
> > > use-cases.
> > >
> > > > >
> > > > > The point is, it looks like we need some kind of probe deferral
> > > > > mechanism too. Whether we want the OP-TEE driver to manage this itself
> > > > > or whether we should let rpmb_dev_find_device() deal with it, I don't
> > > > > know.
> > >
> > > I wouldn't like to see the OP-TEE driver probe being deferred due to
> > > this since there are other kernel drivers like OP-TEE RNG (should be
> > > available as early as we can) etc. which don't have any dependency on
> > > RPMB.
> >
> > I agree, the optee driver itself can probe without RPMB.
> >
> > >
> > > How about for the time being we defer fTPM probe until RPMB is available?
> >
> > Sounds a bit like what we do with the
> > optee_enumerate_devices(PTA_CMD_GET_DEVICES_SUPP) call when
> > tee-supplicant has opened the supplicant device. It would perhaps work
> > with a PTA_CMD_GET_DEVICES_RPMB or such.
>
> That sounds much better, it will be like an OP-TEE driver callback
> (optee_enumerate_devices(PTA_CMD_GET_DEVICES_RPMB)) registered with
> the RPMB subsystem. But we should check if all the RPMB partitions are
> registered before we invoke the callbacks such that OP-TEE will have a
> chance to select the right one.
I agree, we should wait until OP-TEE has found an RPMB device
programmed with the expected key as only OP-TEE should know that key.
Thanks,
Jens
>
> -Sumit
>
> >
> > Thanks,
> > Jens
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-02-07 6:11 ` Sumit Garg
2024-02-07 7:25 ` Jens Wiklander
@ 2024-02-07 7:34 ` Ilias Apalodimas
1 sibling, 0 replies; 22+ messages in thread
From: Ilias Apalodimas @ 2024-02-07 7:34 UTC (permalink / raw)
To: Sumit Garg
Cc: Ulf Hansson, Jens Wiklander, linux-kernel, linux-mmc, op-tee,
Shyam Saini, Jerome Forissier, Bart Van Assche, Randy Dunlap,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman, Tomas Winkler,
Alex Bennée
On Wed, 7 Feb 2024 at 08:11, Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Hi Ilias, Ulf,
>
> On Tue, 6 Feb 2024 at 20:41, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > Hi Ulf,
> >
> > On Tue, 6 Feb 2024 at 14:34, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > >
> > > On Wed, 31 Jan 2024 at 18:44, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> > > >
> > > > 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: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. 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 which
> > > > can be accessed by the optee driver to facilitate early RPMB access to
> > > > OP-TEE OS (secure OS) during the boot time.
> > >
> > > How early do we expect OP-TEE to need RPMB access?
> >
> > It depends on the requested services. I am currently aware of 2
> > services that depend on the RPMB
> > - FirmwareTPM
> > - UEFI variables stored there via optee.
> >
> > For the FirmwareTPM it depends on when you want to use it. This
> > typically happens when the initramfs is loaded or systemd requests
> > access to the TPM. I guess this is late enough to not cause problems?
>
> Actually RPMB access is done as early as during fTPM probe, probably
> to cache NVRAM from RPMB during fTPM init. Also, there is a kernel
> user being IMA which would require fTPM access too. So we really need
> to manage dependencies here.
Ah true. I was wrongly assuming loading is a module and having systemd
or something similar handling that dependency. But in case this is
built-in we do need to handle that internally.
>
> >
> > For the latter, we won't need the supplicant until a write is
> > requested. This will only happen once the userspace is up and running.
> > The UEFI driver that sits behind OP-TEE has an in-memory cache of the
> > variables, so all the reads (the kernel invokes get_next_variable
> > during boot) are working without it.
> >
> > Thanks
> > /Ilias
> > >
> > > The way things work for mmc today, is that the eMMC card gets
> > > discovered/probed via a workqueue. The work is punted by the mmc host
> > > driver (typically a module-platform-driver), when it has probed
> > > successfully.
>
> It would be nice if RPMB is available as early as possible but for the
> time being we can try to see if probe deferral suffices for all
> use-cases.
>
> > >
> > > The point is, it looks like we need some kind of probe deferral
> > > mechanism too. Whether we want the OP-TEE driver to manage this itself
> > > or whether we should let rpmb_dev_find_device() deal with it, I don't
> > > know.
>
> I wouldn't like to see the OP-TEE driver probe being deferred due to
> this since there are other kernel drivers like OP-TEE RNG (should be
> available as early as we can) etc. which don't have any dependency on
> RPMB.
>
> How about for the time being we defer fTPM probe until RPMB is available?
>
> -Sumit
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-02-06 12:33 ` Ulf Hansson
2024-02-06 15:10 ` Ilias Apalodimas
@ 2024-02-07 8:06 ` Jens Wiklander
2024-02-13 23:16 ` Ulf Hansson
1 sibling, 1 reply; 22+ messages in thread
From: Jens Wiklander @ 2024-02-07 8:06 UTC (permalink / raw)
To: Ulf Hansson
Cc: linux-kernel, linux-mmc, op-tee, Shyam Saini, Jerome Forissier,
Sumit Garg, Ilias Apalodimas, Bart Van Assche, Randy Dunlap,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman, Tomas Winkler,
Alex Bennée
On Tue, Feb 6, 2024 at 1:34 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Wed, 31 Jan 2024 at 18:44, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> >
> > 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: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. 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 which
> > can be accessed by the optee driver to facilitate early RPMB access to
> > OP-TEE OS (secure OS) during the boot time.
>
> How early do we expect OP-TEE to need RPMB access?
>
> The way things work for mmc today, is that the eMMC card gets
> discovered/probed via a workqueue. The work is punted by the mmc host
> driver (typically a module-platform-driver), when it has probed
> successfully.
>
> The point is, it looks like we need some kind of probe deferral
> mechanism too. Whether we want the OP-TEE driver to manage this itself
> or whether we should let rpmb_dev_find_device() deal with it, I don't
> know.
As I wrote in another reply. I'd like to probe the OP-TEE driver
without touching RPMB first, and then as the devices start to appear
we discover the one to use. In this patchset I'm relying on the OP-TEE
client to wait until the RPMB device is available. That's probably
good enough for user space client, but I guess not for kernel clients
(drivers).
>
> >
> > A TEE device driver can claim the RPMB interface, for example, via
> > class_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().
>
> By looking at the design of the interface, I do like it. It's simple
> and straightforward.
>
> However, I wonder if you considered avoiding using a class-device
> altogether? Even if it helps with lifecycle problems and the
> ops-lookup, we really don't need another struct device with a sysfs
> node, etc.
Yes, the class-device might be more of a leftover from earlier
versions with a user space interface too. Let's try to do this without
a class-device. I was considering using class_interface_register() for
the optee driver to get notified of an eventual RPMB device, but if we
don't have an RPMB class device we'll need some other mechanism for
that. Perhaps a rpmb_interface_register() with similar callbacks as
class_interface_register().
>
> To deal with the lifecycle issue, we could probably just add reference
> counting for the corresponding struct device that we already have at
> hand, which represents the eMMC/UFS/NVME card. That together with a
> simple list that contains the registered rpmb ops. But I may be
> overlooking something, so perhaps it's more complicated than that?
I could try to call mmc_blk_get() in mmc_blk_alloc_rpmb_part() when
storing the md pointer in the newly created struct mmc_rpmb_data. If
that works as I hope, then I can get rid of the two get_resources()
and put_resources() callbacks. We should probably update
mmc_rpmb_chrdev_open() and mmc_rpmb_chrdev_release() to match this.
>
> >
> > The detailed operation of implementing the access is left to the TEE
> > device driver itself.
> >
> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> > Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
> > Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
> > ---
> > MAINTAINERS | 7 ++
> > drivers/misc/Kconfig | 9 ++
> > drivers/misc/Makefile | 1 +
> > drivers/misc/rpmb-core.c | 247 +++++++++++++++++++++++++++++++++++++++
> > include/linux/rpmb.h | 184 +++++++++++++++++++++++++++++
> > 5 files changed, 448 insertions(+)
> > create mode 100644 drivers/misc/rpmb-core.c
> > create mode 100644 include/linux/rpmb.h
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 8999497011a2..e83152c42499 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -19012,6 +19012,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 <jens.wiklander@linaro.org>
> > +L: linux-kernel@vger.kernel.org
> > +S: Supported
> > +F: drivers/misc/rpmb-core.c
> > +F: include/linux/rpmb.h
> > +
> > RPMSG TTY DRIVER
> > M: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
> > L: linux-remoteproc@vger.kernel.org
> > diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> > index 4fb291f0bf7c..891aa5763666 100644
> > --- a/drivers/misc/Kconfig
> > +++ b/drivers/misc/Kconfig
> > @@ -104,6 +104,15 @@ config PHANTOM
> > If you choose to build module, its name will be phantom. If unsure,
> > say N here.
> >
> > +config RPMB
> > + tristate "RPMB partition interface"
>
> Should we add a "depends on MMC"? (We can add the other NVME and UFS
> later on too).
That makes sense, I'll add that.
>
> > + 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..a3c289051687
> > --- /dev/null
> > +++ b/drivers/misc/rpmb-core.c
> > @@ -0,0 +1,247 @@
> > +// 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 DEFINE_IDA(rpmb_ida);
> > +static DEFINE_MUTEX(rpmb_mutex);
> > +
> > +/**
> > + * 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->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->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
> > + *
> > + * @return < 0 on failure
> > + */
> > +int rpmb_route_frames(struct rpmb_dev *rdev, u8 *req,
> > + unsigned int req_len, u8 *rsp, unsigned int rsp_len)
> > +{
> > + struct rpmb_frame *frm = (struct rpmb_frame *)req;
>
> Is there a reason why we are passing an u8 *req, in favor of a
> "rpmb_frame *frame" directly as the in-parameter?
In the OP-TEE driver, we get an arbitrarily sized block of data from
the secure world, but we don't interpret it. I expect that it would be
the same for any other driver. You get data from somewhere and need to
pass it on. With this interface, we can provide the needed sanity
checks here instead of forcing each caller to do it instead.
>
> > + u16 req_type;
> > + bool write;
> > +
> > + if (!req || req_len < sizeof(*frm) || !rsp || !rsp_len)
> > + return -EINVAL;
> > +
> > + req_type = be16_to_cpu(frm->req_resp);
> > + switch (req_type) {
> > + case RPMB_PROGRAM_KEY:
> > + if (req_len != sizeof(struct rpmb_frame) ||
> > + rsp_len != sizeof(struct rpmb_frame))
> > + return -EINVAL;
> > + write = true;
> > + break;
> > + case RPMB_GET_WRITE_COUNTER:
> > + if (req_len != sizeof(struct rpmb_frame) ||
> > + rsp_len != sizeof(struct rpmb_frame))
> > + return -EINVAL;
> > + write = false;
> > + break;
> > + case RPMB_WRITE_DATA:
> > + if (req_len % sizeof(struct rpmb_frame) ||
> > + rsp_len != sizeof(struct rpmb_frame))
> > + return -EINVAL;
> > + write = true;
> > + break;
> > + case RPMB_READ_DATA:
> > + if (req_len != sizeof(struct rpmb_frame) ||
> > + rsp_len % sizeof(struct rpmb_frame))
> > + return -EINVAL;
> > + write = false;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > +
> > + return rdev->ops->route_frames(rdev->dev.parent, write,
> > + req, req_len, rsp, rsp_len);
> > +}
> > +EXPORT_SYMBOL_GPL(rpmb_route_frames);
>
> [...]
>
>
> > +
> > +/**
> > + * enum rpmb_type - type of underlaying 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,
> > +};
>
> In what way do we expect these to be useful?
>
> Perhaps we should add some information about this, because currently
> in the series they seem not to be used. Maybe the OP-TEE driver needs
> it when extending support to NVME and UFS?
Yes, we need to pass this information to the secure side. I'll update
the OP-TEE driver to extract and use the type field from struct
rpmb_ops.
Thanks,
Jens
>
> [...]
>
> Kind regards
> Uffe
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH v2 1/3] rpmb: add Replay Protected Memory Block (RPMB) subsystem
2024-02-07 8:06 ` Jens Wiklander
@ 2024-02-13 23:16 ` Ulf Hansson
0 siblings, 0 replies; 22+ messages in thread
From: Ulf Hansson @ 2024-02-13 23:16 UTC (permalink / raw)
To: Jens Wiklander
Cc: linux-kernel, linux-mmc, op-tee, Shyam Saini, Jerome Forissier,
Sumit Garg, Ilias Apalodimas, Bart Van Assche, Randy Dunlap,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman, Tomas Winkler,
Alex Bennée
On Wed, 7 Feb 2024 at 09:06, Jens Wiklander <jens.wiklander@linaro.org> wrote:
>
> On Tue, Feb 6, 2024 at 1:34 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Wed, 31 Jan 2024 at 18:44, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> > >
> > > 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: WRITE, READ, GET_WRITE_COUNTER, and PROGRAM_KEY. 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 which
> > > can be accessed by the optee driver to facilitate early RPMB access to
> > > OP-TEE OS (secure OS) during the boot time.
> >
> > How early do we expect OP-TEE to need RPMB access?
> >
> > The way things work for mmc today, is that the eMMC card gets
> > discovered/probed via a workqueue. The work is punted by the mmc host
> > driver (typically a module-platform-driver), when it has probed
> > successfully.
> >
> > The point is, it looks like we need some kind of probe deferral
> > mechanism too. Whether we want the OP-TEE driver to manage this itself
> > or whether we should let rpmb_dev_find_device() deal with it, I don't
> > know.
>
> As I wrote in another reply. I'd like to probe the OP-TEE driver
> without touching RPMB first, and then as the devices start to appear
> we discover the one to use. In this patchset I'm relying on the OP-TEE
> client to wait until the RPMB device is available. That's probably
> good enough for user space client, but I guess not for kernel clients
> (drivers).
Right, I understand.
Obviously we don't need to solve all problems (use-cases) at once, but
it sure sounds like we at least need to make some additional thinking
around this part.
>
> >
> > >
> > > A TEE device driver can claim the RPMB interface, for example, via
> > > class_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().
> >
> > By looking at the design of the interface, I do like it. It's simple
> > and straightforward.
> >
> > However, I wonder if you considered avoiding using a class-device
> > altogether? Even if it helps with lifecycle problems and the
> > ops-lookup, we really don't need another struct device with a sysfs
> > node, etc.
>
> Yes, the class-device might be more of a leftover from earlier
> versions with a user space interface too. Let's try to do this without
> a class-device. I was considering using class_interface_register() for
> the optee driver to get notified of an eventual RPMB device, but if we
> don't have an RPMB class device we'll need some other mechanism for
> that. Perhaps a rpmb_interface_register() with similar callbacks as
> class_interface_register().
Okay, sounds like you want to make it a try. I am happy to look at the
code, ofcourse. Although, honestly - I don't know what's the preferred
option here.
>
> >
> > To deal with the lifecycle issue, we could probably just add reference
> > counting for the corresponding struct device that we already have at
> > hand, which represents the eMMC/UFS/NVME card. That together with a
> > simple list that contains the registered rpmb ops. But I may be
> > overlooking something, so perhaps it's more complicated than that?
>
> I could try to call mmc_blk_get() in mmc_blk_alloc_rpmb_part() when
> storing the md pointer in the newly created struct mmc_rpmb_data. If
> that works as I hope, then I can get rid of the two get_resources()
> and put_resources() callbacks. We should probably update
> mmc_rpmb_chrdev_open() and mmc_rpmb_chrdev_release() to match this.
Something like that. But I need to have a closer look at this
(probably easier to review another version of the patchseries), to
really tell what works best.
Do note that mmc/sd cards are hot-pluggable (removable) from the mmc
block device point of view.
[...]
Kind regards
Uffe
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH v2 2/3] mmc: block: register RPMB partition with the RPMB subsystem
2024-01-31 17:43 [PATCH v2 0/3] Replay Protected Memory Block (RPMB) subsystem Jens Wiklander
2024-01-31 17:43 ` [PATCH v2 1/3] rpmb: add " Jens Wiklander
@ 2024-01-31 17:43 ` Jens Wiklander
2024-02-01 9:18 ` Jorge Ramirez-Ortiz, Foundries
2024-01-31 17:43 ` [PATCH v2 3/3] optee: probe RPMB device using " Jens Wiklander
2024-02-02 9:59 ` [PATCH v2 0/3] Replay Protected Memory Block (RPMB) subsystem Sumit Garg
3 siblings, 1 reply; 22+ messages in thread
From: Jens Wiklander @ 2024-01-31 17:43 UTC (permalink / raw)
To: linux-kernel, linux-mmc, op-tee
Cc: Shyam Saini, Ulf Hansson, Jerome Forissier, Sumit Garg,
Ilias Apalodimas, Bart Van Assche, Randy Dunlap, Ard Biesheuvel,
Arnd Bergmann, Greg Kroah-Hartman, Jens Wiklander, Tomas Winkler,
Alexander Usyskin
Register eMMC RPMB partition with the RPMB subsystem and provide
an implementation for the RPMB access operations abstracting
the actual multi step process.
Add callbacks for getting and putting the needed resources, that is, the
RPMB data and the RPMB disk.
Add a callback to extract the needed device information at registration
to avoid accessing the struct mmc_card at a later stage as we're not
holding a reference counter for this struct.
Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
---
drivers/mmc/core/block.c | 177 +++++++++++++++++++++++++++++++++++++++
1 file changed, 177 insertions(+)
diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
index 32d49100dff5..5286e0b3a5a2 100644
--- a/drivers/mmc/core/block.c
+++ b/drivers/mmc/core/block.c
@@ -33,6 +33,7 @@
#include <linux/cdev.h>
#include <linux/mutex.h>
#include <linux/scatterlist.h>
+#include <linux/string.h>
#include <linux/string_helpers.h>
#include <linux/delay.h>
#include <linux/capability.h>
@@ -40,6 +41,7 @@
#include <linux/pm_runtime.h>
#include <linux/idr.h>
#include <linux/debugfs.h>
+#include <linux/rpmb.h>
#include <linux/mmc/ioctl.h>
#include <linux/mmc/card.h>
@@ -163,6 +165,7 @@ struct mmc_rpmb_data {
int id;
unsigned int part_index;
struct mmc_blk_data *md;
+ struct rpmb_dev *rdev;
struct list_head node;
};
@@ -2707,6 +2710,169 @@ static void mmc_blk_rpmb_device_release(struct device *dev)
kfree(rpmb);
}
+static void rpmb_op_mmc_get_resources(struct device *dev)
+{
+ struct mmc_rpmb_data *rpmb = dev_get_drvdata(dev);
+
+ /*
+ * When the MMC card is removed rpmb_dev_unregister() is called
+ * from mmc_blk_remove_rpmb_part(). That removes references to the
+ * devices in struct mmc_rpmb_data and rpmb->md. Since struct
+ * rpmb_dev can still reach those structs we must hold a reference
+ * until struct rpmb_dev also is released.
+ *
+ * This is analogous to what's done in mmc_rpmb_chrdev_open() and
+ * mmc_rpmb_chrdev_release() below.
+ */
+ get_device(dev);
+ mmc_blk_get(rpmb->md->disk);
+}
+
+static void rpmb_op_mmc_put_resources(struct device *dev)
+{
+ struct mmc_rpmb_data *rpmb = dev_get_drvdata(dev);
+
+ mmc_blk_put(rpmb->md);
+ put_device(dev);
+}
+
+static struct mmc_blk_ioc_data **alloc_idata(struct mmc_rpmb_data *rpmb,
+ unsigned int cmd_count)
+{
+ struct mmc_blk_ioc_data **idata;
+ unsigned int n;
+
+ idata = kcalloc(cmd_count, sizeof(*idata), GFP_KERNEL);
+ if (!idata)
+ return NULL;
+
+ for (n = 0; n < cmd_count; n++) {
+ idata[n] = kcalloc(1, sizeof(**idata), GFP_KERNEL);
+ if (!idata[n]) {
+ kfree(idata);
+ return NULL;
+ }
+ idata[n]->rpmb = rpmb;
+ }
+
+ return idata;
+}
+
+static void set_idata(struct mmc_blk_ioc_data *idata, u32 opcode,
+ int write_flag, u8 *buf, unsigned int buf_bytes)
+{
+ idata->ic.opcode = opcode;
+ idata->ic.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
+ idata->ic.write_flag = write_flag;
+ idata->ic.blksz = sizeof(struct rpmb_frame);
+ idata->ic.blocks = buf_bytes / idata->ic.blksz;
+ idata->buf = buf;
+ idata->buf_bytes = buf_bytes;
+}
+
+static void free_idata(struct mmc_blk_ioc_data **idata, unsigned int cmd_count)
+{
+ unsigned int n;
+
+ for (n = 0; n < cmd_count; n++)
+ kfree(idata[n]);
+ kfree(idata);
+}
+
+static int rpmb_op_mmc_route_frames(struct device *dev, bool write, u8 *req,
+ unsigned int req_len, u8 *resp,
+ unsigned int resp_len)
+{
+ struct mmc_rpmb_data *rpmb = dev_get_drvdata(dev);
+ struct mmc_blk_data *md = rpmb->md;
+ struct mmc_blk_ioc_data **idata;
+ unsigned int cmd_count;
+ struct request *rq;
+ int ret;
+
+ if (write)
+ cmd_count = 3;
+ else
+ cmd_count = 2;
+
+ if (IS_ERR(md->queue.card))
+ return PTR_ERR(md->queue.card);
+
+ idata = alloc_idata(rpmb, cmd_count);
+ if (!idata)
+ return -ENOMEM;
+
+ if (write) {
+ struct rpmb_frame *frm = (struct rpmb_frame *)resp;
+
+ /* Send write request frame(s) */
+ set_idata(idata[0], MMC_WRITE_MULTIPLE_BLOCK,
+ 1 | MMC_CMD23_ARG_REL_WR, req, req_len);
+
+ /* Send result request frame */
+ memset(frm, 0, sizeof(*frm));
+ frm->req_resp = cpu_to_be16(RPMB_RESULT_READ);
+ set_idata(idata[1], MMC_WRITE_MULTIPLE_BLOCK, 1, resp,
+ resp_len);
+
+ /* Read response frame */
+ set_idata(idata[2], MMC_READ_MULTIPLE_BLOCK, 0, resp, resp_len);
+ } else {
+ /* Send write request frame(s) */
+ set_idata(idata[0], MMC_WRITE_MULTIPLE_BLOCK, 1, req, req_len);
+
+ /* Read response frame */
+ set_idata(idata[1], MMC_READ_MULTIPLE_BLOCK, 0, resp, resp_len);
+ }
+
+ rq = blk_mq_alloc_request(md->queue.queue, REQ_OP_DRV_OUT, 0);
+ if (IS_ERR(rq)) {
+ ret = PTR_ERR(rq);
+ goto out;
+ }
+
+ req_to_mmc_queue_req(rq)->drv_op = MMC_DRV_OP_IOCTL_RPMB;
+ req_to_mmc_queue_req(rq)->drv_op_result = -EIO;
+ req_to_mmc_queue_req(rq)->drv_op_data = idata;
+ req_to_mmc_queue_req(rq)->ioc_count = cmd_count;
+ blk_execute_rq(rq, false);
+ ret = req_to_mmc_queue_req(rq)->drv_op_result;
+
+ blk_mq_free_request(rq);
+
+out:
+ free_idata(idata, cmd_count);
+ return ret;
+}
+
+static int rpmb_op_mmc_set_dev_info(struct device *dev, struct rpmb_dev *rdev)
+{
+ struct mmc_rpmb_data *rpmb = dev_get_drvdata(dev);
+ struct mmc_card *card = rpmb->md->queue.card;
+ unsigned int n;
+ u32 cid[4];
+
+ for (n = 0; n < 4; n++)
+ cid[n] = be32_to_cpu(card->raw_cid[n]);
+
+ rdev->dev_id = kmemdup(cid, sizeof(cid), GFP_KERNEL);
+ if (!rdev->dev_id)
+ return -ENOMEM;
+ rdev->dev_id_len = sizeof(cid);
+ rdev->reliable_wr_count = card->ext_csd.raw_rpmb_size_mult;
+ rdev->capacity = card->ext_csd.rel_sectors;
+
+ return 0;
+}
+
+static struct rpmb_ops rpmb_mmc_ops = {
+ .type = RPMB_TYPE_EMMC,
+ .get_resources = rpmb_op_mmc_get_resources,
+ .put_resources = rpmb_op_mmc_put_resources,
+ .route_frames = rpmb_op_mmc_route_frames,
+ .set_dev_info = rpmb_op_mmc_set_dev_info,
+};
+
static int mmc_blk_alloc_rpmb_part(struct mmc_card *card,
struct mmc_blk_data *md,
unsigned int part_index,
@@ -2751,6 +2917,14 @@ static int mmc_blk_alloc_rpmb_part(struct mmc_card *card,
goto out_put_device;
}
+ rpmb->rdev = rpmb_dev_register(&rpmb->dev, &rpmb_mmc_ops);
+ if (IS_ERR(rpmb->rdev)) {
+ pr_err("%s: could not register RPMB device\n", rpmb_name);
+ ret = PTR_ERR(rpmb->rdev);
+ rpmb->rdev = NULL;
+ goto out_cdev_device_del;
+ }
+
list_add(&rpmb->node, &md->rpmbs);
string_get_size((u64)size, 512, STRING_UNITS_2,
@@ -2762,6 +2936,8 @@ static int mmc_blk_alloc_rpmb_part(struct mmc_card *card,
return 0;
+out_cdev_device_del:
+ cdev_device_del(&rpmb->chrdev, &rpmb->dev);
out_put_device:
put_device(&rpmb->dev);
return ret;
@@ -2770,6 +2946,7 @@ static int mmc_blk_alloc_rpmb_part(struct mmc_card *card,
static void mmc_blk_remove_rpmb_part(struct mmc_rpmb_data *rpmb)
{
+ rpmb_dev_unregister(rpmb->rdev);
cdev_device_del(&rpmb->chrdev, &rpmb->dev);
put_device(&rpmb->dev);
}
--
2.34.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [PATCH v2 2/3] mmc: block: register RPMB partition with the RPMB subsystem
2024-01-31 17:43 ` [PATCH v2 2/3] mmc: block: register RPMB partition with the RPMB subsystem Jens Wiklander
@ 2024-02-01 9:18 ` Jorge Ramirez-Ortiz, Foundries
2024-02-01 11:40 ` Jens Wiklander
0 siblings, 1 reply; 22+ messages in thread
From: Jorge Ramirez-Ortiz, Foundries @ 2024-02-01 9:18 UTC (permalink / raw)
To: Jens Wiklander
Cc: linux-kernel, linux-mmc, op-tee, Shyam Saini, Ulf Hansson,
Jerome Forissier, Ilias Apalodimas, Bart Van Assche, Randy Dunlap,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman, Tomas Winkler,
Alexander Usyskin
On 31/01/24 18:43:46, Jens Wiklander wrote:
> Register eMMC RPMB partition with the RPMB subsystem and provide
> an implementation for the RPMB access operations abstracting
> the actual multi step process.
>
> Add callbacks for getting and putting the needed resources, that is, the
> RPMB data and the RPMB disk.
>
> Add a callback to extract the needed device information at registration
> to avoid accessing the struct mmc_card at a later stage as we're not
> holding a reference counter for this struct.
>
> Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
> Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
> ---
> drivers/mmc/core/block.c | 177 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 177 insertions(+)
>
> diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> index 32d49100dff5..5286e0b3a5a2 100644
> --- a/drivers/mmc/core/block.c
> +++ b/drivers/mmc/core/block.c
> @@ -33,6 +33,7 @@
> #include <linux/cdev.h>
> #include <linux/mutex.h>
> #include <linux/scatterlist.h>
> +#include <linux/string.h>
> #include <linux/string_helpers.h>
> #include <linux/delay.h>
> #include <linux/capability.h>
> @@ -40,6 +41,7 @@
> #include <linux/pm_runtime.h>
> #include <linux/idr.h>
> #include <linux/debugfs.h>
> +#include <linux/rpmb.h>
>
> #include <linux/mmc/ioctl.h>
> #include <linux/mmc/card.h>
> @@ -163,6 +165,7 @@ struct mmc_rpmb_data {
> int id;
> unsigned int part_index;
> struct mmc_blk_data *md;
> + struct rpmb_dev *rdev;
> struct list_head node;
> };
>
> @@ -2707,6 +2710,169 @@ static void mmc_blk_rpmb_device_release(struct device *dev)
> kfree(rpmb);
> }
>
> +static void rpmb_op_mmc_get_resources(struct device *dev)
> +{
> + struct mmc_rpmb_data *rpmb = dev_get_drvdata(dev);
> +
> + /*
> + * When the MMC card is removed rpmb_dev_unregister() is called
> + * from mmc_blk_remove_rpmb_part(). That removes references to the
> + * devices in struct mmc_rpmb_data and rpmb->md. Since struct
> + * rpmb_dev can still reach those structs we must hold a reference
> + * until struct rpmb_dev also is released.
> + *
> + * This is analogous to what's done in mmc_rpmb_chrdev_open() and
> + * mmc_rpmb_chrdev_release() below.
> + */
> + get_device(dev);
> + mmc_blk_get(rpmb->md->disk);
> +}
> +
> +static void rpmb_op_mmc_put_resources(struct device *dev)
> +{
> + struct mmc_rpmb_data *rpmb = dev_get_drvdata(dev);
> +
> + mmc_blk_put(rpmb->md);
> + put_device(dev);
> +}
> +
> +static struct mmc_blk_ioc_data **alloc_idata(struct mmc_rpmb_data *rpmb,
> + unsigned int cmd_count)
> +{
> + struct mmc_blk_ioc_data **idata;
> + unsigned int n;
> +
> + idata = kcalloc(cmd_count, sizeof(*idata), GFP_KERNEL);
> + if (!idata)
> + return NULL;
> +
> + for (n = 0; n < cmd_count; n++) {
> + idata[n] = kcalloc(1, sizeof(**idata), GFP_KERNEL);
> + if (!idata[n]) {
> + kfree(idata);
don't you need to unwind these allocations on error?
> + return NULL;
> + }
> + idata[n]->rpmb = rpmb;
> + }
> +
> + return idata;
> +}
> +
> +static void set_idata(struct mmc_blk_ioc_data *idata, u32 opcode,
> + int write_flag, u8 *buf, unsigned int buf_bytes)
> +{
> + idata->ic.opcode = opcode;
> + idata->ic.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
> + idata->ic.write_flag = write_flag;
> + idata->ic.blksz = sizeof(struct rpmb_frame);
> + idata->ic.blocks = buf_bytes / idata->ic.blksz;
> + idata->buf = buf;
> + idata->buf_bytes = buf_bytes;
> +}
> +
> +static void free_idata(struct mmc_blk_ioc_data **idata, unsigned int cmd_count)
> +{
> + unsigned int n;
> +
> + for (n = 0; n < cmd_count; n++)
> + kfree(idata[n]);
> + kfree(idata);
> +}
> +
> +static int rpmb_op_mmc_route_frames(struct device *dev, bool write, u8 *req,
> + unsigned int req_len, u8 *resp,
> + unsigned int resp_len)
> +{
> + struct mmc_rpmb_data *rpmb = dev_get_drvdata(dev);
> + struct mmc_blk_data *md = rpmb->md;
> + struct mmc_blk_ioc_data **idata;
> + unsigned int cmd_count;
> + struct request *rq;
> + int ret;
> +
> + if (write)
> + cmd_count = 3;
> + else
> + cmd_count = 2;
> +
> + if (IS_ERR(md->queue.card))
> + return PTR_ERR(md->queue.card);
> +
> + idata = alloc_idata(rpmb, cmd_count);
> + if (!idata)
> + return -ENOMEM;
> +
> + if (write) {
> + struct rpmb_frame *frm = (struct rpmb_frame *)resp;
> +
> + /* Send write request frame(s) */
> + set_idata(idata[0], MMC_WRITE_MULTIPLE_BLOCK,
> + 1 | MMC_CMD23_ARG_REL_WR, req, req_len);
> +
> + /* Send result request frame */
> + memset(frm, 0, sizeof(*frm));
> + frm->req_resp = cpu_to_be16(RPMB_RESULT_READ);
> + set_idata(idata[1], MMC_WRITE_MULTIPLE_BLOCK, 1, resp,
> + resp_len);
> +
> + /* Read response frame */
> + set_idata(idata[2], MMC_READ_MULTIPLE_BLOCK, 0, resp, resp_len);
> + } else {
> + /* Send write request frame(s) */
> + set_idata(idata[0], MMC_WRITE_MULTIPLE_BLOCK, 1, req, req_len);
> +
> + /* Read response frame */
> + set_idata(idata[1], MMC_READ_MULTIPLE_BLOCK, 0, resp, resp_len);
> + }
> +
> + rq = blk_mq_alloc_request(md->queue.queue, REQ_OP_DRV_OUT, 0);
> + if (IS_ERR(rq)) {
> + ret = PTR_ERR(rq);
> + goto out;
> + }
> +
> + req_to_mmc_queue_req(rq)->drv_op = MMC_DRV_OP_IOCTL_RPMB;
> + req_to_mmc_queue_req(rq)->drv_op_result = -EIO;
> + req_to_mmc_queue_req(rq)->drv_op_data = idata;
> + req_to_mmc_queue_req(rq)->ioc_count = cmd_count;
> + blk_execute_rq(rq, false);
> + ret = req_to_mmc_queue_req(rq)->drv_op_result;
> +
> + blk_mq_free_request(rq);
> +
> +out:
> + free_idata(idata, cmd_count);
> + return ret;
> +}
> +
> +static int rpmb_op_mmc_set_dev_info(struct device *dev, struct rpmb_dev *rdev)
> +{
> + struct mmc_rpmb_data *rpmb = dev_get_drvdata(dev);
> + struct mmc_card *card = rpmb->md->queue.card;
> + unsigned int n;
> + u32 cid[4];
> +
> + for (n = 0; n < 4; n++)
> + cid[n] = be32_to_cpu(card->raw_cid[n]);
> +
> + rdev->dev_id = kmemdup(cid, sizeof(cid), GFP_KERNEL);
> + if (!rdev->dev_id)
> + return -ENOMEM;
> + rdev->dev_id_len = sizeof(cid);
> + rdev->reliable_wr_count = card->ext_csd.raw_rpmb_size_mult;
> + rdev->capacity = card->ext_csd.rel_sectors;
> +
> + return 0;
> +}
> +
> +static struct rpmb_ops rpmb_mmc_ops = {
> + .type = RPMB_TYPE_EMMC,
> + .get_resources = rpmb_op_mmc_get_resources,
> + .put_resources = rpmb_op_mmc_put_resources,
> + .route_frames = rpmb_op_mmc_route_frames,
> + .set_dev_info = rpmb_op_mmc_set_dev_info,
> +};
> +
> static int mmc_blk_alloc_rpmb_part(struct mmc_card *card,
> struct mmc_blk_data *md,
> unsigned int part_index,
> @@ -2751,6 +2917,14 @@ static int mmc_blk_alloc_rpmb_part(struct mmc_card *card,
> goto out_put_device;
> }
>
> + rpmb->rdev = rpmb_dev_register(&rpmb->dev, &rpmb_mmc_ops);
> + if (IS_ERR(rpmb->rdev)) {
> + pr_err("%s: could not register RPMB device\n", rpmb_name);
> + ret = PTR_ERR(rpmb->rdev);
> + rpmb->rdev = NULL;
> + goto out_cdev_device_del;
> + }
> +
> list_add(&rpmb->node, &md->rpmbs);
>
> string_get_size((u64)size, 512, STRING_UNITS_2,
> @@ -2762,6 +2936,8 @@ static int mmc_blk_alloc_rpmb_part(struct mmc_card *card,
>
> return 0;
>
> +out_cdev_device_del:
> + cdev_device_del(&rpmb->chrdev, &rpmb->dev);
> out_put_device:
> put_device(&rpmb->dev);
> return ret;
> @@ -2770,6 +2946,7 @@ static int mmc_blk_alloc_rpmb_part(struct mmc_card *card,
> static void mmc_blk_remove_rpmb_part(struct mmc_rpmb_data *rpmb)
>
> {
> + rpmb_dev_unregister(rpmb->rdev);
> cdev_device_del(&rpmb->chrdev, &rpmb->dev);
> put_device(&rpmb->dev);
> }
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH v2 2/3] mmc: block: register RPMB partition with the RPMB subsystem
2024-02-01 9:18 ` Jorge Ramirez-Ortiz, Foundries
@ 2024-02-01 11:40 ` Jens Wiklander
0 siblings, 0 replies; 22+ messages in thread
From: Jens Wiklander @ 2024-02-01 11:40 UTC (permalink / raw)
To: Jorge Ramirez-Ortiz, Foundries
Cc: linux-kernel, linux-mmc, op-tee, Shyam Saini, Ulf Hansson,
Jerome Forissier, Ilias Apalodimas, Bart Van Assche, Randy Dunlap,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman, Tomas Winkler,
Alexander Usyskin
On Thu, Feb 1, 2024 at 10:18 AM Jorge Ramirez-Ortiz, Foundries
<jorge@foundries.io> wrote:
>
> On 31/01/24 18:43:46, Jens Wiklander wrote:
> > Register eMMC RPMB partition with the RPMB subsystem and provide
> > an implementation for the RPMB access operations abstracting
> > the actual multi step process.
> >
> > Add callbacks for getting and putting the needed resources, that is, the
> > RPMB data and the RPMB disk.
> >
> > Add a callback to extract the needed device information at registration
> > to avoid accessing the struct mmc_card at a later stage as we're not
> > holding a reference counter for this struct.
> >
> > Signed-off-by: Tomas Winkler <tomas.winkler@intel.com>
> > Signed-off-by: Alexander Usyskin <alexander.usyskin@intel.com>
> > Signed-off-by: Jens Wiklander <jens.wiklander@linaro.org>
> > ---
> > drivers/mmc/core/block.c | 177 +++++++++++++++++++++++++++++++++++++++
> > 1 file changed, 177 insertions(+)
> >
> > diff --git a/drivers/mmc/core/block.c b/drivers/mmc/core/block.c
> > index 32d49100dff5..5286e0b3a5a2 100644
> > --- a/drivers/mmc/core/block.c
> > +++ b/drivers/mmc/core/block.c
> > @@ -33,6 +33,7 @@
> > #include <linux/cdev.h>
> > #include <linux/mutex.h>
> > #include <linux/scatterlist.h>
> > +#include <linux/string.h>
> > #include <linux/string_helpers.h>
> > #include <linux/delay.h>
> > #include <linux/capability.h>
> > @@ -40,6 +41,7 @@
> > #include <linux/pm_runtime.h>
> > #include <linux/idr.h>
> > #include <linux/debugfs.h>
> > +#include <linux/rpmb.h>
> >
> > #include <linux/mmc/ioctl.h>
> > #include <linux/mmc/card.h>
> > @@ -163,6 +165,7 @@ struct mmc_rpmb_data {
> > int id;
> > unsigned int part_index;
> > struct mmc_blk_data *md;
> > + struct rpmb_dev *rdev;
> > struct list_head node;
> > };
> >
> > @@ -2707,6 +2710,169 @@ static void mmc_blk_rpmb_device_release(struct device *dev)
> > kfree(rpmb);
> > }
> >
> > +static void rpmb_op_mmc_get_resources(struct device *dev)
> > +{
> > + struct mmc_rpmb_data *rpmb = dev_get_drvdata(dev);
> > +
> > + /*
> > + * When the MMC card is removed rpmb_dev_unregister() is called
> > + * from mmc_blk_remove_rpmb_part(). That removes references to the
> > + * devices in struct mmc_rpmb_data and rpmb->md. Since struct
> > + * rpmb_dev can still reach those structs we must hold a reference
> > + * until struct rpmb_dev also is released.
> > + *
> > + * This is analogous to what's done in mmc_rpmb_chrdev_open() and
> > + * mmc_rpmb_chrdev_release() below.
> > + */
> > + get_device(dev);
> > + mmc_blk_get(rpmb->md->disk);
> > +}
> > +
> > +static void rpmb_op_mmc_put_resources(struct device *dev)
> > +{
> > + struct mmc_rpmb_data *rpmb = dev_get_drvdata(dev);
> > +
> > + mmc_blk_put(rpmb->md);
> > + put_device(dev);
> > +}
> > +
> > +static struct mmc_blk_ioc_data **alloc_idata(struct mmc_rpmb_data *rpmb,
> > + unsigned int cmd_count)
> > +{
> > + struct mmc_blk_ioc_data **idata;
> > + unsigned int n;
> > +
> > + idata = kcalloc(cmd_count, sizeof(*idata), GFP_KERNEL);
> > + if (!idata)
> > + return NULL;
> > +
> > + for (n = 0; n < cmd_count; n++) {
> > + idata[n] = kcalloc(1, sizeof(**idata), GFP_KERNEL);
> > + if (!idata[n]) {
> > + kfree(idata);
>
> don't you need to unwind these allocations on error?
>
Yes, you're right.
Thanks,
Jens
> > + return NULL;
> > + }
> > + idata[n]->rpmb = rpmb;
> > + }
> > +
> > + return idata;
> > +}
> > +
> > +static void set_idata(struct mmc_blk_ioc_data *idata, u32 opcode,
> > + int write_flag, u8 *buf, unsigned int buf_bytes)
> > +{
> > + idata->ic.opcode = opcode;
> > + idata->ic.flags = MMC_RSP_R1 | MMC_CMD_ADTC;
> > + idata->ic.write_flag = write_flag;
> > + idata->ic.blksz = sizeof(struct rpmb_frame);
> > + idata->ic.blocks = buf_bytes / idata->ic.blksz;
> > + idata->buf = buf;
> > + idata->buf_bytes = buf_bytes;
> > +}
> > +
> > +static void free_idata(struct mmc_blk_ioc_data **idata, unsigned int cmd_count)
> > +{
> > + unsigned int n;
> > +
> > + for (n = 0; n < cmd_count; n++)
> > + kfree(idata[n]);
> > + kfree(idata);
> > +}
> > +
> > +static int rpmb_op_mmc_route_frames(struct device *dev, bool write, u8 *req,
> > + unsigned int req_len, u8 *resp,
> > + unsigned int resp_len)
> > +{
> > + struct mmc_rpmb_data *rpmb = dev_get_drvdata(dev);
> > + struct mmc_blk_data *md = rpmb->md;
> > + struct mmc_blk_ioc_data **idata;
> > + unsigned int cmd_count;
> > + struct request *rq;
> > + int ret;
> > +
> > + if (write)
> > + cmd_count = 3;
> > + else
> > + cmd_count = 2;
> > +
> > + if (IS_ERR(md->queue.card))
> > + return PTR_ERR(md->queue.card);
> > +
> > + idata = alloc_idata(rpmb, cmd_count);
> > + if (!idata)
> > + return -ENOMEM;
> > +
> > + if (write) {
> > + struct rpmb_frame *frm = (struct rpmb_frame *)resp;
> > +
> > + /* Send write request frame(s) */
> > + set_idata(idata[0], MMC_WRITE_MULTIPLE_BLOCK,
> > + 1 | MMC_CMD23_ARG_REL_WR, req, req_len);
> > +
> > + /* Send result request frame */
> > + memset(frm, 0, sizeof(*frm));
> > + frm->req_resp = cpu_to_be16(RPMB_RESULT_READ);
> > + set_idata(idata[1], MMC_WRITE_MULTIPLE_BLOCK, 1, resp,
> > + resp_len);
> > +
> > + /* Read response frame */
> > + set_idata(idata[2], MMC_READ_MULTIPLE_BLOCK, 0, resp, resp_len);
> > + } else {
> > + /* Send write request frame(s) */
> > + set_idata(idata[0], MMC_WRITE_MULTIPLE_BLOCK, 1, req, req_len);
> > +
> > + /* Read response frame */
> > + set_idata(idata[1], MMC_READ_MULTIPLE_BLOCK, 0, resp, resp_len);
> > + }
> > +
> > + rq = blk_mq_alloc_request(md->queue.queue, REQ_OP_DRV_OUT, 0);
> > + if (IS_ERR(rq)) {
> > + ret = PTR_ERR(rq);
> > + goto out;
> > + }
> > +
> > + req_to_mmc_queue_req(rq)->drv_op = MMC_DRV_OP_IOCTL_RPMB;
> > + req_to_mmc_queue_req(rq)->drv_op_result = -EIO;
> > + req_to_mmc_queue_req(rq)->drv_op_data = idata;
> > + req_to_mmc_queue_req(rq)->ioc_count = cmd_count;
> > + blk_execute_rq(rq, false);
> > + ret = req_to_mmc_queue_req(rq)->drv_op_result;
> > +
> > + blk_mq_free_request(rq);
> > +
> > +out:
> > + free_idata(idata, cmd_count);
> > + return ret;
> > +}
> > +
> > +static int rpmb_op_mmc_set_dev_info(struct device *dev, struct rpmb_dev *rdev)
> > +{
> > + struct mmc_rpmb_data *rpmb = dev_get_drvdata(dev);
> > + struct mmc_card *card = rpmb->md->queue.card;
> > + unsigned int n;
> > + u32 cid[4];
> > +
> > + for (n = 0; n < 4; n++)
> > + cid[n] = be32_to_cpu(card->raw_cid[n]);
> > +
> > + rdev->dev_id = kmemdup(cid, sizeof(cid), GFP_KERNEL);
> > + if (!rdev->dev_id)
> > + return -ENOMEM;
> > + rdev->dev_id_len = sizeof(cid);
> > + rdev->reliable_wr_count = card->ext_csd.raw_rpmb_size_mult;
> > + rdev->capacity = card->ext_csd.rel_sectors;
> > +
> > + return 0;
> > +}
> > +
> > +static struct rpmb_ops rpmb_mmc_ops = {
> > + .type = RPMB_TYPE_EMMC,
> > + .get_resources = rpmb_op_mmc_get_resources,
> > + .put_resources = rpmb_op_mmc_put_resources,
> > + .route_frames = rpmb_op_mmc_route_frames,
> > + .set_dev_info = rpmb_op_mmc_set_dev_info,
> > +};
> > +
> > static int mmc_blk_alloc_rpmb_part(struct mmc_card *card,
> > struct mmc_blk_data *md,
> > unsigned int part_index,
> > @@ -2751,6 +2917,14 @@ static int mmc_blk_alloc_rpmb_part(struct mmc_card *card,
> > goto out_put_device;
> > }
> >
> > + rpmb->rdev = rpmb_dev_register(&rpmb->dev, &rpmb_mmc_ops);
> > + if (IS_ERR(rpmb->rdev)) {
> > + pr_err("%s: could not register RPMB device\n", rpmb_name);
> > + ret = PTR_ERR(rpmb->rdev);
> > + rpmb->rdev = NULL;
> > + goto out_cdev_device_del;
> > + }
> > +
> > list_add(&rpmb->node, &md->rpmbs);
> >
> > string_get_size((u64)size, 512, STRING_UNITS_2,
> > @@ -2762,6 +2936,8 @@ static int mmc_blk_alloc_rpmb_part(struct mmc_card *card,
> >
> > return 0;
> >
> > +out_cdev_device_del:
> > + cdev_device_del(&rpmb->chrdev, &rpmb->dev);
> > out_put_device:
> > put_device(&rpmb->dev);
> > return ret;
> > @@ -2770,6 +2946,7 @@ static int mmc_blk_alloc_rpmb_part(struct mmc_card *card,
> > static void mmc_blk_remove_rpmb_part(struct mmc_rpmb_data *rpmb)
> >
> > {
> > + rpmb_dev_unregister(rpmb->rdev);
> > cdev_device_del(&rpmb->chrdev, &rpmb->dev);
> > put_device(&rpmb->dev);
> > }
> > --
> > 2.34.1
> >
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH v2 3/3] optee: probe RPMB device using RPMB subsystem
2024-01-31 17:43 [PATCH v2 0/3] Replay Protected Memory Block (RPMB) subsystem Jens Wiklander
2024-01-31 17:43 ` [PATCH v2 1/3] rpmb: add " Jens Wiklander
2024-01-31 17:43 ` [PATCH v2 2/3] mmc: block: register RPMB partition with the RPMB subsystem Jens Wiklander
@ 2024-01-31 17:43 ` Jens Wiklander
2024-02-06 11:12 ` Sumit Garg
2024-02-02 9:59 ` [PATCH v2 0/3] Replay Protected Memory Block (RPMB) subsystem Sumit Garg
3 siblings, 1 reply; 22+ messages in thread
From: Jens Wiklander @ 2024-01-31 17:43 UTC (permalink / raw)
To: linux-kernel, linux-mmc, op-tee
Cc: Shyam Saini, Ulf Hansson, Jerome Forissier, Sumit Garg,
Ilias Apalodimas, Bart Van Assche, Randy Dunlap, Ard Biesheuvel,
Arnd Bergmann, Greg Kroah-Hartman, Jens Wiklander
Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
use an RPMB device via the RPBM 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 <jens.wiklander@linaro.org>
---
drivers/tee/optee/core.c | 1 +
drivers/tee/optee/ffa_abi.c | 2 +
drivers/tee/optee/optee_private.h | 6 +
drivers/tee/optee/optee_rpc_cmd.h | 33 +++++
drivers/tee/optee/rpc.c | 221 ++++++++++++++++++++++++++++++
drivers/tee/optee/smc_abi.c | 2 +
6 files changed, 265 insertions(+)
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index 3aed554bc8d8..21bcccbe2207 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -177,6 +177,7 @@ void optee_remove_common(struct optee *optee)
tee_shm_pool_free(optee->pool);
optee_supp_uninit(&optee->supp);
mutex_destroy(&optee->call_queue.mutex);
+ mutex_destroy(&optee->rpmb_dev_mutex);
}
static int smc_abi_rc;
diff --git a/drivers/tee/optee/ffa_abi.c b/drivers/tee/optee/ffa_abi.c
index ecb5eb079408..1d207a9d4f3b 100644
--- a/drivers/tee/optee/ffa_abi.c
+++ b/drivers/tee/optee/ffa_abi.c
@@ -934,6 +934,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)) {
@@ -968,6 +969,7 @@ 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);
+ 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_private.h b/drivers/tee/optee/optee_private.h
index 7a5243c78b55..3a87ad4ef1e2 100644
--- a/drivers/tee/optee/optee_private.h
+++ b/drivers/tee/optee/optee_private.h
@@ -20,6 +20,7 @@
/* 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
@@ -197,6 +198,8 @@ 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
* @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,6 +218,9 @@ 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;
unsigned int rpc_param_count;
bool scan_bus_done;
struct work_struct scan_bus_work;
diff --git a/drivers/tee/optee/optee_rpc_cmd.h b/drivers/tee/optee/optee_rpc_cmd.h
index f3f06e0994a7..672e5dcdf041 100644
--- a/drivers/tee/optee/optee_rpc_cmd.h
+++ b/drivers/tee/optee/optee_rpc_cmd.h
@@ -16,6 +16,14 @@
* and sends responses.
*/
+/*
+ * Replay Protected Memory Block access
+ *
+ * [in] memref[0] Frames to device
+ * [out] memref[1] Frames from device
+ */
+#define OPTEE_RPC_CMD_RPMB 1
+
/*
* Get time
*
@@ -103,4 +111,29 @@
/* 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 Must be OPTEE_RPC_RPMB_EMMC
+ * [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
+
#endif /*__OPTEE_RPC_CMD_H*/
diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
index e69bc6380683..6fd6f99dafab 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,217 @@ 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, ¶m);
}
+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 (!IS_ENABLED(CONFIG_RPMB)) {
+ handle_rpc_supp_cmd(ctx, optee, arg);
+ 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_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 rpc_rpmb_match(struct device *dev, const void *data)
+{
+ return 1;
+}
+
+static void handle_rpc_func_rpmb_probe_next(struct tee_context *ctx,
+ struct optee *optee,
+ struct optee_msg_arg *arg)
+{
+ struct rpmb_dev *start_rdev;
+ struct rpmb_dev *rdev;
+ struct tee_param params[2];
+ void *buf;
+
+ if (!IS_ENABLED(CONFIG_RPMB)) {
+ handle_rpc_supp_cmd(ctx, optee, arg);
+ 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_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);
+ start_rdev = optee->rpmb_dev;
+ rdev = rpmb_dev_find_device(NULL, start_rdev, rpc_rpmb_match);
+ rpmb_dev_put(start_rdev);
+ 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->dev_id_len) {
+ arg->ret = TEEC_ERROR_SHORT_BUFFER;
+ return;
+ }
+ memcpy(buf, rdev->dev_id, rdev->dev_id_len);
+ params[1].u.memref.size = rdev->dev_id_len;
+ params[0].u.value.a = OPTEE_RPC_RPMB_EMMC;
+ params[0].u.value.b = rdev->capacity;
+ params[0].u.value.c = rdev->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;
+}
+
+/* Request */
+struct rpmb_req {
+ u16 cmd;
+#define RPMB_CMD_DATA_REQ 0x00
+#define RPMB_CMD_GET_DEV_INFO 0x01
+ u16 dev_id;
+ u16 block_count;
+ /* Optional data frames (rpmb_data_frame) follow */
+};
+
+#define RPMB_REQ_DATA(req) ((void *)((struct rpmb_req *)(req) + 1))
+
+#define RPMB_CID_SZ 16
+
+/* Response to device info request */
+struct rpmb_dev_info {
+ u8 cid[RPMB_CID_SZ];
+ u8 rpmb_size_mult; /* EXT CSD-slice 168: RPMB Size */
+ u8 rel_wr_sec_c; /* EXT CSD-slice 222: Reliable Write Sector */
+ /* Count */
+ u8 ret_code;
+#define RPMB_CMD_GET_DEV_INFO_RET_OK 0x00
+#define RPMB_CMD_GET_DEV_INFO_RET_ERROR 0x01
+};
+
+static int get_dev_info(struct rpmb_dev *rdev, void *rsp, size_t rsp_size)
+{
+ struct rpmb_dev_info *dev_info;
+
+ if (rsp_size != sizeof(*dev_info))
+ return TEEC_ERROR_BAD_PARAMETERS;
+
+ dev_info = rsp;
+ memcpy(dev_info->cid, rdev->dev_id, sizeof(dev_info->cid));
+ dev_info->rpmb_size_mult = rdev->capacity;
+ dev_info->rel_wr_sec_c = rdev->reliable_wr_count;
+ dev_info->ret_code = RPMB_CMD_GET_DEV_INFO_RET_OK;
+
+ return TEEC_SUCCESS;
+}
+
+/*
+ * req is one struct rpmb_req followed by one or more struct rpmb_data_frame
+ * rsp is either one struct rpmb_dev_info or one or more struct rpmb_data_frame
+ */
+static u32 rpmb_process_request(struct optee *optee, struct rpmb_dev *rdev,
+ void *req, size_t req_size,
+ void *rsp, size_t rsp_size)
+{
+ struct rpmb_req *sreq = req;
+ int rc;
+
+ if (req_size < sizeof(*sreq))
+ return TEEC_ERROR_BAD_PARAMETERS;
+
+ switch (sreq->cmd) {
+ case RPMB_CMD_DATA_REQ:
+ rc = rpmb_route_frames(rdev, RPMB_REQ_DATA(req),
+ req_size - sizeof(struct rpmb_req),
+ rsp, rsp_size);
+ if (rc) // TODO translate error code
+ return TEEC_ERROR_BAD_PARAMETERS;
+ return TEEC_SUCCESS;
+ case RPMB_CMD_GET_DEV_INFO:
+ return get_dev_info(rdev, rsp, rsp_size);
+ default:
+ return TEEC_ERROR_BAD_PARAMETERS;
+ }
+}
+
+static void handle_rpc_func_rpmb(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) {
+ handle_rpc_supp_cmd(ctx, optee, arg);
+ 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);
+ arg->ret = rpmb_process_request(optee, rdev, p0,
+ params[0].u.memref.size,
+ p1, params[1].u.memref.size);
+ if (arg->ret)
+ goto out;
+
+ if (optee->ops->to_msg_param(optee, arg->params,
+ arg->num_params, params))
+ arg->ret = TEEC_ERROR_BAD_PARAMETERS;
+out:
+ rpmb_dev_put(rdev);
+}
+
void optee_rpc_cmd(struct tee_context *ctx, struct optee *optee,
struct optee_msg_arg *arg)
{
@@ -271,6 +483,15 @@ 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;
+ case OPTEE_RPC_CMD_RPMB_PROBE_RESET:
+ handle_rpc_func_rpmb_probe_reset(ctx, optee, arg);
+ break;
+ case OPTEE_RPC_CMD_RPMB_PROBE_NEXT:
+ handle_rpc_func_rpmb_probe_next(ctx, optee, arg);
+ break;
+ case OPTEE_RPC_CMD_RPMB:
+ handle_rpc_func_rpmb(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..8c85c3b8dbb4 100644
--- a/drivers/tee/optee/smc_abi.c
+++ b/drivers/tee/optee/smc_abi.c
@@ -1715,6 +1715,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);
@@ -1782,6 +1783,7 @@ static int optee_probe(struct platform_device *pdev)
err_close_ctx:
teedev_close_context(ctx);
err_supp_uninit:
+ 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
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [PATCH v2 3/3] optee: probe RPMB device using RPMB subsystem
2024-01-31 17:43 ` [PATCH v2 3/3] optee: probe RPMB device using " Jens Wiklander
@ 2024-02-06 11:12 ` Sumit Garg
0 siblings, 0 replies; 22+ messages in thread
From: Sumit Garg @ 2024-02-06 11:12 UTC (permalink / raw)
To: Jens Wiklander
Cc: linux-kernel, linux-mmc, op-tee, Shyam Saini, Ulf Hansson,
Jerome Forissier, Ilias Apalodimas, Bart Van Assche, Randy Dunlap,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman
Hi Jens,
On Wed, 31 Jan 2024 at 23:14, Jens Wiklander <jens.wiklander@linaro.org> wrote:
>
> Adds support in the OP-TEE drivers (both SMC and FF-A ABIs) to probe and
> use an RPMB device via the RPBM 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 <jens.wiklander@linaro.org>
> ---
> drivers/tee/optee/core.c | 1 +
> drivers/tee/optee/ffa_abi.c | 2 +
> drivers/tee/optee/optee_private.h | 6 +
> drivers/tee/optee/optee_rpc_cmd.h | 33 +++++
> drivers/tee/optee/rpc.c | 221 ++++++++++++++++++++++++++++++
> drivers/tee/optee/smc_abi.c | 2 +
> 6 files changed, 265 insertions(+)
>
[snip]
> #endif /*__OPTEE_RPC_CMD_H*/
> diff --git a/drivers/tee/optee/rpc.c b/drivers/tee/optee/rpc.c
> index e69bc6380683..6fd6f99dafab 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,217 @@ 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, ¶m);
> }
>
> +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 (!IS_ENABLED(CONFIG_RPMB)) {
> + handle_rpc_supp_cmd(ctx, optee, arg);
> + 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_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 rpc_rpmb_match(struct device *dev, const void *data)
> +{
> + return 1;
> +}
> +
> +static void handle_rpc_func_rpmb_probe_next(struct tee_context *ctx,
> + struct optee *optee,
> + struct optee_msg_arg *arg)
> +{
> + struct rpmb_dev *start_rdev;
> + struct rpmb_dev *rdev;
> + struct tee_param params[2];
> + void *buf;
> +
> + if (!IS_ENABLED(CONFIG_RPMB)) {
> + handle_rpc_supp_cmd(ctx, optee, arg);
> + 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_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);
> + start_rdev = optee->rpmb_dev;
> + rdev = rpmb_dev_find_device(NULL, start_rdev, rpc_rpmb_match);
> + rpmb_dev_put(start_rdev);
> + optee->rpmb_dev = rdev;
> + mutex_unlock(&optee->rpmb_dev_mutex);
> +
> + if (!rdev) {
> + arg->ret = TEEC_ERROR_ITEM_NOT_FOUND;
One of the major comments I have here is regarding how this implicit
dependency on eMMC driver probe is met here. What if OP-TEE based
fTPM/EFI client driver probes before eMMC driver?
-Sumit
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH v2 0/3] Replay Protected Memory Block (RPMB) subsystem
2024-01-31 17:43 [PATCH v2 0/3] Replay Protected Memory Block (RPMB) subsystem Jens Wiklander
` (2 preceding siblings ...)
2024-01-31 17:43 ` [PATCH v2 3/3] optee: probe RPMB device using " Jens Wiklander
@ 2024-02-02 9:59 ` Sumit Garg
2024-02-02 10:46 ` Jens Wiklander
3 siblings, 1 reply; 22+ messages in thread
From: Sumit Garg @ 2024-02-02 9:59 UTC (permalink / raw)
To: Jens Wiklander
Cc: linux-kernel, linux-mmc, op-tee, Shyam Saini, Ulf Hansson,
Jerome Forissier, Ilias Apalodimas, Bart Van Assche, Randy Dunlap,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman
Hi Jens,
On Wed, 31 Jan 2024 at 23:14, Jens Wiklander <jens.wiklander@linaro.org> wrote:
>
> Hi,
>
> It's been a while since Shyam posted the last version [1] of this patch
> set. I've pinged Shyam, but so far I've had no reply so I'm trying to make
> another attempt with the RPMB subsystem. If Shyam has other changes in mind
> than what I'm adding here I hope we'll find a way to cover that too. I'm
> calling it version two of the patchset since I'm trying to address all
> feedback on the previous version even if I'm starting a new thread.
>
> 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 wont rely on userspace as
> well as some TPM issues [6] that were solved.
>
> 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.
>
> 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/20230722014037.42647-1-shyamsaini@linux.microsoft.com/
> [2] https://lore.kernel.org/lkml/20220405093759.1126835-2-alex.bennee@linaro.org/
> [3] https://lore.kernel.org/linux-mmc/1478548394-8184-2-git-send-email-tomas.winkler@intel.com/
> [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
>
> Thanks,
> Jens
>
> 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
>
Thanks for working on this. This is a huge step towards supporting TEE
kernel client drivers. IIRC you mentioned offline to test it with
virtio RPMB on Qemu. If it works then I would be happy to try it out
as well.
Along with that can you point me to the corresponding OP-TEE OS
changes? I suppose as you are just adding 3 new RPC calls in patch#3,
so we should be fine ABI wise although people have to uprev both
OP-TEE and Linux kernel to get this feature enabled. However, OP-TEE
should gate those RPCs behind a config flag or can just fallback to
user-space supplicant if those aren't supported?
-Sumit
>
>
> Jens Wiklander (3):
> rpmb: add Replay Protected Memory Block (RPMB) subsystem
> mmc: block: register RPMB partition with the RPMB subsystem
> optee: probe RPMB device using RPMB subsystem
>
> MAINTAINERS | 7 +
> drivers/misc/Kconfig | 9 ++
> drivers/misc/Makefile | 1 +
> drivers/misc/rpmb-core.c | 247 ++++++++++++++++++++++++++++++
> drivers/mmc/core/block.c | 177 +++++++++++++++++++++
> drivers/tee/optee/core.c | 1 +
> drivers/tee/optee/ffa_abi.c | 2 +
> drivers/tee/optee/optee_private.h | 6 +
> drivers/tee/optee/optee_rpc_cmd.h | 33 ++++
> drivers/tee/optee/rpc.c | 221 ++++++++++++++++++++++++++
> drivers/tee/optee/smc_abi.c | 2 +
> include/linux/rpmb.h | 184 ++++++++++++++++++++++
> 12 files changed, 890 insertions(+)
> create mode 100644 drivers/misc/rpmb-core.c
> create mode 100644 include/linux/rpmb.h
>
>
> base-commit: 41bccc98fb7931d63d03f326a746ac4d429c1dd3
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH v2 0/3] Replay Protected Memory Block (RPMB) subsystem
2024-02-02 9:59 ` [PATCH v2 0/3] Replay Protected Memory Block (RPMB) subsystem Sumit Garg
@ 2024-02-02 10:46 ` Jens Wiklander
0 siblings, 0 replies; 22+ messages in thread
From: Jens Wiklander @ 2024-02-02 10:46 UTC (permalink / raw)
To: Sumit Garg
Cc: linux-kernel, linux-mmc, op-tee, Shyam Saini, Ulf Hansson,
Jerome Forissier, Ilias Apalodimas, Bart Van Assche, Randy Dunlap,
Ard Biesheuvel, Arnd Bergmann, Greg Kroah-Hartman
Hi Sumit,
On Fri, Feb 2, 2024 at 10:59 AM Sumit Garg <sumit.garg@linaro.org> wrote:
>
> Hi Jens,
>
> On Wed, 31 Jan 2024 at 23:14, Jens Wiklander <jens.wiklander@linaro.org> wrote:
> >
> > Hi,
> >
> > It's been a while since Shyam posted the last version [1] of this patch
> > set. I've pinged Shyam, but so far I've had no reply so I'm trying to make
> > another attempt with the RPMB subsystem. If Shyam has other changes in mind
> > than what I'm adding here I hope we'll find a way to cover that too. I'm
> > calling it version two of the patchset since I'm trying to address all
> > feedback on the previous version even if I'm starting a new thread.
> >
> > 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 wont rely on userspace as
> > well as some TPM issues [6] that were solved.
> >
> > 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.
> >
> > 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/20230722014037.42647-1-shyamsaini@linux.microsoft.com/
> > [2] https://lore.kernel.org/lkml/20220405093759.1126835-2-alex.bennee@linaro.org/
> > [3] https://lore.kernel.org/linux-mmc/1478548394-8184-2-git-send-email-tomas.winkler@intel.com/
> > [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
> >
> > Thanks,
> > Jens
> >
> > 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
> >
>
> Thanks for working on this. This is a huge step towards supporting TEE
> kernel client drivers. IIRC you mentioned offline to test it with
> virtio RPMB on Qemu. If it works then I would be happy to try it out
> as well.
I'm sorry, I didn't get far enough with that. I've been testing on a
HiKey 620 with a removable HardKernel eMMC. So I have two RPMBs to
test with.
>
> Along with that can you point me to the corresponding OP-TEE OS
> changes? I suppose as you are just adding 3 new RPC calls in patch#3,
> so we should be fine ABI wise although people have to uprev both
> OP-TEE and Linux kernel to get this feature enabled. However, OP-TEE
> should gate those RPCs behind a config flag or can just fallback to
> user-space supplicant if those aren't supported?
Here are the OP-TEE OS patches
https://github.com/jenswi-linaro/optee_os/tree/rpmb_probe .
Yes, there's automatic fallback to the user-space supplicant if the
kernel reports that the new RPCs aren't supported and the kernel will
not use the in-kernel driver unless the new RPCs have been used.
Cheers,
Jens
>
> -Sumit
>
> >
> >
> > Jens Wiklander (3):
> > rpmb: add Replay Protected Memory Block (RPMB) subsystem
> > mmc: block: register RPMB partition with the RPMB subsystem
> > optee: probe RPMB device using RPMB subsystem
> >
> > MAINTAINERS | 7 +
> > drivers/misc/Kconfig | 9 ++
> > drivers/misc/Makefile | 1 +
> > drivers/misc/rpmb-core.c | 247 ++++++++++++++++++++++++++++++
> > drivers/mmc/core/block.c | 177 +++++++++++++++++++++
> > drivers/tee/optee/core.c | 1 +
> > drivers/tee/optee/ffa_abi.c | 2 +
> > drivers/tee/optee/optee_private.h | 6 +
> > drivers/tee/optee/optee_rpc_cmd.h | 33 ++++
> > drivers/tee/optee/rpc.c | 221 ++++++++++++++++++++++++++
> > drivers/tee/optee/smc_abi.c | 2 +
> > include/linux/rpmb.h | 184 ++++++++++++++++++++++
> > 12 files changed, 890 insertions(+)
> > create mode 100644 drivers/misc/rpmb-core.c
> > create mode 100644 include/linux/rpmb.h
> >
> >
> > base-commit: 41bccc98fb7931d63d03f326a746ac4d429c1dd3
> > --
> > 2.34.1
> >
^ permalink raw reply [flat|nested] 22+ messages in thread