A shutdown of a disposable vm (dvm) does not flush cache and swap memory.
As an alternative to a complete cold reboot, would the following work with minimal impact on Qubes operation (other than slowing things down momentarily)?
ex. $ sudo sysctl vm.drop_caches=1 (or 2, or 3)
-or-
ex. # sync; echo 1 > /proc/sys/vm/drop_caches (or echo 2, echo 3)
-or-
ex. # swapoff -a && swapon -a
As a follow-up and to improve my understanding of disposable vms; when and where does the decryption and removal of a dvm’s template occur?
Remember that Xen is unlike KVM: Xen is outside of dom0 and handles memory allocations to VMs, including to dom0.
-
Disk encryption – Disposable VMs are not encrypted separately from the rest of your system**. If you chose (during installation) to encrypt your system, then the disposable VMs are no more nor no less encrypted than the rest of your system. Which is to say that data written by the disposable VM may stick around on disk for some time after a disposable VM is shut down. If an encrypted system is shut down then the data at rest is encrypted (including deleted but not yet overwritten data). If the system is booted in dom0, then the plaintext is available.
-
Memory protection – Memory in a VM that is returned to Xen from a VM (such as after shutdown) is not immediately cleared, and remains in physical RAM. However, a) Xen does not have swap and b) Xen clears any memory before giving it to any other VM, even dom0. So, that’s helpful, but not a guarantee that RAM from disposable VMs is gone after VM shutdown, only guaranteed after system shutdown.
-
Dom0 SWAP – Therefore…dom0 swap should not contain the contents of VM memory (disposable or not) as any memory given to dom0 by Xen is explicitly cleared. This is because, as discussed above, memory recovered from and issued to VMs, including dom0, is handled by Xen and Xen is configured to zero out memory before handing it to a VM, including when giving memory to dom0.
HOWEVER. With all that said, some additional cautions on dom0 swap and logs: memory in dom0 (and therefore swap in dom0) could potentially contain data from a VM if the data was sent to dom0 via a method other than memory allocation: e.g. via the conduits that send contents of windows to dom0 (or the guivm), logs from VMs consoles, logs from qubes compontents running in VMs, etc…
Summary: if you depend on disposable VMs to be forensically clean, then you should use TAILS. The closest Qubes method I can recommend is to create an ephemeral pool with a separate, temporary cryptsetup with /dev/urandom key, add that pool, copy templates/vms there, do work, shutdown, delete template/vms there, remove the pool, shutdown cryptsetup, dismount storage. Then shred dom0 logs and reboot.
Lastly, if you have TRIM/Discard enabled all the way down the stack and you have a SED drive that supports TRIM (w/ RZAT/DRAT): If data is trimmed either in the VM (or with the blkdiscard during Qubes-controlled LVM LV removal), that data is likely extremely hard to recover or potentially even impossible, depending on the hardware implementation.
Brendan
** the only exception is work in progress under R4.1 and only if you have manually enabled the new feature that encrypts the volatile volume of disposable VMs. It’s not on by default and does not encrypt either the root nor private volumes or their snapshots, just volatile. It’s the beginning of a long term work in progress, and currently gives not much of any kind of guarantee.
1 Like
Since the level 1 hypervisor resides between the vm and hardware it was to be expected that Xen would impact how hardware (ram) would be used. The hope was that methods to clear caches existed other than a cold reboot. Thanks for the lucid reply.