How To Turn Off Swap & The Cost Of Doing So?

I’m trying to prevent any sensitive data from ending up in swap.

I suspect the best solution is just to disable swap all together.

Is this the way to go, or is there a better solution?

And if it is, how do I do that in Qubes 4.1?

And if I do it, what can I expect to change in terms of performance with say 32gb RAM, for average Qubes use (3 or so Qubes running at the same time)?

you could comment out the swap partition in /etc/fstab and see were it goes. 32gb should be plenty for 3 qubes. a good rule of thumb i use is 4gb per vm which has gui.

1 Like

I imagine I do this in dom0, and it would carry over to all the qubes?

Changing it in dom0 will only impact dom0.

If you want to disable swap everywhere all Templates and Standalone VMs would also need to be similarly modified.


The only thing that persists in an app Qube is home correct?

If so, do I have the same swap partition risk in an app Qube as dom0? If I shutdown the qube, can I assume the swap clears with the shutdown?

The volatile volume in LVM is removed, yes.

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.

Indeed, there’s a flag to enable ephemeral encryption for volatile volumes only (the simplest to implement) in 4.1 that isn’t currently enabled, that might be usable … I think it’s still considered experimental, may not be completely working. It’s a property of the pool, I believe? See: System-wide toggle for encrypting volatile volumes · Issue #6958 · QubesOS/qubes-issues · GitHub

Work continues on supporting it (ephemeral volatile), see marmarek’s commits over the last year or so referenced before the most recent conversations here: DisposableVMs: support for in-RAM execution only (for anti-forensics) · Issue #904 · QubesOS/qubes-issues · GitHub

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.


I take it this is not default on 4.1? And I need to setup the config myself?

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


1 Like

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

1 Like