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 for Android: free password hash cracker in your pocket

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

Message-ID:
 <PH7PR16MB61967C18645C64E582B222B6E5FD2@PH7PR16MB6196.namprd16.prod.outlook.com>
Date: Tue, 11 Feb 2025 08:13:47 +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

> >> 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?

Thanks,
Avri

> >> To achieve this Linux OS and the secure TZOS make use of:
> >> - shared hardware semaphore register
> >> - a set of SDIO shared work registers and
> >> - IPI interrupt registers
> >> The sdio shared work registers indicates next in queue to access the
> >> controller and current agent in the queue. The currently running OS
> >> that needs access to the controller puts itself in its slot of work
> >> register and if its next in line it can try to grab the hardware semaphore and
> complete its mmc requests.
> >> Next agent queue state is changed under the hardware semaphore lock
> >> before it release it by looking at work slot register. send and
> >> receive IPI interrupts between linux and secure world are used to
> >> indicatecompletion of transaction to the waiting OS. TZOS has its own
> >> RPMB driver which accesses partition when it wants to read/write RPMB
> >> frames. Current implementation assumes Linux and TZOS as the two work
> agents.
> >
> > We recently added an in-kernel interface/subsystem for RPMB
> > (drivers/misc/rpmb-core.c). The optee driver (drivers/tee/*) uses it
> > ro read/write frames and route them for the secure OS.
> >
> > When the mmc subsystem probes the eMMC card, it registers it as an
> > RPMB device via the new RPMB subsystem. In this way, it allows
> > consumers (as the optee driver) to read/write to/from it.
> 
> Yes we are quite familiar with this subsystem and the many iterations that
> were proposed before it eventually landed upstream. At the time the
> hardware was designed, we were not sure of the direction that the generic
> RPMB subsystem would take so we decided to add the semaphore, scratch
> registers and interrupt generation capability so we would not be dependent
> upon such a subsystem. We also had other factors playing into designing it the
> way it is, such as allowing for N participants, including another
> processor/firmware.
> 
> >
> >>
> >> Change required adding two core mmc_host_ops request_start() and
> >> request_done() to let the host controller driver know when a mmc
> >> request starts and ends so that the access can be synchronized. This
> >> has been tested with both the sdhci and cqhci access. Currently these
> >> ops are implemented by the sdhci-brcmstb controller dirver to acquire
> >> and release the hardware semaphore before and after access. This
> >> change to the mmc/core driver does not have any impact to existing
> controller drivers.
> >
> > It seems to me that this isn't needed at all, assuming we have an
> > in-kernel tee driver that can route the RPMB frames, but maybe I don't
> > fully understand the use case.
> 
> The proposed scheme here scales to an arbitrary number of agents in the
> system. Our immediate use case is for both Linux and a Trusted OS (not OP-
> TEE based BTW) to share the eMMC controller, but we also accounted for a
> third agent which is a power management micro controller firmware to be able
> to participate in the scheme and occasionally make its own eMMC operations.
> --
> Florian