From: Jens Wiklander <jens.wiklander@oss.qualcomm.com>
To: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
Cc: alim.akhtar@samsung.com, avri.altman@wdc.com, bvanassche@acm.org,
James.Bottomley@hansenpartnership.com,
martin.petersen@oracle.com, beanhuo@micron.com,
can.guo@oss.qualcomm.com, linux-scsi@vger.kernel.org,
linux-kernel@vger.kernel.org, op-tee@lists.trustedfirmware.org,
jenswi@kernel.org, sumit.garg@oss.qualcomm.com
Subject: Re: [PATCH v1 2/2] ufs: rpmb: use a fixed-length RPMB dev_id
Date: Fri, 17 Jul 2026 11:38:31 +0200 [thread overview]
Message-ID: <CAGgiveXtErFjDgxN9reR7s705U3wnnH65c4Su06ZQz_7EYwzuA@mail.gmail.com> (raw)
In-Reply-To: <20260716083728.2226422-3-jorge.ramirez@oss.qualcomm.com>
Hi Jorge,
On Thu, Jul 16, 2026 at 10:37 AM Jorge Ramirez-Ortiz
<jorge.ramirez@oss.qualcomm.com> wrote:
>
> The RPMB authentication key is derived from the dev_id handed to the
> RPMB subsystem. OP-TEE implements the eMMC RPMB flow, where the dev_id
> is the eMMC CID, a fixed 16-byte value, and it derives the key on that
> assumption.
>
> The UFS RPMB id built here is "<device_id>-R<region>", which is variable
> length and longer than 16 bytes. Passing it verbatim would tie the
> derived key to a length OP-TEE does not expect and diverge from the
> fixed-CID eMMC ABI, requiring OP-TEE to be taught about variable-length
> UFS ids.
Yes, if it's possible, It's nice to avoid that.
>
> Hash the UFS id into a fixed 16-byte dev_id with blake2s instead. This
> keeps the derived key stable and unique per region while matching the
> eMMC CID layout OP-TEE relies on, so the key-derivation ABI stays
> identical and no OP-TEE change is needed.
>
> Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
> ---
> drivers/ufs/core/ufs-rpmb.c | 19 +++++++++++++++++--
> 1 file changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ufs/core/ufs-rpmb.c b/drivers/ufs/core/ufs-rpmb.c
> index d0c7ea7a36f4..b800871269bb 100644
> --- a/drivers/ufs/core/ufs-rpmb.c
> +++ b/drivers/ufs/core/ufs-rpmb.c
> @@ -10,6 +10,7 @@
> * Can Guo <can.guo@oss.qualcomm.com>
> */
>
> +#include <crypto/blake2s.h>
> #include <linux/module.h>
> #include <linux/device.h>
> #include <linux/kernel.h>
> @@ -21,6 +22,7 @@
> #include <linux/unaligned.h>
> #include "ufshcd-priv.h"
>
> +#define UFS_RPMB_ID_LEN 16 /* Match eMMC CID Length */
> #define UFS_RPMB_SEC_PROTOCOL 0xEC /* JEDEC UFS application */
> #define UFS_RPMB_SEC_PROTOCOL_ID 0x01 /* JEDEC UFS RPMB protocol ID, CDB byte3 */
>
> @@ -154,6 +156,7 @@ int ufs_rpmb_probe(struct ufs_hba *hba)
> {
> struct ufs_rpmb_dev *ufs_rpmb, *it, *tmp;
> struct rpmb_dev *rdev;
> + char *dev_id = NULL;
> char *cid = NULL;
> int region;
> u32 cap;
> @@ -213,8 +216,17 @@ int ufs_rpmb_probe(struct ufs_hba *hba)
> goto err_out;
> }
>
> - descr.dev_id = cid;
> - descr.dev_id_len = strlen(cid);
> + dev_id = kzalloc(UFS_RPMB_ID_LEN, GFP_KERNEL);
> + if (!dev_id) {
> + device_unregister(&ufs_rpmb->dev);
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + blake2s(NULL, 0, cid, strlen(cid), dev_id, UFS_RPMB_ID_LEN);
> +
> + descr.dev_id = dev_id;
> + descr.dev_id_len = UFS_RPMB_ID_LEN;
This change will break current users of this interface, if there are
any. There are currently no upstream users in OP-TEE since you're
adding that with https://github.com/OP-TEE/optee_os/pull/7881, but I
suppose that's not the only use case.
Cheers,
Jens
> descr.capacity = cap;
>
> /* Register RPMB device */
> @@ -228,6 +240,8 @@ int ufs_rpmb_probe(struct ufs_hba *hba)
>
> kfree(cid);
> cid = NULL;
> + kfree(dev_id);
> + dev_id = NULL;
>
> ufs_rpmb->rdev = rdev;
> ufs_rpmb->region_id = region;
> @@ -240,6 +254,7 @@ int ufs_rpmb_probe(struct ufs_hba *hba)
> return 0;
> err_out:
> kfree(cid);
> + kfree(dev_id);
> list_for_each_entry_safe(it, tmp, &hba->rpmbs, node) {
> list_del(&it->node);
> device_unregister(&it->dev);
> --
> 2.54.0
>
next prev parent reply other threads:[~2026-07-17 9:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-16 8:37 [PATCH v1 0/2] ufs: rpmb: make RPMB usable with OP-TEE key derivation Jorge Ramirez-Ortiz
2026-07-16 8:37 ` [PATCH v1 1/2] ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN Jorge Ramirez-Ortiz
2026-07-16 8:37 ` [PATCH v1 2/2] ufs: rpmb: use a fixed-length RPMB dev_id Jorge Ramirez-Ortiz
2026-07-17 9:38 ` Jens Wiklander [this message]
2026-07-17 10:28 ` Jorge Ramirez
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=CAGgiveXtErFjDgxN9reR7s705U3wnnH65c4Su06ZQz_7EYwzuA@mail.gmail.com \
--to=jens.wiklander@oss.qualcomm.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=alim.akhtar@samsung.com \
--cc=avri.altman@wdc.com \
--cc=beanhuo@micron.com \
--cc=bvanassche@acm.org \
--cc=can.guo@oss.qualcomm.com \
--cc=jenswi@kernel.org \
--cc=jorge.ramirez@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=op-tee@lists.trustedfirmware.org \
--cc=sumit.garg@oss.qualcomm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox