Monthly Archives: March 2015

Xen Project Hypervisor versions 4.3.4 and 4.4.2 are available

I am pleased to announce the release of Xen 4.3.4 and Xen 4.4.2. Both releases are available immediately from their git repositories and download pages (see below). We recommend to all users of the 4.3 and 4.4 stable series to update to these latest point releases.

Xen 4.3.4

This release is available immediately from its git repository at
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.3
(tag RELEASE-4.3.4) or from the XenProject download page.

Note that this is expected to be the last release of the 4.3 stable series. The tree will be switched to security only maintenance mode after this release.

This fixes the following critical vulnerabilities:

  • CVE-2014-5146, CVE-2014-5149 / XSA-97: Long latency virtual-mmu operations are not preemptible
  • CVE-2014-7154 / XSA-104: Race condition in HVMOP_track_dirty_vram
  • CVE-2014-7155 / XSA-105: Missing privilege level checks in x86 HLT, LGDT, LIDT, and LMSW emulation
  • CVE-2014-7156 / XSA-106: Missing privilege level checks in x86 emulation of software interrupts
  • CVE-2014-7188 / XSA-108: Improper MSR range used for x2APIC emulation
  • CVE-2014-8594 / XSA-109: Insufficient restrictions on certain MMU update hypercalls
  • CVE-2014-8595 / XSA-110: Missing privilege level checks in x86 emulation of far branches
  • CVE-2014-8866 / XSA-111: Excessive checking in compatibility mode hypercall argument translation
  • CVE-2014-8867 / XSA-112: Insufficient bounding of “REP MOVS” to MMIO emulated inside the hypervisor
  • CVE-2014-9030 / XSA-113: Guest effectable page reference leak in MMU_MACHPHYS_UPDATE handling
  • CVE-2014-9065, CVE-2014-9066 / XSA-114: p2m lock starvation
  • CVE-2015-0361 / XSA-116: xen crash due to use after free on hvm guest teardown
  • CVE-2015-1563 / XSA-118: arm: vgic: incorrect rate limiting of guest triggered logging
  • CVE-2015-2152 / XSA-119: HVM qemu unexpectedly enabling emulated VGA graphics backends
  • CVE-2015-2044 / XSA-121: Information leak via internal x86 system device emulation
  • CVE-2015-2045 / XSA-122: Information leak through version information hypercall
  • CVE-2015-2151 / XSA-123: Hypervisor memory corruption due to x86 emulator flaw

Additionally a bug in the fix for CVE-2014-3969 / CVE-2015-2290 / XSA-98 (which got assigned CVE-2015-2290) got addressed.

Sadly the workaround for CVE-2013-3495 / XSA-59 (Intel VT-d Interrupt Remapping engines can be evaded by native NMI interrupts) still can’t be guaranteed to cover all affected chipsets; Intel continues to be working on providing us with a complete list.

Apart from those there are many further bug fixes and improvements.

We recommend all users of the 4.3 stable series to update to this last point release.

Xen 4.4.2

This release is available immediately from its git repository at
http://xenbits.xen.org/gitweb/?p=xen.git;a=shortlog;h=refs/heads/stable-4.4
(tag RELEASE-4.4.2) or from the XenProject download page.

This fixes the following critical vulnerabilities:

  • CVE-2014-5146, CVE-2014-5149 / XSA-97: Long latency virtual-mmu operations are not preemptible
  • CVE-2014-7154 / XSA-104: Race condition in HVMOP_track_dirty_vram
  • CVE-2014-7155 / XSA-105: Missing privilege level checks in x86 HLT, LGDT, LIDT, and LMSW emulation
  • CVE-2014-7156 / XSA-106: Missing privilege level checks in x86 emulation of software interrupts
  • CVE-2014-6268 / XSA-107: Mishandling of uninitialised FIFO-based event channel control blocks
  • CVE-2014-7188 / XSA-108: Improper MSR range used for x2APIC emulation
  • CVE-2014-8594 / XSA-109: Insufficient restrictions on certain MMU update hypercalls
  • CVE-2014-8595 / XSA-110: Missing privilege level checks in x86 emulation of far branches
  • CVE-2014-8866 / XSA-111: Excessive checking in compatibility mode hypercall argument translation
  • CVE-2014-8867 / XSA-112: Insufficient bounding of “REP MOVS” to MMIO emulated inside the hypervisor
  • CVE-2014-9030 / XSA-113: Guest effectable page reference leak in MMU_MACHPHYS_UPDATE handling
  • CVE-2014-9065, CVE-2014-9066 / XSA-114: p2m lock starvation
  • CVE-2015-0361 / XSA-116: xen crash due to use after free on hvm guest teardown
  • CVE-2015-1563 / XSA-118: arm: vgic: incorrect rate limiting of guest triggered logging
  • CVE-2015-2152 / XSA-119: HVM qemu unexpectedly enabling emulated VGA graphics backends
  • CVE-2015-2044 / XSA-121: Information leak via internal x86 system device emulation
  • CVE-2015-2045 / XSA-122: Information leak through version information hypercall
  • CVE-2015-2151 / XSA-123: Hypervisor memory corruption due to x86 emulator flaw

Additionally a bug in the fix for CVE-2014-3969 / CVE-2015-2290 / XSA-98 (which got assigned CVE-2015-2290) got addressed.

Sadly the workaround for CVE-2013-3495 / XSA-59 (Intel VT-d Interrupt Remapping engines can be evaded by native NMI interrupts) still can’t be guaranteed to cover all affected chipsets; Intel continues to be working on providing us with a complete list.

Apart from those there are many further bug fixes and improvements.

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

Xen Project Participates in Outreachy (formerly OPW)

This is a quick reminder that the Xen Project is again participating in Outreachy (formerly known as OPW/Outreach program for Women).

Outreachy is the successor of the Outreach Program for Women. Please see its page for the information about the May 2015 round of interships.

Outreach Program for Women has been helping women (cis and trans), trans men, and genderqueer people get involved in free and open source software. It provided a supportive community for beginning to contribute any time throughout the year and offered focused internship opportunities twice a year with a number of free software organizations. This work is continued by Outreachy, with the goal of expanding the program to more participants from underrepresented backgrounds.

Round 10 of Outreachy

outreachy-poster-2015-May-AugustThe application deadline for interns is March 24, 2015 April 7, 2015. For a list of projects for interns and more information on how to apply, check our Xen Project Outreachy portal.

We have many different projects in many different areas! Check out the following project ideas: Outreach Program Projects, General List of Development Projects or MirageOS Pioneer Projects.

Learn about the Experience of past Applicants

At least year’s Xen Project Developer Summit, we ran a panel discussion that included OPW interns, GSoC students as well as mentors.


You may also want to read Women interns rocking open source at Xen Project.

GSoC 2015

Unfortunately the project has not been accepted for GSoC in 2015! However, there are several Xen related projects hosted in various mentoring organisations, such as

Please apply to these projects using the normal GSoC application process.

Future of Xen Project: Video Spotlight Interview with Cavium’s Larry Wikelius

With several companies introducing ARM servers recently, cloud providers and enterprise datacenters are excited to see new alternatives for reducing costs and power use come to market. Cavium, a semiconductor leader with a long heritage in security and wireless/ networking, entered the race with the introduction of ThunderX™ the industry’s first 48-core and 96-core family of ARMv8 workload optimized processors. To get to this point, numerous companies, developers and organizations, including Cavium, put great effort into the development of server software, standards and products to make ARM based SoCs a viable option in these environments. For Cavium, joining the Xen Project was a critical part of its work to advance the evolving ARM ecosystem. According to Larry Wikelius, Xen Project Advisory Board member and Cavium’s Director of Ecosystems and Partner Enablement, it has also been crucial to competing in this evolving market.

In our latest “Future of Xen” video, Larry says working with Xen Project hypervisor is an important requirement for certain customers. With many Cavium customers and partners already using the open source hypervisor, the company needs to not only support Xen, but commit to optimizing the hypervisor for private and public clouds as well as corporate datacenters. Cavium joined the Xen Project community last year and is pleased to see the Project dedicate significant resources and development cycles to ensuring full support, peak performance and efficiencies for ARM-based servers and SoCs. As a board member, Cavium is also able to shape the Project’s roadmap, ensuring it protects Xen deployments and a scale-out strategy to support cloud, telecommunications, Internet of Things devices, big data analytics and more. While the Project’s early commitment for ARM support is relevant, what’s equally important is the hypervior’s small footprint and the growing number of silicon vendors, software companies and end users investing in the Project.

So beyond scale out Data Center and Cloud deployments, what else is ahead for ARM-based servers and SoCs? Larry already sees the networking and carrier space mobilizing behind network function virtualization (NFV). Versions of its ThunderX chip aimed at (NFV) workloads as well as telecommunication, media, and gaming systems offer more I/O in general and security accelerators. Larry recently spoke about this topic at The Linux Foundation’s Collaboration Summit 2015 last month. Be sure to watch his video and check out slides from his talk to learn more. 

 

Xen Project Now an Easy Option in OpenStack

Recent Changes Let Xen Project Work Out of the Box in OpenStack

Members of the Xen Project development team have always believed that the hypervisor must be available for integration into other Open Source projects.  In particular, the initiators of the Xen Project envisioned the day when compute resources would be available in a dynamic form, which has since been codified in the technology we now call Cloud Computing.

However, most members of the project team have usually left the details of integration into other projects to those interested individuals who were participating in those other projects.  In the case of OpenStack, however, it became apparent that the Xen Project team would need to be engaged to make the integration as transparent as it should be.

Improvements to Libvirt

Xen Project has always supported the libvirt toolset, but in recent years, the quality of integration into libvirt has suffered.  As libvirt has become a key cross-platform integration technology in recent years, this deficiency became problematic with OpenStack and other projects which rely on libvirt.

But over the past year, Jim Fehlig has led the charge to bring Xen Project support in libvirt up to par.  In addition, the interface had to be re-engineered to use the libxenlight library which has become the predominant interface for Xen Project in the past few releases.  The needed improvements have made integration into OpenStack reasonable.  But that was only the beginning of the battle.

OpenStack Involvement and Improvements

Even with greatly improved libvirt support, OpenStack itself had to use the interface in a way which made sense with the Xen Project Hypervisor.  The existing integration logic within OpenStack was good, but it needed a couple of patches to make basic functions work correctly.  Anthony Perard stepped in and produced the needed patches which have recently been accepted into OpenStack.

This marks the beginning of an increasing involvement of Xen Project within the OpenStack community.  In addition to committing to make the hypervisor work well within OpenStack, the Xen Project team has begun making plans to eventually raise the hypervisor from Group C support in OpenStack to Group A.  Also, Xen Project developers will be examining ways to help make the hypervisor even more usable in OpenStack in the future.

Greatly Improved Documentation

If you looked for OpenStack integration information on the Xen Project Wiki just 6 months ago, you would have found absolutely nothing dealing with integration via libvirt.  Now, however, you can find information on integrating the hypervisor with OpenStack, a HowTo on building a Xen Project-based Ubuntu OpenStack, instructions on installing DevStack, and more.

Presentations at FOSDEM and openSUSE Mini-Summit, plus a Video Demo

Attendees of this year’s FOSDEM’15 had the opportunity to hear Stefano Stabellini talk about using the Xen Project Hypervisor in OpenStack.  They also had the opportunity to see Anthony Perard’s demonstration of building a functional Xen Project-based DevStack in under 15 minutes, which eventually birthed this HowTo video:

This was followed by a presentation at the openSUSE Mini-Summit at the Southern California Linux Expo (SCALE 13x) given by Peter Linnell of SUSE and Russell Pavlicek.  This presentation discussed how the Xen Project Hypervisor works out-of-the-box with the SUSE OpenStack Cloud.

What Comes Next?

To move the Xen Project Hypervisor to Group B or A in OpenStack, we need a fully functional testbed which can run the required tests every time the OpenStack software is improved.  Our team is already hard at work constructing this testbed so our hypervisor can be promoted to a higher support group.

We may have improved Xen Project’s documentation around OpenStack, but we also need to raise the quality of documentation within the OpenStack itself.  For example, if you look at OpenStack’s Xen Project via Libvirt wiki page, it is (as of this writing) empty.  We need proper documentation to reflect the libvirt integration which is currently used by a variety of OpenStack implementations, both in the OpenStack wiki and in its formal documentation.

Watch our blog for more advances as they happen!

Intel hosts Xen Project Hackathon, April 28-29 in Shanghai

I am pleased to announce the next Xen Project Hackathon to be held this spring.  Although we call it a Hackathon, the event consists of several parallel sessions in which Xen Project developers will create, discuss and review designs and changes that impact Xen’s architecture. We’ll perform code reviews, discuss our future roadmap, work on improving the development process, tackle debug problems in the code base and cover other development related topics. Sessions are very interactive: typically there are no presentations.

Intel-logoThe Hackathon will be hosted by Intel at their Shanghai Zizhu Campus, April 28-29. I wanted to thank Susie Li and Mei Yu from Intel for hosting the Hackathon. Intel has been one of the core contributors to the Xen Project since 2003 and has been contributing many features to the Project. Intel joined the Xen Project Advisory Board in 2013 when the software became a Linux Foundation Collaborative Project. We recently interviewed Donald Dugger, Intel’s Virtualization Architect, to find out why Intel continues to support, contribute and invest in the Xen Project.

What to expect at a Xen Project Hackathon?

The aim of the Hackathon is to give developers the opportunity to meet face-to-face to discuss development, coordinate, write code and collaborate with other developers. Of course, the event will allow everyone to meet in-person and build relationships; to facilitate this, we will have a social event on the evening of the 28th. We will cover many hot topics such as the latest Xen Project Hypervisor 4.6 features, planning for the next Xen Project Hypervisor release, Cloud Integration, Cloud Operating Systems, MirageOS, as well as new opportunities in embedded, mobile, automotive and NFV. But at the end of the day, the community chooses what topics will be covered.

To ensure that the event runs efficiently, each day is divided into several segments. We will have a number of work areas that are labelled with numbers (or other unique identifiers). Each morning will start with a plenary and scheduling session. Every attendee can propose a session, which we will map against a work area and time-slot. This makes it easy for other attendees to participate in projects and sessions they care about. Of course we also encourage attendees to highlight projects they plan to share before the event by adding them to our wiki.

How to Register

Spaces for the Xen Project Hackathon are limited (we can accommodate 50 people). Be sure to request an invitation to the event before our cut-off registration date of April 12th, 2015.

More Information

Updates to Xen Project Security Process

lockBefore Christmas, the Xen Project ran a community consultation to refine its Security Problem Response Process.  We recently approved changes that, in essence, are tweaks to our existing process, which is based on a Responsible Disclosure philosophy.

Responsible Disclosure and our Security Problem Response Process are important components of keeping users of Xen Project-based products and services safe from security exploits. Both ensure that products and services can be patched by members of the pre-disclosure list before details of a vulnerability are published and before said vulnerabilities can be exploited by black hats.

The changes to our response process fall into a number of categories:

  • Clarify whether security updates can be deployed on publicly hosted systems (e.g. cloud or hosting providers) during embargo
  • Sharing of information among pre-disclosure list members
  • Applications procedure for pre-disclosure list membership

The complete discussion leading to the changes, the concrete changes to the process, and the voting records supporting the changes are tracked in Bug #44 -Security policy ambiguities. On February 11, 2015, the proposed changes were approved in accordance with Xen Project governance. Note that some process changes are already implemented, whereas others are waiting for implementation tasks (e.g. new secure mailing lists) before they can fully be put in place. We have however updated our Security Problem Response Process as the most important elements of the process are already in place.

Process Changes Already in Operation

The updated policy makes explicit whether or not patches related to a Xen Security Issue can be deployed by pre-disclosure list members. The concrete policy changes can be found here and here. In practice, every Xen Security Advisory will contain a section such as:

DEPLOYMENT DURING EMBARGO
=========================

Deployment of the patches and/or mitigations described above (or
others which are substantially similar) is permitted during the
embargo, even on public-facing systems with untrusted guest users and
administrators.

Predisclosure list members who wish to deploy significantly different
patches and/or mitigations, please contact the Xen Project Security
Team.

This section will clarify whether deploying fixed versions of Xen during the embargo is allowed. Any restrictions will also be stated in the embargoed advisory. The Security Team will impose deployment restrictions only to prevent the exposure of security vulnerability technicalities, which present a significant risk of vulnerability rediscovery (for example, by visible differences in behaviour). Such situations have been, and are expected, to be rare.

Changes to Application Procedure for Pre-disclosure List Membership

We also made additional changes related to streamlining and simplifying the process of applying for pre-disclosure list membership. Detailed policy changes can be found here and here. Moving forward, future applications to become members of the Xen Project pre-disclosure list have to be made publicly on the predisclosure-applications mailing list. This enables Xen Project community members to provide additional information and also is in line with one of our community’s core principles: transparency. In addition, we’ve clarified our eligibility criteria to make it easier for the Xen Project Security Team, as well as observers of the mailing list, to verify whether applicants are eligible to become members of the list.

Process Changes Not Fully Implemented:  Sharing of Information Among Pre-disclosure List Members

Finally, members of the pre-disclosure list will be explicitly allowed to share fixes to embargoed issues, analysis, and other relevant information with the security teams of other pre-disclosure members. Information sharing will happen on a private and secure mailing list hosted by the Xen Project.  Note the list is not yet in place; more details here.