Security by separation is essential for embedded applications: Page 3 of 6

November 29, 2016 //By Majid Bemanian, director of segment marketing at Imagination Technologies Group plc
Security by separation is essential for embedded applications
Majid Bemanian of Imagination discusses security features in the context of IoT-style embedded applications and the use of virtualization within CPU cores.

Building trust in a virtual environment

Figure 3 demonstrates the four quadrants required for creating security by separation and establishment of a trusted environment.

Figure 3: the four quadrants needed to create security by separation and a trusted environment

The MIPS M5150 can be divided into four areas/quadrants based on two axes. This is in contrast to the traditional single axis operation of User and Kernel space. The User and Kernel spaces are grouped into Root and Guest context:

Guest-User: user land with lowest privileged state where rich applications are generally executed

Guest-Kernel: typical kernel space of a CPU where privileged OS level tasks are executed.  Examples are Linux; Input-output, interrupt handling and memory allocation.

Root-User: a single privileged state of the CPU that can executed protected applications

Root-Kernel: The highest privileged execution state of the CPU where privileged instructions execute.  Exceptions from violation can be handled in this state. Second level memory management is used to enforce protection of resources are also managed at this state. A trusted hypervisor can manage the operation of trusted applications and all other protected Guests.

Both Guest-User and Guest-Kernel can be replicated to create multiple isolated domains.

The Guest contexts are replicated into parallel domains or environments, each isolated by a hardware mechanism. In the case of the M5150, up to seven Guest contexts can be established bringing the total number of contexts to eight.

The Root context executes at a privileged state in the M5150; this allows privileged instructions, software routines, interrupts and exceptions to execute within this context, providing a mechanism for control, management and termination of Guest services as needed.  Accesses from any Guest to Root resources can be prohibited by hardware. However, the Root context may act as a proxy to provide indirect access to restricted or protected resources.

The Root context can maintain an isolated state; however, to establish and maintain trust, an RoT can be implemented to start the SoC after power-up into a known state.  The complexity of the RoT may vary from application to application and is a function of the attack and protection profile.

Next: Two cores for the price of one

Design category: 

Vous êtes certain ?

Si vous désactivez les cookies, vous ne pouvez plus naviguer sur le site.

Vous allez être rediriger vers Google.