BELK-TN-001: Real-timeness, system integrity and TrustZone® technology on AMP configuration

Info Box Applies to Bora Applies to BORA Xpress

History

Version	Date	BELK version	Notes
0.9.0	September 2015	3.0.0	Internal draft

Introduction

Because of widely available Internet connectivity, nowadays security concerns are not longer limited to PCs, servers and workstations but have become common to many embedded systems as well. To deal with this kind of challenges, several hardware and software technologies have been developed. ARM® TrustZone® technology is one of these. As stated in , Xilinx Zynq-7000 AP SoC natively supports TrustZone® technology, since it integrates dual-core ARM® Cortex™-A9 MPCore™ processor.

Even if this technology has been conceived primarily to address security issues, embedded systems designers can leverage it to implement innovative configurations, satisfying different in nature requirements that typically arise in industrial applications and deep embedded systems. Two of such requirements are real-timeness and system integrity.

This White Paper describes the TrustZone-based solution that DAVE Embedded Systems has implemented to meet all these requirements on BORA and BORAX platforms. A technical description of the adopted approach is provided. Also, performance and characterization tests are detailed and considerations about future developments and improvements are included.

This solution can be considered as a sort of natural evolution on the traditional AMP configuration described in . For this reason, reading of this document is highly recommended.

Limitations of traditional configurations

Xilinx Zynq AP architecture provides unprecedented possibilities in terms of integration. In industrial world applications, this is often leveraged to combine on a single chip the implementation of real-time tasks with generic software applications and functionalities that don't have specific requirements in terms of real-timeness. In addition, the flexibility offered by the FPGA - known as Programmable Logic or PL for short - allows system designers to implement in hardware custom IPs to add new interfaces and peripherals or to move processing modules from the software to the hardware world.

The following list recaps the typical requirements that such systems must meet. This list has been compiled on the base of real world use cases (specifically medical, transportation, automation and telecom applications):

• real-time and non real-time tasks integration: on the same physical component it is required that non real-time and real-time world coexist; this allows overall design simplification, BOM reduction and better integration
• the non real-time world - denoted as W2 in the rest of the document - is based on a well-known operating system such as linux
• the real-time world - denoted as W1 in the rest of the document - is based on a RTOS or a bare metal executable
• inter-world communication and data sharing: the two worlds must have the capability to:
  1. communicate via asynchronous mechanisms
  2. share data
• integrity: W1 must guarantee a high reliability level, no matter how the other world behaves; in other words, W1 can not be altered by any kind of actions taken by the code executed in W2. W1 is also known as Secure world or Trust world. W2 is also called Non-secure world" or Non-trust world.

The traditional AMP configuration satisfies all of these requirements except the last one. For example an application with root privileges or code executed in kernel space can access memory regions that are supposed to be exclusively accessed by code executed in W1. This may lead to unpredictable behaviors and potentially to catastrophic consequences. This is where TrustZone technology comes to help: it creates a sort of barrier between the two worlds and prevents W2 code from unauthorized accesses to certain regions of the processor's addressing space.

TBD aggiungere analisi delle soluzioni micro grosso+microcontrollore e di quelle big.little ?

TrustZone-based approach

Overview

The major difference with respect to the traditional AMP configuration is the use of a software monitor, specifically TOPPERS SafeG .

Nagoya University TOPPERS SafeG architecture

As shown in the picture, the monitor can be viewed as a software layer that lies between W1/W2 and underlying hardware. The monitor is responsible for:

• enabling and initializing TrustZone in order to protect memory regions that must not be accessible by Non-secure world
• TBD

About operating systems, linux has been chosen for Non-trust world, while FreeRTOS has been selected for the Trust world.

About the multi-processing scheme, AMP has been used.

These choices lead to the configuration depicted in the following picture.

DAVE Embedded Systems' TrustZone-enabled AMP solution

Inter-world communication

dualoscomm

perché abbiamo scelto RPMsg

System memory partitioning

System memory partitioning is shown by the following picture.

caption

Boot process

The boot process is composed by several stages that are detailed by the following list.

1. The first piece of code executed by the processor is BootROM. Depending on bootstrap configuration pins, FSBL image is retrieved from a specific non-volatile memory by BootROM and stored into on-chip memory (OCM).
2. FSBL performs basic hardware initializations (including SDRAM subsystem) and retrieves U-Boot bootloader image
3. U-Boot
   • completes hardware initializations
   • retrieves the following binary images and store them into SDRAM:
     • monitor
     • trusted code (FreeRTOS image in our case)
     • non-trusted code (linux kernel image and Device Tree Blob in our case).
   • gives monitor the control.
4. monitor initializes TrustZone subsystem and gives trusted code the control of the machine.
5. FreeRTOS kernel is initialized and real-time tasks are started. Under the control of the tasks running on top of the RTOS kernel, the non-trusted (NT for short) code is started. Please note that this is done via a Secure Monitor Call (referred as SMC in the rest of the document) that is handled by the monitor.

L2 cache management

TBD

Characterization and performance tests

TBD

Isolation vs performances

TBD

Conclusions

TBD

---