Will Deacon led the first KS2012 ARM minisummit session on creating a common API for the secure
monitor mode of ARM processors. This security feature—part of the
ARM TrustZone extensions—uses a secure
monitor call (SMC) instruction to switch between secure and non-secure
modes. It can be used to implement digital rights
management (DRM), secure payment, and more. The secure monitor also
provides services for booting and idling the processor. Currently, Linux
has no common API to access secure mode, so various ARM platforms implement
differently. The current situation is painful, Deacon said.
What's needed, Deacon suggested, is a common API that could be used by any
ARM system-on-a-chip (SoC) that needed it. Samsung has proposed an API
that handles the
boot and idle SMCs, which could be used as a starting point. But, handling
SMCs is still likely to require some amount of board-specific code.
For some ARM boards, there are SMCs that need to be done in the
early boot assembly code. There are various SoC errata that
need to be worked around via SMCs early in the boot process. It would be
preferable if calling the SMCs could be pushed into device drivers, but that
may not be possible for all processors.
There are also some services provided via SMC, like video and audio format
handling, which need to be accounted for. Those kinds of services could be
described in the device tree for the processor if there is some agreement
on how to create those descriptions. That would allow access to those
services via drivers using the common API.
Deacon suggested that there was no need to solve all of the problems "in
one go", and that focusing on the things that could be done from drivers
would be the place to start. There will still need to be platform-specific
code to handle set up that needs to be done before the MMU is enabled, as
well as to handle quirks of some of the platforms.
Another problem is that the actual calls into secure mode are not
standardized, and there are already multiple existing implementations. The
differences can be in the mapping from a number to the actual SMC it
corresponds with (somewhat akin to system call numbers). The parameters
can also be different. Those differences could be described in the device
the platform, and used by the common SMC framework. Actually invoking an
SMC would stay in the platform-specific code.
There is a recent recommendation from ARM to standardize the SMCs, but it is just
that: a recommendation. That document also describes how to use SMCs for
doing thermal and power management, so the common API could eventually
incorporate some or all of those kinds of calls, but they are
just recommendations that may or may not catch on.
By starting with what can be done in the C code from drivers, at least a
partial solution to the "complete mess" that exists today can be achieved.
Starting with the cpu_boot() and do_idle() hooks that the
Samsung API provides, then adding additional SMCs as needed, will start
cleaning up that mess.
to post comments)