Is it forensically cleared? Not intentionally**. Volatile volume content (e.g. swap content) may continue to exist in the unallocated space in the LVM thin pool until overwritten.
The same applies to the content of the snapshot volume for root (that is, changes to root volume since start, such as logging). That too can stick around in the unallocated space in the LVM thin pool until overwritten.
The same, generally, applies to disposable VMs as well (adding the additional data from the private volume to the mix as well).
This is why the Qubes developers are looking at adding ephemeral encryption (via throwaway keys) for volumes and snapshots that are not meant to be kept past the current session.
The solution for the other volume types (root-snapshots, private) is still in design stage.
** assuming a standard hard drive, the (luks encrypted) data simply persists on disk until later overwritten, but could be seen as plain text by a forensic examiner who has access to your password, dom0 luks key, login session or a decrypted image. However, there’s what I call an “opportunistic anti-forensics” feature that might clear the data for you. If you are using an SSD/storage device that supports discard/trim and at every layer [storage hardware (e.g. SSD), luks, lvm, etc.] you and/or qubes developers have configured the system to pass discards down, then the SSD hardware will receive Trim/Discard commands when an LVM volume is removed by the qubes lvm storage driver. On most hardware this will, within a very short amount of time, erase the memory cells containing the data the volume contained. This is not a cryptographic guarantee, but relatively solid.
…Would the same apply for encryption outside of the top level Luks enryption… such as mounted Veracrypt vaults? If they don’t have the Veracrypt keys, the data that might end up in swap would be encrypted with those VC keys and not viewable with the top level Luks keys? Or does unencrypted VC data in RAM potentially end up in swap?
It wasn’t the default to flow it all the way to the hardware on R4.0 a couple years back. IIRC, I had to enable it for LUKS at the time…memory is fuzzy.
However, looking at fstab in a recently installed R4.1, LUKS is configured to pass discards down. LVM is too, by default under both versions. So you should be good, if your hardware supports it.
Notably issue_discards is still = 0 in lvm.conf, but that does not apply to thin LVs, only normal LVs. Under standard install of Qubes, it’s only useful to set that to 1 if you are removing thin pools regularly (I do), as a thin pool is build inside of a normal LV object.
Hmm, if you’re mounting volumes directly in dom0, then no, I wouldn’t make a claim that the passwords, keys or plaintext from veracrypt volumes would never end up in dom0 swap. It really depends on how you are using the data in dom0 and how the memory used to store that data is flagged in the kernel.
If you were mounting the containers in domU VMs then it would be much less likely to end up in dom0 swap, since VM memory is Xen memory and can’t be swapped by dom0 kernel unless the VM sends it to dom0 (e.g. via some channel or introspection, the most critical is likely to be the display of a domU window in dom0).