> There are two shims: PV-in-HVM aka Vixen and PV-in-PVH aka Comet. Both
have limitations making them incompatible (or at least suboptimal) in

Marek, thanks for the clarification. So, IIUC, Vixien's shim is no-go and 
Comet's shim would do the same (but at higher cost) as migration to PVH where 
possible. Now, your solution looks like a reasonable tradeoff.

> Indeed, the table is about generic/default VMs. If one choose HVM, it
will have PV stubdomain, regardless of Qubes version. We'll clarify

The problem is not just when explicitly requesting HVM (while not explicitly 
stated, I can understand it is not about that), it seem to be inaccurate even 
about the default VM types. As far as I know, PVH For Qubes 4, it seems OK, we 
got rid of some stubdoms. In Qubes 3.2, currently no stubdoms are used for such 
VMs, but you have PV in the table. For 3.2+ for VMs with PCI devices, you also 
have noted that there is PV stubdom, but there is AFAIU no stubdom.

> ## Only running VMs are vulnerable
> Since Qubes OS is a memory-hungry system, it seems that an attacker
> would only be able to steal secrets from VMs running concurrently with
> the attacking VM. This is because any pages from shutdown VMs will
> typically very quickly get allocated to other, running VMs and get wiped
> as part of this procedure.

It depends. In fact, not letting more-trusted-VMs and less-trusted-VMs run 
together (as advised) makes Qubes less memory hungry. On a system with 
something like 32 GiB of RAM, this can lead to having much spare memory. I have 
upgraded to 32 GiB after realizing that I'd like to have slightly more than 16 
GiB and maybe it would be better to have two the same modules. As a result, I 
have much spare memory now. IIUC, the memory is usually not overwritten until 
it is assigned to another VM, so the data are at risk even after shutdown.

For this reason, I've created a BrickVM whose purpose is just to allocate 
unneeded memory. Unfortunately, the VM does not take much memory even if it 
could, so I have decided to run about twenty or thirty DVMs for this purpose. 
(OK, I could run something memory-intensive in the BrickVM, but running many 
DVMs (or closing them if needed) seems to be easier.)

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