On Fri, Oct 05, 2012 at 05:43:46AM +0200, Maxim Kammerer wrote: > Did anyone try this with devices that are supposed to be resistant to > file shredding due to wear leveling? I tried the following on two USB > keys, one ~12 years old, another ~6 years old, both formatted as > FAT32: > > echo test_string_123 > x > for i in $(seq 20); do cat x x > x1; mv x1 x; done > cp x /media/... && sync > shred -u /media/... && sync > cp /dev/sd... image > LC_ALL=C grep -wc test_string_123 image > > The result was 0 in both cases.
That's expected, because you're still going through the translation layer. If you had instead hooked up a microcontroller to the data pins of the flash chips on the circuitboard, you'd find that much of the data you'd written is still on the flash chips; it's simply in pages that aren't referenced by the current FTL state. Think of flash as a series of 6 whiteboards with 4 post-it notes tracking which "page" of notes is which. You start out writing to the board with "1" on it; when you fill that up you go to "2", then "3", then "4". Since you only have 4 post-it notes (4GB of memory) but the board with "1" on it is full of crud, you move the "1" post-it to a new board and continue writing. A gnome comes along and starts erasing the old "1" board because it doesn't have a post-it. Before the gnome finishes erasing old-"1", you move "2" to a new whiteboard and keep writing. Now, what happened when you ran shred? The 4 post-it notes (the FTL) got moved to fresh boards, which got filled with random writing. But the original board with test_string_123 on it doesn't have a post-it note and the gnome got tired, so the board isn't erased and there's no way to read it (because you can only read boards with post-it notes). In fact, one of the boards got used so much that its stand broke, and the gnome wheeled it into the corner without erasing it. Both of these gnome problems are real problems with FTL based systems; erase blocks can wear out and fail to erase, and the background erase process can fail to erase data as expected. Neither problem is very likely for any particular write, nor for any particular data, but just to be safe I always recommend using full-disk encryption when using SSDs, and physically destroying any removable flash-based media that have critically important data on them. PGP can be used to symmetrically encrypt data before putting it on an SD card/USB drive, too. -andy -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
