On 23.07.26 16:38, Jorge Ramirez-Ortiz via U-Boot wrote: > OP-TEE secure storage (CFG_RPMB_FS) relies on an RPMB partition, but > U-Boot's OP-TEE RPMB supplicant only speaks the legacy single-command > interface, which is bound to eMMC. SoCs that are UFS-only and have no > eMMC (for example the Qualcomm SA8775P) therefore cannot back OP-TEE > secure storage from U-Boot today. This series adds that support. > > It introduces the transport-agnostic OP-TEE RPMB "subsystem" interface > (PROBE_RESET / PROBE_NEXT / FRAMES), where the normal world enumerates > the RPMB device and reports its kind, size and CID, then carries the > signed frames. The legacy eMMC supplicant is preserved unchanged, only > renamed to rpmb_emmc.c, with the new UFS backend added as a separate > rpmb_ufs.c; the two are mutually exclusive via Kconfig (SUPPORT_UFS_RPMB > depends on !SUPPORT_EMMC_RPMB) because the OP-TEE supplicant handles a > single RPMB transport. The subsystem interface is UFS-only for now; eMMC > can be migrated onto it later as the legacy path is retired. >
Just stumbled over this. Not sure if you saw [1] already. Our series collide, and while yours lacks RPMB TA enumeration (to enable fTPM e.g.), mine is based on the the in-tree emmc-only core. How to resolve that best? Establish a common optee/rpmb.c for now so that the service enumeration can be shared by both? > On top of that it adds a UFS RPMB transport that moves JEDEC RPMB frames > to and from the RPMB Well-Known LUN using SCSI SECURITY PROTOCOL IN/OUT. > The per-region 16-byte CID is derived by BLAKE2b-hashing the exact > device-id string the Linux kernel builds (ufshcd_create_device_id() > plus a "-R<region>" suffix), so OP-TEE derives an RPMB key that matches > the one Linux would use. > > The first patch is a standalone UFS descriptor fix the RPMB path depends > on (UTF-16BE string decoding); the transport patches also include a > power-on UNIT ATTENTION retry and a DMA-alignment bounce for the RPMB > WLUN. > > Note: reading UFS descriptors reliably also requires the descriptor > data-segment cache-invalidation fix, which has already been posted and > merged separately, so this series is based on top of it. > > Tested on the Qualcomm IQ-9075-EVK (SA8775P): OP-TEE with CFG_RPMB_FS > programs the RPMB key through U-Boot and reads/writes secure-storage > objects, with the derived CID matching the Linux UFS device_id ABI. Looks like the QEMU model for UFS is still lacking RPMB support. Did you happen to have a look if the eMMC bits could be reused for that? We are doing most of the security stack integration tests via QEMU now, including OTP key deployments - you would need a lot of new hardware otherwise. Jan [1] https://lore.kernel.org/u-boot/[email protected]/ -- Siemens AG, Foundational Technologies Linux Expert Center
