Oversimplifying the Arm RD-1AE Secure Boot Process

You have likely heard that the Arm RD-1AE is the newest and most advanced high-performance reference design for automotive applications based on Arm Neoverse-V3AE cores. The RD-1AE is available on the Arm Virtual Hardware Platform powered by Corellium. You might have seen a few block diagrams of the system, such as the Reference Software Stack High-Level Diagram.

Get a Free Trial

As an automotive software application developer, you may have wondered why almost two-thirds of the image is dominated by the safety, security, and control blocks in yellow/orange, green, and blue instead of highlighting the application cores in red/orange on the left. You probably expected the block diagram to resemble the one in the Neoverse Compute Subsystem solution page, where control and security are represented as two small blocks.

This shift in representation goes beyond mere aesthetics or marketing; it reflects a fundamental change in how the industry views safety and security. Historically, security was an afterthought, typically added once a software image was built. However, this has evolved by integrating trusted platform modules and secure boot hardware to many systems. In most cases, system developers could ignore these new components, leaving their use to the security experts. With the RD-1AE, both security and functional safety are foundational concepts for the platform, which becomes evident when examining the boot process as detailed on the Arm Automotive Solutions site.

Understanding the Secure Boot Process for Arm Reference Design

The detailed nature of this boot flow diagram may obscure the high-level message, so I will oversimplify. When the Arm RD-1AE exits reset, the only core that is enabled is the Cortex-M55, marked as RSE or RSS with a green outline. This Runtime Security Engine is effectively the Root of Trust for the system.

While security experts might argue that the tamper-proof storage of the first-level boot loader is the true root of trust, for those focused on the application domain, that is a distinction without a difference. Regardless, the RSE securely runs several boot loaders until it starts the RSE Runtime, a software load verified by the boot loaders, which can run the cryptographic software necessary to prove the integrity of software for other parts of the system.

Once the RSE is stable, it validates the firmware for the SCP, or System Control Processor, which is a Cortex-M7 outlined in blue in the diagrams. The SCP is then responsible for initializing the various components of the Safety Island, consisting of several R82AE clusters in yellow/orange, and ultimately for validating the boot loader for the application cores. Thus, it is only after several other processors have been booted and the firmware validated that the Neoverse-V3AE application cores finally come out of reset.

Now you may be saying "How is that different from secure boot with TPM on a PC, and why should I care?" Architecturally, the main difference is the addition of the safety island, which you may well not care about. However, the security implementation is the key difference. In most PC applications, there is often a workaround to bypass the security and jump right to the boot loader, as the original PC architecture was defined without security and no one wants to break backward compatibility.

The RD-1AE, as a new system architecture, doesn't have to worry about breaking old code that doesn't exist. Moreover, you've likely started with Arm's next-gen software enablement or the commercial SDK from your preferred vendor, which already accounts for these factors. So, back to the question: "Why do I care?" You care because this boot code must run every boot, even if someone else wrote it. This is where Corellium Virtual Hardware with Arm native acceleration shines.

Our hypervisor-based technology allows RSE and SCP code to run at near-native speeds on Neoverse-based cores in the cloud, which are generally much faster than the actual hardware. This capability enables you to run real binaries with integrity checking enabled in your fully cloud-enabled CI/CD flow, without the worry that the kludge solution to work around secure boot will brick your development device at the end of the development cycle.

Ready to Take the Next Step with Corellium's Arm Virtual Hardware Platform?

While this blog didn't make you a security expert, you should now understand that RD-1AE has a robust security architecture. Additionally, you now know that Corellium not only understands this security architecture but also provides full support for running and testing your projects that use the architecture to build best in class solutions for your customers. 

If you're interested in leveraging Corellium's platform to accelerate your development and ensure robust security for your automotive software, set up a meeting with us today.