Ross Lagerwall

UEFI is a replacement for the BIOS. It supports Secure Boot which is signature verification of bootloaders and OS kernels which helps prevent attacks where malware injects itself into the bootloader or kernel so that it can be loaded during startup. Despite the poor reputation that Secure Boot has in the free software community (mostly due to non-technical reasons), this would be useful to have for VMs running on Xen. It is also required for features in guests such as Windows Credential Guard. This talk describes how Secure Boot support has been added to Xen.

Xen has long had support for running guests booted with UEFI using a build of edk2/Tianocore built for VMs called OVMF.

Systems that use UEFI boot have a small amount of NVRAM that stores variables critical for booting the system. Secure Boot is built upon the concepts of authenticated variables and a set of keys. Authenticated variables require updates to be signed by particular keys. These keys themselves are stored in authenticated variables.

Verifying updates to authenticated variables needs to be performed in a way that cannot be tampered with by the guest which may have been infected by malware. There are a few ways of dealing with this. The talk will look at the approach taken by bare metal, KVM, and finally how we have implemented it for Xen. This is done by introducing a new component called varstored which runs outside of the context of the guest. It acts as an interface to the guest's NVRAM and verifies updates to it. Actual storage of the NVRAM is delegated to a number of backends to support different uses cases. For example, for a single host it could store the NVRAM in a simple file. For a pool of hosts it could store the NVRAM in database server accessible poolwide.

Live patching -- the process of updating software while it is running -- has become a popular topic of late, with several companies offering services providing live patching for Linux culminating with an implementation being contributed to Linux. While Xen supports live migration of VMs which mitigates the need for live patching, there are still some reasons why live patching is useful. For example, to minimize downtime, when running applications with low latency requirements, and when using PCI passthrough.

This talk reviews the state of live patching for Xen. A live patching implementation has recently been contributed to Xen so we will look at the design and implementation in detail, noting how and why it differs from live patching for Linux. We will look at some of the ways that live patches can be created and the pitfalls to watch out for when doing so. There will also be a status report of ongoing and future work for live patching for Xen. Finally, the talk will show a demo of live patching in action by building a live patch for a known security issue and applying it to a vulnerable system.

Xen LivePatch is a new tech preview feature in Xen 4.7 for live patching the hypervisor. It is the result of collaboration between several members in the community guided by the existing live patching efforts for Linux. We will talk about this and how Xen's requirements differ from Linux.

The core idea of Xen LivePatch is to insert a "trampoline" in each buggy function with a jump to a replacement function. This is simple in principle, but there are a number of complexities which make it interesting to look at.

Live patches can be built by hand, by compiling the replacement functions in a separate source file. This is a manual process and can also be unreliable due to the nature of compiler optimizations. So we repurposed kpatch's live patch creation tool for Xen. This computes a binary difference of the output binaries before and after a source patch is applied. This simplifies the process of creating live patches and overcomes issues with compiler optimizations but is still not without difficulties. We look at the process of creating live patches and why it is hard.