-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Sat, Mar 02, 2024 at 01:54:33PM +0100, Marek Marczykowski-Górecki wrote: > On Sat, Mar 02, 2024 at 10:58:26AM +0100, Simon Gaiser wrote: > > 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. > > 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).
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----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/ZeNnkWIET_lYl6v7%40itl-email.
