> 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 Qubes
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 this. 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 firstname.lastname@example.org. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6dab89ca-8b43-4066-bc59-99a08608c7bc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.