This covers Meltdown and Spectre Mitigation on Xen 6.5 and Xen 7.x. By now, you have probably heard about Meltdown and Spectre vulnerabilities affecting Intel processors on Linux, OS X, and Windows operating systems. Most cloud providers and Linux distribution companies have started pushing patches for the same.
How does Meltdown affect VMs and Virtualization Infrastructure?
You can read more on this by visiting https://spectreattack.com/. To summarize, Meltdown breaks all security assumptions given by the CPU’s memory isolation capabilities which allows an unprivileged process to read data mapped in the kernel address space, including the entire physical memory on Linux and OS X, and a large fraction of the physical memory on Windows.
This may include a physical memory of other processes, the kernel, and in case of kernel-sharing sandbox solutions (e.g., Docker, LXC) or Xen in paravirtualization mode, the memory of the kernel (or hypervisor), and other co-located instances.
On a cloud platform where many Virtual Machines co-exist on the same hypervisor ( physical server), a compromised virtual machine could be used to peer deeply into the secrets of its neighbors.
How Meltdown affect Xen?
Meltdown and Spectre affect your Virtualization Infrastructure if you’re in any of the following lists:
- Using Intel CPUs
- Running 64-bit PV ( Paravirtualized VMs) – Note that HVM/PVHVM VMs are not affected.
- Offering/Running VMs in the Cloud / VMs with public internet access ( Untrusted VMs)
It has been reported that 64-bit Virtual Machines are the only ones affected since they share the same address space with the Hypervisor ( but with different privileges). Since Hardware Virtual Machine ( HVM) doesn’t share address space with the hypervisor in any way, they’ aren’t affected.
Mitigating Meltdown on Xen
The recommended method of mitigating Meltdown on Xen is by migrating Paravirtualized VMs to Hardware Virtual Machine. In this guide, I’ll show you how this is done.
Get a list of affected VMs.
First, you’ll need to identify Paravirtualized VMs, use these commands on Xen CLI:
# xe vm-list HVM-boot-policy= is-control-domain=false
This will list all VMs with PV, to further filter by UUID, use the command:
# xe vm-list HVM-boot-policy= is-control-domain=false | \ egrep '[0-9a-f]8-[0-9a-f]4-[0-9a-f]4-[0-9a-f]4-[0-9a-f]12' -o
You can, of course, pipe the output of above command to a file for using later:
# export pv_guests_file="./pv_guests.txt" # xe vm-list HVM-boot-policy= is-control-domain=false | \ egrep '[0-9a-f]8-[0-9a-f]4-[0-9a-f]4-[0-9a-f]4-[0-9a-f]12' -o > $pv_guests_file
Convert PV Guest machines to HVM
Now the output will be saved to a file ./pv_guests.txt. With the list of virtual machines stored with UUIDs only, we can write a simple while loop in bash to convert all VMs listed from PV to HVM:
cat $pv_guests_file | while read VM_UUID; do xe vm-param-set HVM-boot-policy="BIOS order" uuid=$VM_UUID done
The command used to convert PV to HVM in Xen is xe vm-param-set HVM-boot-policy=”BIOS order” uuid=
Meltdown and Spectre PV to HVM Xen patching Script
To recap this, let’s put it in a shell script which can be easily copied and pasted:
# vim pv_to_hvm.sh
#!/bin/bash pv_guests_file="./pv_guests.txt" # Convert PV Guest VMs to HVM get_pv_guests () \ egrep '[0-9a-f]8-[0-9a-f]4-[0-9a-f]4-[0-9a-f]4-[0-9a-f]12' -o > $pv_guests_file # Convert PV Guests to HVM convert_pv_hvm () cat $pv_guests_file # Run main get_pv_guests convert_pv_hvm
Make the script executable and run it.
# chmod +x pv_to_hvm.sh # ./pv_to_hvm.sh
After successfully migrating VMs from PV to HVM on Xen, you should be safe from Meltdown on Xen. The next action to take is upgrading all VMs to patch them as well. You can also take a look at