The Xen Security team recently disclosed a vulnerability, Xen Security Advisory 7 (CVE-2012-0217), which would allow guest administrators to escalate to hypervisor-level privileges. The impact is much wider than Xen; many other operating systems seem to have the same vulnerability, including NetBSD, FreeBSD, some versions of Microsoft Windows (including Windows 7), and possibly Apple OSX.
So what was the vulnerability? It has to do with a subtle difference in the way in which Intel processors implement error handling in their version of AMDâ€™s SYSRET instruction. The SYSRET instruction is part of the x86-64 standard defined by AMD. If an operating system is written according to AMDâ€™s spec, but run on Intel hardware, the difference in implementation can be exploited by an attacker to write to arbitrary addresses in the operating systemâ€™s memory. This blog will explore the technical details of the vulnerability.
Xen 4.2 will contain two new scheduling parameters for the credit1 scheduler which significantly increase its confurability and performance for cloud-based workloads:
ratelimit_us. This blog post describes what they do, and how to configure them for best performance.
Linux 2.6.37, released just few days ago, is the first upstream Linux kernel that can boot on Xen as Dom0… Just enabling CONFIG_XEN in the kernel config of a 2.6.37 Linux kernel allows the very same Linux kernel image to boot on native, on Xen as Dom0, on Xen as normal PV guest and on Xen as PV on HVM guest!
I’m working on now is an automated test framework, which will measure the effectivenes of the scheduler. This is actually a bit trickier than one might expect. You can’t simply run a workload by itself and measure its performance; for that use case, you don’t actually need a scheduler. You need to run each workload in competition with an array of other workloads, and at various levels of CPU “pressure”.