On 27.08.26 11:06, Jorge Ramirez wrote: > On 24/08/26 11:07:16, Jorge Ramirez wrote: >> On 24/08/26 07:47:33, Jan Kiszka wrote: >>> 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? >> >> um, not sure what happened but my previous reply seems to have gone to >> some black hole (some mutt issue, might resurface later) >> >> No I didnt notice - I wasnt really tracking thought, just hoping that my >> series would be merged anytime now (I posted v4 last week). >> But yes I agree, a shared rpmb.c for enumeration seems like the right >> way to go. >> >>> >>>> 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. >> >> I didn't look beyond confirming the support is still missing. I needed >> to do an end-to-end validation on real hardware before proposing the >> change anyway, and having done this kind of integration across several >> platforms — AMD, NXP, ST, now QC — I had a reasonable degree of >> confidence about how to derisk it...plus the thrill of bricking boards. >> >> But joke aside having the QEMU bits in place would be _really_ useful. >> >> if you want to merge your changes before mine I could rework my series >> on top. I am fine either way. > > I followed up on the kernel side (seems complete on the v4 I sent this > morning, ABI accepted, just a minor update on a definiton). > > I believe the plan now is just to merge the OP-TEE change as per the PR > thread discussion > > So unless your set is ready to be merged Jan, I'd like to go ahead with > my u-boot changes: this is really taking too much time from other > deliverables. >
If mine is ready depends on the PoV of the reviewers :) - I don't have own todos pending for it. But I also don't mind rebasing over your series once more if it gets in first. Jan -- Siemens AG, Foundational Technologies Linux Expert Center
