Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qvm-clone: add --move and --shred #3717

Open
rootkovska opened this issue Mar 19, 2018 · 4 comments
Open

qvm-clone: add --move and --shred #3717

rootkovska opened this issue Mar 19, 2018 · 4 comments
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: task Type: task. An action item that is neither a bug nor an enhancement.

Comments

@rootkovska
Copy link
Member

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 --shred the 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).

@rootkovska rootkovska added C: core T: task Type: task. An action item that is neither a bug nor an enhancement. labels Mar 19, 2018
@rootkovska rootkovska added this to the Release 4.1 milestone Mar 19, 2018
@marmarek
Copy link
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.

@tasket
Copy link

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).

@PowerPress
Copy link

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.

@andrewdavidwong
Copy link
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.

@andrewdavidwong andrewdavidwong removed this from the Release 4.1 updates milestone Aug 13, 2023
@andrewdavidwong andrewdavidwong added the P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. label Aug 13, 2023
@marmarek marmarek removed their assignment Mar 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C: core P: default Priority: default. Default priority for new issues, to be replaced given sufficient information. T: task Type: task. An action item that is neither a bug nor an enhancement.
Projects
None yet
Development

No branches or pull requests

6 participants