Embed Size (px)
Citation preview
Eliminating State Entanglement withCheckpoint-Based
Virtualization of Mobile OS Services
Kevin Boos Ardalan Amiri Sani Lin Zhong
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
2
What is State Entanglement?
Application-relevant states stored outside of the application process
APSYS 2015 TOKYO, JAPAN
Background
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
3
Shared Library Model
APSYS 2015 TOKYO, JAPAN
Client Process
Application
Shared Library
Linux Kernel
syscall
All states in one process
Background
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
4
Mobile OS Service Model
APSYS 2015 TOKYO, JAPAN
Client Process
Application
Linux Kernel
syscall
OS Service Process
System Service
States spread across multiple processes
IPC
State Entanglement!
microkernel … ish
Background
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
5
Why do we care? What is our larger goal?◦ Users are only interested
in states from their applications
What can’t we do because of state entanglement?
◦ Fault isolation◦ Fault tolerance◦ Application migration◦ Live update◦ Application speculation
APSYS 2015 TOKYO, JAPAN
Motivation
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
6
Problems – Fault Isolation
APSYS 2015 TOKYO, JAPAN
OS Service
App A
App B
App A
OS Service
App B
App A affects App B through the OS
Service
Problems
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
7
Problems – Fault Tolerance
APSYS 2015 TOKYO, JAPAN
Problems
OS Service
App A
App B
OS ServiceOS Service t-1OS Service t-2OS Service t-3
?A fault recovery for App A unexpectedly breaks
App B
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
8
Problems – App Migration
APSYS 2015 TOKYO, JAPAN
Post-migration, App A cannot continue using
OS Service
App
OS Service
original device
OS Service
target device
?
Problems
Solution: OS Service Virtualization
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
10
OS Service Virtualization
Virtualize an OS Service on a per-app basis◦ N to 1 1 to 1
Encapsulate only one app’s states in a service ◦ Disentangles states
APSYS 2015 TOKYO, JAPAN
App A
App B
App N
OS Service A
OS Service B
OS Service N
Cannot instantiate a service multiple times!
Design
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
11
CORSA: Checkpoint-based Virtualization
Virtualization through checkpoint/restore◦ Intercept app-service transactions
Per-app checkpoint history◦ Only one active instance
All other OS bodies see a single service instance◦ Preserves legacy expectations
APSYS 2015 TOKYO, JAPAN
OS Service
App A
App BCurrent
Base CheckpointVirtual
Service A
App N Virtual Service N
Virtual Service A
Base Checkpoint
Virtual Service B
Eliminates state entanglement
No knowledge of virtualized entity
Design
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
12
CORSA Enables Fault Isolation
APSYS 2015 TOKYO, JAPAN
OS Service
App A
App B
App A
App B is unaffectedby App A’s failures
Design
Virtual Service A
Virtual Service B
Virtual Service A
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
13
OS Service
Virtual Service B
Virtual Service A
CORSA Enables Fault Tolerance
APSYS 2015 TOKYO, JAPAN
Design
App A
App B Recovering a service for App A does not break
App B
Virtual Service A
Virtual Service A-1
Virtual Service A-2
Virtual Service A-3
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
14
CORSA Enables App Migration
APSYS 2015 TOKYO, JAPAN
Post-migration, App A can continue using OS
Servicewith all states intact
App
OS Service
original device
OS Service
target device
Design
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
15
Ongoing Implementation
Checkpointing software is an implementation choice
Kernel-based checkpoint/restore mechanism◦ Checkpoint: duplicates process structures, COW◦ Restore: swaps process control block pointers◦ Triggered upon intercepted Binder IPC transactions◦ Must monitor both sides of transaction, proxy and stub
Key insight: Checkpoint and Restore can be parallelized ◦ Optimization: checkpoint can be slow, restore must be fast◦ Only restore is on the critical path of an application
transition
APSYS 2015 TOKYO, JAPAN
Implementation
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
16
Feasibility Is checkpoint/restore a feasible means of virtualization?
APSYS 2015 TOKYO, JAPAN
Time to checkpoint a service
Time to restore a service checkpoint
Interval between two one-shot transactions
Frequency of periodic transactions
tC
tR
θ
f
Key MeasurementsNexus 5 + Android 5.0
Feasibility
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
17
Feasibility
APSYS 2015 TOKYO, JAPAN
App A(Opening App)
tC + tR
��
App B(Launcher)
Transaction BOS Service(SurfaceFlinger)
idle
idle
C/R Transaction A
0.3 ms 4.4 µs1.07 ms
Critical Path!
Feasibility
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
18
Feasibility
APSYS 2015 TOKYO, JAPAN
App A(Opening App)
tR
App B(Launcher)
Transaction BOS Service(SurfaceFlinger)
idle
idle
R Transaction Ackpt
tC
Min. Delay
proactiveparallelasync
Feasibility
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
19
Related Work at a glance
Virtualization: a choice of boundary and granularity◦ Whole-system VMs, OS-level, process-level, and more
Record & Replay: temporally and spatially less efficient◦ Flux: app migration through selective R&R
Memory Protection: provides foundations of isolation ◦ Relies on manual knowledge and identification of states
Manual Modification: deep understanding + tedious engineering effort
APSYS 2015 TOKYO, JAPAN
Related Work
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
20
Discussion Limited scope: interactions between apps and OS Services
◦ State entanglement also manifests in other layers◦ Each layer requires its own solution because states are fundamentally
different
APSYS 2015 TOKYO, JAPAN
Permitted Modification Potential
No modifications Preserve legacy compatibility
Entities themselves ≈ Manual disentanglement
Layers beneath the entitiesDisentangle unmodified higher levels
Clean slate OS rewritten from scratch
∞
Stateless entities, à la RESTFUL web services
Wrap Up
RICE
Background Motivation Problems Design Implementation Feasibility Related Work Wrap Up
21
Concluding Remarks
APSYS 2015 TOKYO, JAPAN
State entanglement: app-specific states stored in service processes
◦ Root cause behind barriers to target use cases
CORSA: virtualizes OS Services on a per-app basis
Virtualization solution implemented via checkpoint/restore
Full implementation in progress, slated for early 2016
Kevin Boos [email protected]
www.owlnet.rice.edu/~kevinaboos
Wrap Up
