I’d like to reiterate that there is a better path towards anti-forensic DisposableVMs:
People might want to focus their energy on generalizing the already existing Qubes OS support for ephemerally encrypted ‘root’ volumes to ‘private’ volumes, which would entail something like the WIP in marmarek/qubes-linux-utils@
volatile-thin-poolfrom, oh wow, 2016. That’s a much cleaner approach to anti-forensic DisposableVMs (#904) than creating and tearing down pools.
More generally, from #904:
The storage layer already has generic support for encrypting a volume with an ephemeral key. In the context of this issue, the problem is that this not implemented for
snap_on_startvolumes like the ‘root’ and especially the ‘private’ volume of a DisposableVM. (For the ‘root’ volume the existing workaround is to set it as read-only, rely on in-VM support to redirect writes to it to the ‘volatile’ volume, and make the non-snap_on_start‘volatile’ volumeephemeralinstead of ‘root’. But there is currently no such in-VM support for the ‘private’ volume.)
Solving the bold part - not necessarily by using exactly the same implementation as in the linked WIP code! - would solve anti-forensic DisposableVMs.
That said, in order to avoid the ‘file’ driver it would also be possible to adapt this thread’s script to create a throwaway Btrfs/XFS filesystem (maybe even on disk, encrypted with a random key) and then use the file-reflink driver for the temporary pool.