On Wednesday, December 18, 2019 at 10:04:40 AM UTC-5, steve.coleman wrote:
> On 2019-12-15 22:04, brend...@gmail.com <javascript:> wrote: 
> My suggestion is, rather than the time consuming wiping of bits after 
> the fact would be to instead create an encrypted volume/partiton/pool 
> when launching a DispVM, and upon shutting it down you simply throw away 
> the key to that temporary volume. Without the key any data on that 
> encrypted volume would be unrecoverable, so then all you really need to 
> wipe is just the memory space that stored the runtime key's working 
> memory. If the key is generated before the volume is created then the 
> key would be only available to dom0 where the key's working memory space 
> can be managed properly and Qubes would be able to support any number of 
> guest OS's as a DispVM. 

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 

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.

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