Page 25

EETE JUN 2015

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 Fig. 3: Components of a Trusted Hypervisor. 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 Guestm. 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. Anchoring the Embedded System A trusted hypervisor is central to the overall s ecurity 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. 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. 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. 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-bystep 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 Fig. 4: Securing the hypervisor. www.electronics-eetimes.com Electronic Engineering Times Europe June 2015 25


EETE JUN 2015
To see the actual publication please follow the link above