[v1] ufs: rpmb: make RPMB usable with OP-TEE key derivation

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

Posted by Jorge Ramirez-Ortiz 4 days, 16 hours 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
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

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

Posted by Bean Huo 4 days, 15 hours ago

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

Posted by Jorge Ramirez 4 days, 15 hours ago

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