...
- Argo is now in upstream Xen and correspondingly the Linux driver needs to be prepared for upstreaming to the Linux kernel
- vsock is upstream in Linux, there are transports for virtio and VMware, https://vmsplice.net/~stefan/stefanha-kvm-forum-2015.pdf
- vsock can provide the socket behavior, which should minimize resistance in getting the driver suite upstreamed
- The driver should expose two separate interfaces: a vsock interface and a character device
- The driver should be built as a common
argo-core
– along the lines of uXen'suxenv4vlib
– with both char and vsock drivers then leveragingargo-core
- Using the existing socket-like interface on the character device does not depend on availability of a network stack
- Potentially useful for minimal services VMs
- Change requested: "The char driver behavior should be reduced back to that of a conventional Linux char driver"
- Xen’s Argo interface will change to support message labeling
- This will enable the kernel to access the XSM/Flask SID label with the arriving data that it is associated with
- OXT-1503: Argo peer labelling for access control
- Test coverage for this will be required, so a method of enabling test cases to access and validate it needs to be determined
- Kernel use of the label: guidance in Smalley presentation on OpenXT's access control at OpenXT Summit 2016
- Should the label be surfaced to userspace?
- How should either the vsock or chardev interfaces support Argo-specific functionality?
- ie. Is the chardev interface the correct interface between userspace and the kernel to provide support for Argo-specific, non-traditional character device, functionality?
- eg. Configuring ring size
- ie. Is the chardev interface the correct interface between userspace and the kernel to provide support for Argo-specific, non-traditional character device, functionality?
- The driver should be built as a common
- The proposal for an Argo name service will need consideration of how names interact with this driver.
- The Argo firewall is currently not in upstream Xen, pending implementation of bi-directional connection tracking in OpenXT before upstreaming. The Linux driver is used to access and configure the firewall.
- Should the The firewall functions should be moved out to into a separate Linux device driver?.
Summary: the driver will need to provide:
...