2. Sierraware
Leading provider of integrated hypervisor and TEE
Delivered as source code. Flexible and easy to customize
Unified TEE and Hypervisor implementation.
Adheres to Global Platforms specifications
Products
– Residential gateways
– Set-top boxes,
– TVs
– Mobile phones
– Automotive and avionics
– Industrial control
3. Software Suite
SierraVisor:
– Hypervisor for ARM
– Para-Virtualizaiton, TrustZone Virtualization, HW Virtualization
– 64 bit Support for Cortex A5x cores
– Linux, uCOS and various RTOS
SierraTEE/Micro Kernel
– TrustZone/GlobalPlatform TEE
– Android, uCos and various other Oses
– Runs on various CPUs from ARM11, Cortex A9, A15 and Cortex A53/57
SierraSHIELD: Integrity Management
– Linux Kernel Integrity Management
– Application Rootkit Scanner
– Incremental Log Scanner
DRM and Content Protection :
– Hardware accelerated media streaming and DTCP toolkit
– Integration with Microsoft Playready
5. SierraVisor
Universal Hypervisor, with three different choices
Hardware Assisted Virtualization – A15 based
SOCs
TrustZone Monitor as VMM – TrustZone
supported Cortex-A9 and ARM11 based SOCs
Para-virtualization – A9 and ARM11 based
SOCs
6. Virtualization for Cortex A9, ARM11
• Cortex A9 and ARM11 are the most popular ARM
cores that are found in todays SOCs
• No support for virtualization
• Only two levels of privilege
• TrustZone provides a third level. Almost all ARM
Cores provide TrustZone support
• There are two distinct ways for virtualizing the CPU
• Hypercalls for sensitive instructions: Run both the Guest
kernel and Guest User in ARM Virtual User Mode
• TrustZone Monitor as VMM: Allows Guest run un-
modified in its native privileges
7. Hypercalls and Sensitive Instructions
• Co-processor Access Instructions
MRC/MCR/CDP/LDC/STC
• TrustZone
SMC
• I/O Regions
READs and WRITEs to I/O regions
• Operations on CSPR
MRS, MSR, CPS, SRS, RFE, LDM, DPSPC
• Indirect CSPR
LDRT, STRT
• Hypercalls are inserted at compilation time
• Very low overhead at run time.
• All the work of identifying the instructions
to be re-written will be done at
compilation time.
• Enables very flexible scheme as the system
designer can choose the operations to be
over ridden and differentiate based on the
real use.
• Not all Virtualization solutions have to be
the same
TrustZone Monitor
Virtualization VMM
Guest1
Guest(n)
Secure World
Secure micro-kernel
TaskletTaskletTasklets
. . .
Virtual User Mode.
Both User and
Kernel run in
Virtual User Mode.
Hypervisor runs in
System Mode.
Guest0
8. TrustZone Monitor as a VMM
TrustZone provides a mirror world, where memory and other
resources are completely isolated from the normal world
TrustZone Monitor can be extended to act as a hypervisor.
– Guests can continue to work without modifications
– Kernel can continue to run in supervisor mode
– Guests OSes can run in their individual containers with low overhead.
TrustZone Monitor and Virtualization VMM
Guest0
Kernel
User
Guest1
Kernel
User
Guest(n)
Kernel
User
. . .
Secure World
kernel
TaskletTaskletTasklets
Secure World
kernel
TaskletTaskletTasklets
9. Hardware-Assisted Virtualization
ARM virtualization extensions and LPAE provides the
CPU, memory and I/O virtualization support through
hardware.
HYP mode
– New execution mode “HYP” is added for hypervisor.
Allowing the guest to continue to run in normal
supervisor/user modes
– Virtualizing all CPU features including CP15
Large Physical Addressing
– 40-bit physical addressing
– Guest virtual memory has support for 4GB address space
– Up to 1 TB of physical address space
10. Hardware Assisted Virtualization
continued…
Nested Page tables support
– Two stages of hardware address translations. i.e.
separate hardware based page tables for Hypervisor,
Guest OS.
– Tables from Guest OS translate VA to IPA
– Hypervisor page table translate IPA to PA
VGIC
– Virtual interrupts are routed to the non-secure
IRQ/FIQ/Abort
– Virtual Masking bits allow each guest to mask and un-
mask GIC virtually
– Guest OS manipulates the virtualized interrupt controller
11. SierraVisor - Flexibility
ARM Platform
Normal I/O
CPU
• Privileged Access
• Execution Time
Normal Memory Protected I/O
Protected Memory
sierraVisor
Memory Access Manager
I/O Access
Manager
VCPU Cluster
Pseudo Virtual I/O
Virtualized GIC
Abort/Trap nested MMU
HW nested MMU
Hypercalls/TrustZone
Scheduler
HW VCPU
Rich GuestOS
Kernel/User SpaceRich GuestOS
Kernel/User Space
Secure Stack
User/Kernel
Secure Stack
User/Kernel
TrustZone
Mailbox
12. SIERRA TEE – TRUSTED
EXECUTION ENVIRONMENT
Android, RTOS Ready
13. SierraTEE: TrustZone Environment
ARM SOC
Crypto Engine Secure Memory
Secure
External bus
Secure
Peripherals:
Flash, Keyboard,
Display
Normal World OS
(Android/uCOS/RTOS)
Kernel
Secure Driver
Global Platform Client API
Secure OS
Dispatcher
Kernel
Monitor/Real Time Scheduler
Media Playback
with DRM
Crypto Display File System
DASM
Services
Mgr
Trustlet
Secure
Tasks
Global Platform Internal API
Java Payment
With Secure
Input/Output
14. Powerful, Purpose-built OS
Flexible with Neon and VFP
– Fully shared mode
– Supports both “Secure” or “Normal” world
Thwarts side channel attacks by protecting
branch target buffers, TLBs, etc
Supports several interrupt models
– FIQ & IRQ in dedicated secure cores
– FIQ only mode when sharing cores
– Interrupt routing from secure to non-secure world
15. Multi-core Ready: AMP/SMP
Dedicated Cores for Secure
and Normal World
Satisfies size and performance
constrained designs
Ideally suited for high
performance applications like
media playback, transcoding
Secure and Non-secure
Kernels Share Cores
Provides maximum peak CPU
bandwidth
Both secure and non-secure
kernels can utilize all available
cores
ARM MP Core
Core0 Core1 Core2 Core3
Normal
World
Secure
World
SierraTEE
ARM MP Core
Normal
World
Secure
World
SierraTEE
Core0 Core1 Core2 Core3
17. Hardware Assisted Virtualization and
TrustZone
Sierravisor provides the Secure TEE along with
the hypervisor support.
Secure TEE and Secure applications support
TrustZone Monitor
HW Virtualization VMM
Guest1 Guest(n)
Secure World
Secure micro-kernel
TaskletTaskletTasklets
. . .Guest0
18. Start, Stop and Restart of Guests –
VCPU state transition diagram
Init: Pre-configured guest
state.
Reset: VCPU in initialized
state and waiting for it to
start.
Ready: Ready to run state
and available for scheduler
Running: Currently running
VCPU.
Pause: Suspended VCPU
and is not available for the
scheduler.
Halt: Due to erroneous
condition vcpu is in this
state.
Init
Reset RunningReady
Halt
Pause
Start
Destroy
Create
Pause
Resume
Reset
Reset
Schedule
Schedule
Reset
Halt
Halt
Reset
19. Device Tree Configuration for Guests
Device tree configuration used for hypervisor and
guest configuration.
Device tree used to configure the cpu details,
memory, device association and interrupt mapping.
Guest configuration example:
guest0 {
model = "vexpress-a15";
device_type = "guest";
compatible = "ARMv7a,cortex-a15";
start_pc = <0x80000000>;
};
20. Start, Stop and Restart of Guests
Commands
Management console is provided to control the guests
Hypervisor shell is implemented using the virtual serial
console driver. It allows to display the Guest OS and
hypervisor console output
Start, stop and restart commands are provided to control
the guest.
Start command:
sw# guest 0 start
Pause command:
sw# guest 0 pause
Resume command:
sw# guest 0 resume
21. Application Support on Hypervisor
Application framework supported added by implementing the
command support in management console
Run time loadable applications support
Pre-defined commands like guest start, pause, resume,
dumpreg, ps
Modules list, load, unload commands support.
Hypervisor application configuration:
struct sw_task {
u32 task_id; /* Task ID */
u32 entry_addr;/* Task entry address */
char name[32]; /* Task user defined name */
u32 state; /* Task state */
void* task_sp; /* Task stack pointer */
u32 task_sp_size; /* Task stack size */
void* tls; /* Task local storage */
acl_t acl /* User access control list */
}
22. Application Support on Hypervisor
Task Helper Functions
Create task – This function helps in task creation. It allocates
the task structure, task local storage, task stack. It puts the
task in suspend state.
create_task(sa_config_t *psa_config, int *task_id);
Start task – This function gets called on command invocation
and puts the task in ready to run state.
start_task(int task_id, u32* params);
Destroy task – This function cleans up the created task. It
frees the resources which got allocated in task creation.
destroy_task(int task_id);
IPC api – This function helps to send the data between two
applications or guests of single request and response.
ipc_api(int origin_id, int target_id, int target_cmd_id, void *req_buf,
int req_buf_len, void *res_buf, int res_buf_len, int *ret_res_buf_len);
24. Pass Through Devices
Direct hardware access support for Guest OS
Memory access is restricted only to the
mapped Guest OS.
Pass through device interrupts are mapped to
the Guest OS
Device tree is used to configure the pass
through devices
Device tree will have information about Device
memory region and Interrupts.
25. Pass Through Devices Continued…
Direct IO driver data flow:
Device
Guest
driver
VMM
Memory
Manager
DMA
Interrupt
Control
List
26. Pass Through Device Configuration
Device tree list for pass through devices
Interrupts are configured per device
Device configuration example for pass through
devices
struct device_conf_entry linuxguest1_dtable[] =
{
{.dce_irq = 42,
.dce_name = “ttc-0”.
.dce_type = DEVTYPE_PASSTHROUGH,
},
{.dce_irq = 54,
.dce_name = “ethernet”.
.dce_type = DEVTYPE_PASSTHROUGH,
},
}
;
28. Shared Devices – System MMU
Systems with SMMU support
– Adding SMMU device for stage 2 translation removes the
need for the hypervisor to manage shadow translation
tables totally in software.
– With stage 2 translation, the SMMU enables any Guest
OS to directly configure all DMA capable devices in the
system sharing the same address space at IPA level.
– The SMMU can also be configured to ensure that devices
operating on behalf of one Guest OS are prevented from
corrupting memory of another Guest OS.
– The Stage 2 address translation system is based on a
translation scheme with a 64-bit descriptor to allow it to
address a physical memory larger than 4GBytes.
29. Devices – System MMU
The following diagram depicts the functionality
of 2-stage System MMU translation.
A0-n
Guest 0-n
Process A
0
4GB
B0-n
Guest 0-n
Process m
4GB
0
Virtual Address (VA)
Space
A0
B0
0
4GB
An
Bn 0
4GB
Stage1
Translation
Stage1
Translation
Intermediate Physical
Address (IPA) Space
A0
B0
An
Bn
Stage2Translation
4GB
0
Physical Address (PA)
Space
31. Virtual Framebuffer
Virtual Frame buffer
– Ring buffer is used for communication between guest and VMM.
– Guest inform the change in notification by writing a request in the
ring buffer.
struct fb_device {
int width; /* Width of the frame buffer */
int height; /* Height of the frame buffer */
u32 line_length; /* Length of a row of pixels */
u32 mem_length; /* Framebuffer length */
}
– Because of bigger in size, data is not place in ring buffer. Copying of
this data (~4MB) will be a expensive operation. Both the Guest and
VMM have statically mapped entries. Guest driver sends the
notification to VMM driver about the region need to be refreshed.
32. GPU Virtualization
API Remoting
Slave Guest Primary Guest
Open GL & EGL
Commands
Remote API
Marshaled API
commands
State Translator
Pipe Driver
GPU
Commands
GPU Driver
Hardware
Commands
34. GPU Virtualization
API Remoting Continued…
Each user call to graphics API translated to remote
procedure call
Marshaled commands are transferred over the shared
memory and local pointers in case of Textures, surface
are translated to safe pointers
On receiving the commands, Proxy Server will translate
that to Hardware commands for the GPU driver
GPU driver creates a context for each remote rendering
context
It executes the drawing commands in the appropriate
context as it services each remote client. By having the
control of context switches, it prevents guest applications
modifying the state of the other contexts.
35. OMX and Secure Codec
Para virtualized IL
Media Player
Extractor
OMX Codec IL Proxy
Audio
Track
Video
Track
Audio
Source
Video
Source
Context Manager
Media Extractor
Containers
Codec
Color
Rende
rer
Android
Kernel
Shared Memory
Master Guest 0
Kernel
Shared mem
Pipe
OMX Application
(Decode & Display)
OMX
VFP
36. Virtio
Para virtualized I/O: virtio provides an efficient abstraction for hypervisors
and a common set of I/O APIs
Components of Virt I/O:
Front-end drivers
Back-end drivers
virtio defines two layers to support guest-to-hypervisor communication.
Virtqueue:
The virtual queue interface that conceptually attaches front-end drivers to
back-end drivers.
Drivers can use zero or more queues, depending on their need.
For example, the virtio network driver uses two virtual queues (one for
receive and one for transmit).
They are actually implemented as rings to traverse the guest-to-hypervisor
transition.
38. Virtio Internals
From the perspective of the guest
1. At the top is the virtio_driver, which represents the front-
end driver in the guest.
2. Devices that match this driver are encapsulated by the
virtio_device (a representation of the device in the guest).
3. virtio_config_ops structure defines the operations for
configuring the virtio device.
4. The virtio_device is referred to by the virtqueue, which
includes a reference to the virtio_device to which it serves.
5. Finally, each virtqueue object references the virtqueue_ops
object, which defines the underlying queue operations for
dealing with the hypervisor driver.
39. Network Emulation
Network Virtualization support
– Emulated virtual switch which can handle multiple
virtual network port
– Virtual network port is a logical connection between
switch and network driver
– “dbuf” is a Data buffer which handles the packet
data
– Two ring buffers for transmit and receive operations
and used to transmit instructions
– Data transfer is done using the shared memory
pages
42. Professional Services
Porting software to
processors
Integrating TEE
and SierraVisor
with applications
Developing drivers,
encoders or apps
Extensive
experience with
ARM processors
and kernel code
Android, Linux,
BSD, and VxWorks
development
Hardware & FPGA
Phased approach
from planning and
development to
testing & certification
Carefully defined
schedules and
communication with
customers to avoid
surprises & delays
Custom
Services
ARM Design
Expertise
Project
Management
43. Technical Support
Telephone and Email Support
Online technical documentation
Software updates for commercial products
Previews of upcoming releases
Ability to influence feature enhancements
Commitment to Quality
– Service Level Agreement (SLA) details support response
times and escalation levels