Sie sind auf Seite 1von 24

ASP-DAC 2007

Towards Scalable and Secure Execution


Platform for Embedded Systems

Junji Sakai, INOUE Hiroaki, Masato Edahiro


System Devices Research Laboratories
NEC Corporation
Jan 24, 2007

Agenda
Background
Problems in high-end embedded systems
Partitioning using multicore

Physical partitioning
for Performance assurance
for Download security

More flexibility and scalability


Virtualization
SMP

Summary and future work


2

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

lack of performance assurance


Existing
approaches:

Tel

DL
App

Mail

Adrs
book

DL App attacks
Mail App

decline in robustness

Reliability degradation

Priority Control

Sandbox

insufficient
3

Improve Reliability with Partitioning


Separate Apps by Partitioning
Interference
Attacks

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

CPU Trend Multicore anywhere


In Servers and Desktops
Use multicore to reduce heat emission

Also in Embedded Systems


Use multicore to reduce power consumption
and moreover,
to resolve the arising problems

our proposal

Two Approaches to Partition


HW level partitioning
(Multicore)
App App
A
B

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

Avoid too much dependence on OS reliability


( OS may be vulnerable )
Fast recovery (reboot only the crashed part)
Simple and robust using commodity CPU and OS

1) performance assurance
2) system robustness
7

Performance Assurance by Multicore


App set: DTV + Newsreader + gadgets
Assign tasks to CPU cores so that mutual
interference is minimized
RT tasks / CPU-centric tasks / Interactive tasks
MP211 (3x ARM9 + 1x DSP)
interactive
CPU0

RSS
News
Server

Task
Switcher
Web
browser
Xserv

CPU-centric
CPU1

RSS
Analyzer
Event
Watcher

RT
CPU2

DTV
Stream
Control

DSP

H264
AAC
Decoder

Browser, Java, Xserver, RT stream control


8

Performance Assurance -- Results


All applications smoothly
run on multicore.
Single core:
short interrupts
of sound stream

DTV

DTV

News
reader

Jitter of a periodical task interval (DTV stream control)


single core

multicore

No jitter in multicore
stable execution
delay occurrences
9

Communication and Partitioning


Comm. and partitioning are tradeoff
X
App App
A
B

App App
C
D

Strong
Difficult

App App
A
B

Partitioning
Communication

App App
C
D

Weak
Free

In our case:

OS standard APIs cannot talk to other core.


Rewriting applications should be avoided.
(No special communication APIs welcomed)
10

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

Downloading and Security


Downloading becomes popular
in embedded systems
Expand functions

Security issue:
Unauthorized access against
core functions
Malicious attacks

Tel

DL
App

Mail

Adrs
book

auth

Existing approaches:
Sandbox (Java)
Authorization (BREW)

apply multicore
to security issue

Tel

DL
App

Tel

DL
App

Mail

Adrs
book

JavaVM

Mail

Adrs
book

Performance
overhead

Validation cost
to ensure safety
Recovery time
12

FIDES: Robustness by Multicore


* FIDES means trust in Latin

Domains (CPU core + OS)


corresponding to Trust levels

Benefit:
(1)No sandbox
lower overhead
(2)Physical partitioning
block attacks

built-ins authorized APs


DL APs
Software
Base Domain Trusted Domain Untrusted Domain
AP
AP

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

But, deeply bound to multicore configuration


# of domains
Performance of each domains

limited

How to expand capability ?


App
A

DL
App

App
B

App
C

expand

App
A
App
B

DL
App

DL
App

Big App
C

DL
App

?
16

Chip Manufacturing Aspect


Small quantity of customized LSI becomes
difficult
Rising cost of chip..
Design
Verification
Manufacturing

Partitioning mechanism should be


more flexible, scalable
Use the same chip for wider applications

17

Shift to Logical Partitioning


HW level partitioning

(2) SMP technology


SW level partitioning

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

VIRTUS : Processor Virtualization


Combines physical partitioning with
virtualization technique

virtus = virtual in Latin

(1)Most important part = HW partition


physically protected
(2)Download Apps = SW partition using multiplex (VMMs)
any # of
on other CPU cores
Software Domains
Hardware Domain
any # of domains

(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

AVMM also avoids


system freeze:
Access domain data
via Master VMM
Never hang up
while holding locks

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

3 ARM processors in MP211


21

SMP-type Multicore
Embedded SMP chips appeared
MPCore (ARM/NEC Electronics)
SH-X3 (Renesas)

SMP merits:
Performance scalability
Automatic load-balancing

aim to higher throughput

demerits:
Poor performance assurance (use affinity)
Poor robustness
No partitioning

Introduce partitioning features to SMP architecture


22

Combination of VIRTUS and SMP

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

Summary & Future work

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

App Big App


B
C

Physical
Partitioning

DL
App

Virtualization,
SMP

App
A

DL
App

App
B

App
C

AVMM
MultipleOS

Reliability
(Secure, Robust)
24

Das könnte Ihnen auch gefallen