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 

> 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.


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 qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to