Disposable VMs were not developed with anti-forensics in mind (e.g. no 
protection in jurisdictions where you can be forced to hand over your drive 
Never thought about it, but that makes sense. I can see how it would be easy to confuse "non-persistence of malware" aspect and the "non-persistence (non-remenance) of data" aspect, though.

But then... What does the checkbox mean, "Keep dispVM in memory", under global settings (R3.2, at least)? Screenshot attached.

That being said...

In 4.0 (updated) qubes now calls blkdiscard on volumes being removed before 
invoking lvremove. If you happen to use a SED SSD and you have manually enabled 
discards through all layers to the physical drive, then, depending on the 
manufacturer implementation, the data from a shutdown disposable VM might not be 
recoverable even with your disk password. >
No guarantee but I recommend enabling discards all the way down.

After some forensics experiments, I put together a rough-at-the-edges bash 
script that does a rather good job of ensuring the volumes are not recoverable.

It creates an over-provisioned lvm volume In the current pool, overlays a new 
randomly keyed luks volume on top, makes that into an lvm pv, layers lvm vg and 
finally an lvm thin pool on top.

Adds that new thin pool to qvm-pools, copies templates and VMs there, 
temporarily modifies the global default pool setting (needed to be sure *all* 
volumes related to the VMs were in the ephemeral pool) and starts up some 

I need to make it a bit more flexible but it served my need.

Once all started VMs are shut down, the script unwinds all the storage layers.

Since the luks layer was random keyed, that data is gone once unmounted.

Been meaning to clean it up and share at some point.


I sort of like the idea mentioned in bug #904, about doing the crypto inside the dispVM itself, so that 1) the key is scrubbed by Xen when the dispVM is shut down, and 2) data is non-recoverable instantly so you don't have to wait until all dispVMs have been shut down for example. Incidentally this approach actually offers a lot of improvement in scenarios where the machine is seized while it's on and unlocked, too, but that's another topic.

That being said, do you think it's currently possible to set up a dispVM template so dispVMs run off encrypted storage? I'm thinking maybe a startup script that overwrites /dev/xvdc (volatile.img) with a dm-crypt container? Or perhaps it could be done at the filesystem level instead, with ecryptfs or encfs using random keys, and dm-crypt for swap? Or even just disable swap and mount a tmpfs over /home, if you have have enough ram or don't write much data in dispVMs.

Just bouncing around some ideas. Seems like it might be possible to do something like that, and perhaps simpler than the ephemeral pool approach, depending on your situation. Thoughts?

This free account was provided by - report spam to

ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the 
NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features! 15GB disk! No bandwidth quotas! Commercial and Bulk Mail Options!
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 view this discussion on the web visit

Reply via email to