Explore Imagination Technologies IP here
Connected products such as many Internet of Things (IoT) devices, gateway routers, IPTVs, mobile devices and automotive systems must increasingly be designed to support numerous unique applications, various content sources, and in-the-field software updates from service providers and operators, all while ensuring privacy and data protection. As multiple applications and associated data co-exist on the same SoC, each must be kept secure from external attacks and also from each other.
For example, in automotive, communications are becoming tightly coupled with smartphones, bringing third party services into the automotive infrastructure. And in supporting emerging applications such as self-parking and autonomous driving, it is critical to ensure ultra-safe operation to meet ADAS requirements.
Static-based approaches for embedded system security which define secure and non-secure zones by partitioning separate hardware subsystems for each zone have been generally effective to-date. But today's approaches are generally CPU-centric, binary - with one secure zone / one non-secure zone - and are complicated to implement. These solutions won't scale to address the sophisticated types of applications and services being enabled by next-generation connected devices and the cloud. As a result, more scalable and cost-effective approaches are required to address the needs of newer devices running multiple applications over several secure environments/domains.
Hardware virtualization as a foundation for embedded security
Hardware virtualization can create the requisite scalable trusted environments for secure embedded systems. Virtualization is a technique for creating multiple isolated environments to house multiple guest operating systems and/or applications over a common shared hardware resource such as a CPU subsystem. This technology is already widely used in datacenter and server systems, and can provide a cost- and power-efficient foundation for implementing security in a wider range of devices including embedded systems.
With hardware virtualization support in the CPU, GPU and other processors in an SoC, companies can create multiple isolated domains, where each application can be protected from the others. Figure 1b shows Imagination's OmniShield hardware-assisted virtualization technology that supports a multi-domain system.
Figure 1- Hardware-assisted virtualization allows effective separation of Guests from the Root
Introducing the hypervisor
For an embedded application, the hypervisor is a small body of privileged code that sits above the hardware and manages the SoC resources by defining access policies for each execution domain referred to as Virtual Machines (VMs) or Guests. With Imagination’s OmniShield-enabled CPUs and GPUs, as many as 255 VMs can scale from a single core to multiple cores within a cluster or multiple clusters.
There is keen interest from companies in a broad range of vertical segments in the concept of using hardware-assisted virtualization to provide multiple independent domains that are isolated from one another for security, reliability, and ease-of development and deployment purposes. But the question remains as how to design embedded security through the use of hypervisors and how hypervisors can be securely anchored to hardware and trusted.
Hardware-supported hypervisor
In a typical embedded system, a translation lookaside buffer (TLB) is used by memory management hardware in a hierarchical fashion to improve virtual address translation speed. In systems leveraging hardware-assisted virtualization, a two-level hierarchy TLB enables isolation while maintaining comparable performance. The hierarchy consists of two layers: 1) Guest TLB; and 2) Root TLB. Each VM/Guest operates in a traditional user mode (Figure 1a) where the Guest TLB (G.TLB) is configured in the same way as a traditional TLB. In this way, little or no modification is required to be made to the Guest Kernel. The hypervisor in privileged mode is in control of the Root TLB (R.TLB), redirecting the Guest access to the correct physical address. In this way, the hypervisor is policing all CPU bus transactions per pre-established access policies, assuring each Guest operates within the boundaries established by the hypervisor. In other words, the Root TLB, as part of the hierarchy of memory management units (Root MMU), under the control of the hypervisor, is used to enforce isolation policies among the Guests. Subsequently, the Guest MMU is fully managed by the Guest OS to isolate guest applications/users.
Securing the hypervisor
The isolation between the Guest application and the privileged Root Kernel is the first step in securing the hypervisor; however, it is also important to assure that the Root-Kernel's "attack surface area" is minimized and all Root-Kernel front and back door entries are restricted and under tight supervision of the hypervisor. As a result, for an embedded platform, a smaller footprint hypervisor would be preferred. Today, there are many proven third party small footprint hypervisor offerings available for embedded applications.
Figure 2 shows how the R.TLB prevents illegal access from the neighboring Guest. First, the R.TLB is configured to fully isolated DDR memory regions for each Guest-n and Guest-m. The Guest-n Write Request (WR-req) to the Guest-n DDR memory region is allowed to execute; while the Guest-m Read Request (RD-req) from Guest-n DDR memory is blocked by the R.TLB; an exception can be generated to the hypervisor in order to take appropriate actions.
Figure 2- enforcing isolation in a virtual environment
Anchoring the Embedded System
A trusted hypervisor is central to the overall security of the embedded platform. However, in order to enforce a trusted hypervisor, additional supporting IP is required as shown in Figure 3. Other elements such as secure NoC, secure GPU and others play a key role in creating a secure SoC.
Figure 3- Components of a Trusted Hypervisor
As shown in Figure 3, a trusted anchor is required in order to secure an embedded platform - in this case, the Root of Trust (RoT) acts as the anchor. The RoT intends to enforce the following and more:
- Authenticate the origin and the integrity of the hypervisor images before execution
- Boot the system into a secure hypervisor state and ensure that it runs only trusted code; subsequently establishing the hypervisor as the chain of trust
Security through the use of a hypervisor
Figure 4 shows how an embedded system that requires multiple isolated and secure environments can be established.
Figure 4 - Securing the hypervisor
The hypervisor, as well as any shared drivers and libraries, are isolated and protected from the Guest Kernels and associated userlands. Subsequently, each Guest is isolated and protected from the neighboring Guests. As explained earlier, the enforcement is done through MMU / TLB hierarchy (Guest and Root TLB). In addition, the RoT anchored by the Trusted Element as show in Figure 4, resides in the same or higher privilege level as the hypervisor that enforces the chain of trust.
Trusting your hypervisor: secure boot sequence
The steps outlined in Figure 5 demonstrate at a high level how to boot a hypervisor into a trusted or secure state, followed by establishing several isolated VMs/Guests into multiple secure environments.
Figure 5 -Booting the system into a secure hypervisor state
In this way, the hypervisor is loaded under the control of the Trusted Element and is anchored to the SoC RoT. The hypervisor loads and authenticates associated software for each VM/Guest leveraging the same secure boot procedure. Following is an example step-by-step secure boot process:
- Root-kernel mode executing
- 1st boot loader is located at reset exception vector – this is what is executed first and would be executing from ROM or OTP-ROM
- The 1st boot loader loads the secondary boot loader into on-chip RAM (OCM)
- The 1st boot loader authenticates the secondary boot loader
- Control is now passed to 2nd boot loader which is now residing in the OCM
- The 2nd boot loader loads the hypervisor package into RAM designated for hypervisor
- The 2nd boot loader authenticates the hypervisor image with the Trusted Element
- Control is passed to hypervisor as the chain of trust which is now running in the isolated area of DRAM
- The hypervisor sets up the Root TLB provisioning up to several VMs/Guests
- The hypervisor loads Linux-0 image into DRAM designated for VM0
- The hypervisor authenticates Linux-0 image with the Trusted Element
- Repeat steps (a) & (b) for VM1/Linux-1
- Repeat steps (a) & (b) for VM2/Linux-2
- Repeat steps (a) & (b) for VM3/Linux-3
- The hypervisor proceeds to run VM/Guest context switching (CS) according to the established policies
Conclusion
There are many approaches to securing embedded platforms today. By definition, an embedded platform generally contains proprietary software developed by an OEM based on the set of reference designs and development kits provided by the SoC manufacturer. As a result, in general, most implemented security techniques have been proprietary. As embedded platforms open up to new third party software, there is a critical need to isolate and protect proprietary software while provisioning for new software capabilities. OEMs are forced to find new ways to address these challenges while maintaining equivalent cost, power and performance compared to existing solutions.
Next-generation approaches must go beyond binary approaches to create multiple secure domains, where each secure/non-secure application/operating system can operate independently in its own separate environment. In addition, these platforms must address the scalability that heterogeneous architectures require by protecting all of the processors in an SoC - including the CPU, GPU and others. In a heterogeneous architecture, application data and resources will be shared between the CPU and other processors in the system, so those processors will now face the same level of exposure as the CPU, and must be given the same level of protection.
Hardware-assisted virtualization provides an ideal and proven foundation for hardware enablement and extensions needed for next-generation embedded security.
A hardware virtualization-based security approach like Imagination's OmniShield ensures that applications which need to be secured are effectively and reliably isolated from each other, as well as protected from non-secure applications, while still meeting required levels of functionality, performance, cost, and power consumption.
Combined with trusted hypervisors for OmniShield and other OmniShield-ready IP, companies can implement a truly secure, heterogeneous multi-domain application environment using hardware-enforced separation and protection throughout the SoC.
