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] [day] [month] [year] [list]
Message-ID:
 <PH7PR16MB6196D9CB65C664259C166D65E51FA@PH7PR16MB6196.namprd16.prod.outlook.com>
Date: Thu, 25 Sep 2025 15:45:28 +0000
From: Avri Altman <Avri.Altman@...disk.com>
To: Bean Huo <beanhuo@...pp.de>, "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 v1 1/3] rpmb: move rpmb_frame struct and constants to
 common header

> On Wed, 2025-09-24 at 06:12 +0000, Avri Altman wrote:
> > > From: Bean Huo <beanhuo@...ron.com>
> > >
> > > Move struct rpmb_frame and RPMB operation constants from MMC block
> > > driver to include/linux/rpmb.h for reuse across different RPMB
> > > implementations (UFS, NVMe, etc.).
> > UFS RPMB differs from mmc RPMB in several levels:
> >  - 9 vs. 5 operations
> >  - frame structure: extended 4k
> >  - rpmb unit descriptor
> > etc.
> > And as time goes on, this gap is likely to become larger, As mmc is
> > not very likely to introduce major changes.
> >
> > Thus, you might want to consider having an internal ufs header - will
> > simplify things in the future.
> >
> > Thanks,
> > Avri
> 
> 
> Avri,
> 
> thanks, I got your points.
> 
> In normal mode, UFS RPMB uses the same 512-byte frame format as eMMC
> RPMB, with the same fields (MAC, nonce, counter, address, etc.). That’s why it
> makes sense to keep a single definition of the frame struct in
> include/linux/rpmb.h, so both eMMC and UFS RPMB drivers can reuse it
> without duplication.
> 
> The major differences only exist in UFS RPMB advanced mode, correct?
> 
> For advanced mode, our plan is to introduce a UFS-specific header for the
> additional features (extended 4K frame, new opcodes, descriptors), so that
> UFS can evolve independently without breaking the shared interface.
> 
> let's firstly enable UFS RPMB in normal mode, since its OP-TEE application is
> avaiable in OP-TEE OS, the custoemr can use it simply. As discussed with Jens,
> we can move next step for advanced RPMB for UFS, is this ok for you?
Yes.  Sound good.

Thanks,
Avri

> 
> 
> Kind regards,
> Bean
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ