24

I want to sell my SSD to my friend, it's a 256GB, I have personal stuff on this SSD, so I want to make sure that it will become extremely hard or at least hard to recover the data back. Erasing the whole SSD, as if it were new.

The other questions similar to this one are over-mentioning that:

  1. erasing one partition is useless.
  2. The commands cat, dd, shred are useless.

I read that erasing the SSD is only useful when erasing the whole disk and not only one partition. So I'm asking to make sure if this information is correct and to know how to do it.

So I thought it would be better to create a new thread here for me and for those people who aren't concerned about data losing anything because they only want to get rid of their SSDs in return for money instead of throwing them in the garbage.

Jens
  • 1,738
  • 4
  • 17
  • 36
Normal
  • 349
  • 2
  • 8
  • There's many search results for "secure erase SSD in linux" - and yes, if you think your friend is going to try and recover your personal "stuff" (nudge nudge wink wink) - you'll want to secure erase the SSD – Bravo Dec 15 '21 at 07:08
  • Is encrypting the complete SSD an option? –  Dec 15 '21 at 08:06
  • I don't know from memory what I used years ago, maybe [this tool](https://www.cnet.com/tech/computing/how-to-securely-erase-an-ssd-drive/). Good luck. – Vlastimil Burián Dec 15 '21 at 11:59
  • 6
    For ATA (SSD or not), have a look there (hardware/firmware feature-dependent): https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase – A.B Dec 15 '21 at 14:24
  • 1
    https://askubuntu.com/questions/42266/what-is-the-recommended-way-to-empty-a-ssd – ron Dec 15 '21 at 19:05
  • Smack it with a hammer. – Hot Licks Dec 15 '21 at 23:44
  • @A.B Worth noting, high end SSDs that implement Secure Erase do not "erase" the SSD, but rather resets the crypto key in the controller. This is worth considering when Eve has resources above state actor level, such as a Kardashev Type 5 civ. – Aron Dec 16 '21 at 12:02
  • You need to also consider that SSD are overprovisioned. That means that a 100 GB driver actually has 110 GB where extra copies of data are stored. Your OS tools won't ever be able to access the overpartitioned sectors, and that data will remain there. Maybe some manufacturer tools can get there, though, but your standard tools can't. – The Impaler Dec 16 '21 at 12:11
  • @Aron indeed, I knew that. – A.B Dec 16 '21 at 13:23
  • oh my god, what happened. I forgot all about this question and now it has 2k views, looks like I wasn't the only one suffering here ️ – Normal Dec 17 '21 at 17:31

3 Answers3

21

Useless depends on context. shred can actually be rather useless - when trying to shred a single file, while other copies of the file still exist [every time you click Save, it's another copy] - but there's also the hand sanitizer definition of useless: it kills 99.9% so in practice, it's not useless at all, but people worry about the 0.01% anyway.

For many SSDs, a simple blkdiscard will cause that data to be gone and never to be seen again.

blkdiscard -v /dev/deleteyourssd
# verification:
echo 3 > /proc/sys/vm/drop_caches
cmp /dev/zero /dev/deleteyourssd
# expected result: EOF on /dev/deleteyourssd

If that's not good enough for you, you can use dd or shred to do a random data wipe:

dd bs=1M status=progress if=/dev/urandom of=/dev/deleteyourssd
# or
shred -v -n 1 /dev/deleteyourssd

For verification, the random data wipe needs to be done by encrypting zeroes:

cryptsetup open --type plain --cipher aes-xts-plain64 /dev/deleteyourssd cryptyourssd
# Three unicorns went into a bar and got stuck in the door frame
badblocks -b 4096 -t 0 -s -w -v /dev/mapper/cryptyourssd

You can also run another verification pass after power cycling (for the encryption method it works only if you re-use the same passphrase):

cmp /dev/zero /dev/mapper/cryptyourssd
# expected result: EOF on /dev/mapper/cryptyourssd

Getting data back — after discarding/overwriting and verifying that everything's gone — would require a bit of a miracle and involves corner cases that most users don't really need to concern themselves with.

But if that's still not good enough for you, you can use Secure Erase if the SSD manufacturer provides it for your SSD model, this is described in detail in the ArchLinux wiki:

Just don't mess it up by setting complex ATA password and then locking yourself out, effectively bricking the device. Keep it simple.

Usually with SSDs, it's already quite impossible to restore any data simply after reinstalling Linux, since most flavors mkfs also discard the entire space first thing:

mke2fs 1.46.4 (18-Aug-2021)
Discarding device blocks: done                            
Creating filesystem [...]

In this fashion it's indeed quite useless to erase SSDs yourself, since everything already does that for you without asking, anyway.

And even if that didn't happen, almost every distro sets up fstrim to wipe all free space regularly. Data recovery is a lot less successful on SSDs than on HDDs where you actually have to go out of your way to overwrite free space.

SSDs are so good at discarding all your data in an eyeblink, you should really worry more about losing the data you still need (make backups and backups of your backups), than worry about being unable to erase it.

frostschutz
  • 47,228
  • 5
  • 112
  • 159
  • 2
    In a lab environment it's probably possible to restore the contents of an SSD which has only seen blkdiscard since this command does not overwrite memory cells. – Artem S. Tashkinov Dec 15 '21 at 17:39
  • Most SSD should actually erase their discarded memory cells, as doing so gives a performance benefit, vs. zero benefits in keeping old data around. But yes, blkdiscard/fstrim as well as Secure Erase, depend on implementation details. If you don't trust the hardware then writing random data **and** verifying its there, is already the best you can do. – frostschutz Dec 15 '21 at 18:32
  • 1
    the blkdiscard command takes a millisecond to complete - I don't think firmware actually wipes the blocks before they are being reused. – Artem S. Tashkinov Dec 16 '21 at 09:35
  • It's a background task (and it just doesn't take all that long)... you can check that the SSD no longer returns the data, as for what happens internally it's a black box. Wiping with random data **and** verifying is much stronger as it gives you formal proof that at least *nominal capacity* worth of data has been overwritten. As for what is left even then, yes well that's the 0.01% discussion, and perhaps not too relevant for the "sell it to a friend" use case. – frostschutz Dec 16 '21 at 10:47
  • 2
    100 % - 99.9 % = 0.1 % – Arsenal Dec 16 '21 at 12:03
11
blkdiscard -v -f /dev/nvme0n1 (or /dev/sdX)

Will make your data effectively vanish without any realistic possibility of restoring it.

If you're paranoid, do this:

cat /dev/urandom > /dev/nvme0n1

followed by blkdiscard.

Vlastimil Burián
  • 27,586
  • 56
  • 179
  • 309
Artem S. Tashkinov
  • 26,392
  • 4
  • 33
  • 64
  • 1
    `-f` (force) seems dangerous - I'd leave that out by default and only add it if needed. – EM0 Aug 02 '23 at 13:33
5

The only way to securely erase a NAND Flash drive is to ask the drive controller to do it for you. Host base utilities that use writes will not work. If it's a NVMe drive look up the nvme format command

Sam
  • 191
  • 7