Linux stub domains

Linux stub domains are used in QubesOS and OpenXT.
* (2018) Linux-based Device Model Stubdomains in Qubes OS, Marek Marczykowski-Górecki
* (2018) Xen Security Weather Report 2018, Lars Kurth
* (2017) MSI support for PCI device pass-through with stub domains, Simon Gaiser
== Upstreaming ==
todo: add remaining patches
00/17 Add support for qemu-xen runnning in a Linux-based stubdomain:
* Aug 2018, v2 patch
* Jul 2018, v1 patch
05/17 libxl: Handle Linux stubdomain specific QEMU options:
* Jan 2019, v3 patch
* Aug 2018, v2 patch
08/17 xl: add stubdomain related options to xl config parser
* Jul 2018, v1 patch
== Interfaces between stubdom QEMU and dom0 ==
* (June 2019) qemu-stubdom<=>dom0 interface changes
* (June 2019) Requirements for PVH stubdoms
== Xen Summit 2019 Design Session ==
=== Display architecture proposed by Brendan K ===
* migrate from display changer on Qubes and OpenXT surfman, to upstream Xen interfaces (from EPAM)
* use Linux 5.1 drm-front driver for displayif
* share common codebase for: EPAM, Qubes, OpenXT, Redfield
=== QMP discussion === 
Proposal: 
- LibXL and block backend: change "xenstore stuff" to "QMP stuff"
Concerns: 
# QMP is not a simple protocol.
# xenstore-based protocol is much simpler than a JSON-encapsulated protocol.
# There have been multiple historical bugs in parsing of JSON in C. 
# If we extend QMP support in LibXL and are communicating with a potentially compromised QEMU process, it would be a security regression.
Possible mitigations for a potentially compromised QEMU
# Reduce privileges given to the QEMU instance
# Limit interfaces to the QEMU instance
# Work with upstream QEMU to propose a new safer-than-JSON alternative marshalling format backend
# Minimize what LibXL does with QMP messages: use an off-the-shelf JSON firewall/translator/filter in the untrusted guest, limited to the QEMU subset of JSON
# Don't talk to QEMU after the device is started: mostly done today, but does not work for some corner cases: optical drive insert, device hotplug
# Have an option to intentionally break all QMP communications
Other notes:
* Qubes uses dracut for build, OpenXT uses OE
* For OpenXT/Qubes, many QEMU functions can build-time disabled
* For Debian/SuSE distro, the generic QEMU binary has many functions enabled. It may be an option to ship "minimal QEMU" and "minimal kernel" configured binaries for distro stubdoms.
Actions:
* Marek to resubmit Linux stubdom patches to xen-devel, ask people to comment on which patches have consensus or open discussion items
* Ian J can review patches in mid-August
* Upstream Xen will merge the ones which are not contended
* Work towards consensus on contended patches
== Additional Notes ==
=== QMP in Qubes and OpenXT ===
Connection between the qemu device model and the libxl toolstack requires a communication channel to be established between the separate domains where they are run, which is then used to deliver QMP traffic in both Qubes and OpenXT.
Qubes uses a vchan-socket-proxy:
https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/blob/master/rootfs/init#L147
https://github.com/QubesOS/qubes-vmm-xen-stubdom-linux/blob/master/helpers/vchan-socket-proxy.c
OpenXT uses a qemu character device that delivers via Argo to a helper process in dom0:
https://github.com/OpenXT/xenclient-oe/blob/9.0.2/recipes-extended/qemu-dm/qemu-dm/qmp-argo-char-driver.patch
https://github.com/OpenXT/xctools/blob/9.0.2/qmp_helper/src/qmp_helper.c
The Xen toolstack libxl is currently dropping QMP Events after parsing them from JSON, so filtering at the qemu source could reduce the volume of interactions over the channel:
https://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=tools/libxl/libxl_qmp.c;h=9aabad74fabd7bfd27b2bac153973c612a46a3c2;hb=HEAD#l278