Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upqvm-clone: add `--move` and `--shred` #3717
Comments
rootkovska
added
C: core
task
labels
Mar 19, 2018
rootkovska
added this to the Release 4.1 milestone
Mar 19, 2018
rootkovska
assigned
marmarek and
woju
Mar 19, 2018
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Mar 19, 2018
Member
IMO it shouldn't be part of qvm-clone tool. Do you mean moving volumes between pools without creating doing internally qvm-clone + qvm-remove - in other words - keeping VM name? If so, IMO it should be part of qvm-volume tool - add migrate action or such.
Also, keep in mind that this feature (dd /dev/zero) may be misleading - if you used the qube in the old pool for some time, there are almost certainly some data blocks no longer connected to its volume, scattered over the disk, but still having that data (until reused form something else). If you want to move a single RSA private key (i.e. something that can easily fit into a single block) away from the source pool completely, you might be disappointed with this method.
|
IMO it shouldn't be part of Also, keep in mind that this feature (dd /dev/zero) may be misleading - if you used the qube in the old pool for some time, there are almost certainly some data blocks no longer connected to its volume, scattered over the disk, but still having that data (until reused form something else). If you want to move a single RSA private key (i.e. something that can easily fit into a single block) away from the source pool completely, you might be disappointed with this method. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
tasket
Mar 28, 2018
One method Mac OS X used to erase formerly associated blocks was to offer options to "erase unused space" in Disk Utility; this could actually work on (simple, flash-less) spinning HDDs.
This might be emulated in Qubes LVM by renaming the target volume as 'temp' and then extending the vsize to at least the pool size and filling it up (in a special mode where most related VMs are stopped). Finally, remove the temp volume and resume normal operation.
On SSDs its more complicated because of wear-leveling, and issuing TRIM commands may or may not wipe block contents (or not immediately). If you don't completely trust the drive firmware then the only way to ensure effective erasure is to have the volume encrypted separately in the first place; then throw away the key. Such volumes could be flagged as "shred-able" (a runtime property that depends on the volume having its own separate encryption key and/or residing on a simple HDD).
tasket
commented
Mar 28, 2018
|
One method Mac OS X used to erase formerly associated blocks was to offer options to "erase unused space" in Disk Utility; this could actually work on (simple, flash-less) spinning HDDs. This might be emulated in Qubes LVM by renaming the target volume as 'temp' and then extending the vsize to at least the pool size and filling it up (in a special mode where most related VMs are stopped). Finally, remove the temp volume and resume normal operation. On SSDs its more complicated because of wear-leveling, and issuing TRIM commands may or may not wipe block contents (or not immediately). If you don't completely trust the drive firmware then the only way to ensure effective erasure is to have the volume encrypted separately in the first place; then throw away the key. Such volumes could be flagged as "shred-able" (a runtime property that depends on the volume having its own separate encryption key and/or residing on a simple HDD). |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
PowerPress
Jun 28, 2018
Any plans to implement this to wipe/shred the data or have the volume encrypted separately in the first place; then throw away the key? Would be a great option to have Qubes have a clickable option for this in each VM, in my opinion, so that traces of something are not left behind once a VM is disposed of.
PowerPress
commented
Jun 28, 2018
|
Any plans to implement this to wipe/shred the data or have the volume encrypted separately in the first place; then throw away the key? Would be a great option to have Qubes have a clickable option for this in each VM, in my opinion, so that traces of something are not left behind once a VM is disposed of. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
andrewdavidwong
Jun 29, 2018
Member
Any plans to implement this to wipe/shred the data or have the volume encrypted separately in the first place; then throw away the key? Would be a great option to have Qubes have a clickable option for this in each VM, in my opinion, so that traces of something are not left behind once a VM is disposed of.
This sounds more like #1293.
This sounds more like #1293. |
rootkovska commentedMar 19, 2018
This is to facilitate (reasonably safe) migration of qubes from one pool to another (e.g. located on a USB disk). When using together with
--shredthe tool should also shred (dd if=/dev/zero) the corresponding volumes, and at least display info about any volumes which it does not move to the new pool (e.g. root and volatile).