On Wed, May 15, 2024 at 09:51:32AM +0200, Jens Wiklander wrote:
On Tue, May 14, 2024 at 5:45 PM Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Tue, May 07, 2024 at 11:16:17AM +0200, 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. Such a partition provides authenticated and replay protected access, hence suitable as a secure storage.
The initial aim of this patch is to provide a simple RPMB driver interface which can be accessed by the optee driver to facilitate early RPMB access to OP-TEE OS (secure OS) during the boot time.
A TEE device driver can claim the RPMB interface, for example, via rpmb_interface_register() or rpmb_dev_find_device(). The RPMB driver provides a callback to route RPMB frames to the RPMB device accessible via rpmb_route_frames().
The detailed operation of implementing the access is left to the TEE device driver itself.
Signed-off-by: Tomas Winkler 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 Reviewed-by: Linus Walleij linus.walleij@linaro.org
MAINTAINERS | 7 ++ drivers/misc/Kconfig | 10 ++ drivers/misc/Makefile | 1 + drivers/misc/rpmb-core.c | 233 +++++++++++++++++++++++++++++++++++++++ include/linux/rpmb.h | 136 +++++++++++++++++++++++ 5 files changed, 387 insertions(+) create mode 100644 drivers/misc/rpmb-core.c create mode 100644 include/linux/rpmb.h
diff --git a/MAINTAINERS b/MAINTAINERS index 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..dbff9e8c3a03 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -104,6 +104,16 @@ config PHANTOM If you choose to build module, its name will be phantom. If unsure, say N here.
+config RPMB
tristate "RPMB partition interface"depends on MMChelpUnified RPMB unit interface for RPMB capable devices such as eMMC andUFS. Provides interface for in-kernel security controllers to accessRPMB unit.If unsure, select N.config TIFM_CORE tristate "TI Flash Media interface support" depends on PCI diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index ea6ea5bbbc9c..8af058ad1df4 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_LKDTM) += lkdtm/ obj-$(CONFIG_TIFM_CORE) += tifm_core.o obj-$(CONFIG_TIFM_7XX1) += tifm_7xx1.o obj-$(CONFIG_PHANTOM) += phantom.o +obj-$(CONFIG_RPMB) += rpmb-core.o obj-$(CONFIG_QCOM_COINCELL) += qcom-coincell.o obj-$(CONFIG_QCOM_FASTRPC) += fastrpc.o obj-$(CONFIG_SENSORS_BH1770) += bh1770glc.o diff --git a/drivers/misc/rpmb-core.c b/drivers/misc/rpmb-core.c new file mode 100644 index 000000000000..e42a45debc76 --- /dev/null +++ b/drivers/misc/rpmb-core.c @@ -0,0 +1,233 @@ +// SPDX-License-Identifier: GPL-2.0 +/*
- Copyright(c) 2015 - 2019 Intel Corporation. All rights reserved.
- Copyright(c) 2021 - 2024 Linaro Ltd.
- */
+#include <linux/device.h> +#include <linux/init.h> +#include <linux/kernel.h> +#include <linux/list.h> +#include <linux/module.h> +#include <linux/mutex.h> +#include <linux/rpmb.h> +#include <linux/slab.h>
+static struct list_head rpmb_dev_list; +static DEFINE_MUTEX(rpmb_mutex); +static struct blocking_notifier_head rpmb_interface =
BLOCKING_NOTIFIER_INIT(rpmb_interface);+/**
- rpmb_dev_get() - increase rpmb device ref counter
- @rdev: rpmb device
- */
+struct rpmb_dev *rpmb_dev_get(struct rpmb_dev *rdev) +{
if (rdev)get_device(rdev->parent_dev);Odd, why are you thinking the parent reference has anything to do with this device's reference?
Why isn't this a "real" device and part of the driver model properly? This way of "hanging onto" a device and attempting to influence it's reference count is odd, please make this real and not "fake".
I did this in response to https://lore.kernel.org/lkml/CAPDyKFqNhGWKm=+7niNsjXOjEJE3U=o7dRNG=JqpptUSo9...
And I would argue, "Yes, we do need yet-another class and sysfs entry".
This is a "device" that a driver controls, it is NOT the parent device, it is a class device, so as such, make it one. That's what the driver model is for. Trying to avoid it causes problems.
Perhaps "parent_dev" isn't the best name. The struct rpmb_dev can be seen as another representation of the underlying device.
I.e. a class device. So use that :)
The life cycle of struct rpmb_dev is tied to the underlying device with rpmb_dev_register() and rpmb_dev_unregister(). Just as rpmb_route_frames() forwards the frames to the device, rpmb_dev_{get, put}() does the corresponding thing.
You should never be modifying the reference count of a device you really do not control, unless you are trying to make sure it is present to use it yourself.
Bonus, you get that notifier callback "for free" if you do that. But really, notifier callbacks are a pain, are you sure you want that?
Yes, they are needed because the device may show up late and the OP-TEE driver doesn't know if any device will show up. As Ulf pointed out in the link above, at this point, there's no need to tell user space about this kernel internal abstraction.
If this is a representation of how the device is interacted with, then yes, you do need to represent that.
thanks,
greg k-h