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

Jorge Ramirez-Ortiz posted 2 patches 3 weeks, 4 days ago
drivers/ufs/Kconfig         |  1 +
drivers/ufs/core/ufs-rpmb.c | 29 ++++++++++++++++++++++++++---
2 files changed, 27 insertions(+), 3 deletions(-)
[PATCH v5 0/2] ufs: rpmb: make RPMB usable with OP-TEE key derivation
Posted by Jorge Ramirez-Ortiz 3 weeks, 4 days ago
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
     blake2b, 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

v5:
  * added Reviewed-by tags from Bean Huo and Stanley Jhu; no code change.

v4:
  * ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN: open-code
    the power-on ASC 0x29 (with a naming comment) as the rest of the SCSI
    tree does, instead of a UFS_RPMB_ASC_POWER_ON define; add a
    UFS_RPMB_UA_RETRIES define for the retry count; reworded the commit
    message.
  * ufs: rpmb: use a fixed-length RPMB dev_id: reworded the commit
    message; no functional change.

v3:
  * ufs: rpmb: use a fixed-length RPMB dev_id: hash into a stack buffer
    instead of a kzalloc'd one; rpmb_dev_register() copies dev_id, so the
    heap allocation and its cleanup were unnecessary.

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/Kconfig         |  1 +
 drivers/ufs/core/ufs-rpmb.c | 29 ++++++++++++++++++++++++++---
 2 files changed, 27 insertions(+), 3 deletions(-)

-- 
2.54.0
Re: [PATCH v5 0/2] ufs: rpmb: make RPMB usable with OP-TEE key derivation
Posted by Martin K. Petersen (Oracle) 1 week, 2 days ago
On Mon, 31 Aug 2026 17:47:59 +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.
> 
> [...]

Applied to 7.4/scsi-queue, thanks!

[1/2] ufs: rpmb: retry power-on UNIT ATTENTION on the RPMB WLUN
      https://git.kernel.org/mkp/scsi/c/a8a34238e5e6
[2/2] ufs: rpmb: use a fixed-length RPMB dev_id
      https://git.kernel.org/mkp/scsi/c/657eff806d38

-- 
Martin K. Petersen
Re: [PATCH v5 0/2] ufs: rpmb: make RPMB usable with OP-TEE key derivation
Posted by Martin K. Petersen (Oracle) 2 weeks, 2 days ago
Jorge,

> 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.

Applied to 7.4/scsi-staging, thanks!

-- 
Martin K. Petersen