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 

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.


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 view this discussion on the web visit 

Reply via email to