SSD Secure Erase – Trimming as an Alternative

secure-erasessd

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.

Best Answer

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.

Related Question