On 2019-12-15 22:04, brendan.h...@gmail.com wrote:
As to the first question: with qubes 4.0 it is a bit difficult to effectively 
wipe free space in the default thin pool.

One can create a thin volume and write to it until the thin pool reaches some 
saturation level (99.5%), then hit that volume with blkdiscard before invoking 
lvremove. Because you should not go to 100% the user may still be rolling the 

Lvm doesn’t like hitting 100% and one can permanently corrupt the system if you 
fill the lvm all the way.

It’s possible the lvm tool chain in 4.1 may have more capabilities once dom0 is 
on a much more recent fedora version.

It’d also be nice to have dom0 in a different pool than the templates/VMs...to 
reduce catastrophic failures.

I have a suggestion but don't know exactly how to implement it since I am not that familiar with how the underlying storage pools work.

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.

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. You just need to assign another key to that locking range. Yes I realize many people don't trust the Opal standard to be on your side, but the exact same capability could be emulated in software using a Qubes generated random one-time-use symmetric software key.

Anyone know if a storage pool can be created quickly on top of an encrypted disk volume? Or can you efficiently create a software encrypted volume on top of a storage pool? Discarding a key might be the fastest way to 'virtually wipe' that temp storage space.

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