KS2012: ARM: Secure monitor API

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 things 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 tree for 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.