Secure Xen on ARM: Status and Driver Domain Separation
Sang-bum Suh
[email protected] SW Laboratories Corporate Technology Operations Samsung Electronics Presented at Xen Summit Autumn 2007, Sun Microsystems
Contributors
Sang-bum Suh Sung-min Lee Joo-young Hwang Jung-hyun Yu Sangdok Mo Chanju Park Bokdeuk Jeong Sungkwan Heo Jaemin Ryu Jun-young Sim Dong-hyuk Lee Igor Nabirushkin Alexander Trofimov Mikhail Levin Il-pyung Park Ho-soo Lee 2/21 SW Laboratories, CTO, Samsung Electronics
Contents Overview and Status of Secure Xen on ARM Architecture 1.0
Requirements for Beyond 3G Mobile Phone Goal and Architecture Development Environments Status of Secure Xen on ARM Architecture 1.0
Driver Domain Separation: Architecture Exploration
Motivation Driver Domain Separation: Architecture Summary Performance
Future Work 3/21 SW Laboratories, CTO, Samsung Electronics
Overview and Status of Secure Xen on ARM Architecture 1.0
4/21 SW Laboratories, CTO, Samsung Electronics
Requirements for Beyond 3G Mobile Phone
End user: Secure and reliable mobile terminals for mobile Internet services using WiBro Manufacturer: Robustness though complexity of devices gets increased Contents provider: Protection of IP rights in end-user terminals Carrier companies: Open and Secure Mobile Platform OSTI (Open Secure Terminal Initiative): NTT DoCoMo, Intel
Apps. & Services
Expected Beyond 3G Environments
Needs
m-Commerce m-Commerce Downloadable Downloadable Application Application VoIP VoIP
Multimedia Multimedia Service Service
Internet/Cellular Integration U-Health U-Health
Mobile 3DMobile Game 3D Game
User Security, Reliability (Secure Terminal)
System
Web Web Browsing Browsing Internet Internet Banking Banking
MultiMultifunction function
Memory >Memory 64MB > 64MB
System
CPU Complexity > 500CPU MIPS High-speed > 500 MIPS High-speed (10~100Mbps), (10~100Mbps), Multi-mode Multi-mode Modem Modem
Component Component Reusability Reusability
Manufacturer Robustness, Time-to-market
Beyond 3G environments and Needs 5/21 SW Laboratories, CTO, Samsung Electronics
Goal and Architecture Goal Light-weight secure virtualization technology for beyond 3G mobile phone
Approach Design and implementation of ¾ VMM on ARM using Xen architecture: Xen on ARM ¾ Security features using Xen on ARM: secure boot, secure SW installation, multi-layer fine-grained access control
Dom U
Dom 0
Application Application
Application Application Back-end Drivers Native Drivers
Access Control
Front-end Drivers
VM Interface
VM Interface
Domain Manager
PeripheralDevices Devices Peripheral
Access Control
Resource Allocator
CPU
Access Control
System Memory
Flash Memory
Secure Xen on ARM Architecture 1.0 SW Laboratories, CTO, Samsung Electronics
6/21
Development Environments HW and SW Environments A Reference System for Implementation ¾ SW – Xen : Xen-3.0.2 – Linux : ARM Linux-2.6.11 – GUI : Qtopia ¾ HW – Processor : ARM-9 266Mhz (Freescale i.MX21) – Memory : 64MB – Flash : NOR 32MB / NAND 64MB – LCD : 3.5 inch – Network : CS8900A 10Base-T Ethernet Controller Development Environments ¾ OS : Fedora Core 6 ¾ Cross-compiler: Montavista ARM GCC 3.3.1 ¾ Debugger : Trace32 ICD (In Circuit Debugger)
7/21 SW Laboratories, CTO, Samsung Electronics
Status of Secure Xen on ARM Architecture 1.0 Xen on ARM: Performance improved Video demo: game on Dom 0 and application/Qtopia on Dom U
video1
Xen Security features: 5 access control modules and visualization supported: ¾ Type Enforcement, Samsung proprietary, BiBA, Bell LaPadula, Chinese wall ¾ GUI-based access control policy manager Video demo: access control mechanism against phishing attack
page21
Driver domain separation: architecture exploration
8/21 SW Laboratories, CTO, Samsung Electronics
Driver Domain Separation: Architecture Exploration
9/21 SW Laboratories, CTO, Samsung Electronics
Motivation Many downloadable services under beyond 3G mobile environments will be increased. This requires an open mobile platform.
Open platform will face problems with malware and bugs similar to PC. Secure Xen can help an open mobile platform secure against malware. However, bugs in device drivers may cause Dom 0 to stop working and the applications to have to restart. ¾ Relatively short life cycle of peripheral chips in consumer electronics products. – Can test cases be updated quickly and be used to detect every bug during development ? Patch is likely.
☞ Device driver domain to be separated from Dom 0 (security applications running on Dom 0 in secure Xen on ARM) kernel.
10/21 SW Laboratories, CTO, Samsung Electronics
Driver Domain Separation: Architecture Dom 0 App
Dom U
Device Driver Domain App
App
App
Backend Driver Frontend Driver
Shared page Event channel
Native Driver
Shared page Event channel
Frontend Driver
Xenbus
Xen on ARM
Hardware 11/21 SW Laboratories, CTO, Samsung Electronics
Summary Device driver domain Xen-Linux kernel, access control module, backend and native drivers Modification ¾ RAMFS used for driver domain during booting ¾ Xenbus, Xenstore, and Xen tools modified ¾ Booting procedure modified – Booting Dom 0 => creating Device Driver Domain => initializing split device driver
Advantage Service availability can be improved even under driver fault ¾ Dom0 and Dom U can work, while due to device driver failure, driver domain has to be restarting.
Disadvantage Performance degradation due to domain switching between Driver Domain and Dom 0 12/21 SW Laboratories, CTO, Samsung Electronics
Performance (1/2) Environments Virtual Network HW Platform: Freescale i.MX21 ¾ 266Mhz ARM926lrmsdmq ¾ Memory: 64MB DDR ¾ Network: CS8900A 10Base-T Ethernet Controller
Backend in dom0
Backend in driver domain
Test S/W
Test S/W
Dom 0
Dom 1
Dom 0
Driver domain
Dom 1
Backend driver
Frontend driver
Frontend driver
Backend driver
Frontend driver
Hardware
Hardware
System memory configuration 44MB 44MB Xen
Dom0
44MB 44MB
20MB 20MB Dom1
Xen
Dom0
20MB 20MB Driver domain
Dom1
13/21
* Driver domain and Dom1 use Ramfs as a root file system.
SW Laboratories, CTO, Samsung Electronics
Performance (2/2) Network Test: Netperf BMT Due to a problem with DMA of the HW, performance is degraded further.
TCP_STREAM Native Linux
BE in Dom0
BE in DomD
10 9
8.86
* Native Linux: network driver in native Linux * BE in Dom0: Backend driver in Dom0 * BE in DomD: Backend driver in drive domain * RH: Remote Host
8.26
8
M b its / s e c
7
6.31
6 5 4 3 2 1 0 RH -> Target * TCP_STREAM: Measuring a bulk data transfer throughput
SW Laboratories, CTO, Samsung Electronics
14/21
Future Work Performance improvement of driver domain separation Minimal OS kernel for driver domain State migration
15/21 SW Laboratories, CTO, Samsung Electronics
Thank you for attention
16/21 SW Laboratories, CTO, Samsung Electronics
Appendix
Access Control Module (1/2) Supporting 5 access control models Type Enforcement ¾ A classical access control model which can be enforced for comprehensive system resources protection ¾ Physical/virtual resources access control Proprietary ¾ Protecting a mobile device from resource drain attacks (e.g., CPU, memory, battery) Bell LaPadula ¾ Confidentiality model ¾ Virtual resources access control where there are many domains (Good for controlling information flow with security level) Biba ¾ Integrity model ¾ Virtual resources access control where there are many domains (Good for controlling information flow with security level) Chinese Wall ¾ Preventing simultaneous execution of multiple domains where the domains have different interests (i.e., assigned to conflict set) 18/21 SW Laboratories, CTO, Samsung Electronics
Access Control Module (2/2) GUI-based policy manager Edits XML-based access control policies Sets new access control policies dynamically
Example of the XML-based TE policy SW Laboratories, CTO, Samsung Electronics
19/21
Secure SW Installation Basic assumptions about software on the secure domain A small set of software (not much) can be installed by only trusted parties (i.e., manufacturer or service providers verified by the manufacturer) The trusted parties must rigorously test the software based on advanced quality assurance methodology during the development phase
Secure SW installer installs only software digitally signed by a manufacturer Access control at the secure domain (Dom0) allows only authentic secure SW installer to create executable files on the domain Even in case a device owner downloads or creates files on the secure domain, they cannot be executed
20/21 SW Laboratories, CTO, Samsung Electronics
Demonstration Scenario Connecting to a phishing site
Alice connects to a phishing server with her mobile phone after receiving an email fraudulently saying launch of UCC services from her favorite web site She downloads and installs malware masqueraded as genuine SW from that site
With a conventional single OS-based mobile phone
video2
Malware corrupts kernel and sends her sensitive information to an attacker while she is using the Internet banking service
With a secure Xen-based mobile phone (with secure domain and normal domain)
video3
Even in case malware corrupts kernel of the normal domain, there is no information leakage or availability threat owing to domain separation and mandatory access control Secure SW installer installs Gifviewer signed by a manufacturer successfully but fails to install Pacman whose digital signature is invalid ¾ Assumption: communication channel between the secure SW installer and manufacturer site which provides downloadable SW is encrypted
21/21 SW Laboratories, CTO, Samsung Electronics
![ARM Security Technology Building a Secure System ... - ARM Infocenter [PDF]](https://m.moam.info/img/260x300/arm-security-technology-building-a-secure-system-a_64800abc098a9e10748b45b1.jpg)
