Is QEMU in dom0 fine if it emulates zero devices?

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Is QEMU in dom0 fine if it emulates zero devices? I’m specifically
wondering about a configuration in which the only emulated device is a
virtio GPU, which will be emulated via crosvm’s vhost-user-gpu support.
This might require some QEMU patches to support the extra commands that
are needed for blob devices. In this mode, QEMU should be able to run
under a strict seccomp allowlist and does not need to interact with the
GPU itself.
- --
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmXi1C8ACgkQsoi1X/+c
IsGXDxAAr6V6Cbd/+41qFtQhVv4uwKg+Oi25XlaAn047E8pQWxIuyakb+V9bn0P2
TgGsyHNlkH7TfBvgSoKfjDczQNVgglkwAAyNXyXHdOE6QrDjjbMnr8ceBgSeGi+c
RNeB7uzEec/iuBhk9CAAVC5qdhIHfnD23mtLqraiBfR87Eu4YoT7VYkP8Ywg2agx
Jngj7U0rvTw7DAWdWIZ6hXpnxGLWgZHq2hYAyqdvBG/N+pbDh3hFUtHsHpeLKS4c
+FAlUNeKK2i+77pN2U5KpquPD9ZDiR04acYIK6MESnd5nk2qGDpGDGRHlnrI26Rs
77iwMlY4qtjyD52XMRo+GYAmQKeYxAoPJwEKaaVr9WprJq6zzDTGqidqhhuNX6mV
oFJzg/0LhqzWeKpbi0RnQeucmTMTnInwRDegIJ0Vatw2MAu0LEhGo2JYzxQCXM/d
5bsw6r6xXx0AwfKj8KUBDdu+wIKb/17opCjIrrd4bsDtN18FYD/kg2YlLwKj+Cam
e0aHY+MdRSAlNsIw7EXKeFcsK1/YVhM62ehuugWaYPuIG5Dy5bTeSmyTXh+cSla5
UvQJnm/YcGh2M9xnp617XV32ncuWCLHeJ2Vz+vdb/haHDc8n7qVVZdE0ahmYfnNm
T8bKBVOMFo3F1UF8bHeBPwyCnZixgVE/XwkeYT9FSVvv5MU8h1A=
=jUUs
-----END PGP SIGNATURE-----

[Simon Gaiser]

Demi Marie Obenour:

> Is QEMU in dom0 fine if it emulates zero devices? I’m specifically
> wondering about a configuration in which the only emulated device is a
> virtio GPU, which will be emulated via crosvm’s vhost-user-gpu support.
> This might require some QEMU patches to support the extra commands that
> are needed for blob devices. In this mode, QEMU should be able to run
> under a strict seccomp allowlist and does not need to interact with the
> GPU itself.

What would be QEMU doing at all in this case?

If we can isolate it similar (or better) than the current stubdomain
solution running it in dom0 is certainly an option.

One thing to look at is how the required interface towards Xen looks like
in this case. AFAIK running QEMU in a Linux sandbox is already supported,
so that interface is probably already prepared for this case.

How would the normal device emulation required for a HVM work in that
case? Or are we talking PVH? But the later normally has no QEMU at all,
so not sure if that would work without major work on the Xen side.

Simon

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The thing we want to avoid the most in dom0-based QEMU is emulation of
all the base devices (PCI root complex, chipset, various legacy devices
etc). This is an old code base, and also historically some emulators
were reachable for attacks even if given device was configured to be
disabled (see VENOM bug). Xen supports ioreq servers API where emulator
can manage a specific PCI (or other) device and won't receive
communication directed at other devices at all (so, much less risk of
unintended attack surface). But it needs to be used by that emulator
this way (instead of claiming the whole PCI bus, which is what QEMU does
right now).

This touches another topic - what is needed to have virtio for a VM.
Preferably for a PVH domain (so, without all the emulated legacy
devices). IIUC currently virtio in Xen works with HVM only, right?
There is a vPCI that handles PCI root complex emulation in Xen, and it's
used for PVH dom0. AFAIK this code should allow emulation of individual
PCI devices by separate ioreq servers, without all the legacy stuff, and
also is a prerequisite for PCI passthrough to PVH. But I'm not sure what
is the state of vPCI supporting non-dom0 VMs, and how much work is
still needed for virtio for PVH (and also PCI passthrough for PVH, which
is another thing interesting for us). Or maybe some of it is completed
already?

- --
Best Regards,
Marek Marczykowski-Górecki

Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXjIYkACgkQ24/THMrX
1yzYSwf7BVnQnu7Nafdm0KE8S3f8dxNg/SEmAkmlr1P99Uic2ASOU/401ni9TTyc
EoilwiGZNtlAL1SZQyzWYE6OOeSqEnG1a4FQP9cBs2VnzamTYKdYANG3F8WV0iV5
Xhn/dbcZMTkzeAvH5kv9FO/xq6D5WoVPKhZaF837lzMyQg49ZxdOTNydiR2n98WP
I9no9mQZ3y1S5oYZdibClb8w5kZB4kBM1WSX3smw//3+oMbrxMB56oB2nYDzawgo
BooSEuyCUyuxzq+qLg/bnCzixWVN5HNcVLedAWjv2i+xrQnjD1Q/vbhK4Ls2ajgO
RWGZpSfWRXpdo/yjna7PYTmoNX0BgA==
=EMoo
-----END PGP SIGNATURE-----

[Demi Marie Obenour]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I believe this means that QEMU in dom0 is not an option right now, even
if vhost-user-gpu is employed. Cloud Hypervisor + vhost-user-gpu should
work once Cloud Hypervisor is ported to Xen, though, and there has been
interest in this from the Cloud Hypervisor side.

> This touches another topic - what is needed to have virtio for a VM.
> Preferably for a PVH domain (so, without all the emulated legacy
> devices). IIUC currently virtio in Xen works with HVM only, right?
> There is a vPCI that handles PCI root complex emulation in Xen, and it's
> used for PVH dom0. AFAIK this code should allow emulation of individual
> PCI devices by separate ioreq servers, without all the legacy stuff, and
> also is a prerequisite for PCI passthrough to PVH. But I'm not sure what
> is the state of vPCI supporting non-dom0 VMs, and how much work is
> still needed for virtio for PVH (and also PCI passthrough for PVH, which
> is another thing interesting for us). Or maybe some of it is completed
> already?

I think it is being worked on, but I’m not sure it is security supported
upstream yet. Even if it was, it seems to move a lot of complexity to
the most privileged context. Is there a reason to believe Xen’s vPCI is
going to be more secure?

- --
Sincerely,
Demi Marie Obenour (she/her/hers)

Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmXjZ5EACgkQsoi1X/+c
IsETtQ//Rtniw1jUc+GLUPkmNlFtJqHgPScr4AhJ1Z3WiM0Kp8o47IBQIlisgJaK
J7KtipWL+UOtls521N804wedn2tNdGSp3tleftm34L63dxC55vMtlot5SqGUqh5K
hDXtrkJNcPfd3Kxye2sq/wa9e9pqyQW7UfYUR64MniyuxfbyTBeMd9teZ306rv8D
ZIMOItT4lEJQy0kM7SlOsuh+EpMexNkQJf4ntrYW8VnrJ0A+RkYhtrqdiZCUJ2bQ
Fnji+Gg6WIgjSWcVRbEEr2BiCAEKl1LJtQjb3j5kLHFcIMkJMshJj+H91X9WbItE
/HB1em/hkOttmwbr6WadRDV4nrONXIQTifTF7xfjOB9vzxEo1bX6ZAWcG71pYRBL
WTpWt3DW/ajE5KG9fF/wdAnr02YX32GJ43XcUptBPG0xPT2sGaEv5z36pMwxfIu6
vyJ/x2pZoVTAEKXA93dRLHvokvgZXT4uRlJYijSCQJK8SN7HeyuQ4Ktt0ljZ+jL8
jrnjDKjD3jJ4FnpB6UJlJLLK+yoDpbaeL0Ce9Xb2L4wHlW7hYQgZ+C+MyqIpEvwq
QJuZ1syvQnBrP0Z+6AjaBRbgr74kR3UFDfiV2oz4nkGwngFP6Nlbaot+35rHh6om
wufxkSMhHp3h3LLnysFMj0WJOuy7Um7M7aWXASWAPD/0pPt8HKM=
=Tf2x
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

The Xen's vPCI is mostly about arbitrating which access goes where (to
the real device in case of passthorugh, to some emulator via ioreq
protocol etc). It doesn't emulate all kind of devices that QEMU does, it
only emulates enough to perform this arbitration.

- --
Best Regards,
Marek Marczykowski-Górecki

Invisible Things Lab
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAmXjegoACgkQ24/THMrX
1yyV7Qf/VZzvpjJRhaVJTT5p2KEsbndG6+vPT8aNIl3sQgJgXX7yjJjD6+ZDwlK4
klIIAGWXP7ex0/sTw9fTO9bufafsPNpVb5QKkOk7LY6jPdD13XnFVa/3p+gpEwzU
yb2HajTmDCGU2Irsv8luSp6ojf5BszVJYIvggoVa/Unq39w1VXPj038XotHEW9ud
6oEfUmYsZVSnKqxmVc63/BOQMtECotsQrCT1B81unBAgXflqoTsk/zSP8VIzrDBS
F8MViA9BqjOEMhS4d1zSpwb/3VRGXwyKN/PM2rXNiOYNunViXZ8lJYzennJkcEbC
OBVt6So9gE32voIIuOQGfg3/fgXu1g==
=NWXw
-----END PGP SIGNATURE-----