| Message ID | 20240131174347.510961-2-jens.wiklander@linaro.org |
|---|---|
| State | New |
| Headers | show |
| Series | Replay Protected Memory Block (RPMB) subsystem | expand |
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
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
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
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
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
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
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
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
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
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__ */