acrn: a big little hypervisor for iot development · area (disk, partition, file or portion of...
TRANSCRIPT
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!!!