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 thanks for the heads up though! Jorge > -- > Thanking You > Neha Malcom Francis >
