summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorMartin K. Petersen (Oracle) <mkp@kernel.org>2026-09-09 21:54:19 -0400
committerMartin K. Petersen (Oracle) <mkp@kernel.org>2026-09-09 21:54:19 -0400
commit06cc447b65beacb6912b675675de49abe24dc02f (patch)
tree961eff2b4cb7eed7b3c459f3f990321c9cf008e7 /tools/perf/scripts/python
parent6b0f8a689ef3e84a9b2fc1a5753466dfbd566306 (diff)
parent657eff806d38abd73e0002cda070c4cf14eb9882 (diff)
downloadlinux-next-06cc447b65beacb6912b675675de49abe24dc02f.tar.gz
linux-next-06cc447b65beacb6912b675675de49abe24dc02f.zip
Merge patch series "ufs: rpmb: make RPMB usable with OP-TEE key derivation"
Jorge Ramirez-Ortiz <jorge.ramirez@oss.qualcomm.com> says: 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 Link: https://patch.msgid.link/20260831154804.719528-1-jorge.ramirez@oss.qualcomm.com Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions