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] [thread-next>] [day] [month] [year] [list]

Message-ID: <d51a9d7a-b942-4c3b-93d2-65b1bb04c8da@broadcom.com>
Date: Tue, 11 Feb 2025 09:01:49 -0800
From: Florian Fainelli <florian.fainelli@...adcom.com>
To: Avri Altman <Avri.Altman@...disk.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.
-- 
Florian