Professional Documents
Culture Documents
Towards Scalable and Secure Execution Platform For Embedded Systems
Towards Scalable and Secure Execution Platform For Embedded Systems
Agenda
Background
Problems in high-end embedded systems
Partitioning using multicore
Physical partitioning
for Performance assurance
for Download security
Arising Problems
Needs: PC-level functions in embedded systems
Multi-Functional
Problems:
Tel
TV
Application Download
Java disturbs
TV stream
(CPU resource
Java consumed)
Net
Tel
DL
App
Adrs
book
DL App attacks
Mail App
decline in robustness
Reliability degradation
Priority Control
Sandbox
insufficient
3
suppressed
App
A
DL
App
App
B
App
C
attack
Reliability
Accompanying issue
= Communication
discussed later
partitioning
App
A
DL
App
App
B
App
C
4
our proposal
App App
C
D
CPU
CPU
Robust
High Performance
Our
approach
SW level partitioning
(VM, OS scheduling)
App App
A
B
App App
C
D
CPU
Tradeoff
Flexible
Extendable
Existing
approaches
degree of
reliability
6
Physical Partitioning
Our basic strategy:
CPU level
separation
and
independent
OS kernel level
instances
Why OS kernel level ?
AMP
App
A
App
B
App App
C
D
OS
OS
CPU
CPU
1) performance assurance
2) system robustness
7
RSS
News
Server
Task
Switcher
Web
browser
Xserv
CPU-centric
CPU1
RSS
Analyzer
Event
Watcher
RT
CPU2
DTV
Stream
Control
DSP
H264
AAC
Decoder
DTV
DTV
News
reader
multicore
No jitter in multicore
stable execution
delay occurrences
9
App App
C
D
Strong
Difficult
App App
A
B
Partitioning
Communication
App App
C
D
Weak
Free
In our case:
OS Wrapper
Provides seamless APIs
for inter-core and intra-core communications
No source code modifications in the Demo set
Hooks OS service calls and dispatches to destination
Mostly user land implementation (can be applied to other OSs)
OS Wrapper
App
A
App
B
App App
C
D
OS Wrapper
OS
CPU
OS
CPU
Seamless
communications
appA
msgsnd()
proxy
task
appB
proxy
task
msgrcv()
CLlib
kernel
CLlib
ipi driver
PE0
CPU0
ipi driver
INTC
kernel
PE1
CPU1
11
Security issue:
Unauthorized access against
core functions
Malicious attacks
Tel
DL
App
Adrs
book
auth
Existing approaches:
Sandbox (Java)
Authorization (BREW)
apply multicore
to security issue
Tel
DL
App
Tel
DL
App
Adrs
book
JavaVM
Adrs
book
Performance
overhead
Validation cost
to ensure safety
Recovery time
12
Benefit:
(1)No sandbox
lower overhead
(2)Physical partitioning
block attacks
AP
(1)
OS
(3)Separate OSs
quick recovery
(2)
AP
CPU0
Bus Filter
AP
AP
DL
App
DL
DL App
App
(3)
OS
OS
CPU1
CPU2
SoC
Mem, I/O
13
Bus Filter
Another security risk: caused through shared devices
Bus Filter :
a firewall on the bus
block illegal access
from DL Apps
Access Control
Resources CPU0 CPU1,2
LCD
R/W
R
I/Os
R/W
R
CPU0 Mem R/W
CPU1,2 Mem R/W R/W
Software
Base Domain Trusted Domain Untrusted Domain
AP
AP
DL
App
AP
AP
OS
CPU0
Bus Filter
AP
AP
DL
DL App
App
OS
OS
CPU1
CPU2
SoC
Mem, I/O
shared mem
14
FIDES sample
Connect a mobile terminal to a projector
Download a document with a device
driver for the projector
Install the driver into the kernel !
If the driver crashes just reboot the
domain. No harm in the base domain.
Base Domain
PDF
doc.
UI App.
Projector
Dev.Drv.
Contents
Trusted Domain
Download
Client
Download
Manager PDF
Mobile Terminal
Apps.
UI App.
Linux
doc.
Dev.Drv.
Linux
Projector
Mobile Terminal
15
New Problems
Physical partitioning is powerful.
Completely removes interference
Makes system quite robust
limited
DL
App
App
B
App
C
expand
App
A
App
B
DL
App
DL
App
Big App
C
DL
App
?
16
17
App App
A
B
App App
C
D
App App
A
B
App App
C
D
CPU
CPU
CPU
CPU
Flexible
Robust
Tradeoff
Extendable
High Performance
Depend on # of Cores
(1) more flexible partitioning
Our next approach
our first
approach
Gradual shift
to logical partitioning
with general multicore
18
(1)
Also FIDES features:
Lower performance overhead OS Master
VMM
Block attacks
CPU0
Quick recovery
Physical partitioning
AP
AP
Pre-installed APs
AP
AP
AP
Downloaded APs
AP
AP
OS Slave
OS Slave
CPU1
CPU2
VMM
VMM
(2) SW multiplex
mechanism
19
Asymmetric VMM
Master VMM on CPU0 manages other slave VMMs
Communications through the Master VMM
Domain switch when talking to a dormant domain
Pre-installed APs
AP
AP
AP
OS
Master
VMM
CPU0
Downloaded APs
Dormant domain Active domain Active domain
AP
AP
AP
AP send
AP
AP
OS
OS
OS
3. Re-transfer
Slave
Slave
Slave
VMM
VMM
VMM 1. Transfer
2. Domain switch CPU1
CPU2
20
VIRTUS Screenshot
Creating 5 domains on 3 CPU cores
1x Base domain
4x untrusted domains for downloaded Apps
MP211 (3x ARM9)
5 Linux OSs
Domain #0 Domain #1/#3
Domain #2/#4
App.
App.
App.
App.
App.
Linux
Master
VMM
Linux
Slave
VMM
Linux
Slave
VMM
Linux
Slave
VMM
Linux
Slave
VMM
ARM
ARM
ARM
SMP-type Multicore
Embedded SMP chips appeared
MPCore (ARM/NEC Electronics)
SH-X3 (Renesas)
SMP merits:
Performance scalability
Automatic load-balancing
demerits:
Poor performance assurance (use affinity)
Poor robustness
No partitioning
App
A
DL
App
App
B
App
C
expand
App
A
App
B
DL
DL
App
DLApp
VIRTUS
App
Big App
SMP
- Any # of domains
- Performance scalability
on the same multicore architecture
23
App
A
Scalability,
Flexibility
App
A
DL
App
App
B
App
C
App
B
App
A
communication
compensation more separation
(OS Wrapper) (bus filter)
App
C
more Virtualization,
Scheduling, QoS,
Domain,
Task Assignments
DL
DL
App
DL
App
App
Physical
Partitioning
DL
App
Virtualization,
SMP
App
A
DL
App
App
B
App
C
AVMM
MultipleOS
Reliability
(Secure, Robust)
24