Stealthy monitoring with Xen altp2m

One of the core features that differentiates Xen from other open-source hypervisors is its native support for stealthy and secure monitoring of guest internals (aka. virtual machine introspection [1]). In Xen 4.6 which was was released last autumn several new features have been introduced that make this subsystem better; a cleaned-up, optimized API and ARM support being just some of the biggest items on this list. As part of this release of Xen, a new and unique feature was also successfully added by a team from Intel that make stealthy monitoring even better on Xen: altp2m. In this blog entry we will take a look at what it’s all about.

p2mIn Xen’s terminology, p2m stands for the memory management layer that handles the translation from guest physical memory to machine physical. This translation is critical for safely partitioning the real memory of the machine between Xen and the various VMs running as to ensure a VM can’t access the memory of another without permission. There are several implementations of this mechanism, including one with hardware support via Intel Extended Page Tables (EPT) available to HVM guests and PVH . In Xen’s terminology, this is called Hardware Assisted Paging (hap). In this implementation the hypervisor maintains a second pagetable, similar to the one in 64-bit operating systems use, dedicated to running the p2m translation. All open-source hypervisors that use this hardware assisted paging method use a single EPT per virtual machine to handle this translation, as most of the time the memory of the guest is assigned at VM creation and doesn’t change much afterwards.

altp2mXen altp2m is the first implementation which changes this setup by allowing Xen to create more then one EPT for each guest. Interestingly, the Intel hardware has been capable of maintaining up to 512 EPT pointers from the VMCS since the Haswell generation of CPUs. However, no hypervisor made use of this capability until now. This changed in Xen 4.6, where we can now create of up to 10 EPTs per guest. The primary reason for this feature is to use it with the #VE and VMFUNC extensions.

It can also be used by external monitoring applications via the Xen vm_event system.

Why alt2pm is a game-changer

Alt2pm is a game-changer for applications performing purely external monitoring is because it simplifies the monitoring process of multi-vCPU guests. The EPT layer has been successfully used in stealthy monitoring applications to track the memory accesses made by the VM from a safe vantage point by restricting the type of access the VM may perform on various memory pages. Since EPT permission violations trap into the hypervisor, the VM would receive no indication that anything out of the ordinary has happened. While the method allowed for stealthy tracing of R/W/X memory accesses of the guest, the memory permission needs to be relaxed in order to allow the guest to continue execution. When a single EPT is shared across multiple running vCPUs, relaxing the permissions to allow one vCPU to continue may inadvertently allow another one to perform the memory access we would otherwise want to track. While under normal circumstances such race-condition may rarely occur, malicious code could easily use this to hide some of its actions from a monitoring application.

Solutions to this problem exist already. For example we can pause all vCPUs while the one violating the access is single-stepped. This approach however introduces heavy overhead just to avoid a race-condition that may rarely occur in practice. Alternatively, one could emulate the instruction that was violating the EPT permission without relaxing the EPT access permissions, as Xen’s built-in emulator doesn’t use EPT to access the guest memory. This solution, while supported in Xen, is not particularly ideal either as Xen’s emulator is incomplete and is known to have issues that can lead to guest instability [2]. Furthermore, over the years emulation has been a hotbed of various security issues in many hypervisors (including Xen [3]), thus building security tools based on emulation is simply asking for trouble. It can be handy but should be used only when no other option is available.

Xen’s altp2m system changes this problem quite significantly. By having multiple EPTs we can have differing access permissions defined in each table, which can be easily swapped around by changing the active EPT index in the VMCS. When the guest makes a memory access that is monitored, instead of having to relax the access permission, Xen can simply switch to an EPT (called a view) that allows the operation to continue. Afterwards the permissive view can be switched back to the restricted view to continue monitoring. Since each vCPU has its own VMCS where this switching is performed, this monitoring can be performed specific to each vCPU, without having to pause any of the other ones, or having to emulate the access. All without the guest noticing any of this switching at all. A truly simple and elegant solution.

Other introspection methods for stealthy monitoring

EPT based monitoring is not the only introspecting technique used for stealthy monitoring. For example, the Xen based DRAKVUF Dynamic Malware Analysis [4] uses it in combination with an additional technique to maximum effect. The main motivation for that is because EPT based monitoring is known to introduce significant overhead, even with altp2m: the granularity of the monitoring is that of a memory page (4KB). For example, if the monitoring application is really just interested in when a function-entry point is called, EPT based monitoring creates a lot of “false” events when that page is accessed for the rest of the function’s code.

This can be avoided by enabling the trapping of debug instructions into the hypervisor, a built-in feature of Intel CPUs that Xen exposes to third-party applications. This method is used in DRAKVUF, which writes breakpoint instructions into the guests’ memory at code-locations of interest. Since we will only get an event for precisely the code-location we are interested in this method effectively reduces the overhead. However, the trade-off is that unlike EPT permissions the breakpoints are now visible to the guest. Thus, to hide the presence of the breakpoints from the guest, these pages need to get further protected by restricting the pages to be execute-only in the EPT. This allows DRAKVUF to remove the breakpoints before in-guest code-integrity checking mechanisms (like Windows Patchguard) can access the page. While with altp2m the EPT permissions can be safely used with multi-vCPU systems, using breakpoints similarly presents a race-condition: the breakpoint hit by one vCPU has to be removed to allow the guest to execute the instruction that was originally overwritten, potentially allowing another vCPU to do so as well without notice.

altp2m-shadowFortunately, altp2m has another neat feature that can be used to solve this problem. Beside allowing for changing the memory permissions in the different altp2m views, it also allows to change the mapping itself! The same guest physical memory can be setup to be backed by different pages in the different views. With this feature we can really think of guest physical memory as “virtual”: where it is mapped really depends on which view the vCPU is running on. Using this feature allows us to hide the presence of the breakpoints in a brand new way. To do this, first we create a complete shadow copy of the memory page where a breakpoint is going to be written and only write the breakpoint into this shadow copy. Now, using altp2m, we setup a view where the guest physical memory of the page gets mapped to our shadow copy. The guest continues to access its physical memory as before, but underneath it is now using the trapped shadow copy. When the breakpoint is hit, or if something is trying to scan the code, we simply switch the view to the unaltered view for the duration of a single-step, then switch back to the trapped view. This allows us to hide the presence of the breakpoints specific to each vCPU! All without having pause any of the other vCPUs or having to emulate. The first open-source implementation of this tracing has been already merged into the DRAKVUF Malware Analysis System and is available as a reference implementation for those interested in more details.


As we can see, Xen continues to be on the forefront of advancing the development of virtualization based security application and allowing third-party tools to create some very exotic setups. This flexibility is what’s so great about Xen and why it will continue to be a trend-setter for the foreseeable future


[1] Virtual Machine Introspection
[2] xen-devel@: Failed vm entry with heavy use of emulator
[3] Hardening Hypervisors Against VENOM-Style Attacks
[4] DRAKVUF Malware Analysis System (
[5] Stealthy, Hypervisor-based Malware Analysis (Presentation)

Xen Project 4.5.3 Maintenance Release is Available

I am pleased to announce the release of Xen 4.5.3. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.5 stable series update to this point release.

Xen 4.5.3 is available immediately from its git repository:;a=shortlog;h=refs/heads/stable-4.5
    (tag RELEASE-4.5.3)

or from the Xen Project download page at

This release contains many bug fixes and improvements. For a complete list of changes in this release, please check the lists of changes on the download page.

We recommend all users of the 4.5 stable series to update to this latest point release.

Call For Participation for the Xen Project Developer Summit in Toronto


Now Accepting Submissions Through May 6

We’re excited to announce the call for speaking proposals for Xen Project Developer Summit 2016, which will be held in Toronto, Canada, August 25-26, 2016. The Xen Project Developer Summit brings together the Xen Project’s community of developers and power users for their annual developer conference. The summit will be co-located with a number of other events, including LinuxCon, ContainerCon, KVM Forum and Linux Security Summit.

To get a sense of past accepted submissions, check out last years presentations. Accepted speakers will be notified by May 27th. The schedule will be announced on June 3rd.

Birds of a Feather Sessions & Discussion Groups

This year, we will again have space for Birds of a Feather Sessions & Discussion Groups, which are in-depth interactive discussions that allow for collaboration between Xen Project developers and community members. We will publish how you can request a BoF closer to the event. In the meantime, here are the ground rules BoFs:

  • Each BoF host will get 3-5 minutes (depending on the number of BoFs on the day) to pitch your BoF to the entire audience. Slides are not allowed.
  • After we publish the Xen Project Developer schedule, community members that have registered for the summit can submit a request to host a BoF (specifying a couple of slots in preference order)
  • BoFs are small discussion groups, not presentations. You are expected to take notes (or nominate an attendee to do so) and post discussion notes on one of our mailing lists after the summit.

Developer Meeting

I am also pleased to announce that we will also be hosting a 1/2 day Xen Project Developer Meeting the day before the Xen Project Developer Summit (space is limited). The event is open to all members of the Developer Community. More details will follow soon.

Where to stay at the summit

Discounted hotels are listed at the event website at the price of CAD $209.00 per night. Reservations have to be made by July 29th. We are sharing a room block with other Linux Foundation events, so please book early.

Xen Project 4.6.1 Maintenance Release is Available

I am pleased to announce the release of Xen 4.6.1. Xen Project Maintenance releases are released in line with our Maintenance Release Policy: this means we make one new point release per stable series every 4 months, which include back-ports of bug-fixes and security issues.

I am pleased to announce the release of Xen 4.6.1. This is available immediately from its git repository;a=shortlog;h=refs/heads/stable-4.6
(tag RELEASE-4.6.1)

or from the XenProject download page
(where a list of changes can also be found).

Note that, as also mentioned on the web page above, due to two oversights the fixes for both XSA-155 and XSA-162 have only been partially applied to this release. (Note further that the same applies to the recently announced 4.4.4 release.)

We recommend all users of the 4.6 stable series to update to this first point release.

Additional note published Feb 17th: We detected the missing patches before the official release, but towards the end of the release process. We then had a discussion whether to make a new release which would have forced us to skip a release number (aka move from 4.6.0 to or 4.6.2) or release 4.6.1 with two security patches which were incomplete, and document what is missing. At this point, we had to decide whether to re-tag (and thus re-number the release) or whether to document any issues. A similar issue happened in 2013, when we released Xen instead of Xen 4.1.6. At that time it became clear that many consumers of Xen have difficulties with a version number that does not fit into the normal version numbering pattern, which led to Xen not being widely used. We cannot re-spin a release without changing the version number if issues are discovered late during the release process. Firstly, making a release involves both extensive testing and also has a security dimension. Normally, after testing succeeds we create a signed tag in the git tree. This means that there is a secure way of accounting for where the tarball came from. We then rebuild and do additional testing, write the release notes, do some more checking and sign the tarballs. The missing patches were discovered on Thursday, before the official release on Monday, but after we created the signed tag. Signed tags cannot be removed, as they have to be tamper proof, which makes everyone more secure.

Future of Xen Project: Video Spotlight Interview with Xen Project’s Chairperson Lars Kurth

Lars Kurth had his first contact with the open source community in 1997 when he worked on various parts of the ARM toolchain. He has since become an open source enthusiasts, worked on several open source communities, and is the chairperson of the Xen Project Advisory Board. He is also the Director of the Xen Project at Citrix.

He recently sat down to discuss why Xen Project software makes sense for the cloud and where the community and technology is heading this year in this short video. Read on for more.

The Xen Project community has flourished and grown throughout the years. The latest release from the Xen Project (Hypervisor 4.6) produced the best quality and quantity of contributors from cloud providers, software vendors, hardware vendors, academic researchers and individuals.

The Xen Project entices new users to join with its high energy and inclusive nature. It periodically hosts hackathons to give developers the opportunity to meet face to face, to discuss development, coordinate, write code, and collaborate with other developers. The Project will have its next hackathon at ARM’s headquarters in Cambridge on April 18 – 19.

Since the Xen Project became a collaborative project under the Linux Foundation tutelage in 2013, the technology has been able to break into a lot of new use cases, most notably automotive and embedded — check out GlobalLogic’s use of Xen on if you haven’t read it already. These recent innovations areas have also been very beneficial to traditional Xen Project use cases. For example, Automotive real-time scheduling is not only important for this industry, but server and data centers as they relate to things like online gaming.

From it’s inception, Xen was created for cloud computing — its early work with Amazon AWS allowed the hypervisor to create a great architecture for the cloud. It has since brought on a lot of new members and contributors to help continue to address the current and future needs of cloud computing, and will continue to innovate in new market segments from automotive to Unikernels.

Xen Project 4.4.4 Maintenance Release is Available

I am pleased to announce the release of Xen 4.4.4. Xen Project Maintenance releases are released in line with our Maintenance Release Policy. We recommend that all users of the 4.4 stable series update to this point release.

Xen 4.4.4 is available immediately from its git repository:;a=shortlog;h=refs/heads/stable-4.4
    (tag RELEASE-4.4.4)

or from the Xen Project download page at

This release contains many bug fixes and improvements. For a complete list of changes in this release, please check lists of changes on the download page.

Note that this is the last Xen Project coordinated release of the 4.4 stable series. The tree will be switched to security only maintenance mode after this release.