35

Whenever I sold a drive I've zeroed it once with shred from a live environment:

sudo shred -vzn 0 /dev/sdX

Before I double-checked it wasn't mounted. This is the fastest way to securely erase a drive I know of. Now I've heard it's bad for SSDs. Is there a way to securely erase an SSD that's as fast or faster?

From a theoretical standpoint I understand that you need to overwrite the whole volume in order to make recovery impossible. So I don't see how there's a way that would put less strain on a SSD. I was told a single pass won't decrease a SSD's life span at all.

Would cat /dev/zero > /dev/sdX be as fast?

I'm not dealing with sensitive data here and don't need to protect the drive from a knowledgeable person going to great length to recover data. Fast is what I need while not decreasing the SSD's life span.

Edit: would this work for a SSD just like for a HDD?

dd if=/dev/urandom of=/dev/sdc bs=1M count=2
Improve this question
12
  • 3
    Does askubuntu.com/a/604447 help at all?
    – roaima
    Jun 16, 2020 at 9:04
  • 5
    @dirkt and that's why SSDs have an erase command
    – roaima
    Jun 16, 2020 at 9:40
  • 9
    All of shred, cat, cp, dd or any other way to attempt to overwrite the file have the problem that they don't work at all in the presence of wear levelling: The data is still there, someone with direct access to the SSD can recover it. And before you talk about speed, you should talk about safety.
    – dirkt
    Jun 16, 2020 at 10:52
  • 12
    Some SSD have an internal encryption key, stored in nvram. When issuing a command with hdparm to "secure erase" it, it will simply mark all SSD's blocks as "unallocated", forget the old key and generate a new one. Of course one has to trust the vendor about this. If there's no such key feature, the erase might be performed more slowly, still by the firmware. Ugly details (not talking about the key, just the erase procedure, whatever time it would take behind): ata.wiki.kernel.org/index.php/ATA_Secure_Erase . Did it once, had to suspend the system to unfreeze the drive etc.
    – A.B
    Jun 16, 2020 at 12:53
  • 2
    This question is self-contradictory: you say you need to securely erase the disk but you "don't need to protect the drive from a knowledgeable person going to great length to recover data." Which is the case? If it's the former, you must somehow overwrite all the sectors. If it's the latter, mounting and a simple rm -rf /mountpoint/* /mountpoint/.* would do it.
    – l0b0
    Jun 18, 2020 at 0:07

5 Answers 5

Reset to default
36

Writing a block to an SSD does not overwrite the old block. That's because all recent SSDs use something called "wear leveling".

To write a block to an SSD, you need to erase it first, and then you can write the new data. But erasing is an operation that can only be executed a limited number of times; each time you do an erase, you "weaken" the hardware, until the block cannot be properly erased anymore.

So instead of erasing and overwriting the same block, wear leveling will make the SSD pick a different, unused block, and will write to this block, leaving the data on the old block in place.

And if the data on the old block is in place, that means it still can be read.

So any of the commands you can use to "overwrite" a file (cp, dd, cat, shred, and many more) have this weakness: It does not actually overwrite the file at all, instead it writes zeroes, random data or whatever to new blocks.

So unlike for HDs, this is not a good way to make sure your data is gone, and cannot be read by someone else.

All of those commands are "bad" for the SSD in the sense that any writes use up the limited number of writes an SSD has, decreasing the lifetime of the SSD. And shred is particularly bad, because it overwrites the file repeatedly. On an HD, this serves a purpose: The read-write-head is never completely centered, so overwriting it multiple time makes sure (or tries to make sure) there's no residual magnetic data left at the border of the track that could be used by the knowledgeable to reconstruct the data.

As for blkdiscard, this calls fstrim, which uses ATAPI trim bit to tell the drive that the block is no longer needed. You can find more details in the ACS-4 specification.

But again, this is not safe: It only tells the SSD to put this block on the list of blocks that are empty and can be re-used. The SSD can choose to actually erase this block right now, or at some time when it is idle, or even just right before the next write to this block. So this isn't a safe way to make sure your data is gone, either.

The reason TRIM was introduced was that the SSD had no way of figuring out if a block with data was still used by the filesystem or not. Which means that even the filesystem had stopped using it, it couldn't be added to the pool that was getting used for wear leveling. TRIM was never meant as a safe way to erase blocks.

As has been mentioned in the comments, there is a way to securely erase the complete SSD. However, if you only want to securely erase a single file, that's probably not what you want.

So what's the solution for your use case? If it is really

I'm not dealing with sensitive data here and don't need to protect the drive from a knowledgeable person going to great length to recover data

then you can just use rm. It actually takes quite a bit of knowledge and effort to recover a deleted file on an ext4 file system, in particular if more writes have happened to this file system in the meantime. It's doable, but not by anyone. And it's certainly the fastest variant.

The next best one is blkdiscard (which will only work on SSD that support TRIM, but that should be true for modern SSDs). While this won't make it safe, as described above, now the bar has been raised to someone who can access the SSD directly. Which no one without the special hardware needed to do this can.

Overwriting the file by whatever means is still the worst: The bar to reconstruction is the same as above, but you've decreased the lifetime of your SSD by doing it, and it will also take longer, no matter which command you use.

Improve this answer
7
  • 5
    Going from "shred is bad" (true for single files, regardless of HDD/SSD; fine for full device wipes) to "blkdiscard isn't safe" (true in theory, usually fine in practice) to "you can just use rm" sounds like bad advice to me... anyone can photorec, in the end for SSD it'll still be TRIM/discard (blkdiscard, fstrim, discard mount flag) to get rid of that data. For HDD you must overwrite (entire device or all free space) in a single pass. There is no purpose to multiple passes at all.
    – frostschutz
    Jun 17, 2020 at 8:39
  • 5
    @frostschutz It's not meant as "advice". It's what came up in the discussion (look at the other answers, and comments). If you want advice: The first step is to define your threat model. Be clear against what and whom you want to protect. "Protect from a knowledgeable person" is not a threat model. Then, once you know this, understand what consequences the actions you do have, and to what degree they protect you against the threat you modeled. This answer tries to shed at least some light on this, because there seem to be a lot of misconceptions around.
    – dirkt
    Jun 17, 2020 at 8:49
  • 3
    Not sure if it's worth adding to your answer, but the erase procedure is actually quite slow, which is another reason to perform erases during idle time / as housekeeping... If they were to erase and write a page at once, then the write performance of even modern SSDs would be awful.
    – Attie
    Jun 17, 2020 at 17:47
  • @Attie: On top of that, drives are limited to erasing large groups of pages at once, meaning that if e.g. 3/4 the pages in a block contain useful data, and 1/4 contain obsolete data, recovering the storage used for obsolete data will require copying the useful blocks to some other location and then erasing the entire block, and will only free up a quarter block worth of pages.
    – supercat
    Jun 17, 2020 at 20:59
  • 3
    I suppose this is why encryption is mandatory for a server environment? Erasing a drive is as simple as "forgetting" the decryption key.
    – adib
    Jun 18, 2020 at 10:40
31

This is the fastest way to securely erase a drive I know of.

For SSDs, no, it's not.

blkdiscard /dev/device is dozens times faster and should be equally safe for your use case.

Would cat /dev/zero > /dev/sdX be as fast?

From the look of it these two commands should be equally fast.

Fast is what I need while not decreasing the SSD's life span.

You do decrease your SSD lifespan by even writing zeros to it. Zeros are still data.

Improve this answer
16
  • 4
    Seconded +1. Don't "erase" an SSD by writing zeros (or bulk writing anything, for that matter)
    – roaima
    Jun 16, 2020 at 10:40
  • 22
    How is blkddiscard "equally safe for you use case"? It just discards the blocks and tells the SSD it can re-use them. Someone with firmware-level access to the SSD can still recover data. At least explain the risks.
    – dirkt
    Jun 16, 2020 at 10:50
  • 19
    The user explicitly said: I'm not dealing with sensitive data here and don't need to protect the drive from a knowledgeable. Is "dd if=/dev/urandom of=/dev/sdc bs=1M count=2" the fastest way to erase a HDD while offering some security towards recovery then? Among all of the commands you've offered this is by far the slowest. Also usually unnecessary as writing zeros is enough to destroy data permanently (and has been for the past ~20 years).
    – Artem S. Tashkinov
    Jun 16, 2020 at 11:05
  • 5
    If you intend to overwrite exactly 2MB of data, then it's near instant for most modern desktop CPUs. Try it for 1TB of storage, i.e. without count :-)
    – Artem S. Tashkinov
    Jun 16, 2020 at 13:14
  • 4
    @dirkt, blkdiscard, if properly implemented, erases the data blocks and puts them into a "ready to use" state. This is exactly identical to the first half of the "read-modify-write" cycle the drive uses when updating the contents of a data block, and when applied to an entire drive, should result in a drive full of "1"s.
    – Mark
    Jun 17, 2020 at 2:29
11

i'd reccommend using secure erase with hdparm if it's at all supported:

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

this has step by step instructions on erasing SSDs

Improve this answer
3
  • 4
    Please, try to be more close to asked question, that's in this case Is shred bad for erasing SSDs?; then pointing out on how to do it, linking to "ATA Secure Erase", that I rightly support
    – mattia.b89
    Jun 16, 2020 at 21:47
  • 6
    Just FYI, an ATA secure-erase command can only erase the entire disk (not just a partition, not just a file). On SSDs with full-time encryption, it works by generating a new key and overwriting the old one, so nothing in the flash cells can be decrypted correctly anymore. (Also clearing the block mapping data so the whole disk acts as freed). This is ideal if you're going to sell a drive, if it supports instant-erase you avoid any wear and tear on the flash.
    – Peter Cordes
    Jun 17, 2020 at 13:41
  • 1
    This is the only right answer.
    – Hashim Aziz
    Jun 18, 2020 at 17:44
10

Not only is shred a bad tool for erasing an SSD, it won't work as intended. As others have noted, overwriting specific data blocks on an SSD is generally not possible, because wear-leveling means that "overwritten" blocks won't necessarily be actually-written to the same physical hardware memory cells. So, there's no point in bothering with filesystem- or logical-device-level "overwrites".

If you just want to wipe out the drive's file allocation state, the quickest option would be to simply clear the partition table and be done with it. The device would appear to be empty. Of course, it would be trivial to restore the entire contents using recovery software.

Assuming you want to be slightly more thorough, blkdiscard is one option for more efficiently deallocating all of the blocks on an SSD. And in recent iterations, it's gained some operational modes that account for the need to bypass the automated retargeting logic that can normally make SSD data blocks difficult to explicitly target/corral.

Selectively quoting the blkdiscard(8) man page from util-linux 2.35.2 (as included in Fedora 32):

OPTIONS
       -s, --secure
              Perform a secure discard.  A secure discard is  the  same  as  a
              regular  discard  except that all copies of the discarded blocks
              that were possibly created by garbage collection  must  also  be
              erased.  This requires support from the device.

       -z, --zeroout
              Zero-fill rather than discard.

So, blkdiscard -z /dev/sd# should be preferred to dd if=/dev/zero …, with a recent-enough version of util-linux. (The --zeroout option was added in util-linux 2.28.) But it will still count as one write cycle for all of the SSD's memory cells.

And if supported by the hardware, blkdiscard -s /dev/sd# would be the best method of ensuring that the discard operation extends to all possible data locations on the device, including any that may hold garbage-collected copies of addressable data blocks.

(I have no idea if blkdiscard -s -z /dev/sd# is a valid/useful combination of flags; the man page is not clear on that point, and I'm certainly not going to try it on my in-use SSD.)

Improve this answer
1
  • But you should still mention if your goal is to make all content of the complete SSD inaccessible, the "secure erase" command is the fastest way: It's secure by sepcification, not by accident, and if it's implemented based on the encryption features of the SSD, it doesn't decrease the lifespan of the devices (because it will just throw away the current key).
    – dirkt
    Jun 19, 2020 at 5:19
1

Edit: would this work for a SSD just like for a HDD?

dd if=/dev/urandom of=/dev/sdc bs=1M count=2

Sure, that works by writing over the first 2 MB of the drive, which probably includes the partition table and the start of the first partition, which often starts at 1 MB.

Most of your files and the intact filesystems of any other partitions would still be there, readable by a normal computer and a normal operating system, it's only a question of having a software to find them.

That, plus the fact that GPT stores a backup copy of the partition table at the end of drive, which would not be overwritten here, and the first filesystem might also be usable, as some filesystems have backup copies of the main data structures.

That's an equally bad solution for any drive, as discussed in the comments to the answer you linked to.

(Of course it's even less useful for SSDs, which might not even actually overwrite or erase the old data of those blocks, so they might be recoverable with proper tools/software. But that's not a major matter compared to having most of the interesting data still readable by normal means.)

If you're happy with just wiping the partition table and filesystem, it might be better to e.g. just create a new empty partition table with a regular partitioning tool, and to make sure to wipe all the filesystems from all partitions perhaps also by creating new ones on top. (The caveats with SSDs would still apply, but at least recovery would require know-how on debug-style access to the drive.)

Improve this answer
4
  • Except that it doesn't necessarily overwrite the physical blocks making up that section of the drive. The new, zeroed blocks can be stored in a different place from the old ones. Sure, the old ones will no longer be allocated to a logical location that's readable without debug tools, but that doesn't mean they're unrecoverable.
    – Charles Duffy
    Jun 17, 2020 at 22:06
  • @CharlesDuffy, Sure. But that's a minor matter compared to leaving most of the interesting stuff readable even without debug tools. :D
    – ilkkachu
    Jun 18, 2020 at 8:31
  • One could say the same thing about rm.
    – Charles Duffy
    Jun 20, 2020 at 16:00
  • @CharlesDuffy, yes. It, too, is pretty much useless for safe data wiping from both SSDs and HDDs.
    – ilkkachu
    Jun 20, 2020 at 20:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.