linux-kernel - RE: [PATCH RFC 0/3] mmc: sdhci-brcmstb: Add rpmb sharing support

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:
 <PH7PR16MB6196A1AB0472684F9A234C55E5FD2@PH7PR16MB6196.namprd16.prod.outlook.com>
Date: Tue, 11 Feb 2025 18:39:25 +0000
From: Avri Altman <Avri.Altman@...disk.com>
To: Florian Fainelli <florian.fainelli@...adcom.com>, Ulf Hansson
	<ulf.hansson@...aro.org>, Kamal Dasu <kamal.dasu@...adcom.com>, Jens
 Wiklander <jens.wiklander@...aro.org>
CC: "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "adrian.hunter@...el.com"
	<adrian.hunter@...el.com>, "linux-mmc@...r.kernel.org"
	<linux-mmc@...r.kernel.org>, "robh@...nel.org" <robh@...nel.org>,
	"krzk+dt@...nel.org" <krzk+dt@...nel.org>, "conor+dt@...nel.org"
	<conor+dt@...nel.org>, "wsa+renesas@...g-engineering.com"
	<wsa+renesas@...g-engineering.com>, "f.fainelli@...il.com"
	<f.fainelli@...il.com>, "bcm-kernel-feedback-list@...adcom.com"
	<bcm-kernel-feedback-list@...adcom.com>
Subject: RE: [PATCH RFC 0/3] mmc: sdhci-brcmstb: Add rpmb sharing support

> On 2/11/25 00:13, Avri Altman wrote:
> >>>> This patch set adds support for Broadcom TZOS to read and write to
> >>>> RPMB partition using synchronized access to the controller hardware.
> > Practically it establishes a communication channel between the trust zone and
> the host controller regardless of the rpmb protocol.
> > Or did I get it wrong?
> 
> Rather than communication channel, I would describe it as an arbitration scheme
> between N participants, with guaranteed forward progress and fairness between
> all participants.
> 
> The interest here is for one of those participants to own the eMMC controller for
> a certain amount of time and indicate when it is done with it. This is not specific
> to eMMC as this could scale to virtually any piece of HW that is driven by
> transactions from a CPU, but the main application is for allowing the Trusted OS to
> own the eMMC controller for a short period of time in order to do its RPMB
> access, and then give it back in the same state it found it to the next participant.
Then maybe edit the subject accordingly and enclose this excellent explanation in the cover letter.
 
Thanks,
Avri

> --
> Florian