Released as Open Source Software (OSS) in June 2014, OpenXT is a collection of hardened Linux VMs configured to provide a user facing Xen platform for client devices. This default configuration was mostly static, applying some disaggregation techniques to segregate system components based on a general threat analysis. The goals embodied in this code base up to its release produced a one-size-fits-most configuration with extensibility in specific areas to encapsulate 3rd party value-add. With a community now forming around OpenXT we must come to terms with the limitations of the this approach. In this talk Philip will define what OpenXT is and in this definition, show that OpenXT can meet the varied needs of the security and virtualization community through the construction of a toolkit for the configurable disaggregation of a Xen platform.

1. OpenXT
Philip Tricca<flihp@openxt.org>
@flihp
XenSummit2014
the open virtual platform

2. Background
•Work on Xendom0 disaggregation goes back 10 years
–Fault-tolerance, Performance & Scalability
–Security and scalability
–Relevant papers collected @ http://openxt.org/references.html
•Talks about Xenand Disaggregation / Security @ XenSummit
–Client Virtualization Framework, Ze'evMaor@ Neocleus, 2009
–Disaggregated Xen, Patrick Colp@ University of British Columbia, 2011
–XenClientXT, GianlucaGuida@ Citrix, 2012
–Windsor / XCP disaggregation, James Bulpin@ Citrix, 2012
–Secure Server Project, Jason Sonnek@ Adventium, 2013
–XenClientXT,PhililpTricca(me) @ Citrix, 2013
•LinuxCon
–Securing your Xen-Based Cloud,George Dunlap @ Citrix, 2013
–Security in the Cloud: Containers, KVM, and Xen, George Dunlap @ Citrix, 2014

3. Terminology
•Guest VM: user facing VM (windows / linux)
•Service VM
–as defined in Xoarpaper
–Virtual machine providing ‘services’ to guests
–Can provide duplication for scalability
–Can perform security sensitive function for isolation
•APIs
–Well defined interfaces between components
–Xenfront/back device model (block, network)
–Platform API like input / ouputplugin architecture
–DBusover Inter-VM communication API
–Application level discovery, proxies, interposition / layer 7 etc

4. Disaggregation: Scalability / Security
bump-in- the-wire
Guest
VM 1
Device Isolation VM
bump-in- the-wire
Guest
VM 2
•Model described in the earlier literature
•Implemented in Qubes, OpenXT, XCP
•Scalability / security by removing dom0 from I/O path
•Value-add @ bump-in-the- wire (encryption, introspection)
F
B
F
B
F
B
F
B

5. Disaggregation: Management
•Model described in Xoarand XenClientXT XenSummittalk
•Cursory implementation in OpenXT
•Separates sphere of influence of mgmt. domain
•Can provide compatibility for multiple toolstacks
•API between mgmt. and outside world & domain builder
•Think libvirtand xapimgmt. on one system
Guest
VM 1
Mgmt
Service VM 1
Guest
VM 2
Guest
VM 3
Mgmt
Service VM 2
Guest
VM 4
Domain Builder
NDVM

6. Disaggregation: Future
•Disaggregation at application level
–Graphics composition
–Peer-to-Peer storage / transfer
–Mesh networking
–“Layer 7” protocol / data interposition
•Proxies of all colors
•In-line rewriting / injection: javascriptetc
•Unikernels/ Pioneering OS research
–Service VM as a unit of experimentation & innovation
–Minimal driver work (PV)
•Purpose-built appliances
–Mesh networking
–Anonymity proxies
–ClickOS

7. Where We Are
•“the Snowden effect”
•Increase use of privacy preserving tech
–Tor
–Startpage/ Ixquick
–SSL protected traffic increased from 1% to 3%

8. Where We Are
•(U) I hunt sys admins
–Targeted attacks on high- value targets
–Targeting the tech community
•Response
–BlackPhone
–Protonet(huge crowd- funding campaign)
–Whisper Systems: RedPhone/ TextSecure/ Flock
–TrueCryptaudit
–Tor PORTAL
–cryptech.is
•Produces results or rhetoric?
–BlackPhoneHacked in 5 minutes@ DEFCON
–Protonet“NSA-Proof” / “Data Sovereignty”

9. •XenClientXT 3.0released 2012
•Subsequent maintenance releases
•OpenXT0.01 released June 2014
–https://github.com/OpenXT(59repos)
•Focus remains
–Platform disaggregation & integrity: benefitsfor security and scalability
–Mainstream client devices
•Room for growth
–Additional device profiles
–Platform research & value-add
Who / What is OpenXT

10. What We Have
•Platform is infrastructure
–Others have built bridges
–We’ve built another one
•Economic value
–transporting “stuffs” from one side to the other
–How many “stuffs” (quantity variety)
–Implies extension
–How safe are the “stuffs” in transit
•So Many XenPlatforms
–Client Virtualization Framework (CVF)
–XenClientInitiative (XCI)
–XenCloud Platform (XCP)
–OpenXCI
–Qubes
–OpenXT

11. What We Want
•Have
–Platform, means for extension and working examples
–Full build environment
•Want
–Curators: maintainers for core platform components
–API hackers: Inter-domain communication (IDC)
–Service VM developers
–Accelerated Graphics
•Paul Durrant: Multiple Device Emulators for HVM Guests
–AMD DRTM / SKINIT & security co-processor
–Composablestorage layer with integrity measurement
•Collaboration with other OSS projects
–Service VM compatibility (XCP / OpenXCI/ Qubes/ Alpine Xen)
–New Service VMs (HalVM/ Mirage / ClickOS/ CoreOS)
–New hardware targets
•“Headless” mode for server
•ARM compatibility

12. Service VM SDK
•Virtual Appliance –initial prototype OVF
•Rootfstemplate (immutable)
•Configuration (immutable)
•Configuration (user / administrator writeable)
•Data (writeable)
•Map concepts from current “containerization” projects to strong isolation in Service VM
–Migration tool
–VtoVmigration
•Better tools and documentation

13. Why this “virtual platform”?
•Buildable from source by anyone who reads docs
–Embedded-style build using OpenEmbedded(OE) / Yocto
–OE layer / distromechanisms support flexible build time config
–Small change in workflow brings larger benefits
•Configurable disaggregation granularity at build-time
–Respect hardware constraints
–Embedded / Client / Server / Cloud
–(Everything is embedded, you just don’t know it yet)
•With specific security properties
–Minimize added threat to guest beyond bare metal
–Improve security properties where possible
–Integrity measurements rooted in hardware
•Have Intel via tboot, want AMD SKINIT
–Mandatory access control

14. “Upstreaming”
•OpenXThas a lot of code that forks “upstream” currently
–Not sustainable
•OpenXTwill aim to treat everything as an upstream except
–Unique build metadata
–Configuration
–Platform mgmt.
•Contributions to upstream OE
–Xenrecipe in meta-virtualization (thanks Chris!)
–meta-selinux(lots already)
–meta-measured (TPM / TXT / measurement architecture)

15. Upstream
Development
Upstream
Platform
OpenXT
OSS Distro
Upstream
Build Metadata
Bitbake/ OE / YoctoMetadata
RPM Metadata
DPKG Metadata
Upstream
Build System
Downstream
Consumer
OE / YoctoImage Recipes
Scripts + apt
Spins / Pungi
ServiceVMProvider
Cloud
IaaS/ PaaS/ SaaS
Hardware OEM
OSV Distro/ Embedded
Xen
toolstacks
Qemu
GNU
.
.
.
Linux
Ecosystem

16. OpenXT
•Project page
–http://openxt.org
•Project repos hosted on Github
–https://github.com/OpenXT
•OpenXTdocumentation / build instructions
–https://github.com/OpenXT/openxt/wiki/
•Google Group
–https://groups.google.com/forum/#!forum/openxt