Hey guys,
I want to shred/sanitize my SSDs. If it was a normal harddrive I would stick to ShredOS / nwipe, but since SSD’s seem to be a little more complicated, I need your advice.
When reading through some posts in the internet, many people recommend using the software from the manufacturer for sanitizing. Currently I am using the SSD SN850X from Western digital, but I also have a SSD 990 PRO from Samsung. Both manufacturers don’t seem to have a specialized linux-compatible software to perform this kind of action.
How would be your approach to shred your SSD (without physically destroying it)?
~sp3ctre
Educate me.
My response would normally be:
dd if=/dev/random of=/dev/sdX ba=1024M, followed by async. Lowest common denominator nearly always wins in my book over specialty programs that aren’t part of minimal core; tools that also happen to be in BusyBox are the best.What makes this situation special enough for something more complex than
dd? Do SSDs not actually save the data you tell them to? I’m trying to guess at how writing a disk’s worth of garbage directly to the device would fail. I’m imagining some holographic effect, where you can actually store more data than the drive holds. A persistent, on disk cache that has no way of directly affecting, but which can somehow be read later and can hold latent data?If I were really, I’d dd, read the entire disk to /dev/null, then dd again. How would this not be sufficient?
I’m honestly trying to figure out what the catch is, here, and why this was even a question - OP doesn’t sound like a novice.
Well, first I need to note that
blkdiscardis not more secure. But it is much more faster. It does not actually wipe flash memory, it just tells the controller to mark it as unused. So it will drop stored data at the moment it decides the best. Maybe immediately, maybe just before writing new data. But anyway it wont provide ability to read it. It would be still possible if you can get direct access to the flash memory bypassing the controller.Second, you forgot that SSDs are not HDDs and data are not stored exactly at offset you write them. The controller remaps memory blocks as needed. And it has more blocks than actually available to user. So when you use
dd(orcp, or any other program writing directly to block device) you only override blocks that are actually mapped, but some blocks can still keep old data. So usingddis also not secure in case someone can get direct access to the flash memory. But it takes much longer time and reduces the flash lifetime.Several people here mentioned a secure erase feature of SSDs. I didn’t know about it. It should be more secure than both methods if implemented correctly by the manufacturer (i. e. clears all memory cells immediately). In the worst case it could be the same as
blkdiscard, I guess.SSDs don’t store the data like HDDs, where you’d overwrite the same part on a magnetic platter. The controller on a SSD will instead handle it, do some magic and decide what to do. So if you use
ddto replace some part with zeros, it might instead invalidate the old data, allocate new memory to you and not really overwrite anything. That’s why SSDs have separate commands for wiping content.I’d say google for “ssd secure erase”: