Global Sources
EE Times-India
Stay in touch with EE Times India
EE Times-India > Embedded

Secure hypervisor for hardware virtualisation

Posted: 03 Jun 2015     Print Version  Bookmark and Share

Keywords:virtualisation  hypervisor  embedded  Internet of Things  CPU 

The hierarchy consists of two layers: 1) Guest TLB; and 2) Root TLB. Each VM/Guest operates in a traditional user mode (Image 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.

Hardware-assisted virtualisation

Hardware-assisted virtualisation allows effective separation of Guests from the Root.

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 minimised 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 neighbouring 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.

Enforcing isolation in a virtual environment

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 below. Other elements such as secure NoC, secure GPU and others play a key role in creating a secure SoC.

A trusted anchor is required in order to secure an embedded platform, in this case, the Root of Trust (RoT) acts as the anchor.

Components of a Trusted Hypervisor

Components of a Trusted Hypervisor

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

The image below shows how an embedded system that requires multiple isolated and secure environments can be established.

 First Page Previous Page 1 • 2 • 3 • 4 Next Page Last Page

Comment on "Secure hypervisor for hardware virtu..."
*  You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.


Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

Back to Top