What needs doing?

Copyright 2014 by Assured Information Security, Inc. Created by Ross Philipson <philipsonr@ainfosec.com>. This work is licensed under the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/.

Tasks suitable for newcomers to OpenXT

Here are some JIRA tickets that should be approachable for newcomers to OpenXT who are looking to get some practical experience with development or documentation. Before getting started, if the ticket already has an Assignee, you should contact that person to see if the work is already under way.

type key summary assignee reporter priority status resolution created updated due

Items listed below this point will be less suited to newcomers.

Task List - A Starting Point

This is a first cut of putting together a task list of things that need to get done or we would like to get done. Each top level item may has a sub-list of smaller tasks listed. Many of these items were on other people's lists too (others involved in the OpenXT project). I am not including effort/time estimates or trying to prioritize these items at this time. I started it here on this wiki so it can be discussed, modified, added to, etc. Eventually we would want to get these items into Jira (and the details of how to do that may need discussion also). I did not use a table because they are not very friendly when using the Github wikis. Please feel free to edit...


Update TBOOT

Our current TBOOT if quite old. It needs a serious upgrade to the latest. This would be an ongoing task as new TBOOT versions are released. Update schedules would have to be carefully planned.

  • Update to the newest TBOOT. In progress - moving to 1.8.3 as of 9/18/2015
  • Clean up the patch queue and upstream patches where possible.
  • Pick up UEFI support.
  • Update TPM tools and remove custom ones (Phil knows about this). Need TPM 2.0 support.
  • Update Trousers, need TPM 2.0 support.

Update Xen

We would like to track upstream as closely as possible and minimize our patch queue. This would be an ongoing task as new Xen versions are released. Update schedules would have to be carefully planned.

  • Update to Xen 4.6 (or newer).
  • Clean up the patch queue and upstream patches where possible.
  • Get rid of unneeded patches, old functionality, etc.
  • Pick up latest RTDS (real time scheduler) functionality.

Update Dom0 Kernel

Again, we would like to track upstream as closely as possible and minimize our patch queue. This would be an ongoing task as new Kernel versions are released or new hardware support is needed. Update schedules would have to be carefully planned.

  • Update to latest reasonable Linux 4.x LTS. In progress.
  • Move to 64b kernel?
  • Clean up the patch queue.

Open Embedded Enhancements

Moving to a new OE and using layers. TODO leaving mostly for others to fill in.

  • Update OE to "dizzy"
  • Remove/eliminate redundant recipes that conflict/overlap with upstream
  • Upstream recipes that aren't openxt-specific package but might find a good home in another upstream layer.
  • Uprev bitbake & upstream/eliminate bitbake patches/classes where possible.
  • Simplify do_build.sh, finding what solutions the OE community use to the work done in it and adopting or innovating in OE where possible.
  • Look at moving back to the standard OE approach of referencing the openxt repositories by commit ID and secure content hash rather by branch. As well as making OpenXT less unusual this would make versioning simpler since you'd need to consider versions in many fewer repositories which makes consistent updates to OpenXT easier (get your work merged into central repositories and then later get the updates made to openxt's OE recipes to move standard builds over to it). We'd still need good workflows for developers to test their changes to OpenXT specific components.
  • Create a layer repo for each of the major patch queues (undo the big move of all the pq repos into xenclient-oe).


This is a blanket item to cover all the PV USB work. Some of the specifics...

  • Comprehensive USB testing, write test plan.
  • Upstream the drivers into Linux and the XenServer Windows PV drivers.
  • Upstream usbback into Xen.
  • USB 3

Dependencies: XenServer PV Windows Drivers

XenServer PV Windows Drivers

The current PV driver set is a very old version of the XenServer drivers. People on the XenServer and platform teams at Citrix did a huge amount of work to open source the latest XenServer drivers and it seems they are becoming the industry standard:https://github.com/xenserver

  • Integrate the XenServer PV Windows drivers into OpenXT (building/packaging/etc). In progress.
  • Make OpenXT additional drivers work with the XenServer drivers (esp. xenbus).
  • Modification to the SDK Windows bits to use the new XenServer drivers.

UEFI Support

There may come a time when we see vendors begin to not support CSMs in their UEFI firmware any longer. OpenXT needs to be prepared for that. This mainly means supporting UEFI booting through GRUB2 using multiboot2 structures. For OpenXT this means TBOOT, Xen and Dom0 must have these new multiboot2 capabilities. It also means supporting GPT partitioning.

  • Updated TBOOT with multiboot2/EFI support. Will pick this up with the move to 1.8.3.
  • Updated Xen with multiboot2/EFI support.
  • Ensure Dom0 kernel support for multiboot2/EFI.
  • Installer changes for supporting GPT.
  • Platform changes for supporting GPT.

Dependencies: Update TBOOT, Update Xen

Toolstack Core Changes

This seems like a very broad item but here it is specifically addressing the core pieces like xenmgr->xenvm->libxc.

  • Documentation! Especially the Haskell and OCaml bits. This will help in making some of the other decisions. In progresss - Martin has started this.
  • The future of the Ocaml code and moving to libxl (or something else).
  • Investigations into how well libxl scales.
  • The future of the Haskell code and what to do with xenmgr and friends.
  • Domain startup is tricky ... qemu-wrapper/dm-agent/svirt/.../qemu. We should do something about that (documentation at least).

Dependencies: Everything

Graphics Stack

This is the Display Handler project introducing a whole new graphics architecture.

  • RFC post for review. In progress, at least a first draft was submitted.
  • XenGT/GVT-g plan for OpenXT
  • TODO leaving this for others to fill in.

Dependencies: Input Server Changes, PV USB, Superhid

Input Server Changes

The input server definitely needs a major overhaul and may need a complete redoing (to be seen).

  • First need a specification or RFC document as a starting point.
  • Using libinput was brought up as a possibility.
  • Changes to support new graphics stack.

Dependencies: Graphics Stack


Superhid introduces a whole new way of creating virtual USB devices in guests, allowing guests to use native drivers and software to do all the standard HID business.

  • RFC post for review.
  • Proof of concept. In progress.
  • TODO more on this.

Dependencies: PV USB, Graphics Stack

Build Improvements

There are a number of things we can do better at...

  • Use the OE SBUILD class to create Debian (.deb) tools packages for guests and service VMs (already written, mostly works).
  • Use the Haskell RPM builder to create CentOS (.rpm) tools packages for guests and service VMs (already written but it is not clear what state it is in).
  • Get rid of the mess of scripts for building tools packages.
  • Reduce the number of machine specific package builds and the number of machines.

Interdomain Communications

We have V4V currently. Do we push forward with it and fix it or consider another approach like one of the grant models. Note that V4V will never be upstreamed into Xen so this is a rather largish nail in the coffin.

  • RFC and discussions on how to proceed.
  • Possibly fixing V4V.
  • Fixing V4V also entails addressing issues that came up during the open source effort as well as known bugs.
  • In the short term, porting the Windows driver to the XenServer xenbus.
  • V4V should have a socket class too.
  • Possibly using a grant model like libvchan. This would require writing a lot of new stuff.

Dependencies: XenServer PV Windows Drivers

Standardize RPC Communications

OpenXT currently has multiple RPC mechanisms and no real standards for interfaces and proxies etc.

  • DBus/DMBus, keep both move to just one of them? (DMBus and DBus overlap most of the time...)
  • Some DBus messages should be DMBus unless we decide to drop DMBus.
  • Bouncers & proxies should have libraries with interface handling and be consistent.
  • Statically linked binaries in stubdoms contributes to this mess and is unnecessary.

Audio Improvements

Really kind of a general bucket for audio related tasks and issues.

  • Audio microphone.

BVT Automated Tests

The original BVT automated test framework was also pushed to open source under the openxt-extras organization. Good automated tests may be key to success of the overall project.

  • Improvements to the existing framework (in progress). Some work was done on this by Chris R. in 2014/2015.
  • Deployment/integration within a larger build infrastructure.
  • Engineering participation in test writing.

Sync XT Improvements

  • implement postgresql as an alternative (or replacement if we can do migration?) to the use of the Oracle RDBMS.
  • selinux policy for the server
  • selinux policy for the client syncvm
  • an open source web interface for SyncXT

vTPM Integration

Adopting the vTPM work done in Xen and elsewhere in OpenXT.

  • Basic integration with existing vTPM solutions.
  • TODO and beyond that
  • TODO remote attestation, realm support, etc.


OpenXT needs a plan for documentation. Currently there are just a bunch of PDFs pushed out in the open source effort.

  • Sorting out the mess that is the docs.git repo. We need to work with Citrix on this. In progress.
  • What tools etc do we use to edit and maintain documentation.
  • Mechanisms for ensuring documentation is kept up to date and ready for eventual OpenXT release cycles.
  • Proper READMEs in the repos to explain what is in them.

Done Stuff

Update TBOOT

  • Patch for CVE-2014-5118. Done, up-streamed.

Update Dom0 Kernel

  • Update to latest reasonable Linux 3.x. Maybe stick with LTS ones? Done by Eric in 2015, moved to 3.18.19.
  • Download from kernel.org and don't use Ubuntu kernels (like linux- Done.

Update QEMU

  • Finish move to 1.4 (in progress). Done by Eric et al in 2014/2015.
  • Get rid of unneeded patches, old functionality, etc.


  • Stabilize the new PV USB solution in OpenXT. Done by Ross in 2014.
  • Create a Linux front end driver. Done by Ross in 2015.
  • Rewrite the vusb dom0 deamon(s). Done by Jed in 2015.

OpenXT PV Linux Drivers

  • Get rid of the duplicate drivers. Done by Ross in 2015.
  • Re-base the remaining drives on PVOPS xenbus. Done by Ross in 2015.