VMM Sandbox

The VMM Sandbox provides a disposable virtual harness for everyday operations, including web surfing and email checking and adds another level of protection to the integrity of the system.

This leads to a set of requirements that must be satisfied for the sandbox to be usable:

1. Support for prevalent OSes, namely M$ Windows
2. Stability
1. Users will be launching a new VM and closing it like they would a normal application
3. Performance
1. Users will expect the same response time and behavior as they would for a normal application
2. Flash cloning and lightweight VM communication scheme
4. Flexibility
1. Support file/data injection
5. User-friendly interface
1. Seamless integration with the existing applications

Collaboration

I work closely with Orathai (Kob) Sukwong and Prof. Hyong Kim in building the first application of the VMM sandbox environment – an email filtering system – using Kob’s novel malware detection algorithm.

Kob and I are pursuing this as a class project for 15-712: Advanced and Distributed Operating Systems.

To-Do

• Flash Cloning
• Stabilize the current Potemkin patch
• Modify flash cloning script to support file injection
• Devise a way to mount QCOW/DSCOW copy-on-write (CoW) images on Linux
• Lightweight VM Communication Scheme
• Support fully virtualized Windows guests
• Remove any sockets-related overhead
• Set up shared memory between guest domains for communication and data transfers

Publications

• Orathai Sukwong, Yongjun Jeon, James C. Hoe, Hyong S. Kim. (2007). “BEEFS: Behavior-based Email Filtering System.” Submitted for publication in 5th USENIX Symposium on Networked Systems Design & Implementation (NSDI ‘08).

Related Works

1. Flash Cloning
1. Potemkin Virtual Honeyfarm

i. Original Potemkin patch supports paravirtualized Xen Linux guest domains only

ii. A newer patch supports fully virtualized Windows guest domains but is unstable

iii. Communication via somewhat inefficient Xen virtual network

2. Lightweight VM Communication Scheme
1. XenSocket – Interdomain Transport for VMs – Presentation, Technical report

i. Linux kernel module

ii. Uses shared memory, bypasses TCP/IP stack

iii. Performance

1. XenSocket – 6535Mb/s
Unix Domain Socket – 4907Mb/s
TCP (DomU to DomU) – 141Mb/s

2. XWay – Lightweight Communication Between Domains in a Single Machine – Presentation

i. Linux kernel module

ii. Uses shared memory, bypasses TCP/IP stack

iii. Improvement over XenSocket

1. Maintains both TCP and XWay sessions

a. TCP sessions not used in data transfers

2. Bidirectional socket communication

a. Better for migration

3. Performance

a. XWay – 10000+Mb/s
TCP – 13Mb/s