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

+-----------------------------------------------------+
| +-------------------------------------------------+ |
| |                                                 | |
| |                                                 | |
| |                                                 | |
| | +-------+ +---------+ +---------+      +-----+  | |
| | |DRM DCL| | ALSA    | | evdev   |      | qmp |  | |
| | +-------+ +---------+ +---------+ QEmu +-----+  | |
| +-------------------------------------------------+ |
|       |          |           |              |       |
|       |          |           |              |       |
| +---------+ +---------+ +---------+   +-----------+ |
| |  card0  | | ALSA/PA | |  evdev  |   |argo_stream| |
| +---------+ +---------+ +---------+   +-----------+ |
+-----------------------------------------------------+
| +---------+ +---------+ +---------+        +------+ |
| | Xen DRM | | Xen Snd | | Xen KBD | Linux  | Xen  | |
| |  Front  | |  Front  | |  Front  | Stubdom| Argo | |
| +---------+ +---------+ +---------+        +------+ |
+-----------------------------------------------------+

QMP discussion

Proposal:

- LibXL and block backend: change "xenstore stuff" to "QMP stuff"

Concerns:

1. QMP is not a simple protocol.
2. xenstore-based protocol is much simpler than a JSON-encapsulated protocol.
3. There have been multiple historical bugs in parsing of JSON in C.
4. 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

1. Reduce privileges given to the QEMU instance
2. Limit interfaces to the QEMU instance
3. Work with upstream QEMU to propose a new safer-than-JSON alternative marshalling format backend
4. 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
5. 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
6. 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 to merge the ones which are not contended
• Work towards consensus on contended patches