Isolating Safety and Security Features on Today’s More Powerful SoCs

Are system consolidation cost savings still possible?

In recent months, we have seen a blurring of the lines between safety and security features on the more powerful and robust SoCs.

The overarching problem when it comes to both safety-critical software and software performing security functions is isolation. This means isolation between the software and hardware resources performing these functions, as well as other software and hardware in the same system that are not trusted or certified as “safe” or “secure.” In many systems, isolation is achieved by placing software performing safe or secure functions on a separate chip, which has been dedicated exclusively for this purpose. While this design paradigm is certainly suitable for many scenarios and definitely achieves strong isolation, it does contrast with the one goal that many companies have today as they update or redesign existing systems: achieving cost savings through system consolidation.

So in a design with two or three processors, with each processor responsible for implementing a different aspect of the system (HMI/connectivity, secure transactions, safety critical, etc.) consolidation efforts focus on moving to a single chip design where all of these functions reside together on a more capable processor (Figure 1). This consolidation reduces BOM costs, hardware design costs, and complexities, and can likely produce a more power-efficient system.

While this concept definitely looks and sounds straight-forward, the devil is in the details.

Figure 1: The move from a legacy design to a more consolidated architecture.

A Consolidation Example
Figure 1 shows consolidation with the Xilinx® UltraScale+™ MPSoC used as an example. The question here is, now that the HMI, the Bluetooth stack, and safety-critical software have been consolidated on the same chip, how do you ensure isolation? For instance, how do you prevent a problem with Qt® running within Linux® from crashing the infusion pump software, running on an RTOS, that could result in serious repercussions for a patient.

The Xilinx UltraScale+ MPSoC is an example of an SoC that offers numerous different hardware mechanisms enabling strong isolation of subsystems. Different pieces of software (secure/unsecure, safe/unsafe) and associated hardware can be separated from each other using hardware enforcement.

The main components within the MPSoC used for isolation include:

  • Arm® TrustZone® Supports isolating secure software and hardware from non-secure software and hardware
  • Virtualization Provides virtualization capabilities and isolation between multiple operating systems (virtual machines) running on the Arm® Cortex®-A53 cores
  • System MMU Adds support to isolate any DMA-capable device other than the CPUs in both virtualized and non-virtualized environments on the Arm Cortex-A53 cores
  • Xilinx Memory Protection Unit (XMPU) Adds more capabilities to isolate different memories to be accessible from various subsystems or types of software (i.e. secure vs. non-secure, etc.)
  • Xilinx Peripheral Protection Unit (XPPU) Adds more capabilities to isolate different peripherals to be accessible from various subsystems or types of software (i.e. secure vs. non-secure, etc.)

Continuing with our Xilinx UltraScale+ MPSoC example, let’s examine the SoC’s major components that are part of the Processing System (PS). Figure 2 shows the major components and a brief description of what each component does or can do within the overall system.

Five separate hardware capabilities (Figure 1) can be configured in countless ways to isolate various aspects of the components Figure 2 describes.

Figure 2: The many components of the Xilinx UltraScale+ MPSoC Processing System

Boot and Configuration Process
The boot and configuration process merits attention because our example SoC, the Xilinx UltraScale+ MPSoC, is highly configurable in respect to how the chip boots and how the system components can be partitioned into subsystems as part of the boot process.

To begin, the Platform Management Unit (PMU) starts the boot process and, after performing some basic power services (initializing system monitors, validation of PLL locks, etc.), it releases the Configuration Security Unit (CSU) from reset. At this point, the CSU loads a First-Stage Boot Loader (FSBL) from a location dictated by the boot-mode selected via boot-mode pin strapping at reset. The CSU can also load PMU firmware code, though this is optional.

Figure 3: The boot process and role of the various components in the system is shown over time. In the configuration displayed, the majority of the boot logic is executing on an Arm Cortex-A53 core, though this could be easily be configured to take place on an Arm Cortex-R5 instead.

The processing unit that runs the FSBL is configurable, so this software can run on either the Arm® Cortex®-R5 (i.e., RPU) or the Arm Cortex-A53 (i.e., APU). Additionally, the FSBL can also set up isolation of the overall system into subsystems that are designated via the Xilinx Vivado tool, which generates code used by the FSBL to perform this operation.

Lastly, the entire boot flow can be made “secure” which guarantees an immutable chain of trust, meaning that all software in the system can be signed and validated to whatever degree is deemed necessary. Figure 3 depicts information on the overall boot flow on the Xilinx UltraScale+ MPSoC, showing one possible configuration of how the boot flow could look on this chip.

The key areas related to isolation on the Xilinx UltraScale+ MPSoC have been discussed. As previously stated, this SoC has several different mechanisms to support isolation of subsystems.

“Isolating Safety and Security Features on the Xilinx Ultrascale MPSoC.” This white paper presents a use case on mixed safety-criticality on APU and RPU and a use case on mixed levels of security on APUs and a RPU.

Demonstration: Mentor will also feature a demo on the Xilinx UltraScale+ MPSoC at Arm TechCon 2017 (Mentor booth #606). To learn more, visit

Dan Driscoll is a Software Architect in the Mentor’s Embedded Systems Division overseeing Arm virtualization, Nucleus RTOS, and multicore/multi-OS technologies and associated development tools. Driscoll has been in the embedded field for over 18 years working from low-level device driver development to software architecture and the design of complex systems. Driscoll holds a Bachelor’s degree in Computer Science from the United States Military Academy at West Point.

The registered trademark Linux® is used pursuant to a sublicense from LMI, the exclusive licensee of Linus Torvalds, owner of the mark on a world-wide basis.
Arm is a registered trademark of Arm Limited (or its subsidiaries).

QT is a registered trademark of the Qt Company Oy.

Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.