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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <5f12fdaaa49aad21403a0a9b96d2b8b3a6d3ca1e.camel@gmail.com>
Date: Wed, 08 Oct 2025 13:47:00 +0200
From: Bean Huo <huobean@...il.com>
To: Avri Altman <Avri.Altman@...disk.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?


how do you think?

Kind regards,
Bean