Re: [qubes-devel] Is QEMU in dom0 fine if it emulates zero devices?
-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.
Re: [qubes-devel] Is QEMU in dom0 fine if it emulates zero devices?
-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.
Re: [qubes-devel] Is QEMU in dom0 fine if it emulates zero devices?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 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). 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- -- 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/ZeMhid01SsUFnAr_%40mail-itl.
Re: [qubes-devel] Is QEMU in dom0 fine if it emulates zero devices?
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 -- 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/7ef0eefc-83a6-4ac8-851c-6bd7b49fe530%40invisiblethingslab.com. OpenPGP_signature.asc Description: OpenPGP digital signature
