When trying to securely wipe SSDs, we have several problems:
- SSDs wear out after a limited amount of erase cycles
- SSDs have a controller that dynamically maps LBAs (logical block addresses used by the system to access the disk) to NVRAM cells (the actual flash memory cells) to balance the wear, which means telling the disk to overwrite the blocks that formerly stored a specific file may result in overwriting any other spare blocks.
- SSDs have a notable percentage of reserve capacity that is used to compensate dying storage cells and reduce wearing. They are not visible to the system and might hold old data fragments.
Now what options do we have from inside Ubuntu to securely wipe SSDs?
I've heard that some newer SSDs should be able to securely wipe themselves, but how do I find out whether my SSD is capable of this and how would I trigger it?
There should also be an ATA secure erase command, how do I find out if that is supported and how would I trigger that?
Are there also ways to securely wipe only a given file or only unused space?
I guess making a backup of all partitions, securely wiping the entire disk and then restoring the backup would be possible but sounds too complicated and would take too long to be practical. Are there other alternatives? If not, what tools can I use to backup partitions without also backing up already deleted files?
Of course the standard tools like shred
or wipe
are not usable here for the points described above. They simply overwrite a a file (by overwriting its file system clusters which are bound to LBAs which are not constantly pointing on the same flash cells due to the wear levelling controller).
Currently there's no way to securely erase files on SSD without erasing the content of the whole drive or access to the firmware of the SSD.
It's impossible to know where the SSD may store previous copies of a logical block.
To make matters worse, due to journalling and copy-on-write mechanisms of the file system it may be impossible to know which logical blocks may hold a previous copy of a particular file.
The only way to prevent the leakage of deleted files to someone with direct access to the drive is to encrypt them in the first place and keep the encryption key safe from prying eyes.
Addendum:
I did some research and found out that you can sort-of erase all previously deleted files if you manage to learn all the unoccupied sectors of a file system, which is generally possible and offered by some file system tools (e. g. for the ext* family), and then discard them (e. g. with
blkdiscard(8)
as outlined in this answer to the linked question), which returns the blocks for garbage collection until they're used again and overwritten in the process.This is secure against everyone who cannot access the flash cells directly, so everyone who
The easiest way to determine whether your drive supports secure erase is to ask it: I've used /dev/sdX in the examples below. You'll need to carefully change it to match the device you are working with:
Sources:
https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase
https://superuser.com/questions/1161531/how-to-un-freeze-drive-in-linux
On my SSD this results in:
If secure erase is supported by your device, triggering it is a 2 or 3 step process.
sudo hdparm -I /dev/sdX
similar to this:Unfreeze it by suspending and resuming your system. I did this with the command
sudo systemctl suspend
moving the pointer until the system resumed.You must set a password to use secure erase in this case I'm using foobar as the password, you can use whatever non-blank password you like as it's temporary.
sudo hdparm --user-master u --security-set-pass foobar /dev/sdX
With the password set you can now use it to securely erase the drive:
sudo hdparm --user-master u --security-erase foobar /dev/sdX
If your drive supports it and you so desire you can opt to use the enhanced security erase instead with:
sudo hdparm --user-master u --security-erase-enhanced foobar /dev/sdX