On Wed, 17 Jan 2018, Lorenzo Lamas wrote: > On Thursday, January 11, 2018 at 3:57:50 PM UTC+1, Andrew David Wong wrote: > > ## Qubes 3.2 > > > > For Qubes 3.2, we plan to release an update that will make almost all > > VMs run in a fully-virtualized mode. Specifically, we plan to backport > > PVH support from Qubes 4.0 and enable it for all VMs without PCI > > devices. After this update, all VMs that previously ran in PV mode (and > > that do not have PCI devices) will subsequently run in PVH mode, with > > the exception of stub domains. Any HVMs will continue to run in HVM > > mode. > > Is this the shim-based approach from XSA-254?
No, it won't be a shim-based approach (see also the Marek's mail in this thread). > Then it should be made clear that the VM's will be more vulnerable to > Meltdown: Even if shims would be used, that "more" claim is false as Meltdown against the host hypervisor from PVs that are currently used in R3.2 expose both host and also the guest through the host hypervisor (its memory). With shims only the guest is still vulnerable, this time through the intermediate xen instance running in the HVM/PVH encapsulating the PV guest. Clearly it's "less" vulnerable rather than "more". Qubes has been trying to migrate away from PVs altogether (rather than e.g., placing PVs into those shims) due to PV vulnerabilities in general. In fact, even before these HW vulnerabilities were discovered, the process towards PVH was ongoing which is why R4.0 rcs as is are much better protected already. These vulnerabilities only accelerated this process. There will be, unfortunately, be one limitation to this migration still due to PCI passthrough: VMs with PCI devices need to remain PV (or their stubdoms in R4.0). > "Note this shim-based approach prevents attacks on the host, but leaves > the guest vulnerable to Meltdown attacks by its own unprivileged > processes; this is true even if the guest OS has KPTI or similar > Meltdown mitigation." > https://xenbits.xen.org/xsa/xsa254/README.which-shim Also, note that one of the fundamental assumption with Qubes security model is that the VMs _will get compromised_ (regardless of HW exploits). What Qubes aims to protect against is escalation from a compromised VM to host or to another VM. -- i. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to email@example.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/alpine.DEB.2.20.1801172252250.29076%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.