[PPT] - Unikernels as Processes Dan Williams, Ricardo Koller (IBM Research) PowerPoint Presentation

SLIDE 1

Unikernels as Processes

Dan Williams, Ricardo Koller (IBM Research) Martin Lucina (robur.io/Center for the Cultivation of Technology) Nikhil Prakash (BITS Pilani)

SLIDE 2

An application linked with library OS components
Run on virtual hardware (like) abstraction
Language-specific
MirageOS (OCaml)
IncludeOS (C++)
Legacy-oriented
Rumprun (NetBSD-based)
Can run nginx, redis, node.js, python,etc..

What is a unikernel?

VM

2

SLIDE 3

Why unikernels?

Lightweight
Only what the application needs
Isolated
VM-isolation is the “gold standard”
Well suited for the cloud
Microservices
Serverless
NFV

3

VM

SLIDE 4

Virtualization is a mixed bag

Good for isolation, but…
Tooling for VMs not designed for lightweight (e.g., lightVM)
How do you debug black-box VMs?
Poor VM performance due to vmexits
Deployment issues on already-virtualized infrastructure

4

SLIDE 5

Why not run unikernels as processes?

Unikernels are a single process anyway!
Many benefits as a process
Better performance
Common tooling (gdb, perf, etc.)
ASLR
Memory sharing
Architecture independence
Isolation by limiting process interface to host
98% reduction in accessible kernel functions

5

Process

SLIDE 6

Outline

Introduction
Where does unikernel isolation come from?
Unikernels as processes
Isolation evaluation
Performance evaluation
Summary

6

SLIDE 7

Isolation: definitions and assumptions

Isolation: no cloud user can read/write state
r modify its execution
Focus on software deficiencies in the host
Code reachable through interface is a metric for

attack surface

We trust HW isolation (page tables, etc.)
We do not consider covert channels, timing

channels or resource starvation

7

Host Kernel app

SLIDE 8

Unikernel architecture

8

Linux monitor process (e.g., ukvm) I/O devices KVM VT-x

ukvm unikernel

monitor

Userspace process
Uses Linux/KVM
Setup and loading
Exit handling

SLIDE 9

Unikernel architecture

9

Linux monitor process (e.g., ukvm) I/O devices KVM VT-x Setup Set up I/O fds 1

ukvm unikernel

monitor

Userspace process
Uses Linux/KVM
Setup and loading
Exit handling

SLIDE 10

Unikernel architecture

10

Linux monitor process (e.g., ukvm) Virtual CPU context I/O devices KVM VT-x Setup Set up I/O fds 1 Load unikernel 2

ukvm unikernel

monitor

Userspace process
Uses Linux/KVM
Setup and loading
Exit handling

SLIDE 11

Unikernel architecture

11

Linux monitor process (e.g., ukvm) I/O devices KVM VT-x Setup Set up I/O fds 1 Exit handling Load unikernel 2 I/O

ukvm unikernel

monitor

Userspace process
Uses Linux/KVM
Setup and loading
Exit handling

Virtual CPU context

SLIDE 12

Unikernel isolation comes from the interface

10 hypercalls
6 for I/O
Network: packet level
Storage: block level
vs. >350 syscalls

12

Hypercall walltime puts poll blkinfo blkwrite blkread netinfo netwrite netread halt

SLIDE 13

Observations

Unikernels are not kernels!
No page table management after setup
No interrupt handlers: cooperative scheduling and poll
The ukvm monitor doesn’t “do” anything!
One-to-one mapping between hypercalls and system calls
Idea: maintain isolation by limiting syscalls available to process

13

SLIDE 14

Unikernel as process architecture

14

Linux tender process I/O devices

Tender: modified ukvm

unikernel monitor

Userspace process
Uses seccomp to

restrict interface

Setup and loading

SLIDE 15

Unikernel as process architecture

15

Linux tender process I/O devices Setup Set up I/O fds 1

Tender: modified ukvm

unikernel monitor

Userspace process
Uses seccomp to

restrict interface

Setup and loading

SLIDE 16

Unikernel as process architecture

16

Linux tender process I/O devices Setup Set up I/O fds 1 Load unikernel 2

Tender: modified ukvm

unikernel monitor

Userspace process
Uses seccomp to

restrict interface

Setup and loading

SLIDE 17

Unikernel as process architecture

17

Linux tender process I/O devices Setup Set up I/O fds 1 Load unikernel 2 Configure seccomp 3

Tender: modified ukvm

unikernel monitor

Userspace process
Uses seccomp to

restrict interface

Setup and loading

SLIDE 18

Unikernel as process architecture

18

Linux tender process I/O devices Setup Set up I/O fds 1 Exit handling Load unikernel 2 I/O Configure seccomp 3

Tender: modified ukvm

unikernel monitor

Userspace process
Uses seccomp to

restrict interface

Setup and loading
“Exit” handling

SLIDE 19

Unikernel isolation comes from the interface

10 hypercalls

19

Hypercall walltime puts poll blkinfo blkwrite blkread netinfo netwrite netread halt

6 for I/O
Network: packet level
Storage: block level
vs. >350 syscalls

SLIDE 20

Unikernel isolation comes from the interface

Direct mapping between 10

hypercalls and system call/resource pairs

20

Hypercall walltime puts poll blkinfo blkwrite blkread netinfo netwrite netread halt

6 for I/O
Network: packet level
Storage: block level
vs. >350 syscalls

System Call Resource clock_gettime write stdout ppoll net_fd pwrite64 blk_fd pread64 blk_fd write net_fd read net_fd exit_group

SLIDE 21

Implementation: nabl nabla !

21

Extended Solo5 unikernel

ecosystem and ukvm

Prototype supports:
MirageOS
IncludeOS
Rumprun
https://github.com/solo5/solo5

SLIDE 22

Measuring isolation: common applications

200 400 600 800 1000 1200 1400 1600 n g i n x n g i n x

l

a r g e n

d

e

e

x p r e s s r e d i s

g

e t r e d i s

s

e t Unique kernel functions accessed process ukvm nabla

22

Code reachable

through interface is a metric for attack surface

Used kernel ftrace
Results:
Processes: 5-6x more
VMs: 2-3x more

SLIDE 23

Measuring isolation: fuzz testing

23

100 200 300 400 500 600 700 50 100 150 200 250 300 Unique kernel functions accept nabla block 30 10

Used kernel ftrace
Used trinity

system call fuzzer to try to access more of the kernel

Results:
Nabla policy reduces

by 98% over a “normal” process

SLIDE 24

Measuring performance: throughput

80% 100% 120% 140% 160% 180% 200% py_tornado py_chameleon node_fib mirage_HTTP py_2to3 node_express nginx_large redis_get redis_set includeos_TCP nginx includeos_UDP Normalized throughput 245 no I/O with I/O

ukvm nabla QEMU/KVM 24

Applications include:
Web servers
Python benchmarks
Redis
etc.
Results:
101%-245% higher

throughput than ukvm

SLIDE 25

Measuring performance: CPU utilization

20 40 60 80 100 120 (a) CPU % 20 40 60 80 100 (b) VMexits/ms 0.5 1 1.5 5000 10000 15000 20000 (c) IPC (ins/cycle) Requests/sec nabla ukvm 25

vmexits have an effect on

instructions per cycle

Experiment with MirageOS

web server

Results:
12% reduction in cpu

utilization over ukvm

SLIDE 26

Measuring performance: startup time

250 500 750

Hello world

QEMU/KVM

10 20 30

ukvm

10 20 30

nabla

10 20 30

process

500 2 4 6 8 10 12 14 16 500 1000 1500

HTTP POST

2 4 6 8 10 12 14 16 50 100 150 200 2 4 6 8 10 12 14 16

Number of cores

50 100 150 200 2 4 6 8 10 12 14 16 50 100 150 200 0 2 4 6 8 500 1000 1500

26

Startup time is important

for serverless, NFV

Results:
Ukvm has 30-370% higher

latency than nabla

Mostly due avoiding KVM
verheads

Hello world HTTP Post

SLIDE 27

Summary and Next Steps

Unikernels should run as processes!
Maintain isolation via thin interface
Improve performance, etc.
Next steps: can unikernels as

processes be used to improve container isolation?

Nabla containers
https://nabla-containers.github.io/

27

Process

SLIDE 28

28