All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jorge Ramirez via U-Boot <u-boot@lists.u-boot-project.org>
To: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Jorge Ramirez <jorge.ramirez@oss.qualcomm.com>,
	trini@konsulko.com, jens.wiklander@linaro.org,
	ilias.apalodimas@linaro.org, bhupesh.linux@gmail.com,
	n-francis@ti.com, marek.vasut+renesas@mailbox.org,
	shawn.lin@rock-chips.com, igor.belwon@mentallysanemainliners.org,
	yoshihiro.shimoda.uh@renesas.com, alchark@gmail.com,
	tuyen.dang.xa@renesas.com, padmarao.begari@amd.com,
	macpaul.lin@mediatek.com, jstephan@baylibre.com, bb@ti.com,
	j-mcarthur@ti.com, venkyada@qti.qualcomm.com,
	hayashi.kunihiko@socionext.com, dlechner@baylibre.com,
	u-boot@lists.denx.de
Subject: Re: [PATCH v2 5/5] optee: implement the RPMB subsystem interface for UFS
Date: Wed, 22 Jul 2026 20:12:19 +0200	[thread overview]
Message-ID: <amEIA0pSVEehZJYt@trex> (raw)
In-Reply-To: <6f5137f9-d358-4c51-ac2c-f667cf126d80@linaro.org>

On 22/07/26 17:43:16, Neil Armstrong wrote:
> On 7/22/26 16:12, Jorge Ramirez wrote:
> > On 22/07/26 10:31:04, neil.armstrong@linaro.org wrote:
> > > Hi,
> > > 
> > > On 7/22/26 08:07, Jorge Ramirez-Ortiz wrote:
> > > > OP-TEE's legacy RPMB supplicant interface assumes the RPMB device is eMMC
> > > > and derives the key from an eMMC-shaped device ID, so it can never
> > > > reproduce the key Linux derives for a UFS device; secure storage on
> > > > UFS-only platforms instead needs the transport-agnostic RPMB subsystem
> > > > interface, through which the normal world describes the real RPMB device
> > > > to OP-TEE. Add a UFS backend for it so OP-TEE derives a key matching Linux
> > > > and can use RPMB secure storage on UFS, leaving the legacy eMMC path
> > > > untouched.
> > > > 
> > > > This subsystem backend currently supports UFS drives only; eMMC still uses
> > > > the legacy interface. As the legacy interface is dropped in favour of the
> > > > subsystem one, an eMMC backend should be added here so both transports are
> > > > served through a single RPMB path.
> > > > 
> > > > Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
> > > > ---
> > > >    drivers/tee/optee/Makefile               |   1 +
> > > >    drivers/tee/optee/optee_msg_supplicant.h |   8 ++
> > > >    drivers/tee/optee/optee_private.h        |  41 ++++++++
> > > >    drivers/tee/optee/rpmb.c                 | 124 +++++++++++++++++++++++
> > > 
> > > Why not rpmb_ufs ?
> > 
> > 
> > because in the future (and IMO) rpmb.c should support UFS and EMMC using
> > the new probe interface (eventually removing rpmb_legacy).
> 
> Let's see in the future, if somehow there's need for a common "new"
> and emmc only legacy some rework will be needed anyway. The eMMC RPMB
> hasn't been updated for a very long time...
> 
> Using the driver model to register an rpmb device attached to an eMMC
> or UFS controller would the cleanest way to handle that, but we're not here now.
> 
> > 
> > > 
> > > It's fine to have 2 backend implementations, the emmc is implementing the
> > > legacy optee API, just add a comment in the eMMC file about that.
> > > 
> > > Neil
> > > 
> > > >    drivers/tee/optee/supplicant.c           |   9 ++
> > > >    5 files changed, 183 insertions(+)
> > > >    create mode 100644 drivers/tee/optee/rpmb.c
> > > > 
> > > > diff --git a/drivers/tee/optee/Makefile b/drivers/tee/optee/Makefile
> > > > index 8321cf53a19..7af19834c00 100644
> > > > --- a/drivers/tee/optee/Makefile
> > > > +++ b/drivers/tee/optee/Makefile
> > > > @@ -4,3 +4,4 @@ obj-$(CONFIG_OPTEE) += core.o
> > > >    obj-y += supplicant.o
> > > >    obj-$(CONFIG_DM_I2C) += i2c.o
> > > >    obj-$(CONFIG_SUPPORT_EMMC_RPMB) += rpmb_legacy.o
> > > > +obj-$(CONFIG_SUPPORT_UFS_RPMB) += rpmb.o
> > > > diff --git a/drivers/tee/optee/optee_msg_supplicant.h b/drivers/tee/optee/optee_msg_supplicant.h
> > > > index 963cfd47824..b720d5d7b3f 100644
> > > > --- a/drivers/tee/optee/optee_msg_supplicant.h
> > > > +++ b/drivers/tee/optee/optee_msg_supplicant.h
> > > > @@ -152,6 +152,14 @@
> > > >     */
> > > >    #define OPTEE_MSG_RPC_CMD_I2C_TRANSFER 21
> > > > +#define OPTEE_MSG_RPC_CMD_RPMB_PROBE_RESET	22
> > > > +#define OPTEE_MSG_RPC_CMD_RPMB_PROBE_NEXT	23
> > > > +#define OPTEE_MSG_RPC_CMD_RPMB_FRAMES		24
> > > > +
> > > > +#define OPTEE_RPC_SHM_TYPE_APPL		0
> > > > +
> > > > +#define OPTEE_RPC_RPMB_UFS		1
> > > > +
> > > >    /*
> > > >     * Was OPTEE_MSG_RPC_CMD_SQL_FS, which isn't supported any longer
> > > >     */
> > > > diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h
> > > > index 1f07a27ee4b..2888257aefe 100644
> > > > --- a/drivers/tee/optee/optee_private.h
> > > > +++ b/drivers/tee/optee/optee_private.h
> > > > @@ -9,6 +9,17 @@
> > > >    #include <tee.h>
> > > >    #include <log.h>
> > > > +#ifdef CONFIG_SUPPORT_UFS_RPMB
> > > > +/**
> > > > + * struct optee_private - OP-TEE driver private data
> > > > + * @rpmb_next_region:	next UFS RPMB region to report on PROBE_NEXT
> > > > + * @rpmb_cur_region:	UFS RPMB region selected by the last PROBE_NEXT
> > > > + */
> > > > +struct optee_private {
> > > > +	unsigned int rpmb_next_region;
> > > > +	unsigned int rpmb_cur_region;
> > > > +};
> > > > +#else
> > > >    /**
> > > >     * struct optee_private - OP-TEE driver private data
> > > >     * @rpmb_mmc:		mmc device for the RPMB partition
> > > > @@ -22,6 +33,7 @@ struct optee_private {
> > > >    	int rpmb_dev_id;
> > > >    	int rpmb_original_part;
> > > >    };
> > > > +#endif
> > > >    struct optee_msg_arg;
> > > > @@ -60,6 +72,35 @@ static inline void optee_suppl_rpmb_release(struct udevice *dev)
> > > >    }
> > > >    #endif
> > > > +#ifdef CONFIG_SUPPORT_UFS_RPMB
> > > > +void optee_suppl_cmd_rpmb_probe_reset(struct udevice *dev,
> > > > +				      struct optee_msg_arg *arg);
> > > > +
> > > > +void optee_suppl_cmd_rpmb_probe_next(struct udevice *dev,
> > > > +				     struct optee_msg_arg *arg);
> > > > +
> > > > +void optee_suppl_cmd_rpmb_frames(struct udevice *dev,
> > > > +				 struct optee_msg_arg *arg);
> > > > +#else
> > > > +static inline void optee_suppl_cmd_rpmb_probe_reset(struct udevice *dev,
> > > > +						    struct optee_msg_arg *arg)
> > > > +{
> > > > +	arg->ret = TEE_ERROR_NOT_IMPLEMENTED;
> > > > +}
> > > > +
> > > > +static inline void optee_suppl_cmd_rpmb_probe_next(struct udevice *dev,
> > > > +						   struct optee_msg_arg *arg)
> > > > +{
> > > > +	arg->ret = TEE_ERROR_NOT_IMPLEMENTED;
> > > > +}
> > > > +
> > > > +static inline void optee_suppl_cmd_rpmb_frames(struct udevice *dev,
> > > > +					       struct optee_msg_arg *arg)
> > > > +{
> > > > +	arg->ret = TEE_ERROR_NOT_IMPLEMENTED;
> > > > +}
> > > > +#endif
> > > > +
> > > >    #ifdef CONFIG_DM_I2C
> > > >    /**
> > > >     * optee_suppl_cmd_i2c_transfer() - route I2C requests to an I2C chip
> > > > diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
> > > > new file mode 100644
> > > > index 00000000000..9c3e0f031ad
> > > > --- /dev/null
> > > > +++ b/drivers/tee/optee/rpmb.c
> > > > @@ -0,0 +1,124 @@
> > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > +
> > > > +#include <dm.h>
> > > > +#include <tee.h>
> > > > +#include <ufs.h>
> > > > +
> > > > +#include "optee_msg.h"
> > > > +#include "optee_msg_supplicant.h"
> > > > +#include "optee_private.h"
> > > > +
> > > > +#define UFS_RPMB_CONTROLLER	0
> > > 
> > > Can this be a config option instead which defaults to 0 ?
> > 
> > um, I dont think so - this assumes there is only one controller. If there
> > are more than one, we would need a mechanism to select which one from
> > the enumerated values (maybe a DT alias (ie ufs-rpmb ?) I think the binding order
> > changes as we enable/disable devices)
> 
> It could collide with other SCSI devices like SATA devices over PCIe.
> 
> Usually we try not to hardcode the devices ids.


right...shall I go ahead with a DT alias approach?

  reply	other threads:[~2026-07-22 18:13 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-22  6:07 [PATCH v2 0/5] ufs: rpmb: route OP-TEE RPMB secure storage over UFS Jorge Ramirez-Ortiz via U-Boot
2026-07-22  6:07 ` [PATCH v2 1/5] ufs: decode string descriptors as UTF-16 big-endian Jorge Ramirez-Ortiz via U-Boot
2026-07-22  6:07 ` [PATCH v2 2/5] ufs: add RPMB transport over SCSI SECURITY PROTOCOL Jorge Ramirez-Ortiz via U-Boot
2026-07-22  6:07 ` [PATCH v2 3/5] ufs: derive the per-region RPMB CID and size for OP-TEE Jorge Ramirez-Ortiz via U-Boot
2026-07-22  8:33   ` Neil Armstrong (Linaro) via U-Boot
2026-07-22  9:47     ` Jorge Ramirez via U-Boot
2026-07-22  6:07 ` [PATCH v2 4/5] optee: rename rpmb.c to rpmb_legacy.c Jorge Ramirez-Ortiz via U-Boot
2026-07-22  8:27   ` Neil Armstrong (Linaro) via U-Boot
2026-07-22  9:46     ` Jorge Ramirez via U-Boot
2026-07-22 12:23       ` Jorge Ramirez via U-Boot
2026-07-22 12:33       ` Peter Robinson via U-Boot
2026-07-22 13:10         ` Neil Armstrong via U-Boot
2026-07-22 14:35           ` Jorge Ramirez via U-Boot
2026-07-23  8:48             ` Neil Armstrong
2026-07-22  6:07 ` [PATCH v2 5/5] optee: implement the RPMB subsystem interface for UFS Jorge Ramirez-Ortiz via U-Boot
2026-07-22  8:31   ` Neil Armstrong (Linaro) via U-Boot
2026-07-22 14:12     ` Jorge Ramirez via U-Boot
2026-07-22 15:43       ` Neil Armstrong via U-Boot
2026-07-22 18:12         ` Jorge Ramirez via U-Boot [this message]
2026-07-22 18:44           ` Jorge Ramirez via U-Boot
2026-07-23  7:33             ` Neil Armstrong
2026-07-23  8:01               ` Jorge Ramirez via U-Boot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=amEIA0pSVEehZJYt@trex \
    --to=u-boot@lists.u-boot-project.org \
    --cc=alchark@gmail.com \
    --cc=bb@ti.com \
    --cc=bhupesh.linux@gmail.com \
    --cc=dlechner@baylibre.com \
    --cc=hayashi.kunihiko@socionext.com \
    --cc=igor.belwon@mentallysanemainliners.org \
    --cc=ilias.apalodimas@linaro.org \
    --cc=j-mcarthur@ti.com \
    --cc=jens.wiklander@linaro.org \
    --cc=jorge.ramirez@oss.qualcomm.com \
    --cc=jstephan@baylibre.com \
    --cc=macpaul.lin@mediatek.com \
    --cc=marek.vasut+renesas@mailbox.org \
    --cc=n-francis@ti.com \
    --cc=neil.armstrong@linaro.org \
    --cc=padmarao.begari@amd.com \
    --cc=shawn.lin@rock-chips.com \
    --cc=trini@konsulko.com \
    --cc=tuyen.dang.xa@renesas.com \
    --cc=u-boot@lists.denx.de \
    --cc=venkyada@qti.qualcomm.com \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.