1. Hardware-Assisted Isolated Computing Environments
Instructor: Kun Sun, Ph.D.

2. Outline Introduction Related Work Our Work on Hardware-assisted ICE
x86 platform
SecureSwitch: OS level isolation [NDSS12]
ARM platform
TrustICE: Flexible ICE [under submission]
Summary

3. Why Isolated Computing Environment?
Bring your own device (BYOD)
Risk of data breaches
Require an ICE to separate sensitive code and data
Suspicious code or data
Trojan, e.g., BitCoinMiner, Keylogger
Run the code in an ICE to protect the host environment
Malware analysis
Rootkits compromises OS
Protect the analysis tools in an ICE

4. Lampson Red/Green System Model
Red/Green system: Policy + Isolation + Accountability +Freedom
* Butler Lampson, Accountability and Freedom Slides, Microsoft, Sept.,2005

5. Outline Introduction Related Work Our Work on Hardware-assisted ICE
x86 platform
SecureSwitch: OS level isolation [NDSS12]
ARM platform
TrustICE: Flexible ICE [under submission]
Summary

6. Software-based ICE Solutions
VMM-based
OS-based
Browser-based
Isolation Level
OS level
User/Process level
Applet level
Example
Xen, VMware,
QEMU, UML
FreeBSD Jail,
Linux OpenVZ, Solaris Container
Adobe Flash,
Java applets,
Silverlight
Security concerns
VMM vulnerabilities*,
Covert Channel
VMM vulnerabilities,
OS vulnerabilities
OS vulnerabilities,
Browser vulnerabilities
* From 1999 to 2009, 373 vulnerabilities affecting virtualization solutions “IBM X-Force 2010 Mid-year trend and risk report”

7. Hardware-based ICE Solutions
Multiple
Computers
Multi-boot
VT-x / SVM
(DRTM)
SMM
Isolation Level
Whole physical computer
OS level;
Instruction level;
Examples
Bootloader:
LILO, Grub
Flicker [2],
TrustVisor [3]
SICE [5],
HyperCheck [6]
Problems
Cost, inflexible
Long switching time
Software compatibility

8. Outline Introduction Related Work Our Work on Hardware-assisted ICE
x86 platform
SecureSwitch: OS level isolation [NDSS12]
ARM platform
TrustICE: Flexible ICE [under submission]
Summary

9. SecureSwitch Architecture
BIOS-assistant OS Level Isolation
no data leakage between two OS environments
without using any mutable software layer (e.g., hypervisor)
no changes of the OS source code
fast switching time, around 6 seconds
Trusted Computing Base (TCB) only contains the BIOS.

10. BIOS, UEFI, and Coreboot Basic Input/Output System (BIOS)
Initializing hardware components.
Stored in non-volatile ROM chips.
Unified Extensible Firmware Interface (UEFI)
A new software interface between OS and firmware.
Partially open source
Coreboot (formerly as LinuxBIOS)
Similar functionality as UEFI
Open source

11. ACPI Sleeping States
Advanced Configuration and Power Interface (ACPI)
OS-directed configuration; Power/thermal management
Global System States
G0 --- Working (System Operational)
G1---Sleeping (CPU stopped)
G2 ---Soft Off
G3 ---Mechanical off (Physical off switch)
Sleeping States in G1: S0 – S5
S3: also called Standby, Suspend to RAM
DRAM still maintained
S4: also called Hibernation or Suspend to Disk
DRAM not maintained
Device Power States: D0 – D3
D0 - Fully-On
D3 -- Power off to device

12. Attack Model Assumption Attacks from the untrusted OS Out of the scope
BIOS and option ROM on devices can be trusted.
No physical access to the protected machine
Attacks from the untrusted OS
Spoofing Trusted OS attacks: faking trusted OS
Data exfiltration attacks: stealing sensitive data
Cache-based side channel attacks: extracting sensitive data
Out of the scope
Denial of Service attacks
Network attacks on trusted OS

13. Secure Switching State Machine

14. Trusted Path
Protect against Spoofing trusted OS attacks by assuring users that they are working with the OS they intend to use.
Protecting system variables
OS_Flag: records which OS should be woken next
Where to save it?
Untrusted OS should be truly suspended.
hardware controlled power LED lights up when system is powered on, and blinks in the sleep mode.
BIOS should be entered.
Press the power button.
OS_Flag: physical jumper, e.g., Parallel port connector

15. Secure Switching Process

16. System Isolation CPU Isolation: two OSes never run concurrently.
Memory Isolation: physical-level isolation
Hard disk isolation: encrypted hard disk, RAM disk
Other I/O isolation: clean the buffers/states in devices.
CPU
Memory
Hard Disk
VGA
NIC
ACPI S3 
BIOS

17. DIMM Mask and DQS Setting
Memory Isolation
A motherboard may have more than one dual in-line memory module (DIMM) slot.
DIMM Mask and DQS Setting
BIOS uses “DIMM_MASK”variable to control which DIMMs to be enabled.
BIOS sets “data strobes”(DQS) parameters to enable DDR RAM memory access.

18. Memory Isolation Physical-level memory isolation ensured by BIOS
Two OS environments run in separate DIMMS.
BIOS only enables one DIMM for each OS.
Two DQS settings for two OSes
“DIMM_MASK” controlled by the physical jumper.
System software, except the BIOS, cannot initialize or enable DIMMs after the system boots up
Transient state of DQS setting
If “DIMM_MASK”has conflicts with DQS setting, system crashes

19. Hard Drive Isolation Hard disk encryption RAM disk
Two hard disks, one for each OS
Disk lock in ATA specification
Need TPM to save the encryption key
RAM disk
For browser-based application, save a small amount of temporary data in the RAM

20. Prototype Hardware Motherboard: ASUS M2V-MX_SE
CPU: AMD Sempron 64 LE-1300
DDR2: Kingston HyperX 1GB
HDD: Seagate 500GB
Software
BIOS: Coreboot + SeaBIOS
Trusted OS: Linux (Centos 5.5)
Untrusted OS: Windows XP

21. Performance Analysis

22. Linux Suspend Time Breakdown
User Space : ms
Kernel Space: ms

23. Linux Wakeup Time Breakdown
Kernel Space: ms
User Space: ms

24. Outline Introduction Related Work Our Work on Hardware-assisted ICE
x86 platform
SecureSwitch: OS level isolation [NDSS12]
ARM platform
TrustICE: Flexible ICE [under submission]
Summary

25. Traditional Solutions
ARM TrustZone
Two isolated domains
Secure/un-secure CPU States
Virtual MMU/Secure Memory
TrustZone-Aware interrupt controller
Traditional solutions
Rich OS and un-secure apps in normal domain
Secure OS and secure apps in secure domain
Limitations
Trusted Computing Base (TCB) is large
No flexible
No isolation between secure Apps.
No protection on non-secure Apps.
Traditional Solutions

26. TrustICE: Flexible ICEs
Basic Idea: Create ICEs in normal domain, instead of secure domain
A Trusted Domain Controller (TDC) enforces the isolation and secures the switching
Benefits:
Small TCB: TDC + Secure boot
Multiple ICEs
Self-contained code
Microkenel with necessary modules
full-featured OS
Flexible
Easy to deploy third-party software
Vendor Apps still in secure domain

27. Outline Introduction Related Work Our Work on Hardware-assisted ICE
x86 platform
SecureSwitch: OS level isolation [NDSS12]
ARM platform
TrustICE: Flexible ICE [under submission]
Summary

28. Our Work on Hardware-assisted ICE
Summary
Our Work on Hardware-assisted ICE
SecureSwitch: BIOS-based ICE on x86 platform
OS level isolation with small TCB
Small switching time
TrustICE: TrustZone-based ICE on arm platform
Flexible multiple ICEs
Small TCB

29. References
P. Barham, B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, R. Neugebauer, I. Pratt, and A. Warfield. Xen and the art of virtualization. In SOSP ’03: Proceedings of the nineteenth ACM symposium on Operating systems principles, pages 164–177, New York, NY, USA, ACM Press.
J. McCune, B. Parno, A. Perrig, M. Reiter, and H. Isozaki. Flicker: An execution infrastructure for TCB minimization. In Proceedings of the 3rd ACM SIGOPS/EuroSys European Conference on Computer Systems 2008, pages 315–328. ACM, 2008.
J. M. McCune, Y. Li, N. Qu, Z. Zhou, A. Datta, V. Gligor, and A. Perrig. TrustVisor: Efficient TCB reduction and attestation. In Proceedings of the IEEE Symposium on Security and Privacy, 2010.
Amit Vasudevan, Bryan Parno, Ning Qu, Virgil D. Gligor, Adrian Perrig. Lockdown: Towards a Safe and Practical Architecture for Security Applications on Commodity Platforms. TRUST 2012.
Ahmed Azab, Peng Ning, Xiaolan Zhang, SICE: A Hardware-Level Strongly Isolated Computing Environment for x86 Multi-core Platforms, in Proceedings of 18th ACM Conference on Computer and Communications Security (CCS11), October 2011.
Fengwei Zhang, Jiang Wang, Kun Sun, Angelos Stavrou, "HyperCheck: A Hardware-Assisted Integrity Monitor," IEEE Transactions on Dependable and Secure Computing, 17 Dec IEEE computer Society Digital Library.
Kun Sun, Jiang Wang, Fengwei Zhang, and Angelos Stavrou, SecureSwitch: BIOS-Assisted Isolation and Switch between Trusted and Untrusted Commodity OSes. In the Proceedings of the 19th Annual Network & Distributed System Security Symposium (NDSS), San Diego, California, 5-8 February 2012.
Y. Fu and Z. Lin. Space Traveling across VM: Automatically bridging the semantic gap in virtual machine introspection via online kernel data redirection. In Proceedings of the 33rd IEEE Symposium on Security and Privacy, 2012.
X. Jiang, X. Wang, and D. Xu. Stealthy malware detection through vmm-based out-of-the-box semantic view reconstruction. In Proceedings of the 14th ACM conference on CCS, 2007.
T. Leek, M. Zhivich, J. Gin, and W. Lee. Virtuoso: Narrowing the semantic gap in virtual machine introspection. In Proceedings of the 32nd IEEE Symposium on Security and Privacy, 2011.