Preface
Note: The security architecture discussed in this document is subject to change, based on ongoing work in RISC-V Technical Committees. Akeana IP will offer a unified security platform, consistent with the eventual ratified RISC-V standard(s) in this area.
Compute applications have evolved over time – security is no longer a requirement only for banking applications and large datacenters. Now, even the tiniest microcontrollers may collect sensitive data and/or be networked with other computing equipment that stores sensitive data. When that is combined with the increasingly-sophisticated nature of attacks, nearly every processor needs to be able to enforce appropriate forms of security.
One means of preventing unauthorized access to data (or unauthorized tampering with other compute activity) is to isolate data belonging to different compute functions, separated it into silos generically referred to as security domains.
Akeana processors offer a robust and flexible feature called “Secure Worlds”, which supports multiple simultaneous security domains.
1 TrustZone, Akeana NS Bit + Secure Worlds
Various vendors offer forms of hardware-enforced security domains, to provide robust isolation for sensitive data. Arm offers a feature called “TrustZone”, which provides one form of basic security. Akeana offers a similar solution, augmented by a “Secure Worlds” enhancement.
1.1 Arm’s TrustZone
The idea behind TrustZone is simple: split physical addresses into two regions, Secure and Non-Secure, referred to as the “Secure World” and the “Non-Secure World”.
All “classical” software executes within the Non-Secure world and its accesses are limited to memory and I/O accesses within the Non-Secure world. Non-Secure code cannot access Secure memory or I/O regions.
The most sensitive data are placed in Secure memory, which is only directly accessible by software operating in the Secure world. In theory, Secure-mode software remains small, is limited to a handful of infrequent entry points, and is less vulnerable to attacks.
The Secure World status is transmitted outside the processor to the rest of the SoC via the “NS” bit on the busses (NS =1 = “Non-Secure world”; NS = 0 = “Secure world”).
1.2 Akeana Secure Worlds
Akeana extends the concept of two security domains (“worlds”, Non-Secure and Secure) into Non-Secure worlds plus many independent Secure Worlds. The NS bit is retained to indicate Secure vs. Non-Secure, but many Secure (and Non-Secure worlds) are available. The various Worlds are differentiated by individual World ID (WID) values. The memory system is tagged throughout with the NS bit (and, if used, WID values) – including cache lines, MMU entries, and PMP entries.
Note that since the NS bit (with optional WorldID value) is a generalization of the single NS bit in Arm TrustZone processors, porting software originally written for TrustZone to an Akeana processor is straightforward.
Figure 2 illustrates a software view of Secure Worlds, when a Hypervisor is in use. Supervisor (OS) software calls into the Supervisor Execution Environment (SEE) using the standard RISC-V Supervisor Binary Interface (SBI). The SEE can be provided either by an HS-mode Hypervisor (as illustrated) or, when no Hypervisor is present, directly by M-mode runtime firmware.
Figure 2. Software view of NS/WorldID Support
Figure 3 provides a hardware conceptual view of the support provided by Akeana processors, for running high-security Trusted Execution Environment (TEE) software. Software is divided up into security domains (“worlds”), the isolation between which is enforced by hardware. That hardware includes an “NS” bit (NS=1 for a Non-Secure World, NS=0 for a Secure World) and, for each World within the Secure or Non-Secure domains, a unique World ID (WID) value.
Figure 3. Hardware view of NS/WorldID Support
Each memory (or device) access request flowing through the system is tagged with the NS bit (“request NS”) and WID (“request WID”) from which the request originated. Data to be accessed (“target data”) is generally tagged with an NS/S bit and World ID(s) identifying which World(s) may access the data.
The notion of using NS and WorldIDs to guard access to data applies equally to all addresses in the address space, including addresses of memory-mapped device registers. Secure Worlds provide an additional layer of protection for managing Root of Trust hardware elements that is not available with PMP or with PMP plus an MMU.
Note that in the simplest case, address ranges within an SoC can be statically assigned to Secure and Non-Secure Worlds. In a more flexible configuration, address Secure World assignments can be dynamically assigned (and changed). For data assigned to a Secure World, finer-grained access protections within that Secure World can be provided by an MMU.
While a Hypervisor provides additional security through its use of a second level of MMU translation, implementation (or use) of a Hypervisor is not a strict requirement for implementing a secure multi-core platform based on Akeana Y/Z/T-Line processors.
The choice of whether to implement a Hypervisor is left to the customer and is largely dependent on the applications running on the platform. If the applications are generally “fixed function”, then a simpler configuration relying on PMP and/or MMU protections without a hypervisor would suffice. General application processing would, on the other hand, favor a Hypervisor for enhanced protection/isolation.
The choice of whether to implement WorldIDs (in addition to the NS bit) is likewise optional; the extent of the benefit of support for multiple Secure Worlds is application-dependent.
