That is what I do via a bash script. LVM vg/pool on top of LUKS (as pv) on top of default LVM pool, and the luks layer uses /dev/urandom sourced key. However, due to some of the constraints of LVM (which, given the features it does provide, I *can* live with), I also need to move the templates to the temporary pool for the approach to work, so there's a time consuming (~4 minutes) setup time before the VMs are running. It's just a script, so execute, perform some other task for a bit and wait for windows to appear. When done with the sensitive task (or prepping for anti-forensics testing), user performs shutdown VMs, tell script you "done", and the script ensures all VMs are closed, then removes the above storage layers. -- There were some discussions in the qubes-issues ticket(s) about adding additional driver layers in the mix that might make utilizing a separate encrypted pool unnecessary. Other discussions involved performing the encryption inside the VMs, but as I mentioned earlier, if the content in the VM that is being manipulated is untrustworthy...then is the VM's internal encryption really trustworthy? > If the volume were intentionally stored on an Opal 2.0 SSD device you > could then use the built in SSD hardware capabilities of the 'encrypted > locking range' (up to four are possible if I remember correctly) for the > temporary workspace and when you destroy/reset the MEK (key) this will > instantly flip all the bits in the underlying hardware of that disk > region and make that range completely unrecoverable. OPAL ranges could be useful, but as they are also basically hardware managed partitions, I believe they would be difficult to utilize effectively, esp. if you want n (instead of a max 4 or 8) different secure areas (some permanent, some ephemeral). That being said, I do believe the opportunistic anti-forensics of trim/discard on a SED with DZAT might be useful (and hence my suggestion of utilizing trim through all layers and proposing to the qubes devs to blkdiscard before lvremove, which qubes now does). Also: some business use cases for permanent encrypted VMs have been given, e.g. keeping client A resources locked down while client B work is being performed or demo'd, etc. I would think LVM, esp. thin LVM, gives quite a bit of flexibility in sizing, adding/removing, etc. and would be applicable, perhaps with the additional encrypting driver layer discussed in the related qubes-issues items in github. 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/d77855e6-83d7-4b00-a451-d9c15d83d475%40googlegroups.com.