| Message ID | 20250206220940.10553-1-kamal.dasu@broadcom.com |
|---|---|
| Headers | show |
| Series | mmc: sdhci-brcmstb: Add rpmb sharing support | expand |
+ Jens On Thu, 6 Feb 2025 at 23:09, Kamal Dasu <kamal.dasu@broadcom.com> wrote: > > This patch set adds support for Broadcom TZOS to read and write to RPMB > partition using synchronized access to the controller hardware. > 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. > > 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. I have looped in Jens Wiklander, allowing him to comment on this too. Kind regards Uffe > > Posting this path to get comments on the initial implementation. > > Todo : > - Provide hardware smeaphore using the harware spinlock driver framework > - Use IPI send receive interrupt controller driver > > Kamal Dasu (3): > mmc: add request_start() and request_done() mmc ops > dt-bindings: mmc: brcm,sdhci-brcmstb: Add sdio sharing support > mmc: sdhci-brcmstb: Add rpmb sharing support in host driver > > .../bindings/mmc/brcm,sdhci-brcmstb.yaml | 16 +- > drivers/mmc/core/core.c | 14 +- > drivers/mmc/host/sdhci-brcmstb.c | 275 +++++++++++++++++- > include/linux/mmc/host.h | 4 + > 4 files changed, 303 insertions(+), 6 deletions(-) > > -- > 2.17.1 > Kind regards Uffe
On 2/10/25 05:21, Ulf Hansson wrote: > + Jens > > On Thu, 6 Feb 2025 at 23:09, Kamal Dasu <kamal.dasu@broadcom.com> wrote: >> >> This patch set adds support for Broadcom TZOS to read and write to RPMB >> partition using synchronized access to the controller hardware. >> 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.
> >> 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
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.
> 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