TRIM is garbage collection and is a part of the wear leveling system. The whole point of TRIM is to have the SSD only hold the charge it needs too for still in use (i.e. not deleted) data. It’s the charge that damages blocks over time,
I’m pretty sure that that is not correct.
The limiting factor is the number of writes. The reason that TRIM enhances life by facilitating wear leveling is that it lets the firmware know that the block no longer has useful data, so it can be returned to the pool used for wear-leveling. Without that, the firmware doesn’t know whether or not it can switch the physical block used to represent a given logical location and safely overwrite the existing contents of that new block.
The reason that TRIM enhances life by facilitating wear leveling is that it lets the firmware know that the block no longer has useful data
Ah I see the disconnect, TRIM doesn’t live in the OS outside of the firmware, TRIM is part of the controller firmware and is exposed as an ATA command for the OS to utilize
The study I have linked in my original comment goes more in-depth
Ah I see the disconnect, TRIM doesn’t live in the OS outside of the firmware, TRIM is part of the controller firmware and is exposed as an ATA command for the OS to utilize
Yes, I know.
The study I have linked in my original comment goes more in-depth
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.
EDIT: I took a look at your PDF on a desktop. While it’s pretty light on the specifics of how they tested that the data was present, nothing there talks about anything below the OS level. My expectation is that what they did for their test was try to do reads from the device at the OS level and see whether it returned zeroes. They aren’t going to look below that. If they were interfacing with the drive at a firmware or below level, I’d expect them to have mentioned it, as it’d be a significant amount of additional work. And they don’t list relevant information like model number, much less firmware revision on the drive.
This is a complete digression but do you know if there is a consumer hardware that can be reliably erased? I’m trying to make something behave as an affordable HSM. If I could store a key encrypted at rest and be able to actually delete it, that would work for me.
This is a complete digression but do you know if there is a consumer hardware that can be reliably erased?
behave as an affordable HSM
Like, to create a hardware keystore? No, I don’t, sorry. If I wanted one myself, I’d probably just buy an existing one and hope that they did things correctly. :-)
I’m pretty sure that that is not correct.
The limiting factor is the number of writes. The reason that TRIM enhances life by facilitating wear leveling is that it lets the firmware know that the block no longer has useful data, so it can be returned to the pool used for wear-leveling. Without that, the firmware doesn’t know whether or not it can switch the physical block used to represent a given logical location and safely overwrite the existing contents of that new block.
Ah I see the disconnect, TRIM doesn’t live in the OS outside of the firmware, TRIM is part of the controller firmware and is exposed as an ATA command for the OS to utilize
The study I have linked in my original comment goes more in-depth
Yes, I know.
I’m on a phone, and it only partly showed up.
Direct PDF link
I mean, I read the PDF, the problem was the viewer bogging down.
googles
This sounds like what I expected:
https://superuser.com/questions/1060831/triming-as-alternative-to-securely-erasing-a-ssd
EDIT: I took a look at your PDF on a desktop. While it’s pretty light on the specifics of how they tested that the data was present, nothing there talks about anything below the OS level. My expectation is that what they did for their test was try to do reads from the device at the OS level and see whether it returned zeroes. They aren’t going to look below that. If they were interfacing with the drive at a firmware or below level, I’d expect them to have mentioned it, as it’d be a significant amount of additional work. And they don’t list relevant information like model number, much less firmware revision on the drive.
This is a complete digression but do you know if there is a consumer hardware that can be reliably erased? I’m trying to make something behave as an affordable HSM. If I could store a key encrypted at rest and be able to actually delete it, that would work for me.
Like, to create a hardware keystore? No, I don’t, sorry. If I wanted one myself, I’d probably just buy an existing one and hope that they did things correctly. :-)