Demonstrating the different hardware mechanisms used for subsystem isolation in Xilinx MPSoC.
As I read my colleague Andrew Caples’ article on The Blurring of Safety and Security for Embedded Devices, I immediately started to think of the Xilinx UltraScale+ MPSoC – as I have engaged with numerous customers about using this chip for both safety and security purposes, and the requirements for both areas are definitely starting to blur.
I quickly realized a blog about the Xilinx MPSoC that outlines both its versatility and capabilities for isolating safety-critical and security-related software from “other” software running on the same chip would be time well spent.
It’s all about isolation
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.
Consolidating on the Xilinx UltraScale+ MPSoC
In looking at Figure 1, now that I have my HMI, Bluetooth stack, and safety-critical software consolidated on the same chip, how do I ensure isolation? How do I prevent, say, a problem with Qt running within Linux from crashing my infusion pump software running on an RTOS that could result in serious repercussions of a patient? To address the original intention of this blog, how can strong isolation be achieved with the Xilinx UltraScale+ MPSoC?
First off, the Xilinx UltraScale+ MPSoC offers a lot of different hardware mechanisms that can be used for strong isolation of subsystems. This means that different pieces of software (secure/unsecure, safe/ unsafe) and associated hardware can be separated from each other using hardware enforcement.
Below is a quick list of the main components within the MPSoC that are used for this purpose:
Before getting too much into how the capabilities listed above can be used, it’s important to understand the major components that are part of the Xilinx UltraScale+ MPSoC Processing System (PS). The diagram below (Figure 2) shows the major components that are discussed later in the blog and it also provides a brief description of what each component does or can do within the overall system.
Figure 2: The many components of the Xilinx UltraScale+ MPSoC Processing System.
Based on information in Figure 1 above, there are now five separate hardware capabilities that can be configured in countless ways to isolate various aspects of the components described in Figure 2.
MPSoC boot and configuration process
The last area of the Xilinx UltraScale+ MPSoC that merits attention is the boot and configuration process. The importance of this topic is due to the fact that this SoC 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.
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 – this just shows one possible configuration of the how the boot flow could look on this chip.
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.
Potential use cases
Now that the major areas related to isolation on the Xilinx UltraScale+ MPSoC have been discussed, I will briefly describe how they can be used together. As I said in the very beginning, this SoC has a lot of different mechanisms to support isolation of subsystems. To illustrate this even further, here are a few use cases that hopefully, with the other information in this blog, will help you extrapolate additional useful benefits of the MPSoC.
USE CASE #1 – Mixed safety-criticality on APU and RPU
For this use case, a mixed safety-criticality scenario is envisioned where a non-safety certified piece of software such as Mentor Embedded Linux is configured to run SMP across 4 x ARM Cortex-A53 cores while safety-certified software runs in lockstep on the 2 x ARM Cortex-R5 cores with Mentor’s Nucleus RTOS. A requirement to perform bi-directional communication exists between the safe and un-safe software and the un-safe software cannot influence or change the behavior of the safe software. To facilitate this communication and booting of both software entities, the Mentor Embedded Multicore Framework will be utilized.
The booting process will boot the FSBL on the ARM Cortex-R5 cores, which in turn, boots the safety-certified Nucleus RTOS and application. The Nucleus RTOS application sets up both the XMPU and XPPU so that peripherals and memory used by the ARM Cortex-R5 cores are isolated from the peripherals and memory used by the ARM Cortex-A53 cores. Some portion of shared memory will be configured as accessible by both the APU and RPU for communication purposes. After configuring these subsystems, the safety-certified application locks both configurations so they cannot be altered unless the device is reset.
Once the Nucleus RTOS safety-certified application is done configuring the subsystems, it loads and boots Mentor Embedded Linux on the primary ARM Cortex-A53 core using the Mentor Embedded Multicore Framework support. To further isolate the RPU subsystem, Nucleus can configure the ARM Cortex-R5 and peripherals/memory used by the ARM Cortex-R5 to be “secure” devices meaning they are only accessible from the secure world while the ARM Cortex-A53 and Mentor Embedded Linux run in the non-secure world.
Figure 4: Safety Critical Software and General Purpose Software on the Xilinx UltraScale+ MPSoC.
USE CASE #2 – Mixed levels of security on APUs and RPU
For the second use case, the device has various levels of security-related software running on the device and each piece of software has different capabilities based on its privilege in this system. To allow more than just two different levels of security, a hypervisor, such as Mentor’s embedded hypervisor, runs on the four ARM Cortex-A53 cores and hosts two different SMP Linux Virtual Machines (VMs) responsible for different aspects of the system. Additionally, a security monitor will run lockstep on the 2 x ARM Cortex-R5 cores and interface to secure IP logic in the FPGA fabric. Again, communication is required between the different software entities in the system. In this use case, communication is needed between each Linux instance and the security monitor, and also between each Linux VM.
The booting process will be somewhat similar to use case #1 except the FSBL will run on an ARM Cortex-A53 while setting up the XMPU and XPPU to isolate the APU and RPU and apportion memory and peripherals to each subsystem. The ARM Cortex-R5 subsystem can, again, be configured to be a secure world entity along with all of its peripherals and memory while the ARM Cortex-A53 software (hypervisor and Linux VMs) will run in the non-secure world.
After configuring both the XMPU and XPPU and locking the settings, the Nucleus RTOS-based security monitor will be loaded to the ARM Cortex-R5, which is immediately followed by loading the Mentor Embedded Hypervisor to the ARM Cortex-A53 primary core. The hypervisor sets up the two Linux VMs using the hardware virtualization capabilities in order to isolate memory and interrupts and also to program the system MMU to ensure DMA-capable devices used by each VM are well isolated.
The Mentor Embedded Linux VMs have a virtual networking interface provided by the Mentor Hypervisor to allow inter-guest communication and also have access to shared memory in order to support rpmsg (IPC) communication to the security monitor.
Figure 5: A high-level diagram showing what the second use case architecture might look like.
Hopefully, this discussion has given you a reasonable overview of the capabilities of the Xilinx UltraScale+ MPSoC as it relates to isolation necessary for designs requiring safety and security. There are many more use cases possible given the numerous hardware features found on this device.
Indeed, the lines between safety and security are definitely blurring like Andrew Caples mentioned in his article.
Thankfully, the Xilinx UltraScale+ MPSoC provides an abundance of support for both environments.
Please visit Mentor’s embedded software products page for additional information.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply