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 password).
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 sessions. 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. Brendan -- 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 https://groups.google.com/d/msgid/qubes-users/f6b7c6e3-6f8d-473a-9dc5-5fdf91cbf3b7%40googlegroups.com.
