ACRN: A Big Little Hypervisor for IoT Development

Eddie Dong, Intel Open Source Technology Center

Key contributors: Christopher Cormack, Matthew Curfman, Jeff Jackson

Table of Contents

PART 1: ACRN Overview

PART 2: Security in ACRN

PART 3: Rich I/O Mediation

PART 4: Call for Participation

…………………………………………….. page 3

…………………………………………….. page 6

…………………………………………….. page 10

…………………………………………….. page 16

What is ACRNACRN is a Big Little Hypervisor for IoT Development

ACRN™ is a flexible, lightweight reference hypervisor, built with

real-time and safety-criticality in mind, optimized to streamline

embedded development through an open source platform

Trusty

World

Architecture Overview

Subtext goes hereService VM

(PIT, PCI, ACPI ..)

Hypercalls

VT-d EPT

ACRN HypervisorVMX

Virtio API Trusty API vPIC/vLAPIC/

vIOAPIC/vMSI

ACRN Device

Model

(Mediators)

VM

Manager

Linux VM

virtio

FE Drivers

User

Kernel

User

Kernel

VM API

SOC Platform (Apollo Lake etc.)

Firmware (UEFI, SlimBoot etc.)

CSE

Keystore

Virtual Firmware

EnclavesEnclaves

Android

World

virtio

FE Drivers

User

Kernel

Virtual Firmware

VMX non-root

operation

VMX root

operation

Android VM

Keystore

Native Device DriverNative Device Driver

Kernel

Mediators

ACRN as a Device Hypervisor

• Small footprint

• BSD licensee

• Be able to cherry pick piece of codes into OSV/OEM’s own hypervisor

• Verified boot

• Rich I/O mediators

KVM Xen ACRN

LOC 17M 290K 25K

GPU IPU TSN CSE USB Audio Ethernet Block IOC Touch

Mediated

PassthruVirtio Virtio Virito Emu. Virtio Virtio Virtio Emu. Virtio

Verified Boot Sequence with SBL

• CSE verifies SBL

• SBL verifies ACRN & SOS

Kernel

• SOS kernel verifies DM &

vSBL thru dm-verity

• vSBL starts the guest side

verification process (reusing

the Android verified boot

mechanism)

• NOTE: Each user VM has a

DM APP instance in SOS

DM APP2Android VM 2

SOS

CSE

SBL

ACRN

SOS Kernel

Device Model

APP1

vSBL: Initialization

Trusty OS Android OS

Android VM 1

vSBL: Android OS Loader

Stitched as

one image

Verified Boot Sequence with UEFI

• UEFI verifies ACRN & OS Bootloader & SOS Kernel

• SOS kernel verifies DM and vSBL thru dm-verity

• vSBL starts the guest side verified boot process

• NOTE: ACRN remains EFI runtime services and boot time services (without interrupt)

UEFI ACRN.EFI SOS KernelOS BootloaderDevice

ModelvSBL …..CSE

SEED Virtualization

• HV gets pSEED from ABL,

which retrieves from CSE

through HECI.

• Hypervisor implements Key

derivation function (KDF) to

generate child seeds (vSEED)

per request

• HMAC-SHA256 for Android

VM

• HMAC-SHA512 for Linux VM

• Present the derived vSEED

to guest VM. Each guest

cannot see/derive the other

guest’s vSEED.

Service OS

(PIT, PCI,

ACPI ..)

User OS

ACRN Hypervisor

Device Model

User OS

User OS

User

Kernel

User

Kernel

vSEED1

vSBL

CSE Hardware & Firmware pSEED

pSEED

SOS SBLvSEED0

One time read after boot

Derive - 0 Derive - 2 Derive - 1

Derive - 3

vSEED0

vSEED1

Get and EraseGet and Erase

UEFI/SBL pSEED

HECI (Host Embedded Controller Interface)

• HECI emulator implements a virtio

PCIe device to support multiple

User OS.

• HECI BE will communicate with

HECI FE driver to send & receive

the HECI messages.

• HECI client layer protocol will

read/write to SOS MEI cdev directly.

And HECI bus messages will

emulate in the BE.

ACRN Hypervisor

User OSService OS

User OS

User OS

User

Kernel

MEI Subsystem

PCI-MEI

MEI cdev

HECI

Applications

User

Kernel

ACRN Device Model

HECI virtio BE

Service

MEI Subsystem

MEI cdev

HECI virtio FE Driver

HECI

Applications

CSE Hardware

mei_cl_driver mei_cl_drivermei_cl_driver

mei_cl_drivermei_cl_driver

mei_cl_driver

APL hardware

MEI: Intel Management Engine Interface Linux driver; mei_cl_driver: mei client driver

User OS

User OS

Storage Virtualization

Service OS

ACRN Hypervisor

User OS

Storage FE

virito driver

Guest Virtual Disk

Map/filter a guest disk

access to a host storage

area (disk, partition, file or

portion of them)

Native Storage Driver

Storage BE

Service

ACRN Device Model

Vm2 partitionVm1 partitionPhysical Disk

• Map a host storage area (SAR), i.e., disk / partition / file, as a guest disk

• Map a portion of host SAR (start_LBA, size) as a guest disk

User OSUser OS

Network Virtualization

Service OS

ACRN Hypervisor

User OS

Virtio-NIC FE

driver

Guest Virtual NIC

Native

NIC Driver

NIC BE

Service

ACRN Device Model

Virtual Bridge /

Switch

Tap / Tun

Driver

External Network

User OS

User OS

IOC (I/O Controller) Virtualization

• SOS owns IOC, but UOS may

access part features

• Whitelisted CMDs from UOS

may be forwarded / emulated

• Support Intel IOC controller

only, OEMs may extend

Service OS

ACRN Hypervisor

Device Model

User OS

IOC Driver

(CBC drive)

IOC

Application

Virtual UART

IOC BE service

(filter to emulate the

whitelisted CMD only)

Physical

UART

IOC Hardware

(MCU)CAN Bus

IOC Driver

(CBC drive)

UART

Emulation

CAN Bus

User OSUser OS

GPU Virtualization

Service OS

ACRN Hypervisor MPT API

User OS

Guest GPU

Driver

User

Kernel

User

Kernel

AppApp

AppApp

GPU

Host GPU

Driver

Pass-through

Trap

GPU BE Services

vGPUvGPUvGPU

User OS

Audio Virtualization

User OS

ACRN Hypervisor

User

Kernel

Audio Apps

ALSA lib/Tiny

ALSA

ALSA Core

SOF Machine Driver

SOF PCM Driver

SOF IPC Driver

Service OS

Virtio Audio BE

Service

User

Kernel

Audio Apps

ALSA lib/Tiny

ALSA

ALSA Core

SOF Machine Driver

SOF PCM Driver

SOF IPC Driver

Virtio Audio FE

Drivers

Shared

Rings

DSP Platform Driver

• ALSA (Advanced Linux Sound

Architecture) lib - same user API

across VMs

• SOF FE driver forwards IPC

commands to its counterpart SOF BE

service (kernel space) thru virtio

shared rings

• The commands carry the address of

audio data (not data)

• Service OS can directly access the

memory of User OS

• FE driver communicate with IPC

driver thru ops callback of platform

driver

• BE service communicate with IPC

driver thru IPC TX/RX interface of

IPC driver

*SOF: Sound Open Firmware; PCM: Pulse-code modulation; IPC: Inter-Processor Communication

USB Virtualization

• xHCI emulator provides multiple

instances of virtual xHCI

controller to share among

multiple User Oss, each USB

port can be dedicatedly assigned

to a VM.

• xDCI controller can be passed

through to the specific user OS

with I/O MMU assistance.

• DRD BE service emulate the

PHY MUX control logic. And

DRD FE driver provide sysfs

interface to user space of user

OS to switch DCI/HCI role in

CarPlay SW.

ACRN Hypervisor

User OS

User OSService OS

APL hardware

User OS

User

Kernel

ACRN Device Model

xHCI controller xDCI

Controller

xDCI Driver

DRD FE Driver

xHCI Driver

SW Role Switch

Sys I/F

CarPlay

Application

Gadget

Daemon

DRD

BE Service

xHCI

Emulator

User

Kernel

Host

Daemon

xHCI Driver

DRD Driver

usbfsSys I/F

PHY MUX control

USB2 PHY USB3 PHY

PHY MUX

IO MMU

Call for Participationhttps://projectacrn.github.io/index.html

Joining ACRN Community Today!!!