-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Sat, Dec 16, 2017 at 02:10:17AM -0800, Vít Šesták wrote: > Just few notes: > > I believe that getting rid of QEMU is rather getting rid of PV domains than > getting rid of QEMU itself.
Yes and no. From security POV this is correct. But at the same time, having qemu (with appropriate isolation) use resources (RAM, CPU), which already are scarce on Qubes. So, we'd like to not have qemu there, where possible. > * First, privilege elevation is not much a threat in Qubes. OTOH, VM escape > is a fatal threat. > * I believe QEMU vulnerabilities typically require some lowlevel access to > devices, so those vulnerabilities typically don't allow you to elevate > privileges within VM. > > The difference for most domains: In Q3.2, attacker needs a suitable > vulnerability for PV domains implementation. In Q4.0, attacker either needs > suitable vulnerabilities for both PV domains implementation and QEMU or a > suitable vulnerability for hardware-virtualized domains implementation. In > Q4.1, attacker will hopefully need a vulnerability in hardware-virtualized > domains implementation. (For sake of simplicity, I consider shared parts as > non-vulnerable, so I don't count potential vulnerabilities in GUI daemon, RPC > services, hardware etc. I compare just the virtualization itself.) Yes. > This might not be clear what is more secure. The reason behind the change is > that HVM implementation is much less complex (and thus much less error-prone) > than PV implementation. As a result, QubesOS 4.1 (or whatever version that > brings PVH) is expected to be more secure that Qubes 3.2 and Qubes 4.0. The > situation in Qubes 4.0 is a bit controversial, but if > hardware-virtualization-specific vulnerabilities are rare (and I believe they > are), it should be also an improvement (compared to Q3.2). As for PVHv2 - in theory it should be available in 4.0 already, if you have VM kernel new enough (4.11+). > Note that we cannot easily get rid of QEMU completely because of OSes like > Windows, ReactOS or other fully-virtualized OSes. > > This brings a question: Can we get rid of PVs for stubdomains, for example by > using PVH for stubdomain? I believe this would be consistent with the > attitude of removing PV. I am not sure how hard/easy it is, though. I'm not sure either, but this is definitely something that we'll look into. As soon as we get stable PVHv2. Right now Xen do not support PVHv2 as stubdomain. Also, Xen do not support PVHv2 with PCI passthrough. At least not yet. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJaL3/PAAoJENuP0xzK19csomoH/0UFMApKJcB45/HDiiejZg4J i6Ux0ErCWF83fWcuqZc+ZOm2Y/9YThnpvAPfX98JzQKcwKilxK/dP/DbntYPwtJz +UDRq+uBP1PdGHijSkq1fxijq0sxzT5MDZOYJEVyqiFC1M6oS74gVU35hxt289PD CcRvmv7dmWQs25sWaK4yWCAVibGJFSdUro4jAicRrA5/mRhQxbC7Lo9ObUEGo2vc 5M2HWB3Y8w8bU74OyY6dQ/QKY4A2Ol+aFoDwad55fRn9kQggLvjWkRRZ5TAMWVgV rs0JsUUxIC/y0t4BnQxy0p4rYr/F239W1IH8CyMkG0ePyGgU9k686F7EDYM6h5w= =52Bl -----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 post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20171216114209.GF1062%40mail-itl. For more options, visit https://groups.google.com/d/optout.
