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