Triming as alternative to securely erasing a SSD
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.
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):
and the difference when the ranges are not aligned and aligned:
(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:
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.