UBC Department of Computer Science
201-2366 Main Mall
Vancouver BC
V6T 1Z4
Canada
|
|
UBC Department of Computer Science 201-2366 Main Mall Vancouver BC V6T 1Z4 Canada |
I am a Ph.D. candidate in the Department of Computer Science at the University of British Columbia. I am a member of the Networks, Systems, and Security (NSS) Lab under the careful supervision of Dr. William Aiello and Dr. Andrew Warfield.
Many critical services are necessarily long-running. However, this creates a large temporal surface that is an alluring target for attackers, both in terms of the increased opportunity to find an exploit and the length of time a service is owned once exploited. While in some instances it may be possible to perform periodic restarts to reduce the window of exploitation and return a service to its fresh, unexploited operational status, this carries with it a high cost. The more often it is restarted, the larger the unavailability due to reinitialisation of the service. Furthermore, it must recover its persistent state, which is not always possible.
In order to protect these services, we propose a form of virtual machine disaggregation which partitions a service into two parts: code (logic) and state (data). Each lives in its own virtual machine, with communication performed over a narrow, well defined interface on which policy can be externally enforced to ensure correctness. This separation enables a service to be continually restarted by rolling back only the code virtual machine to a snapshotted known good state, which can be measured and attested. This prevents exploits from persisting while still maintaining good performance.
Thesis: Eliminating the Long-Running Process: Separating Code and State
This project aims to implement a viable deterministic replay mechanism for the Xen VMM. The initial target is single CPU HVM guests, but the ultimate goal is to support multi-core replay.
In deterministic replay, the non-deterministic events (rdtsc, network packets, interrupts, etc.) are recorded along with the "time" they occurred. This log can then be used to replay the execution in the exact way it originally happened. This can be a powerful tool for debugging, security, execution mining, etc.
Slides: DR_Slides.pdf
Report: DR_Report.pdf
This project aims to export an generic "memory event" interface for the Xen VMM. By a "memory event" we mean any access to memory (read, write, execute).
The goal of this project is to provide the ability for multiple clients to register with Xen to receive sub-page granularity notifications of memory events. Beyond just receiving notification, the client can register to have the VCPU causing the event to be paused (synchronous mode), the entire VM to be paused (synchronous all mode), or to have the VM execute as normal (asynchronous mode).
The memory event interface will allow any number of tools to be built for Xen. This includes things from memory snapshotting and page swapping (see projects below, which are currently not built on this interface, but will be ported to it when it is completed) to introspection to kernel integrity protection.
There is some initial support for this project in Xen 4.0, available through the Xen source website.
In some cases, it may be desirable to over-commit resources for virtual machines. For example, There are usually more virtual CPUs than physical CPUs. In this project, I developed a memory page swapper for VMs running on Xen. This allows the physical memory to be over-committed, which is particularly useful if there are a lot of idle VMs on a host.
This project has been added into the Xen 4.0 release and is available through the Xen source website.
There has been an emergence of dependability- and security-related applications which take advantage of the isolation provided by VMMs. These applications can verify properties about a running virtual machine from an external context, away from malicious code.
Without the ability to snapshot a VM, however, these tools must be able to cope with constantly changing memory contents, aggravating the process. For example, a clever virus may move itself around in memory so as to avoid detection by an external virus scanner.
A version of copy-on-write snapshots was released for xen-unstable revision 19553 (April 2009).
A re-write of XenStore done in OCaml.
This version of XenStore is intended to address some of the short-comings of XenStore while providing code that is cleaner and more verifiable. The code base is almost entirely OCaml, with only a handful of C functions, where required. The size of the code was shrunk to about a quarter of the original size (~10,000 lines to ~2,500 lines).
One of the more notable changes is an improvement to the transaction system. Transactions now have optimistic concurrency control and copy-on-write. Previously, for each transaction the entire store would be duplicated. Upon commit, the duplicated store would over-write the current one. Only one active transaction could commit at a time. This can be exploited to create a denial-of-service attack on XenStore. A version of this attack is included in the tarball of the OCaml XenStore.