Homework 1

E6698 Virt Tech Cloud Computing Spring 2021

DUE: Monday 2/22/2021 at 11:59pm EST

This assignment will be done using a variant of KVM, a popular type-2 hypervisor. KVM is built on the Linux kernel to reuse its existing functions to support virtualization. As a part of this assignment, you will be experimenting with KVM and gaining familiarity with the development environment and add new features to it. KVM can run on many different architectures, but the specific platform we will be targeting is the Arm CPU family.

We will use CloudLab for this assignment, which a cloud infrastructure for academic work that provides Arm servers that you can use to test and run your system. You should sign up for an account. When you sign up, be sure to choose "Join Existing Project" and fill in "VirtualCloudTech" (No space, caps V/C/T).

You should submit patches for your hypercall implementation to via email, in a manner similar to how patches are submitted to the Linux kernel mailing lists, along with a PDF report describing your implementation and evaluation results. You will then be asked to arrange a time to demo your homework assignment.


KVM, like most commodity hypervisors, is a complex piece of software. It is essential that the software be correct to ensure that it guarantees that virtual machines run in the cloud using KVM are isolated from one another and cannot gain access to each other's data. However, because the software is complex, ensuring that it does not contain vulnerabilities is problematic.

Recent work has shown that it is possible to retrofit KVM to reduce its trusted computing base to a few thousand lines of code, reducing the likelihood of vulnerabilities in its trusted computing base. This is done by decomposing KVM into two parts, an untrusted hostvisor that is deprivileged and contains most of KVM, and a trusted corevisor that runs in hypervisor mode (EL2 on Arm). This work is described in a USENIX Security paper and has been implemented using the Linux 4.18 kernel.

Your goal in this assignment will be to apply this approach to a different version of Linux/KVM and get it to work successfully. We are providing the source code for the Linux 4.18 version of the retrofitted KVM, and your job is to port those changes to a newer version of Linux. This will involve minimal changes to the corevisor, but various modifications to the hostvisor to modify KVM to use the interface provided by the corevisor, requiring you to understand the Arm implementation of KVM. To give you a sense of the changes you will need to make, we also provide the source code for a Linux 5.4 version of the retrofitted KVM for a different hardware platform; however, this implementation has not been tested to function on the CloudLab machines you will use and is only for reference.

Each student is responsible for one version of Linux. The version options are 4.19, 4.20, 5.0, 5.1, 5.2, 5.3, 5.4, 5.5, 5.6, 5.7, 5.8, 5.9, 5.10, or 5.11. You may reserve the version you choose to work on by emailing the instructor with your UNI and a ordered list of preferred versions to use; reservations will be made on a first-come, first-serve basis. It is expected that there will be different modifications required for different versions of Linux. You are welcome to use any resources for completing the assignment, and you are encouraged to work with other students in the class, but each student is responsible for his or her own assigned kernel version and you must acknowledge any help you received from anyone other than the instructional staff. For example, you are free to share code that you develop or modify with each other in completing the assignment so long as you give proper credit to the person whose code you are using.

There are two parts to this assignment. The first part is to get the retrofitted KVM working on the CloudLab m400 Arm servers. We suggest you first familarize yourself with CloudLab and KVM by getting regular KVM running on the machine, then running the 4.18 version of the retrofitted KVM. The second part is the run the benchmarks described in the Usenix Security paper to demonstrate that your implementation works, including reporting the actual performance measurements for the benchmarks. A report describing both what you had to do to make the system work on your assigned version of Linux and the performance results should be submitted, along with the kernel patches for your assigned version of Linux.