On 08/09/26 09:43:14, [email protected] wrote: > On 9/7/26 10:40, Jorge Ramirez wrote: > > On 07/09/26 12:47:39, Neha Malcom Francis wrote: > > > Hi Jorge > > > > > > On 07/09/26 12:38, Jorge Ramirez wrote: > > > > On 27/08/26 11:01:41, Jorge Ramirez wrote: > > > > > On 21/08/26 16:02:18, Jorge Ramirez wrote: > > > > > > On 17/08/26 16:38:40, Jorge Ramirez wrote: > > > > > > > On 07/08/26 16:01:05, Jorge Ramirez-Ortiz 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. > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > Dependencies: > > > > > > > > Linux kernel: > > > > > > > > > > > > > > > > https://lore.kernel.org/linux-scsi/[email protected]/ > > > > > > > > Op-tee > > > > > > > > https://github.com/OP-TEE/optee_os/pull/7881 > > > > > > > > > > > > > > > > v4: > > > > > > > > - ufs: decode string descriptors: dropped the in-place > > > > > > > > ufshcd_str_desc_to_cpu() byte-swap helper; instead added an > > > > > > > > endian > > > > > > > > argument to utf16_to_utf8() (UTF16_HOST/LITTLE/BIG_ENDIAN) > > > > > > > > and decode > > > > > > > > with UTF16_BIG_ENDIAN, mirroring the kernel's > > > > > > > > utf16s_to_utf8s(). > > > > > > > > Existing EFI callers pass UTF16_HOST_ENDIAN. > > > > > > > > - ufs: RPMB transport: build the SECURITY PROTOCOL CDB with > > > > > > > > put_unaligned_be16()/put_unaligned_be32(); drop the > > > > > > > > rpmb_frame_request() helper in favour of > > > > > > > > get_unaligned_be16(); move > > > > > > > > ufs_rpmb_read_geometry() to the patch that first uses it so > > > > > > > > it is not > > > > > > > > an unused static function during git bisect. > > > > > > > > - ufs: per-region CID/size: reject an out-of-range > > > > > > > > device-reported > > > > > > > > logical block size before shifting and split the size > > > > > > > > computation into > > > > > > > > separate statements for readability; order <u-boot/...> > > > > > > > > after > > > > > > > > <linux/...>; note that the serial hex encoding matches the > > > > > > > > kernel > > > > > > > > device-id ABI. > > > > > > > > > > > > > > > > > > > > > > any further comments, is it ok to merge? > > > > > > > > > > > > > > > > > > > EOW reminder - this has been pending for a long while > > > > > > > > > > > > > > > anyone care to comment please? > > > > > > > > > > > > kernel changes accepted and op-tee changes merged. > > > > Just this one pending with no comments for nearly a month. > > > > > > > > maybe we can merge? > > > > > > > > thanks > > > > Jorge > > > > > > > > > > > > > > > > > > Looks like you're sending to the old mailing list instead of > > > [email protected] > > > > > > > hi Neah, > > > > ah interesting, maybe that explains it depending on people'w workflows: I > > see it hasnt landed on u-boot lore's. > > > > I just run get_maintainers.pl and the recommended list is > > > > jramirez@trex:u-boot (ufs-rpmb.v4 $) $ ./scripts/get_maintainer.pl > > drivers/tee/optee/Makefile > > Jens Wiklander <[email protected]> (maintainer:TEE) > > Ilias Apalodimas <[email protected]> > > (maintainer:TEE,commit_signer:2/3=67%) > > Tom Rini <[email protected]> (maintainer:THE > > REST,authored:1/3=33%,added_lines:1/3=33%,removed_lines:1/2=50%) > > Jorge Ramirez-Ortiz <[email protected]> > > (commit_signer:2/3=67%,authored:2/3=67%,added_lines:2/3=67%,removed_lines:1/2=50%) > > [email protected] (open list)... > > > > still I can see it on patchworks with Neil being the gatekeeper. > > > > I hope he can work from there without me having to resend > > I'd like some review on the optee side before picking the UFS changes, which > are fine. > > I'm worried about the clash with Jan's changeset on the optee side. > > Neil
adding the correct mailing list now > > > > > thanks for the heads up though! > > Jorge > > > > > > > -- > > > Thanking You > > > Neha Malcom Francis > > > >
