-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Mar 02, 2024 at 12:53:21PM -0500, Demi Marie Obenour wrote: > 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?
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----- -- 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/ZeN6CkBRa2cR_ILi%40mail-itl.
