Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

Xen Project 15 Years down the Line

What do “Crazy in Love” by Beyonce and the “Xen Project” have in common? They are both 15-year-old hits. Flash forward to today. The Xen Project is used by more than 10 million users, powers some of the largest clouds on the planet, and is starting to build momentum in embedded and safety-conscious market segments. The Xen Project played a key role in developing technologies outside of the hypervisor, like hardware virtualization, and open source security disclosure standards that impact entire industries.

The Xen Project’s success and longevity can be attributed to its flexible architecture, but more importantly to enabling community members to contribute ideas and code, even if they are not core to the project's main use-case. We will share how the project has supported new technologies and ideas (sometimes in the form of failures and sometimes wins) and will derive best practices that may help other projects .

4.
What is Xen and Xen Project?
Versatile Virtualization Platform
Designed to be a component in a SW stack
Ease of use for end-users was never a design goal
Xen Hypervisor = “Engine”
Taken by integrators to build a product, service, …
Analogy: integrators build a “car” with Xen as “engine”
Xen Project
Development community with several sub projects
that develop technologies related to Xen
– Hypervisor
– PV Drivers
– Unikernel related projects: MirageOS, Unikraft

13.
From the Beginning
Disaggregation was part of the original Xen conception
Influenced by microkernel thinking
The PV protocols were specifically designed for untrusted
backends and untrusted native device drivers
Particularly the grant tables
Security technologies were always in maintainers minds
They were up-streamed without resistance
Sometimes with a lot of support from maintainers

15.
Tension: Core vs. non-Core Usage
Many security technologies were not made easy to use
Disaggregation is a good example
Product schedule pressure, led to
– Core team members choosing the quick to implement / more performant
approach ➜ New features went into Dom0 first
– Maintainers reviewing non-Core contributions: takes effort to understand
and guide contributors to the best approach ➜ This did often not happen
E.g. Xen has no build capability for disaggregated domains
Led to duplication amongst vendors
Increased the barrier to adoption for newcomers

20.
2012: The Xenon Separation VMM
Secure virtualization infrastructure for military clouds (pdf)
“ We reduce the size of the code base by dropping support
for selected features that are not needed to run commodity
operating systems, e.g. Windows 7 or Linux. Because the
internal design and construction of the base Xen VMM is
highly modular, removing some of the features does not
disable any of the remaining features.
The total effort required was about 3 engineers over a
period of 2 years, and includes the effort of keeping up with
the Xen community. ”

21.
x86: Desktop / Tablet Use Cases
2009: Virtual Computer releases NxTop 1.0
NxTop is the first of 3 Xen based client solutions
Citrix and Neocleus release their first solutions in 2010
2012: Snowden-approved Qubes OS 1.0 releases
Today, Qubes OS 4.0 is the first technology to use PVHv2 in production
2013: Citrix and DoD collaborate to create SecureView
In 2015, XenClient is discontinued and released as OpenXT
SecureView continues to be developed on top of OpenXT
OpenXT, SecureView
(desktop, laptops, tablets)
Defense Applications
General purpose desktop Virtualization
XenClient, NxTop, Neosphere, Qubes OS

22.
Reflection
Early & continued engagement of Security Researchers
Security feature contributions before being productized
Xen became an attractive platform for security research
Enabler:
The Xen community accepted contributions
Modular Architecture
Enabled specialised and certifiable products for defence use
But: Innovations were not attempted to be up-streamed

23.
Reflection
Attempts to commercialize Xen on Desktop
Enabled a new products leveraging Xen’s security features
They also relied on removing upstream Xen code (on x86)
BUT:
None of these Xen capabilities were used in Server/Cloud
Related Story: GPU Passthrough & Virtualization
Were developed for Desktop Use Cases on Xen
TODAY:
GPU Virtualization is widely used in Server/Cloud

24.
Virtual Machine Introspection:
from Research to Commercial
Server Products

26.
Georgia Tech: 2007, Atlanta, USA
2007: Virtual Machine Introspection for Xen hatched at
Georgia Tech
– 2003: Initial Research by Tal Garfinkel & Mendel Rosenblum
– Bryan Payne created a project called XenAccess
Later expanded scope to other hypervisors as LibVMI
2009: XenAccess and mem-events APIs were added
Used for security research and specialist security apps
Enabler:
The project accepted these changes with active help
from maintainers

27.
Commercial interest in VMI
2013 to 2015: Intel launched its Haswell & Broadwell CPUs
Specifically VMFUNC, EPTP and #VE capabilities
New HW capabilities of Haswell & Broadwell generated
commercial interest in VMI by multiple vendors
2014 to 2015: The XenAccess and mem-events APIs were
re-architected into the VMI subsystem
In parallel: related companion technologies such as alt2pm
are being developed

28.
Productization
2015 to 2016: Citrix and Bitdefender collaborated to bring
VMI to market through XenServer 7.0 and Bidefender HVI
Today: Similar products are available from AIS and Zentific
Today: ongoing contributions by security vendors to alt2pm
indicate future productization

29.
Reflection
Few security features made it into Server/Cloud
For example: VMI & Live Patching
WHY?
HW capabilities were not enough
It was too early or the market wasn’t ready
Example: Dynamic Root of Trust related technologies
Complex and Use Case dependent
Example: Xen Security Modules - requires Specialist expertise;
configuration is Use Case dependent

35.
2012, Cambridge, UK
Xen on Arm reboot
Patches for upstream Xen on Arm support are posted
Armv7 and v8 are fully supported upstream by March 2014
The primary motivation for this work was to target Arm
based servers
Developers learned from the earlier Arm port:
– Clean and simple architecture
– Perfect match between Xen and Arm ISA
– Much smaller code size compared to Xen on x86

36.
Upstream support and simplicity
of Arm port enabled embedded
Use Cases on Arm

38.
A new Evolutionary Wave
2014: Xen moves into embedded and automotive
The Xen Project launched an automotive initiative
Xen based distros and products are being developed
2015: First automotive Xen based platform
GlobalLogic introduces the Nautilus platform at CES 2015
2015: First embedded Arm-only Xen Distro
Xen Zynq Distribution for XILINX
The last few years: R&D
Similar order of magnitude to earlier waves

40.
Sedimentation:
Functionality implemented in Software being fully or partly
implemented in Hardware
Example: PV Interrupt and Timers ➜ using IO APIC and
Posted Interrupts
Silicon vendors have always worked closely with Xen
Xen’s had a significant impact on virtualization
related technology in Hardware
I wanted to tell this story, but:
It’s very difficult to explain
And much of the work was performed under NDAs

42.
Culture enables Innovation
Accept changes for non-Core Use Cases
In our case this was not planned: we inherited the culture
But: do not sacrifice due diligence and future-proofing
Help people trying to adopt Xen for non-Core Use Cases
We were bad at this until about 3 years ago
Work with new ideas, forks and distributions
Developer Events: allow air-time for new ideas
Forks are not always bad: Samsung fork hosted by us
OpenXT (distro): close collaboration is key

43.
Process enables Innovation
Feature/Configuration Classification
Experimental ➜ Tech Preview ➜ Supported
Marked non-Core functionality as Experimental or Preview
Maintainership
Contributors need to step up for larger non-Core Features
Proves longer term commitment by the contributor
Deprecation of Features
Intent to deprecate is announced on list: identify objections
Remove non-core Features, if stale or not used

44.
Tension need to be Managed
Vendors have different Priorities
These can lead to conflicts
Non-Core vs. Core arguments can be ugly
Active community management is required
New Processes can lead to Tensions
Security Vulnerability Management led to problems
Who deals with a Vulnerability in non-Core code?
We didn’t understand this ➜ created tension and rejection
of non-Core features until we modified the process

45.
Process enables Innovation
Security Support
The security team does not handle non-Core Vulnerabilities
– Supported Feature without Security Support
– Delegated Security Support (e.g. ARINC653 scheduler)
KCONFIG based Configuration Management
Larger non-core features are build or run-time disabled
Subprojects as incubators for New Ideas
Can be used to foster innovation on the periphery
Examples: MirageOS, Automotive Project, Unikraft