linux-kernel - RE: [PATCH v2 3/3] scsi: ufs: core: Add OP-TEE based RPMB driver for UFS devices

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <PH7PR16MB61966F897DF133E14AC693DAE5E1A@PH7PR16MB6196.namprd16.prod.outlook.com>
Date: Wed, 8 Oct 2025 12:16:24 +0000
From: Avri Altman <Avri.Altman@...disk.com>
To: Bean Huo <huobean@...il.com>, "avri.altman@....com" <avri.altman@....com>,
	"bvanassche@....org" <bvanassche@....org>, "alim.akhtar@...sung.com"
	<alim.akhtar@...sung.com>, "jejb@...ux.ibm.com" <jejb@...ux.ibm.com>,
	"martin.petersen@...cle.com" <martin.petersen@...cle.com>,
	"can.guo@....qualcomm.com" <can.guo@....qualcomm.com>,
	"ulf.hansson@...aro.org" <ulf.hansson@...aro.org>, "beanhuo@...ron.com"
	<beanhuo@...ron.com>, "jens.wiklander@...aro.org" <jens.wiklander@...aro.org>
CC: "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v2 3/3] scsi: ufs: core: Add OP-TEE based RPMB driver for
 UFS devices

> 
> On Wed, 2025-10-01 at 10:06 +0000, Avri Altman wrote:
> > > From: Bean Huo <beanhuo@...ron.com>
> > >
> > > This patch adds OP-TEE based RPMB support for UFS devices. This
> > > enables secure RPMB operations on UFS devices through OP-TEE,
> > > providing the same functionality available for eMMC devices and
> > > extending kernel-based secure storage support to UFS-based systems.
> > >
> > > Benefits of OP-TEE based RPMB implementation:
> > > - Eliminates dependency on userspace supplicant for RPMB access
> > > - Enables early boot secure storage access (e.g., fTPM, secure UEFI
> > > variables)
> > > - Provides kernel-level RPMB access as soon as UFS driver is
> > > initialized
> > > - Removes complex initramfs dependencies and boot ordering
> > > requirements
> > > - Ensures reliable and deterministic secure storage operations
> > > - Supports both built-in and modular fTPM configurations
> > >
> > > Co-developed-by: Can Guo <can.guo@....qualcomm.com>
> > > Signed-off-by: Can Guo <can.guo@....qualcomm.com>
> > > Signed-off-by: Bean Huo <beanhuo@...ron.com>
> > Reviewed-by: Avri Altman <avri.altman@...disk.com>
> >
> > Nit: Would it make sense to simplify things, e.g. :
> > Instead of struct list_head rpmbs;
> > Use:
> > struct ufs_rpmb_dev *rpmbs[4];
> 
> 
> Hi Avri,
> 
> I am working on the next version, seems we should keep struct list_head
> rpmbs.
> 
> On the hot path, runtime RPMB I/O operations use dev_get_drvdata(dev) to
> get the device pointer directly, never searching through hba->rpmbs. Array's
> O(1) direct access advantage is therefore irrelevant. and the list is only
> accessed during probe/remove (one-time operations at boot/shutdown)
> where performance differences are negligible. The list iterates only over active
> regions without NULL checks, while an array requires checking all 4 slots.
> 
> List uses 16 bytes per active region, array uses 32 bytes (4 × 8-byte pointers)
> regardless of how many regions are active, most of UFS devices only enabled
> 1-2 RPMB regions, making the list more memory-efficient, right?
Yes.  The code looks good as it is.

Thanks,
Avri

> 
> 
> how do you think?
> 
> Kind regards,
> Bean
> 
>