[PATCH v1 0/2] ufs: rpmb: make RPMB usable with OP-TEE key derivation

[PATCH v1 0/2] ufs: rpmb: make RPMB usable with OP-TEE key derivation

[Jorge Ramirez-Ortiz]

This series makes UFS RPMB work out of the box with an OP-TEE that
implements the standard eMMC RPMB key-derivation flow, without requiring
any fundamental changes on the OP-TEE side.

RPMB provides an authenticated, replay-protected storage area whose
security relies on a secret authentication key. In our setup that key is
never exposed to the kernel: OP-TEE derives it in the secure world from
its hardware-unique key and a device identifier (dev_id) that the RPMB
core hands down. OP-TEE's implementation targets eMMC, where dev_id is
the 16-byte eMMC CID, and both the fixed length and the raw-CID layout
are baked into its key derivation.

Two things stand in the way of reusing that same, unmodified OP-TEE flow
for UFS RPMB:

  1. On a cold boot the very first frame sent to the RPMB well-known LU
     comes back with a power-on UNIT ATTENTION (ASC 0x29), which the SCSI
     core reports rather than retries. RPMB has no earlier guaranteed
     access that could clear the condition first, so RPMB fails on every
     power cycle. Patch 1 asks the SCSI core to retry the power-on UNIT
     ATTENTION on the RPMB WLUN.

  2. The UFS RPMB id 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
     eMMC CID ABI. Patch 2 hashes it into a fixed 16-byte dev_id with
     blake2s, keeping the key stable and unique per region while matching
     the eMMC CID layout OP-TEE relies on. The hash algorithm and input
     string are thus part of the key-derivation ABI and must stay stable.

With both patches, UFS RPMB is functional from the first access after a
cold boot and derives keys through the existing eMMC-style OP-TEE flow,
(requires minimal OP-TEE changes pending on the CID proposal done here).

Tested on IQ-9075 with Open Firmware [1], pending OP-TEE changes
[1]https://ldts.github.io/qcom-buildroot

Dependencies:

U-boot:
https://lore.kernel.org/u-boot/20260720085202.537019-1-jorge.ramirez@oss.qualcomm.com/T/#mc423eb4dcf8a15849077029e4f7c1913bb7d8873

OP-TEE:
https://github.com/OP-TEE/optee_os/pull/7881

v2:
  * ufs: rpmb: replace blake2s with blake2b so that the same support
    can be added to u-boot (CRYPTO_LIB_BLAKE2B)
  * added links to U-boot and OP-TEE changes.    

v1:
  * ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN:
     - fix using uses SCMD_FAILURE_ASC_ANY to retry any Unit Attention
     - fix unused variable
  * ufs: rpmb: use a fixed-length RPMB dev_id
     - fix selecting a non-existent Kconfig symbol

Jorge Ramirez-Ortiz (2):
  ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN
  ufs: rpmb: use a fixed-length RPMB dev_id

 drivers/ufs/core/ufs-rpmb.c | 39 ++++++++++++++++++++++++++++++++++---
 1 file changed, 36 insertions(+), 3 deletions(-)

-- 
2.54.0

[PATCH v2 1/2] ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN

[Jorge Ramirez-Ortiz]

After a power cycle, the first command sent to a UFS logical unit
completes with CHECK CONDITION and a power-on UNIT ATTENTION (ASC
0x29). The SCSI core reports this to the caller instead of retrying
it. For the RPMB well-known LU, that first command is the first RPMB
frame sent after boot, so the frame fails. RPMB has no earlier,
guaranteed access that could clear the condition beforehand, so this
breaks RPMB on every cold boot.

Ask the SCSI core to retry the power-on UNIT ATTENTION on the RPMB WLUN
so that RPMB works from the very first access after a power cycle.

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
---
 drivers/ufs/core/ufs-rpmb.c | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/drivers/ufs/core/ufs-rpmb.c b/drivers/ufs/core/ufs-rpmb.c
index ffad049872b9..d0c7ea7a36f4 100644
--- a/drivers/ufs/core/ufs-rpmb.c
+++ b/drivers/ufs/core/ufs-rpmb.c
@@ -40,6 +40,23 @@ struct ufs_rpmb_dev {
 static int ufs_sec_submit(struct ufs_hba *hba, u16 spsp, void *buffer, size_t len, bool send)
 {
 	struct scsi_device *sdev = hba->ufs_rpmb_wlun;
+	/* Retry the power-on UNIT ATTENTION (ASC 0x29); the SCSI core does not. */
+	struct scsi_failure failure_defs[] = {
+		{
+			.sense = UNIT_ATTENTION,
+			.asc = 0x29,
+			.ascq = SCMD_FAILURE_ASCQ_ANY,
+			.allowed = 3,
+			.result = SAM_STAT_CHECK_CONDITION,
+		},
+		{}
+	};
+	struct scsi_failures failures = {
+		.failure_definitions = failure_defs,
+	};
+	const struct scsi_exec_args exec_args = {
+		.failures = &failures,
+	};
 	u8 cdb[12] = { };
 
 	cdb[0] = send ? SECURITY_PROTOCOL_OUT : SECURITY_PROTOCOL_IN;
@@ -48,7 +65,8 @@ static int ufs_sec_submit(struct ufs_hba *hba, u16 spsp, void *buffer, size_t le
 	put_unaligned_be32(len, &cdb[6]);
 
 	return scsi_execute_cmd(sdev, cdb, send ? REQ_OP_DRV_OUT : REQ_OP_DRV_IN,
-				buffer, len, /*timeout=*/30 * HZ, 0, NULL);
+				buffer, len, /*timeout=*/30 * HZ, /*retries=*/0,
+				&exec_args);
 }
 
 /* UFS RPMB route frames implementation */
-- 
2.54.0

[PATCH v2 2/2] ufs: rpmb: use a fixed-length RPMB dev_id

[Jorge Ramirez-Ortiz]

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.

Hash the UFS id into a fixed 16-byte dev_id with blake2b 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. blake2b is used because it is
already available in bootloaders such as U-Boot that must derive the
same dev_id, avoiding the need to add a blake2s implementation there.

Signed-off-by: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>
---
 drivers/ufs/Kconfig         |  1 +
 drivers/ufs/core/ufs-rpmb.c | 19 +++++++++++++++++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/drivers/ufs/Kconfig b/drivers/ufs/Kconfig
index f662e7ce71f1..b62c00e7ff06 100644
--- a/drivers/ufs/Kconfig
+++ b/drivers/ufs/Kconfig
@@ -7,6 +7,7 @@ menuconfig SCSI_UFSHCD
 	tristate "Universal Flash Storage Controller"
 	depends on SCSI && SCSI_DMA
 	depends on RPMB || !RPMB
+	select CRYPTO_LIB_BLAKE2B if RPMB
 	select PM_DEVFREQ
 	select DEVFREQ_GOV_SIMPLE_ONDEMAND
 	select NLS
diff --git a/drivers/ufs/core/ufs-rpmb.c b/drivers/ufs/core/ufs-rpmb.c
index d0c7ea7a36f4..0d8399b6497a 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/blake2b.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;
+		}
+
+		blake2b(NULL, 0, cid, strlen(cid), dev_id, UFS_RPMB_ID_LEN);
+
+		descr.dev_id = dev_id;
+		descr.dev_id_len = UFS_RPMB_ID_LEN;
 		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

Re: [PATCH v2 2/2] ufs: rpmb: use a fixed-length RPMB dev_id

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

Pre-existing issues:
- [High] Use-After-Free on device unbind due to devm_kzalloc used for struct embedding a device
- [High] Circular dependency between parent and child devices prevents cleanup and causes resource leak
- [High] NULL pointer dereference in ufs_rpmb_remove if ufs_rpmb_probe bails out early
--

--- Patch [2]: [PATCH v2 2/2] ufs: rpmb: use a fixed-length RPMB dev_id ---
commit 2720876781cfffc7b6138bf9c11da0d2249234f9
Author: Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com>

ufs: rpmb: use a fixed-length RPMB dev_id

The RPMB authentication key is derived from the dev_id handed to the
RPMB subsystem. This commit hashes the variable-length UFS id into a fixed
16-byte dev_id using blake2b to match the eMMC CID layout OP-TEE relies on.

> diff --git a/drivers/ufs/core/ufs-rpmb.c b/drivers/ufs/core/ufs-rpmb.c
> index d0c7ea7a36f49..0d8399b6497a1 100644
> --- a/drivers/ufs/core/ufs-rpmb.c
> +++ b/drivers/ufs/core/ufs-rpmb.c

[ ... ]

> @@ -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;

[Severity: High]
This isn't a bug introduced by this patch, but does the early return in
ufs_rpmb_probe() leave the rpmbs list head uninitialized?

If the function returns early due to a missing device ID:

drivers/ufs/core/ufs-rpmb.c:ufs_rpmb_probe() {
    if (!hba->dev_info.device_id) {
        dev_err(hba->dev, "UFS Device ID not available\n");
        return -EINVAL;
    }

    INIT_LIST_HEAD(&hba->rpmbs);
    ...
}

When ufs_rpmb_remove() is later called on driver unbind, list_empty()
evaluates to false because hba->rpmbs is completely zeroed out rather than
pointing to itself. This causes a NULL pointer dereference when traversing
the list:

drivers/ufs/core/ufs-rpmb.c:ufs_rpmb_remove() {
    if (list_empty(&hba->rpmbs))
        return;

    list_for_each_entry_safe(ufs_rpmb, tmp, &hba->rpmbs, node) {
    ...
}

[Severity: High]
This is a pre-existing issue, but does using devm_kzalloc() for a structure
that embeds a device cause a use-after-free on driver unbind?

drivers/ufs/core/ufs-rpmb.c:ufs_rpmb_probe() {
    ...
    ufs_rpmb = devm_kzalloc(hba->dev, sizeof(*ufs_rpmb), GFP_KERNEL);
    ...
    device_register(&ufs_rpmb->dev);
    ...
}

If a userspace process opens a sysfs file for this device, the device
reference count is elevated. If the UFS driver is unbound at this point,
devres will automatically free the ufs_rpmb structure.

Later, when the sysfs file is closed, the device core drops the final
reference and calls ufs_rpmb_device_release(), which accesses the
already-freed memory:

drivers/ufs/core/ufs-rpmb.c:ufs_rpmb_device_release() {
    struct ufs_rpmb_dev *ufs_rpmb = dev_get_drvdata(dev);

    rpmb_dev_unregister(ufs_rpmb->rdev);
}

Should ufs_rpmb be allocated with a standard kzalloc() and explicitly freed
in the device release callback instead?

[Severity: High]
This is a pre-existing issue, but is there a circular dependency preventing
the release callback from ever running?

The child device (rdev) holds a reference to its parent (ufs_rpmb->dev).
However, the child is only unregistered in the parent's release callback:

drivers/ufs/core/ufs-rpmb.c:ufs_rpmb_device_release() {
    struct ufs_rpmb_dev *ufs_rpmb = dev_get_drvdata(dev);

    rpmb_dev_unregister(ufs_rpmb->rdev);
}

During driver unbind, only the parent device is unregistered:

drivers/ufs/core/ufs-rpmb.c:ufs_rpmb_remove() {
    ...
    list_for_each_entry_safe(ufs_rpmb, tmp, &hba->rpmbs, node) {
        ...
        device_unregister(&ufs_rpmb->dev);
    }
}

Because the child is left registered, it continues to hold a reference to
the parent. As a result, the parent's reference count never reaches zero,
ufs_rpmb_device_release() is never called, and the device structures are
leaked.

Should the child device be explicitly unregistered in ufs_rpmb_remove()
before unregistering the parent?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260720091614.544968-1-jorge.ramirez@oss.qualcomm.com?part=2

Re: [PATCH v1 0/2] ufs: rpmb: make RPMB usable with OP-TEE key derivation

[Bean Huo]

This is very strange, coverletter is v1, but the patches are v2?


On Mon, 2026-07-20 at 11:16 +0200, Jorge Ramirez-Ortiz wrote:
> This series makes UFS RPMB work out of the box with an OP-TEE that
> implements the standard eMMC RPMB key-derivation flow, without requiring
> any fundamental changes on the OP-TEE side.
> 
> RPMB provides an authenticated, replay-protected storage area whose
> security relies on a secret authentication key. In our setup that key is
> never exposed to the kernel: OP-TEE derives it in the secure world from
> its hardware-unique key and a device identifier (dev_id) that the RPMB
> core hands down. OP-TEE's implementation targets eMMC, where dev_id is
> the 16-byte eMMC CID, and both the fixed length and the raw-CID layout
> are baked into its key derivation.
> 
> Two things stand in the way of reusing that same, unmodified OP-TEE flow
> for UFS RPMB:
> 
>   1. On a cold boot the very first frame sent to the RPMB well-known LU
>      comes back with a power-on UNIT ATTENTION (ASC 0x29), which the SCSI
>      core reports rather than retries. RPMB has no earlier guaranteed
>      access that could clear the condition first, so RPMB fails on every
>      power cycle. Patch 1 asks the SCSI core to retry the power-on UNIT
>      ATTENTION on the RPMB WLUN.
> 
>   2. The UFS RPMB id 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
>      eMMC CID ABI. Patch 2 hashes it into a fixed 16-byte dev_id with
>      blake2s, keeping the key stable and unique per region while matching
>      the eMMC CID layout OP-TEE relies on. The hash algorithm and input
>      string are thus part of the key-derivation ABI and must stay stable.
> 
> With both patches, UFS RPMB is functional from the first access after a
> cold boot and derives keys through the existing eMMC-style OP-TEE flow,
> (requires minimal OP-TEE changes pending on the CID proposal done here).
> 
> Tested on IQ-9075 with Open Firmware [1], pending OP-TEE changes
> [1]https://ldts.github.io/qcom-buildroot
> 
> Dependencies:
> 
> U-boot:
> https://lore.kernel.org/u-boot/20260720085202.537019-1-jorge.ramirez@oss.qualcomm.com/T/#mc423eb4dcf8a15849077029e4f7c1913bb7d8873
> 
> OP-TEE:
> https://github.com/OP-TEE/optee_os/pull/7881
> 
> v2:
>   * ufs: rpmb: replace blake2s with blake2b so that the same support
>     can be added to u-boot (CRYPTO_LIB_BLAKE2B)
>   * added links to U-boot and OP-TEE changes.    
> 
> v1:
>   * ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN:
>      - fix using uses SCMD_FAILURE_ASC_ANY to retry any Unit Attention
>      - fix unused variable
>   * ufs: rpmb: use a fixed-length RPMB dev_id
>      - fix selecting a non-existent Kconfig symbol
> 
> Jorge Ramirez-Ortiz (2):
>   ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN
>   ufs: rpmb: use a fixed-length RPMB dev_id
> 
>  drivers/ufs/core/ufs-rpmb.c | 39 ++++++++++++++++++++++++++++++++++---
>  1 file changed, 36 insertions(+), 3 deletions(-)
> 

Re: [PATCH v1 0/2] ufs: rpmb: make RPMB usable with OP-TEE key derivation

[Jorge Ramirez]

On 20/07/26 12:23:39, Bean Huo wrote:
> 
> This is very strange, coverletter is v1, but the patches are v2?

I messed up (manual edition of the letter) but the thread is proper

> 
> 
> On Mon, 2026-07-20 at 11:16 +0200, Jorge Ramirez-Ortiz wrote:
> > This series makes UFS RPMB work out of the box with an OP-TEE that
> > implements the standard eMMC RPMB key-derivation flow, without requiring
> > any fundamental changes on the OP-TEE side.
> > 
> > RPMB provides an authenticated, replay-protected storage area whose
> > security relies on a secret authentication key. In our setup that key is
> > never exposed to the kernel: OP-TEE derives it in the secure world from
> > its hardware-unique key and a device identifier (dev_id) that the RPMB
> > core hands down. OP-TEE's implementation targets eMMC, where dev_id is
> > the 16-byte eMMC CID, and both the fixed length and the raw-CID layout
> > are baked into its key derivation.
> > 
> > Two things stand in the way of reusing that same, unmodified OP-TEE flow
> > for UFS RPMB:
> > 
> >   1. On a cold boot the very first frame sent to the RPMB well-known LU
> >      comes back with a power-on UNIT ATTENTION (ASC 0x29), which the SCSI
> >      core reports rather than retries. RPMB has no earlier guaranteed
> >      access that could clear the condition first, so RPMB fails on every
> >      power cycle. Patch 1 asks the SCSI core to retry the power-on UNIT
> >      ATTENTION on the RPMB WLUN.
> > 
> >   2. The UFS RPMB id 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
> >      eMMC CID ABI. Patch 2 hashes it into a fixed 16-byte dev_id with
> >      blake2s, keeping the key stable and unique per region while matching
> >      the eMMC CID layout OP-TEE relies on. The hash algorithm and input
> >      string are thus part of the key-derivation ABI and must stay stable.
> > 
> > With both patches, UFS RPMB is functional from the first access after a
> > cold boot and derives keys through the existing eMMC-style OP-TEE flow,
> > (requires minimal OP-TEE changes pending on the CID proposal done here).
> > 
> > Tested on IQ-9075 with Open Firmware [1], pending OP-TEE changes
> > [1]https://ldts.github.io/qcom-buildroot
> > 
> > Dependencies:
> > 
> > U-boot:
> > https://lore.kernel.org/u-boot/20260720085202.537019-1-jorge.ramirez@oss.qualcomm.com/T/#mc423eb4dcf8a15849077029e4f7c1913bb7d8873
> > 
> > OP-TEE:
> > https://github.com/OP-TEE/optee_os/pull/7881
> > 
> > v2:
> >   * ufs: rpmb: replace blake2s with blake2b so that the same support
> >     can be added to u-boot (CRYPTO_LIB_BLAKE2B)
> >   * added links to U-boot and OP-TEE changes.    
> > 
> > v1:
> >   * ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN:
> >      - fix using uses SCMD_FAILURE_ASC_ANY to retry any Unit Attention
> >      - fix unused variable
> >   * ufs: rpmb: use a fixed-length RPMB dev_id
> >      - fix selecting a non-existent Kconfig symbol
> > 
> > Jorge Ramirez-Ortiz (2):
> >   ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN
> >   ufs: rpmb: use a fixed-length RPMB dev_id
> > 
> >  drivers/ufs/core/ufs-rpmb.c | 39 ++++++++++++++++++++++++++++++++++---
> >  1 file changed, 36 insertions(+), 3 deletions(-)
> > 
>