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

From: Bean Huo

Date: Mon Jul 20 2026 - 06:32:56 EST



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@xxxxxxxxxxxxxxxx/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(-)
>