[Xen-devel] [PATCH v2 00/18] Argo: hypervisor-mediated interdomain communication

[Christopher Clark <christopher.w.clark@xxxxxxxxx>]

This is the second version of the patch series that implements the Argo
hypervisor-mediated interdomain communication mechanism as an experimental
feature for incorporation into the Xen hypervisor.

Feedback from version one has been incorporated, with notable changes:

* VIRQs are used exclusively for signal delivery
  (ie. not raw events, or ISA IRQ in this version).

* The get_config operation has been dropped from the series since the
  raw event channels are not in use and channel number need not be queried.

* The memory pages supplied by the guest in the register ring operation
  are described using values that indicate page address and granularity
  rather than guest frame number.

* Xen's soft reset operation has been implemented.

* The compat machinery for validating hypercall arguments structures
  has been enabled.

* 'goto' has been reintroduced by popular demand, and indentation
  decreased.

* Comments have been added where reviews have identified queries;
  commit messages are expanded.

* Xen-prefixes have been applied throughout the public header,
  and then everywhere else to match.

* The public header has been relicensed under the terms of the
  BSD License, with sign-off to be confirmed by Citrix with this series.

* Several patches melded, folding related work together.

and more.

Thank-you to Paul, Jan, Julien and Roger for the extensive and helpful
reviews of the first version of this series.

Christopher

===
v1 cover letter:

Relevant to the ARM deadline for inclusion in the Xen 4.12 release,
there are very few and only minor ARM-specific changes in this series.

This is derived from the v4v work of XenClient, retained in the OpenXT
Project and developed further by Bromium in uxen. It has benefitted from
and been improved by previous rounds of review in this Xen community,
and is the combined work of a series of Xen engineers that have
preceeded the efforts of the current submission.

The motivation for this feature continues to be that a non-networking,
non-shared memory, hypervisor-mediated communication mechanism between
domains concurrently executing on the same hypervisor has attractive
properties for use cases that value strong mechanisms for policy
enforcement and isolation.

In this series, Argo is made optional for inclusion via Kconfig. When
included, it defaults to disabled and requires a Xen boot parameter to
enable it.  It has XSM integration for access control over
domain-to-domain communication, and a second boot parameter governs the
level of permissiveness over shared communication rings when using the
non-XSM/Flask default.

Design documentation can be found on the Xen wiki, at:
https://wiki.xenproject.org/wiki/Argo:_Hypervisor-Mediated_Exchange_(HMX)_for_Xen

and it will be updated to correspond to the submission here in the coming days.

Argo has recently been discussed on the Xen x86 Community Call, minutes:
https://docs.google.com/document/d/1VUPdWwd1raDOPhjReVVkmb6YoQB3X5oU12E4ExjO1n0/edit#heading=h.mz1wjb9vekjn

In (very) short, Argo is implemented by a new hypercall with five operations:
    * register ring
    * unregister ring
    * sendv
    * notify
    * get config

Ring registration is performed by a domain to provide a region of memory
for receiving messages from one or many other domains. A domain can
issue a send operation to send messages to another domain's ring. The
data is transferred synchronously by the hypervisor. There is no shared
memory between domains, allowing for increased confidence by the domain
that the memory accesses in the registered ring conform to the expected
protocol. The hypervisor is able to enforce access control policy over
the communication.

== Naming

v4v lives on in the Bromium uxen codebase. It is not the same
implementation as this, it doesn't have quite the same properties and
I don't expect the two to converge (though I do hope continued
cross-pollination will happen). Given that, this feature needs to be
describable with a different name.

It's also a complex enough system, with design details that matter and
affect important properties of it, that a generic term (eg. "message
rings") is not sufficient.

Xen's name originates from Xenia, the ancient Greek concept of
hospitality. Argo is the ship from Greek mythology that provided secure
transport for the mission to obtain the Golden Fleece. This feature aims
to provide secure transport.

With this series, I'm proposing that this work shall use the name: argo.
(short, pronouncable, unique within Xen's context so acceptable in code
and material artefacts will be discoverable with a search engine.)

Valued feedback was given in review prior to this posting about whether
naming aspects of the implementation 'argo' was ok. I took this
seriously, and spent significant time looking at how to reduce the level
of argo-ness in this implementation. This version does incorporate changes
from that effort but in general, my view is that use of the name in the
code assists the clarity of it, so much of it has been retained.

The term "Hypervisor-Mediated data eXchange (HMX)" was introduced in a
presentation at the Platform Security Summit 2018, to describe the
general, hypervisor-agnostic, capability of data transfer between
domains performed by the hypervisor. It is viewable at:

  https://www.platformsecuritysummit.com/2018/speaker/clark/

Argo conforms to HMX as described, as does Hyper-V's message-sending
primitive.

== Future items

The Linux device driver used to test this software is derived from the
OpenXT v4v Linux device driver, available at:
    https://github.com/OpenXT/v4v
The Argo implementation is not yet ready to publish (focus has been on
the hypervisor code to this point). A Linux device driver suitable for
inclusion in Xen will be submitted for a future Xen release and
incorporation into OpenXT.

This submission does not include a firewall for constraining
domain-to-domain communication. The XSM hooks added currently provide
granularity of control at domain-to-domain level. We intend to extend
this to provide finer-grained access control in a future submission, but
the current implementation should be sufficient to provide sufficient
isolation for some use cases.

Communication between VMs at different levels of nesting in a
multi-hypervisor system is of strong interest and will inform near-term
enhancements.

Optimization of notification delivery to VMs is a known area for improvement.
* uxen's v4v uses an edge-triggered interrupt to reduce VMEXIT load.
* delivering extended notification data via a dedicated registered ring
  will allow a guest to avoid a search to identify notification causes.

Additional items will be noted on the Xen wiki.

== Credits

Contributors to the design and implementation of this software include:
James McKenzie, Jean Guyader, Ross Philipson, Christopher Clark

with the support of the OpenXT Project.

Thanks are due for the helpful reviews of earlier revisions by
Tim Deegan, Jan Beulich, Ian Campbell and Eric Chanudet.


Christopher Clark (18):
  argo: Introduce the Kconfig option to govern inclusion of Argo
  argo: introduce the argo_message_op hypercall boilerplate
  argo: define argo_dprintk for subsystem debugging
  argo: init, destroy and soft-reset, with enable command line opt
  xen: add simple errno-returning macros for copy from guest
  xen: add XEN_GUEST_HANDLE_NULL macros for null XEN_GUEST_HANDLE
  errno: add POSIX error codes EMSGSIZE, ECONNREFUSED to the ABI
  xen/arm: introduce guest_handle_for_field()
  xsm, argo: XSM control for argo register; add argo_mac bootparam
  xsm, argo: XSM control for argo message send operation
  argo: implement the register op
  argo: implement the unregister op
  argo: implement the sendv op; evtchn: expose send_guest_global_virq
  argo: implement the notify op
  xsm, argo: XSM control for any access to argo by a domain
  xsm, argo: notify: don't describe rings that cannot be sent to
  argo: validate hypercall arg structures via compat machinery
  argo: unmap rings on suspend; signal ring-owners on resume

 xen/arch/x86/guest/hypercall_page.S   |    2 +-
 xen/arch/x86/hvm/hypercall.c          |    3 +
 xen/arch/x86/hypercall.c              |    3 +
 xen/arch/x86/pv/hypercall.c           |    3 +
 xen/common/Kconfig                    |   20 +
 xen/common/Makefile                   |    3 +-
 xen/common/argo.c                     | 2296 +++++++++++++++++++++++++++++++++
 xen/common/compat/argo.c              |   60 +
 xen/common/domain.c                   |   29 +
 xen/common/event_channel.c            |    2 +-
 xen/include/Makefile                  |    1 +
 xen/include/asm-arm/guest_access.h    |   23 +
 xen/include/asm-x86/guest_access.h    |   20 +
 xen/include/public/argo.h             |  284 ++++
 xen/include/public/errno.h            |    2 +
 xen/include/public/xen.h              |    8 +-
 xen/include/xen/argo.h                |   25 +
 xen/include/xen/event.h               |    7 +
 xen/include/xen/guest_access.h        |    3 +
 xen/include/xen/hypercall.h           |    9 +
 xen/include/xen/sched.h               |    6 +
 xen/include/xlat.lst                  |    7 +
 xen/include/xsm/dummy.h               |   26 +
 xen/include/xsm/xsm.h                 |   31 +
 xen/xsm/dummy.c                       |    6 +
 xen/xsm/flask/hooks.c                 |   41 +-
 xen/xsm/flask/policy/access_vectors   |   16 +
 xen/xsm/flask/policy/security_classes |    1 +
 28 files changed, 2929 insertions(+), 8 deletions(-)
 create mode 100644 xen/common/argo.c
 create mode 100644 xen/common/compat/argo.c
 create mode 100644 xen/include/public/argo.h
 create mode 100644 xen/include/xen/argo.h

-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel