The recommended way of securely erasing a SSD is the ATA secure erase. Most of the BIOSes disable this function by freezing the drive. Some tricks around the BIOS freeze exist and may or may not work depending on the setup. This makes ATA secure erase difficult to use.

Could triming be misused as an alternative to securely erasing a SSD?

One could delete any existing partition table and create a new GPT with one ext4 partition filling the whole SSD. Triming the ext4 partition would cause the SSD to erase all logical blocks on the SSD but the blocks holding the GPT and the ext4 super block. Reserve blocks which are not assigned to a logical block are erased by definition. This way all physical blocks would either be erased or contain useless GPT/ext4 meta information.

Do you see any flaw in this plan?

Please do not answer that ATA secure erase should be used to securely erase a SSD, this is not the question.

  • 1
    TRIMming is used to erase an SSD.
    – Deltik
    Apr 3 '16 at 15:15
  • In my question yes :-). According to Shimpi, Anand Lal. (2009-03-18). p. 10.: "Trimming enables the SSD to handle garbage collection overhead, which would otherwise significantly slow down future write operations to the involved blocks, in advance." (found on Wikipedia). It just happens that preparing the flash for future write operation involves erasing it; it could be otherwise with other memory technologies. Apr 3 '16 at 15:41

Let's put it this way:

The truth is, in most, if not all, SSDs, ATA Secure Erase is an equivalence to a full device TRIM. Except those with "hardware encryption", where ATA Enhanced Secure Erase is basically a regeneration of the encryption key. So after all ATA Secure Erase in SSDs is not really THAT secure, unless yours support "hardware encryption".

On the other hand, fstrim is not the only way to TRIM a device. You can use blkdiscard to wipe a whole block device (disk/partition) including the GPT and superblock and whatsoever.

However, be aware that TRIM implementation in some of the disks has a "requirement" in the TRIM commands issued, so only when it is fulfilled, all the blocks on the drive will then "read zero" after TRIM.

For example, the Intel 530 SSD requires the TRIM block ranges to be "aligned" to 8 blocks. So when I want to wipe it clean with blkdiscard or hdparm, I will need to make sure that no "minimum unit" is "covered" by two TRIM ranges.

With blkdiscard, I'll need to specify -p 33550336 (65528 blocks * 512 bytes, where 65528 = 65535 (max no. of block in a single range) - 65535 % 8), assuming the starting offset is 0 (or a multiple of [8 * 512]), otherwise there will be leftover blocks that will not be wiped. This can be checked with something like hexdump after the TRIM.

See the difference of my Intel 530 (sda) and Silicon Power S70 (sdb):

enter image description here

and the difference when the ranges are not aligned and aligned:

enter image description here

(There are still leftover at the end since 65535 * 2 = 131070 is not a multiple of 8, but you can see that 131064 blocks [0x3FFF000 / 512] are continuously wiped.)

No cheating:

enter image description here

P.S. I've also seen drives from SanDisk that its "head" and "tail" cannot be wiped with TRIM command in any form. The "minimum unit" of it is 256 blocks.


If data security is your concern, it should be noted that neither a SECURE_ERASE nor a TRIM actually erase the flash cells. The SSD firmware keeps a list of which cells are allocated and which are not. A TRIM simply marks a cell as unallocated the same way deleting a file causes the filesystem to mark a cluster as unallocated. No attempt is made to actually erase the data. A read request from an unallocated cell simply causes the device to return 0x00 (or some other bit pattern) without actually checking the cell's contents.

There is no effective way of securely wiping an SSD. Forensics tools that can interface with the firmware directly can see the cells' contents. Also, there is more storage on the device than what is accessible from user-space. These extra cells are used in garbage collection. Garbage collection can reallocate cells on-the-fly and can still work even on a drive that is 100% full. A SECURE_ERASE may (probably does) TRIM those cells, but a blkdiscard or fstrim certainly wouldn't, since they use sector numbers to identify the areas to be TRIMmed.

The only way to securely erase an SSD is to destroy it. This is the policy of most companies in health care, banking, and government when surplussing equipment.

  • A secure erase is required to actually erase the medium, not just the block translation tables.
    – psusi
    Apr 5 '16 at 2:14
  • 2
    This is a very interesting answer which raises many questions. What is the meaning of a secure erase according to the ATA specification? Can you maybe cite sources? I understand that trimming may not lead immediately to a cell erase. Still after some fixed (probably not to long) amount of time the trimmed cell need to be physically erased; otherwise after this amount of time a drop of write performance would be noticeable because the SSD would run out of fresh cells (like on SSDs without trim support). What do you think? Apr 5 '16 at 6:53
  • Furthermore I understand that there is a lot of speculation and guessing in my reasoning; for very sensible data a big organization would prefer physical destruction to rule out any risk of a backdoor or bug in the SSD firmware. My concern is more about the normal consumer reselling his drive. Apr 5 '16 at 6:54
  • 1
    Vendors never really cared about the definitions of ATA Secure Erase when they make an SSD or one of those drive (HDD/SSD) that supports hardware encryption. It makes sense since the definitions (zero/one/pattern-filling) simply does not fit well in SSD, and there is (or was, I think they added something recently) no feature/command defined that allows implemention of hardware encryption (I mean, a means for users to trigger a regeneration of encryption key, pretty much the whole point of those non-OPAL encryption). So at the end of the day, the vendors simply implement it in the way they like
    – Tom Yan
    Apr 5 '16 at 12:13
  • 1
    @Alex over-writing files on SSD does not erase them from the media, the new bits go onto a different physical location - you might as well just use TRIM.
    – Jasen
    Sep 3 '18 at 22:26

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.