Quickest way to wipe an SSD clean of all its partitions for repartitioning in Linux?

I want to wipe an SSD clean of all its partitions and data, so I can repartition it (this is not for security purposes).

I've looked at sudo dd if=/dev/zero of=/dev/sdb bs=1M but if this just fills each partition with zeros, I'm not sure this what I want to do.

I plan to run this command quite often, and I don't want to exhaust my SSD's writes. Could anyone give me advice on tackling this problem?

IgDV

Posted 2018-01-11T08:49:42.870

Reputation: 331

Study this: ATA Secure Erase. I have no experience with the process, so this is not an answer, just a hint. Anyone feel free to write your own answer about this if you know this is the right way.

– Kamil Maciorowski – 2018-01-11T08:54:44.450

18For security purposes, or merely because you need to repartition? – user1686 – 2018-01-11T08:55:46.140

mostly just to repartition – IgDV – 2018-01-11T09:07:31.660

1412 gauge pump-action. And you knew someone was going to say it sooner or later! – ssimm – 2018-01-11T13:40:19.260

1@ssimm - My preference is a charcoal barbecue. – Daniel R Hicks – 2018-01-12T02:08:23.683

You command should wipe the whole disk. It may need a partition rescan for the sdbX devices to vanish, but the partitioning is removed when you overwrite the first few megabytes of the disk. – allo – 2018-01-12T12:42:46.577

@IgDV: The fact that this is not for security purposes is critical to your question, so I have edited it to add this. Please review and correct as appropriate :-). – sleske – 2018-01-12T13:50:48.883

@ssimm: That's a very drastic form of repartitioning. – sleske – 2018-01-12T13:51:13.617

What's your SSD estimated TWB? It's pretty hard to kill a SSD these days... – Firebug – 2018-01-12T19:46:04.277

I think you don't have to do anything at all. The partition tool will overwrite the existing partition table. – Paul – 2018-01-13T04:48:50.810

Answers

On an SSD: You can TRIM whole disks or partitions using blkdiscard. It's not very secure, but practically instant (the disk merely marks all cells as unused).

For security: Use full-disk encryption. Don't bother wiping the entire disk if it's encrypted – you only need to wipe the area containing your keys (e.g. the first 1–2 MiB of every encrypted partition).

For repartitioning: Again, don't bother erasing all data. You only need to destroy the filesystems using wipefs, then scrub the first 1 MiB of your disk to purge leftover bootloaders. After you format a partition using mkfs, the OS will simply assume it is completely empty.

(In fact, on Linux, mkfs.ext4 will automatically TRIM the entire partition before formatting it.)

user1686

Posted 2018-01-11T08:49:42.870

Reputation: 283 655

6For repartitioning, why not just delete old partitions and create new ones? – el.pescado – 2018-01-11T10:41:49.613

5Because if you create new partitions at the same location (start position), you'll just find the same old data in them! (Of course that's usually not a problem, because reformatting with mkfs will trash it anyway. But various odd situations do happen – wipefs exists because it was needed.) – user1686 – 2018-01-11T10:45:01.323

What command will I need to use to apply this to /dev/sdb just wipefs /dev/sdb ? – IgDV – 2018-01-11T12:35:22.013

4@IgDV - what does man wipefs say? (Hint: look at the first example in the man page's examples section) – Timo – 2018-01-11T15:51:51.667

2"you only need to wipe the area containing your keys" - on SSD the keys are likely to be recoverable as well. TPM or strong password protecting keys might be better option. blkdiscard would be nice too as it would create a puzzle out of rest of the disk even if attacker knew key (assuming the old mapping cannot be recovered as well). "then scrub the first 1 MiB of your disk to purge leftover bootloaders" - the extra section is used only as overflow of first 512B. If you wipe first 512B you're not harmed by the rest of 1M. – Maciej Piechotka – 2018-01-11T21:50:46.950

Sure, those keys normally are password-protected or even TPM-protected. – user1686 – 2018-01-11T22:19:14.363

1@MaciejPiechotka: Unfortunately, some bootloaders (grub in particular) also use the space after the MBR. – user1686 – 2018-01-12T05:44:22.190

@grawity Doesn't matter. As long as MBR is erased there isn't a program which would load anything from this partition so it shouldn't affect anything. Just like erasing MBR doesn't remove the OS and files are still, technically, there. – Maciej Piechotka – 2018-01-12T06:04:19.943

As Kamil Maciorowski mentions, the best way, with the least write-wear, of deleting an entire disk, is to use the ATA 'secure erase' command. This will instruct the hardware to do a single full wipe, rather than overwriting the cells repeatedly as with tools like shred. This can only be done for the entire disk, if you need to selectively wipe partitions, see grawity's answer (blkdiscard)

The exact implementation of the command depends on the hardware.

Most SSDs will use a bulk electric signal to wipe entire chips in an all-or-nothing fashion. This does incur (normal) write-wear, but only to the minimum extent possible (~ single write cycle).
Self-encrypting SSDs will usually just wipe the encryption key inside the controller chip (really instantaneous). Self-encrypting drives always encrypt, even out-of-the-box (with a factory-default key). So wiping the key leaves only un-decryptable jumble on the flash chips, even if no user-key was set.
Spinning-Rust hard-disks will do a hardware-based zero-write of all sectors, which is equivalent (and as time-consuming) as doing dd if=/dev/zero.

The process is documented quite well here: https://www.thomas-krenn.com/en/wiki/SSD_Secure_Erase (I have personally used this process repeatedly on my own SSDs when re-installing OS'es)

Edit: if you're interested in the security implications: check this Security.SE's question

Jules Kerssemakers

Posted 2018-01-11T08:49:42.870

Reputation: 191

Is Secure Erase supported by most ATA disks? I was under the impression that its support is uncommon. – Ruslan – 2018-01-11T10:21:21.763

I haven't found a (modern, SATA) disk yet that didn't support it, but I admit my experience is limited to harddrives I have personally owned.

There also seems to be a difference between "secure erase" and "enhanced secure erase", with the latter one being less supported.

– Jules Kerssemakers – 2018-01-11T12:17:12.323

3@Ruslan I have never seen (or heard of) a SATA-2 specification disk that didn't support it. Just about any SATA disk made in the last 10 years or so should have it. – Tonny – 2018-01-11T14:56:10.697

Does this also mean that on self-encrypting SSDs the TRIM command is a no-op? (Otherwise it's not always encrypting, right?) – user541686 – 2018-01-11T22:18:36.757

@Mehrdad why would trim be a no-op on encrypted drives? Isn't the trim an operation sent from the operating system saying that a given block(s) are not being used for storage? The running OS will see the volume as if it wasn't encrypted. – Zoredache – 2018-01-11T23:53:03.470

@Zoredache: Well it probably isn't implemented that way, but the problem in that case is that it would expose empty space as zeros. Genuine full encryption would encrypt empty space just like anything else. But TRIM would mean the drive is not encrypting the empty space. – user541686 – 2018-01-11T23:57:12.810

@Mehrdad: Yes, using TRIM on an encrypted SSD leaks information about which blocks are free. Whether that is acceptable depends on your security needs. See e.g. https://askubuntu.com/questions/399211/is-enabling-trim-on-an-encrypted-ssd-a-security-risk for a discussion.

– sleske – 2018-01-12T13:55:42.230

Keeping in mind you've asked for a solution on how to quickly wipe disks Replace /dev/sdx with your disk, most likly /dev/sda

This will wipe the partition table.

dd if=/dev/zero of=/dev/sdx bs=1024 count=50

This will wipe the entire disk, it will take a while.

cat /dev/zero > /dev/sdx

Jarrod Chesney

Posted 2018-01-11T08:49:42.870

Reputation: 149

4Do not use cat. Use dd to improve performance. – Micheal Johnson – 2018-01-11T19:57:25.447

6@Micheal You say that, but by default dd uses 512-byte buffers, which will ruin performance... Coreutils (cp and presumably also cat) have a more sensible buffer size. There's nothing about dd that makes it somehow inherently faster, anyway. – user1686 – 2018-01-11T22:21:21.647

3@grawity You can change the buffer size with dd. Last time I tried to use cat to write an image to a disk, it was significantly slower than using dd with an appropriate buffer size. – Micheal Johnson – 2018-01-12T22:04:06.223