Priorities for OpenXT Derivative Appliances

(A) OpenEmbedded Jethro Migration

• The public AIS auto-builder does not have the compute/storage capacity to generate Jethro builds. Additional hardware has been requested, but will not arrive in the near term. There is not yet a public, Jethro-based OpenXT installer ISO binary available for testing.
• To improve the efficiency of Jethro development and testing, it was decided that Adam's work should be submitted as a PR and merged to OpenXT master at the earliest opportunity, after branching. This will make ISOs available from the current auto-builder.
• Anyone who has built and tested Jethro is asked to document what is known to be working or not working, to avoid duplication of testing and bug reports after the merge. Jethro-related regressions can be documented in JIRA, see OXT-26 and OXT-426 for the OE upgrade epics. There is outstanding work for SE Linux.

(B) SecureView roadmap/schedule dependencies may reduce near-term testing and development capacity for Jethro stabilization

• There is a SecureView release targeted for Jan. 2016.\
• Following the upcoming SecureView release, there is a requirement to support Skylake hardware ASAP, which may require moving to the Linux 4.3 or 4.4 kernels. This requirement is driven by OEMs phasing out sales of Broadwell devices, typically within one quarter of the release of a new Intel hardware generation.
• TPM Versions: HP has shipped some Broadwell devices with BIOS-level selection of either TPM 1.2 or TPM 2.0. Other devices (e.g. Broadwell NUC) include only TPM 2.0, not yet supported by OpenXT.

OpenXT Platform Definition

(A)  Discussion of development process, governance, discovery of base platform properties and definition of optional use case layers:

• R. Philipson will document the existing lightweight process that is used by the AIS OpenXT team for open-source development.
• R. Philipson will work on a "bottom-up" analysis of existing OpenXT components. 
• M. Gregory will work on a "top-down" architecture analysis of system-level principles, properties and security claims, independent of implementation convenience. 
• If we can reduce the number of OpenXT-unique components by migrating to well-maintained upstream alternatives, there will be less to govern and finance. If an OpenXT component provides unique value, then it may be modified for upstream adoption and governance by other open-source projects. If an OpenXT component has high value only to OpenXT derivatives, then it would need to be maintained and governed exclusively by the OpenXT community.
• When a governance process is agreed upon, it can be used to ratify a list of OpenXT system-level principles and properties. Component designs and implementations could then be evaluated for compliance with OpenXT system-level principles and properties.

(B)  Discussion of a possible scenario to incrementally rebuild the platform using upstream projects and components. The following summary was provided by M. Gregory, without assertions on feasibility or timeline.

OpenXT Rebuild: A Thought Experiment

The goal of this exercise is to understand the fundamental design choices that were made in the development of OpenXT. Additionally, the information documented as a part of this exercise will be valuable in refactor the OpenXT project.

1. Enumerate the functional requirement s for OpenXT

2. Enumerate the security requirements

3. Enumerate any constraints

Start with a small “runnable” OpenXT system of an initramfs and dom0. Identify the core image functionality for booting the system and strip out all other functionality. Upstream images like xen-image-minimal may serve as a good comparisons. Identify and document the functional and security requirements met by the initramfs and dom0 base system.

Add a core service VM, like UIVM, back into the system. Identify the functional and security requirements that the UIVM meets. Use the requirements to identify the core functionality. Strip the UIVM domain down to its core functionality needed for the current system and to meet identified requirements. Enumerate all new functional and security requirements that stem from the addition of the core UVIM. For instance, a new security requirement stating that only the UIVM has access to the graphic and input devices.

Add in code to support interactions between the Dom0 and the UIVM. The code that is added by into the build should be grouped into services or functional units. Evaluate each functional unit against identified security properties ensuring they are not violated. Additionally, document alternatives to the functional units. For example, v4v would be functional unit providing inter-VM communication.

This process should continue until all domains and functionality has been added back into the system. The results of this process will be a “complete” set of functional and security requirements, as well as a design tree. The design tree will contain all design choices as well as alternatives.