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
dice.
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
https://groups.google.com/d/msgid/qubes-users/a5238cd4-5649-8106-3f80-d00d0348ea11%40jhuapl.edu.
