On 2/10/25 05:21, Ulf Hansson wrote:
+ Jens
On Thu, 6 Feb 2025 at 23:09, Kamal Dasu <kamal.dasu@xxxxxxxxxxxx> 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.
--
Florian
