case study of xen hypervisor

Xen Case Studies

This page contains a collection of Xen hypervisor case studies showing the unique solutions being solved with the open source Xen hypervisor.

• Google ( (video)
• Xen ATG Case Study (pdf)
• Xen Time Machine (pdf)

North America

• Amazon ( video )
• Xen Brandeis Case Study (pdf)
• Pivot3 Case Study (pdf)
• Xen Avaya Case Study (pdf)
• Aplura Virtualization Slides (pdf)

Please contact [email protected], if you would like to be added to this list.

Navigation menu

• View source

Personal tools

• Set up Search

NAVIGATION BY INDEX

• Index Guide
• All Categories
• Recent Changes

NAVIGATION BY AUDIENCE

Hypervisor & tools.

• Xen Project Developers
• Windows PV Drivers Developers
• XAPI Developers

EMBEDDED/AUTOMOTIVE

• Embedded and Automotive
• Unikraft Developers
• MirageOS Developers

NAVIGATION BY DOC TYPE

• Compatibility
• Index Pages

NAVIGATION BY TECHNOLOGY

• Xen Project Hypervisor
• PVOPS (in Linux Kernel)

INTERACTION

• Wiki community
• Manage Wiki
• Recent changes
• What links here
• Related changes
• Special pages
• Printable version
• Permanent link
• Page information

• This page was last edited on 5 December 2011, at 16:11.

• Privacy policy
• Disclaimers

• Corpus ID: 11141440

Xen* Hypervisor Case Study - Designing Embedded Virtualized Intel ® Architecture Platforms Executive Summary Xen* Hypervisor Case Study - Designing Embedded Virtualized Intel® Architecture Platforms Contents

• Computer Science, Engineering

Figures from this paper

2 Citations

Experimental proof: data remanence in cloud vms, enhancing eucalyptus community cloud, 17 references, a multi-layered approach to security in high assurance systems, a distributed secure system, the mils architecture for high-assurance embedded systems, intelŵvirtualization technology in embedded and communications infrastructure applications, copyright © intel corporation 2008 * other names and brands may be claimed as the property of others, intel ® trusted execution technology ( intel ® txt ), related papers.

Showing 1 through 3 of 0 Related Papers

• Find Training
• Become a Partner
• Get Certified

Xen Virtualization and Cloud Computing #03: Key Features of Xen

The previous articles in this series introduced virtualization and showed how Xen is designed to provide it efficiently. Here we’ll delve into some interesting features and their importance. A larger list can be found at the appropriate project page on features . At time of writing this article, the most recent version of Xen Project is 4.13.

Security-related features

The Meltdown and Spectre processor vulnerabilities, which exploit complex performance-enhancing features of modern microprocessors, have presented formidable challenges to the developers of operating systems and application. Meltdown and Spectre were officially discovered in January 2018.  This section describes two enhancements to Xen to mitigate against these difficult vulnerabilities.

Meltdown, which affects Intel x86, IBM Power, and some ARM microprocessors, allows a malicious process to read data from any address that is mapped to the current process’s memory space. Effectively, the process can read all memory without permission. The malicious process accomplishes this by finding a timing flaw in the execution of several processor features (such as the cache and pipeline) that are individually secure. At the time of disclosure, this vulnerability affected many products, with impacts on an enormous number of servers and cloud providers. Companies began writing patches to block the Meltdown vulnerability, causing performance losses between 5 and 30 percent.

Spectre also exploits modern performance features. In modern microprocessors, a digital circuit tries to guess the outcome of a conditional operation such as an “if…else” statement, using information gathered before the execution of the program, and prepares for the most likely result. It. In other words, it tries to guess the way of an if-then-else statement will go before it knows it exactly. The name of this technique is branch prediction. It is an important component of modern CPU architectures such as the x86 and plays a critical role in achieving higher performance. Spectre exploits branch predication system to read arbitrary locations in the allocated memory of a program. This attack can be implemented in a browser using JavaScript, so it is important to keep your browser up to date.

On March 15, 2018, Intel reported that it will redesign its CPU processors to help protect against Meltdown and Spectre. On October 8, 2018, Intel added firmware to its latest processors to mitigate against these attacks.

Hypervisor changes to mitigate against Meltdown and Spectre

The Xen hypervisor, like other products, was affected by these vulnerabilities, specifically:

• “Rogue Data Load” (aka SP3, “Variant 3”, Meltdown, CVE-2017-5754)
• “Branch Target Injection” (aka SP2, “Variant 2”, Spectre CVE-2017-5715)
• “Bounds-check bypass” (aka SP1, “Variant 1”, Spectre CVE-2017-5753)

There is no way to completely prevent risks from these vulnerabilities, but adding execution boundaries and other checks to code can partially plug the holes. Thus, we talk about “mitigating against” the vulnerabilities.

The initial focus of the Xen Project was on fixes for Meltdown, then Spectre Variant 2, and finally Spectre Variant 1. SP1 and SP2 affect Intel and AMD processors, but ARM processors vary by model and manufacturer. SP3 affects only Intel processors. To mitigate against Meltdown, the Xen Project published three solutions with the names Vixen, Comet, and PTI. Unfortunately, the fix to mitigate against SP1 requires microcode updates from Intel and AMD. Currently, therefore, there is no mitigation for SP1. But its attack surface can be reduced through technology contributed to the Xen Project by Citrix. It works by branch hardening.

• SP2 can be mitigated by a combination of microcode, compiler, and hypervisor changes.
• SP3 can be mitigated by page-table isolation (PTI).

For more up-to-date information about these vulnerabilities and the Xen Project’s responses, see our Advisory 254 .

Core Scheduling

This technology, contributed by SuSE Linux, helps to contain the negative effects of a Meltdown or Spectre breach. Normally, every virtual CPU could be scheduled on any physical CPU, and could move between physical CPUs for efficient scheduling. This increased the risk that information could be leaked from one VM to another, just as travel between cities allows an infection to spread faster. The only way to completely mitigate against this vulnerability is to disable hyper-threading, which would cause tremendous performance hits.

The core scheduling feature allows Xen to group virtual CPUs and schedule them on a limited set of physical cores. With this technology, users can keep hyperthreading enabled. Initial benchmarks have shown lost performance for many workloads. SUSE and Citrix are working on the feature, and in upcoming releases we hope to see better trade-offs between security and performance.

Hypervisor-based Memory Introspection (HVMI)

This is technology donated by Bitdefender to the Xen project on July 30, 2020 to protect against malware in the operating systems that run on Xen. HVMI has a key advantage over malware detection systems on guest operating systems: while smart malware can take over a whole guest and disable detection or prevention mechanisms on the guest, the malware has no way to reach into the underlying hypervisor.

Malware has become extremely dangerous and hard to fight for several reasons:

• It can enter the system whenever a single unaware user on the system visits an infected web site or opens a file received from a trusted person.
• It can exploit operating system vulnerabilities to gain superuser privileges and take over the whole system. Very few operating systems divide privileges in order to limit malware to  one area.
• It has gotten sophisticated enough to hide its files or other traces from administrators, and to disable measures designed the thwart it.

A remarkable story showing the power of malware concerns an attack known as Carbanak , which infected more than 100 banks in thirty nations and did $1 billion worth of damage globally. In late 2013, an investigation of a bank in Kiev revealed that stealth malware injected by Carbanak monitored the internal systems of the bank for several months successfully covering its tracks. The malware recorded every employee’s activity and sent back videos and images to the intruder without drawing  any attention..

The Bitdefender name is familiar to all IT staff. It is a leading global cybersecurity company, protecting over 500 million systems worldwide. Bitdefender and Citrix collaborated on Citrix Hypervisor . As we know, the hypervisor isolates VMs from each other and provide clean, low-level information about the memory used by each virtual machine. The result of this collaboration is a new security layer that can see everything happening in your infrastructure, but which Malware cannot reach. Bitdefender’s Hypervisor Introspection (HVI) technology detects suspicious activities by working directly with raw memory. At this level, malware can’t hide.

Bitdefender HVI assumes that your systems are not clean, and you can command it to inject cleaning tools into the live virtual machines. The HVI already detects and blocks the most famous attacks, including Carbanak, Turla, APT28, NetTraveler, and Wild Neutron, without knowing the vulnerabilities used by the attackers.

When Bitdefender decided to release HVI to Xen  as open source, they called it Hypervisor-based Memory Introspection (HVMI). The HVMI technology understands and applying security logic to memory events within running Linux and Windows VMs. It examines the memory in real time for signs of memory-based attack techniques that used to exploit known and unknown vulnerabilities.

Along with this, Bitdefender open sourced its ”thin” hypervisor technology, known as Napoca , and donated it to the Xen Project. The Napoca hypervisor was used in developing HVI technology. A distinctive feature of Napoca is that it virtualizes CPU and memory, not all hardware, and therefore allows hypervisor introspection on machines that don’t run a full hypervisor.

Management-related features

These features reduce the burden of managing hypervisors.

Late uCode loading

Microcode , often shorted to “uCode” (where the “u” stands for the Greek letter mu), is chip manufacturer firmware, The uCode typically contains mitigations for HW vulnerabilities and is typically updated during system initialization or kernel boot. The update formerly required a reboot and a long down-time. Xen Project 4.13 lets the Xen Hypervisor deploy a uCode update without any reboot. This feature was contributed by Intel.

Upgraded live-patching

This is a mechanism for replacing small sections of code in a running hypervisor, so that you don’t have to shut down the hypervisor and terminate all the VMs running on it. The feature is generally used to deploy critical security fixes.

Live-patching has been around for a while in several Xen-based products, and was included as a tech preview feature since Xen 4.7. Now it is a supported feature on the x86 architecture. The patching does need all activity to be paused, but this pause time should be small. Amazon is working to improve this feature further. We plan to extend it to other architectures besides x86.

Recent improvements to live-patching include the capability to patch inline assembly code, improvements to stacked modules, support for module parameters, additional hooks and replicable apply/revert actions, extended python bindings for automation, and additional validation of live patches.

Live-patching is not the final goal for  live updates, because it is limited to small, localized code changes. The Xen Project team is also working on a broader live update feature. When it’s finished, an administrator will be able to upgrade a Xen hypervisor and its tools to a new version without stopping and relaunching the guests.

Embedded and safety-critical application features

These features support particular settings that need to run the hypervisor and VMs in unusual ways.

OP-TEE support

TrustZone is a security feature of ARM processors, allowing privileged users to run a process is memory shut off from access by other processes. Because there is only one trusted zone on each chip, sharing it among multiple VMs is difficult . Therefore, Xen did not originally offer TrustZone access to guest VMs. Thanks to a feature contributed by EPAM , starting with Xen 4.13, all guests can concurrently run applications on Arm TrustZone without conflicts. More work need to be done on this feature, though.

Renesas R-CAR IPMMU-VMSA driver

Automobiles rely increasingly on software. Their multiple, concurrent software processes call for virtualization in order to protect the high-stakes security required in automobiles. Thus, many automotive systems use Xen hypervisors. Access to GPUs is valuable for the virtual processes, in order to achieve the real-time performance needed when the car is in motion, but this requires access to ARM’s Virtual Memory System Architecture (VMSA). Renesas has added this VMSA support to its ARM-based chips in Xen 4.13, and a driver contributed to the Xen Project by EPAM makes that access available to automobiles’ computing systems.

Dom0-less passthrough and ImageBuilder

An earlier article in this series described the central role of the privileged domain, Dom0, in Xen. Because the presence of Dom0 adds significant time (measurable in seconds) to the loading of each VM, some embedded system developers have asked for a Dom0-less architecture. Many embedded  systems need to have several VMs up and running in less than a second after the user boots the system. The code to implement a Dom0-less architecture was contributed by Xilinx in 2018. The feature does not yet work with Paravirtualization, but works with other forms of Xen virtualization.

Because there is no privileged process and no userspace tools in a Dom0-less Xen, systems using it must load guests using U-Boot, an open-source boot loader . The guest images must contain all the required binaries, such as operating system kernels and ramdisks. Thus, a new tool named ImageBuilder , whose code is on GitLab , is provided to automate the building of Dom0-less configurations for U-Boot.

Figure 4 shows a Dom0-less architecture.

The next component of this series examines the interesting relationship between Xen and some other forms of virtualization, notably containers.  

Read the previous post | Read the next post

About Mohsen Mostafa Jokar:

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Linux Professional Institute is a non profit organization.

Linux Professional Institute (LPI) is the global certification standard and career support organization for open source professionals. With more than 250,000 certification holders, it’s the world’s first and largest vendor-neutral Linux and open source certification body. LPI has certified professionals in over 180 countries, delivers exams in multiple languages, and has hundreds of training partners.

Our mission is to promote the use of open source by supporting the people who work with it.

• Privacy and Cookie Policy
• Diversity, Equity, and Inclusion Policy
• Exam Vouchers and Return Policy
• Community Code of Conduct

In case of a content discrepancy between English and the translation, the English version is canonical. Spot a mistake or want to help improve this translation? Please  let us know .

© Copyright 1999-2024 Linux Professional Institute Inc. All rights reserved. Linux is a registered trademark of Linus Torvalds. Linux Professional Institute and corresponding “L” logo are registered trademarks.

• Case Studies

Exploring the Power of Xen Hypervisor

In today's rapidly evolving technological landscape, the demand for efficient and secure virtualization solutions is more crucial than ever. Enter Xen Hypervisor, a powerful tool gaining increasing recognition for its versatility and reliability in managing virtualized environments. At the forefront of this innovation is the integration of Xen Hypervisor with the i.MX8 processor, unlocking a new realm of possibilities in embedded systems.

Watch Our Demo in Action: Xen Hypervisor on i.MX8 Processor

Our recent demo showcases the innovative fusion of Xen Hypervisor with the i.MX8 processor, demonstrating its capabilities in a real-world scenario. In this demo, we have implemented multiple domains (guest OSs) running concurrently on the i.MX8 platform:

• Guest OS G1 Video Rendering with GPU Acceleration: Guest OS G1 is dedicated to video rendering tasks, leveraging the power of the GPU for efficient processing. By offloading video rendering to a dedicated guest OS, system performance is optimized, ensuring smooth and high-quality output.
• Guest OS G2 Video Streaming and Display: Guest OS G2 is tasked with video streaming via Ethernet and displaying the streamed content on a screen. Leveraging Xen Hypervisor's strong isolation capabilities, Guest OS G2 operates independently from Guest OS G1, ensuring reliable and secure video streaming without compromising system integrity.

The Importance of Xen Hypervisor

Xen Hypervisor stands out as a leading open-source hypervisor, renowned for its robustness and efficiency. Its lightweight design and strong isolation capabilities make it an ideal choice for embedded systems, where resource optimization and security are paramount. By enabling multiple guest operating systems (OSs) to run concurrently on a single hardware platform, Xen Hypervisor empowers developers to create sophisticated and flexible solutions while maximizing hardware utilization.

The Challenge and Purpose

The integration of Xen Hypervisor with the i.MX8 processor presents both a challenge and an opportunity. One of the primary challenges lies in harnessing the full potential of the i.MX8 processor while ensuring seamless integration with Xen Hypervisor. However, overcoming this challenge opens doors to a multitude of applications across various industries, from automotive and aerospace to industrial automation and beyond.

The integration of Xen Hypervisor with the i.MX8 processor marks a significant milestone in the evolution of embedded systems. By harnessing the power of virtualization, developers can unlock new levels of efficiency, flexibility, and security in their applications. As technology continues to advance, the synergy between Xen Hypervisor and the i.MX8 processor promises to drive innovation and shape the future of embedded computing. If you're interested in exploring the possibilities of Xen Hypervisor on the i.MX8 platform further or discussing how it can benefit your projects, we're here to help. Contact us today to learn more about our solutions and services.

Technologies

• Data Center Monitoring
• Industry 4.0
• IOT Getaway Elco35
• Factory Automation
• Jacinto 7 Training
• IoT Mobile Application
• GDPR Privacy Policy
• Software License Agreement
• Terms and Conditions
• Quality And Information Security Policy
• Career Page

• Imam Muhammad bin Saud Islamic University
• This person is not on ResearchGate, or hasn't claimed this research yet.

• Taif University

• Georgia Institute of Technology

Abstract and Figures

Discover the world's research

• 25+ million members
• 160+ million publication pages
• 2.3+ billion citations

• Valentina Timcenko

• Nenad Kraljević
• Stefan Marić
• Kristina Janjić
• Kristijan Kuk
• Saša Gucunja

• Marek Šimon
• Ladislav Huraj

• Boris Dzuverovic
• Waldemar Graniszewski
• Adam Arciszewski

• Rizwan Qaiser

• Mumtaz M.Ali

• Frederick Y. Wu

• Varun Kumar Manik
• Deepak Arora
• Geoffrey Phi C. Tran

• Stephen P. Crago
• Aaron Paradowski

• Recruit researchers
• Join for free
• Login Email Tip: Most researchers use their institutional email address as their ResearchGate login Password Forgot password? Keep me logged in Log in or Continue with Google Welcome back! Please log in. Email · Hint Tip: Most researchers use their institutional email address as their ResearchGate login Password Forgot password? Keep me logged in Log in or Continue with Google No account? Sign up

Academia.edu no longer supports Internet Explorer.

To browse Academia.edu and the wider internet faster and more securely, please take a few seconds to  upgrade your browser .

Enter the email address you signed up with and we'll email you a reset link.

• We're Hiring!
• Help Center

A comparison Study between Virtualized and non-virtualized Environments

Related Papers

Andrew Warfield

1st Workshop on Operating System and Architectural Support …

The Xen virtual machine monitor allows multiple operating systems to execute concurrently on commodity x86 hard- ware, providing a solution for server consolidation and util- ity computing. In our initial design, Xen itself ...

Rajesh Bose

Any discussion of Cloud computing typically begins with virtualization. Virtualization is critical to cloud computing because it simp lifies the delivery of services by providing a platform fo r optimizing complex IT resources in a scalable manner, wh ich is what makes cloud computing so cost effective. Desktop virtualization, often called client virtualization, is a virtualizat ion technology used to separate a computer desktop environment fro m the physical computer. Desktop virtualizat ion is considered a type of client-server computing model because the "virtualized" desktop is stored on a centralized, or remote, server and not the physical machine being virtualized. Desktop virtualization "virtualizes desktop computers" and these virtual desktop environments are "served" to users on the network. In this paper, we proposed a secure cloud data center architecture that made by an application virtualizat ion product like citrix xenapp/citrix xen desktop and with a proposed model that help us to encrypt and store the data like virtualized desktop or virtualized applicat ion in a suitable storage area.

Jean-Pierre Hombach

Jon Crowcroft

Divya Kapil

Virtualization technology allows abstraction and isolation of lower level functionalities and underlying hardware. Virtual machine monitor, also called a hypervisor, which is a logical layer between underlying hardware and computational processes, and runs on the top of a given host. Virtualization provides facility to migrate virtual machine from one host (source) to another physical host (destination). Virtual Machine Migration is a useful tool for administrator of data centers. The reasons for VM migration are: Load Balancing, accomplished by migrating VMs out of overloaded / overheated servers, and Server Consolidation. Two major VM migration technologies are VMotion and XenMotion respectively supported by two major virtualization vendors-VMware and Citrix. In this paper we are comparing these two live virtual machine migration techniques.

Natalia Castro Fernandes

Network testbeds strongly rely on virtualization that allows the simultaneous execution of multiple protocol stacks but also increases the management and control tasks. This paper presents a system to control and manage virtual networks based on the Xen platform. The goal of the proposed system is to assist network administrators to perform decision making in this challenging virtualized environment. The system management and control tasks consist of defining virtual networks, turning on, turning off, migrating virtual routers, and monitoring the virtual networks within few mouse clicks thanks to a user-friendly graphical interface. The administrator can also perform high-level decisions, such as redefining the virtual network topology by using the plane-separation and loss-free live migration functionality, or saving energy by shutting down physical routers. Our performance tests assure the system has low response time; for instance, less than 3 minutes to create 4-node virtual networks.

Nikhil Bhatia

Andrew Grimshaw

This document presents the Levels 1 and 2 decompositions of Version 1 of the XSEDE architecture, as defined by the XSEDE architecture team based on requirements obtained by broad stakeholder consultation. The Level 1 decomposition identifies the nature and purpose of the three principal layers of the architecture: the resources layer, which encompasses the diverse physical and virtual resources provided by XSEDE service providers; the services layer, which provides access to those resources via well-defined ...

Loading Preview

Sorry, preview is currently unavailable. You can download the paper by clicking the button above.

RELATED PAPERS

USENIX Annual …

Todd Deshane

Jehan-Francois Paris

Virgilio Almeida

Science Park Research Organization & Counselling

Concurrency and Computation: Practice and Experience

Wesam Dawoud

Alfons Crespo

Olaf Maennel , Andreas Wundsam

IJERA Journal

Xen Summit, Boston, …

Lucky Prasetiyo

Dhiraj Mishra

RELATED TOPICS

•   We're Hiring!
•   Help Center
• Find new research papers in:
• Health Sciences
• Earth Sciences
• Cognitive Science
• Mathematics
• Computer Science
• Academia ©2024

🎫 Meet us at KubeCon + CloudNativeCon NA · Nov 12-15 · Salt Lake City REGISTER TODAY

Xen Project Announces Performance and Security Advancements with Release of 4.19

The linux foundation | 31 july 2024.

 New release marks significant enhancements in performance, security, and versatility across various architectures.  SAN FRANCISCO – July 31st, 2024 – The Xen Project , an open source project under the Linux Foundation, is proud to announce the release of Xen Project 4.19. This release marks a significant milestone in enhancing performance, security, and versatility across various architectures, including Arm, PPC, RISC-V, and x86, altogether providing a robust and secure hypervisor solution for both enterprises and cloud providers. 

The Xen Project continues to lead the way in virtualization technology. With contributions from a wide and diverse range of companies, including board members AMD, ARM, AWS, EPAM, Vates, and XenServer, Xen Project 4.19 introduces a range of key changes and improvements that solidify its position as a premier open-source virtualization platform. Comprehensive improvements include substantial enhancements in memory management, security, and system stability, spanning multiple architectures and benefitting a wide array of users and use cases. "The 4.19 release is a significant achievement for the Xen community, bringing crucial enhancements across all supported architectures," said Kelly Choi, Community Manager at the Xen Project. "New features such as the x2APIC driver for x86 and dynamic node programming for Arm highlight our focus on meeting the evolving needs of our users, and underscores our dedication to advancing virtualization technology with a robust, reliable and open source hypervisor."

Notable Improvements in Release 4.19 Include:

Security Enhancements

• Published 13 new Xen Security Advisories (XSAs) to mitigate vulnerabilities.
• Adoption of additional MISRA-C rules for improved code quality.

Arm Architecture

•  Introduction of dynamic node programming using overlay dtbo.
•  FF-A notification support

x86 Architecture

Introduce a new x2APIC driver that uses Cluster Logical addressing mode for IPIs and physical addressing mode for external interrupts.

Deprecate support for XeonPhi in 4.19, with the firm plan to remove support in 4.20.

• PVH dom0 has now moved to "supported with caveats" status​​​​​​​
• PVH/HVM can now map foreign pages, which should for example allow QEMU stubdomains to run as PVH
• Boot time speedup due to the IOMMU changes
• Don't expose pIRQ support to HVM guests by default.  The feature (XENFEAT_hvm_pirqs) can now be enabled on a per-domain basis

Other updates:

Add a new 9pfs backend running as a daemon in dom0. First user is Xenstore-stubdom now being able to support full Xenstore trace capability. 

libxl support for backendtype=tap with tapback.

• Increase the maximum number of CPUs Xen can be built for from 4095 to 16383.
• When building with Systemd support (./configure --enable-systemd), remove

      libsystemd as a build dependency.  Systemd Notify support is retained, now

      using a standalone library implementation.

• xenalyze no longer requires `--svm-mode` when analyzing traces generated on AMD CPUs.
• Code symbol annotations and MISRA compliance improvements.
• CI updates:
• Minimum fixes to rebuild the containers, following the HEREDOC problems.
• Rebuild containers to have testing with up-to-date LTS distros.
• Few build system checks, and strip the obsolete contents of the build containers.

The Xen Project 4.19 release underscores the community’s commitment to advancing virtualization technology. Visit the Xen Project website to learn more, and join the conversation by signing up for the Xen Project mailing list and Matrix .

Supporting Quotes

"AMD looks forward to embracing the advancements in the Xen 4.19 release. With MISRA C compliance nearing completion, this milestone brings us closer to a safety-certifiable hypervisor.   Additionally, the support for Device Tree overlays for dynamic VM configurations significantly enhances Xen's flexibility with AMD FPGAs and adaptive SoCs, positioning  it as a robust solution for critical embedded applications."

– Kris Chaplin, Open Source Software Lead - Systems Engineering, AMD. 

“As a proud board member of the Xen Project, XenServer is thrilled to witness the release of Xen 4.19. This new release signifies a remarkable stride in code safety and memory management across various architectures. At XenServer, we are committed to our collaboration with the community to contribute to the future of the Xen hypervisor. We look forward to integrating these enhancements in security and performance into the XenServer product, ensuring that our users can leverage the latest advancements in virtualisation technology.”

– Diego Novellon, Software Engineering Manager, XenServer

"At Vates, we are pleased with the continuous advancements of the Xen project and are proud to contribute to its progress. Notably, Oleksii, one of our dedicated XCP-ng developers, served as the release manager for Xen 4.19. Currently, we are involved in the AMD SEV projects and the Xen port to RISC-V. Alongside other board members, we continue to elevate the Xen project's visibility, ensuring it is recognized not only by its contributors but also within the virtualization sector. Beyond this release, we remain deeply committed to expanding the Xen project's reach by building bridges with other communities and the academic world, fostering broader collaboration and innovation through teamwork."

– Olivier Lambert, CEO, Vates

“Arm is the platform of choice for a vast ecosystem of developers, and our ongoing work with the Xen Project continues to be an important part of our commitment to the open source software community. Virtualization is critical to applications like automotive, where the XEN Hypervisor is part of the SOAFEE open source reference implementation , and the release of Xen 4.19 brings significant improvements in dynamic node programming for the Arm architecture. We look forward to seeing how developers leverage this new release for future automotive use-cases on Arm."

 – Andrew Wafaa, senior director, Software Communities at Arm 

About the Xen Project

The Xen Project is the home for several virtualization-related open source projects and is licensed under the GPLv2. Hosted by the Linux Foundation, Xen Project is focused on advancing virtualization in a number of different commercial and open source applications, including server virtualization, Infrastructure as a Services (IaaS), desktop virtualization, security applications, embedded and hardware appliances, and automotive/aviation. For more information visit XenProject.org .

Media Contact:

Noah Lehman  

The Linux Foundation  

[email protected]  

About The Linux Foundation

The Linux Foundation is the world’s leading home for collaboration on open source software, hardware, standards, and data. Linux Foundation projects are critical to the world’s infrastructure including Linux, Kubernetes, Node.js, ONAP, OpenChain, OpenSSF, PyTorch, RISC-V, SPDX, Zephyr, and more. The Linux Foundation focuses on leveraging best practices and addressing the needs of contributors, users, and solution providers to create sustainable models for open collaboration. For more information, please visit us at linuxfoundation.org. The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, please see its trademark usage page: www.linuxfoundation.org/trademark-usage. Linux is a registered trademark of Linus Torvalds.

Stay Connected with the Linux Foundation

• Artificial Intelligence
• Generative AI
• Business Operations
• IT Leadership
• Application Security
• Business Continuity
• Cloud Security
• Critical Infrastructure
• Identity and Access Management
• Network Security
• Physical Security
• Risk Management
• Security Infrastructure
• Vulnerabilities
• Software Development
• Enterprise Buyer’s Guides
• United States
• United Kingdom
• Newsletters
• Foundry Careers
• Terms of Service
• Privacy Policy
• Cookie Policy
• Member Preferences
• About AdChoices
• E-commerce Links
• Your California Privacy Rights

Our Network

• Computerworld
• Network World

Xen hypervisor faces third highly critical VM escape bug in 10 months

The xen paravirtualization mode is proving to be a constant source of serious vulnerabilities, allowing attackers to escape from virtual machines.

The Xen Project has fixed three vulnerabilities in its widely used hypervisor that could allow operating systems running inside virtual machines to access the memory of the host systems, breaking the critical security layer among them.

Two of the patched vulnerabilities can only be exploited under certain conditions, which limits their use in potential attacks, but one is a highly reliable flaw that poses a serious threat to multitenant data centers where the customers’ virtualized servers share the same underlying hardware.

The flaws don’t yet have CVE tracking numbers, but are covered in three Xen security advisories called XSA-213 , XSA-214 and XSA-215 .

“XSA-213 is a fatal, reliably exploitable bug in Xen,” said the security team of Qubes OS, an operating system that isolates applications inside Xen virtual machines. “In the nearly eight-year history of the Qubes OS project, we have become aware of four bugs of this calibre: XSA-148, XSA-182, XSA-212 and now XSA-213.”

Of these four highly critical and easy to exploit vulnerabilities, three have been found and patched over the past 10 months and two over the past month — XSA-182 was fixed in July 2016, XSA-212 in April and XSA-213 on Tuesday.

Another commonality is that all of them affected the Xen memory virtualization for paravirtualized (PV) VMs. Xen supports two types of virtual machines: Hardware Virtual Machines (HVMs), which use hardware-assisted virtualization, and paravirtualized VMs that use software-based virtualization.

The other two flaws patched Tuesday, XSA-214 and XSA-215, also affect paravirtualized VMs. The difference is that XSA-214 requires two malicious guest VMs to work together in order to access the system memory, while XSA-215 only affects “x86 systems with physical memory extending to a configuration dependent boundary of 5TB or 3.5TB.”

One limitation for XSA-213 is that it can only be exploited from 64-bit PV guests, so systems running only HVM or 32-bit PV guests are not affected.

The Xen developers released patches for Xen 4.8.x, Xen 4.7.x, Xen 4.6.x and Xen 4.5.x that can be applied manually to affected systems.

The open-source Xen hypervisor is used by many cloud computing providers and virtual private server (VPS) hosting companies, some of which received the patches in advance and were forced to schedule maintenance downtimes.

For example, VPS provider Linode had to reboot some of its legacy Xen PV hosts in order to apply the fix and advised customers to move to its HVM-based servers to avoid future downtimes.

Meanwhile, Amazon Web Services said that its customers’ data and instances were not affected by these vulnerabilities and no customer action was required.

The Qubes OS team, which prides itself on building one of the most secure desktop operating systems, has had enough of having to repeatedly deal with Xen PV vulnerabilities. That’s why, over the past 10 months, it has put in extra work to switch the next version of the OS — Qubes 4.0 — to HVM.

“We originally hoped we could transition to running all Linux VMs in a so-called PVH mode of virtualization, where the I/O emulator is not needed at all, but it turned out the Linux kernel is not quite ready for this,” the Qubes team said in an analysis of the latest Xen patches. “So, in Qubes 4.0, we will use the classic HVM mode, where the I/O emulator is sandboxed within… a PV VM (which is also the case when one runs Windows AppVMs on Qubes 3.x).”

The good news is that the groundwork is set to switch Qubes to PVH in the future when the Linux kernel adds the needed support, and even to replace Xen entirely with something else, if a better alternative comes along.

You can’t escape it, add your comments to our Facebook page.

Related content

Eu's dora regulation explained: new risk management requirements for financial firms, black hat: latest news and insights, 6 hot cybersecurity trends — and 2 going cold, will the public nature of ransom payments change ciso strategy over whether to pay, from our editors straight to your inbox.

Lucian Constantin writes about information security, privacy, and data protection for CSO.

More from this author

Apt groups increasingly attacking cloud services to gain command and control, new critical apache ofbiz vulnerability patched as older flaw is actively exploited, attackers leverage cloudflare tunnels to obscure malware distribution, 12 wide-impact firmware vulnerabilities and threats, north korean cyberspies trick developers into installing malware with fake job interviews, secure boot no more leaked key, faulty practices put 900 pc/server models in jeopardy, dnssec explained: why you might want to implement it on your domain, ics malware frostygoop disrupted heating in ukraine, remains threat to ot worldwide, most popular authors.

Show me more

Ransomware attack paralyzes milking robots — cow dead.

The top new cybersecurity products at Black Hat USA 2024

Generative AI takes center stage at Black Hat USA 2024

CSO Executive Sessions: Guardians of the Games - How to keep the Olympics and other major events cyber safe

CSO Executive Session India with Dr Susil Kumar Meher, Head Health IT, AIIMS (New Delhi)

CSO Executive Session India with Charanjit Bhatia, Head of Cybersecurity, COE, Bata Brands

Cybersecurity Insights for Tech Leaders: Addressing Dynamic Threats and AI Risks with Resilience

• Trending Now
• Foundational Courses
• Data Science
• Practice Problem
• Machine Learning
• System Design
• DevOps Tutorial

A hypervisor is a form of virtualization software used in Cloud hosting to divide and allocate the resources on various pieces of hardware. The program which provides partitioning, isolation, or abstraction is called a virtualization hypervisor. The hypervisor is a hardware virtualization technique that allows multiple guest operating systems (OS) to run on a single host system at the same time. A hypervisor is sometimes also called a virtual machine manager(VMM). 

Types of Hypervisor –

TYPE-1 Hypervisor:   The hypervisor runs directly on the underlying host system. It is also known as a “Native Hypervisor” or “Bare metal hypervisor”. It does not require any base server operating system. It has direct access to hardware resources. Examples of Type 1 hypervisors include VMware ESXi, Citrix XenServer, and Microsoft Hyper-V hypervisor.   

Pros & Cons of Type-1 Hypervisor:

Pros: Such kinds of hypervisors are very efficient because they have direct access to the physical hardware resources(like Cpu, Memory, Network, and Physical storage). This causes the empowerment of the security because there is nothing any kind of the third party resource so that attacker couldn’t compromise with anything. 

Cons: One problem with Type-1 hypervisors is that they usually need a dedicated separate machine to perform their operation and to instruct different VMs and control the host hardware resources.

TYPE-2 Hypervisor:   A Host operating system runs on the underlying host system. It is also known as ‘Hosted Hypervisor”. Such kind of hypervisors doesn’t run directly over the underlying hardware rather they run as an application in a Host system(physical machine). Basically, the software is installed on an operating system. Hypervisor asks the operating system to make hardware calls. An example of a Type 2 hypervisor includes VMware Player or Parallels Desktop. Hosted hypervisors are often found on endpoints like PCs.  The type-2 hypervisor is very useful for engineers, and security analysts (for checking malware, or malicious source code and newly developed applications).

Pros & Cons of Type-2 Hypervisor:

Pros: Such kind of hypervisors allows quick and easy access to a guest Operating System alongside the host machine running. These hypervisors usually come with additional useful features for guest machines. Such tools enhance the coordination between the host machine and the guest machine.

Cons: Here there is no direct access to the physical hardware resources so the efficiency of these hypervisors lags in performance as compared to the type-1 hypervisors, and potential security risks are also there an attacker can compromise the security weakness if there is access to the host operating system so he can also access the guest operating system.

Choosing the right hypervisor  :

Type 1 hypervisors offer much better performance than Type 2 ones because there’s no middle layer, making them the logical choice for mission-critical applications and workloads. But that’s not to say that hosted hypervisors don’t have their place – they’re much simpler to set up, so they’re a good bet if, say, you need to deploy a test environment quickly. One of the best ways to determine which hypervisor meets your needs is to compare their performance metrics. These include CPU overhead, the amount of maximum host and guest memory, and support for virtual processors. The following factors should be examined before choosing a suitable hypervisor: 

1. Understand your needs: The company and its applications are the reason for the data center (and your job). Besides your company’s needs, you (and your co-workers in IT) also have your own needs. Needs for a virtualization hypervisor are: 

a. Flexibility  b. Scalability  c. Usability  d. Availability  e. Reliability  f. Efficiency  g. Reliable support 

2. The cost of a hypervisor: For many buyers, the toughest part of choosing a hypervisor is striking the right balance between cost and functionality. While a number of entry-level solutions are free, or practically free, the prices at the opposite end of the market can be staggering. Licensing frameworks also vary, so it’s important to be aware of exactly what you’re getting for your money. 

3. Virtual machine performance: Virtual systems should meet or exceed the performance of their physical counterparts, at least in relation to the applications within each server. Everything beyond meeting this benchmark is profit. 

4. Ecosystem: It’s tempting to overlook the role of a hypervisor’s ecosystem – that is, the availability of documentation, support, training, third-party developers and consultancies, and so on – in determining whether or not a solution is cost-effective in the long term. 

5. Test for yourself: You can gain basic experience from your existing desktop or laptop. You can run both VMware vSphere and Microsoft Hyper-V in either VMware Workstation or VMware Fusion to create a nice virtual learning and testing environment. 

HYPERVISOR REFERENCE MODEL  : There are 3 main modules coordinates in order to emulate the underlying hardware:   

• DISPATCHER:   The dispatcher behaves like the entry point of the monitor and reroutes the instructions of the virtual machine instance to one of the other two modules.   
• ALLOCATOR:   The allocator is responsible for deciding the system resources to be provided to the virtual machine instance. It means whenever a virtual machine tries to execute an instruction that results in changing the machine resources associated with the virtual machine, the allocator is invoked by the dispatcher.   
• INTERPRETER:   The interpreter module consists of interpreter routines. These are executed, whenever a virtual machine executes a privileged instruction.  

Please Login to comment...

Similar reads.

• virtualization

Improve your Coding Skills with Practice

What kind of Experience do you want to share?