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