Linux

54627 readers

517 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
No misinformation
No NSFW content
No hate speech, bigotry, etc

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 6 years ago

MODERATORS

[email protected]

Shredding my SSDs (NVMe) under linux? (feddit.org)

submitted 2 weeks ago by [email protected] to c/[email protected]

51 comments fedilink hide all child comments

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

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 1 points 2 weeks ago (1 children)

Then over-writing the size by a few gigs, reading the entire disk, and writing it again - as I put in my example - should work. In any case blkdiscard is not guaranteed to zero data unless the disk specifically supports that capability, and data can be forensically extracted from a blkdiscarded disk.

The Arch wiki says blkdiscard -z is equivalent to running dd if=/dev/zero.

[–] [email protected] 1 points 2 weeks ago (1 children)

I don't see how attempting to over-write would help. The additional blocks are not addressable on the OS side. dd will exit because it reached the end of the visible device space but blocks will remain untouched internally.

The Arch wiki says blkdiscard -z is equivalent to running dd if=/dev/zero.

Where does it say that? Here it seems to support the opposite. The linked paper says that two passes worked "in most cases", but the results are unreliable. On one drive they found 1GB of data to have survived 20 passes.

[–] [email protected] 1 points 2 weeks ago* (last edited 2 weeks ago) (1 children)

Sorry, it wasn't the Arch wiki. It was this page.

I hate using Stack Exchange as a source of truth, but the Arch wiki references this discussion which points out that not all SSDs support "Deterministic read ZEROs after TRIM", meaning a pure blkdiscard is not guaranteed to clear data (unless the device is advertised with that feature), leaving it available for forensics. Which means having to use --secure, which is (also) not supported by all devices, which means having to use -z, which the previous source claims is equivalent to dd if=/dev/zero.

So the SSD is hiding extra, inaccessible, cells. How does blkdiscard help? Either the blocks are accessible, or they aren't. How are you getting a the hidden cells with blkdiscard? The paper you referenced does not mention blkdiscard directly as that's a Linux-specific command, but other references imply or state it's just calling TRIM. That same paper, in a footnote below section 3.3, claims TRIM adds no reliable data security.

It looks like - especially from that security paper - that the cells are inaccessible and not reliably clearable by any mechanism. blkdiscard then adds no security over dd, and I'd be interested to see whether, with -z, it's any faster than dd since it perforce would have to write zeros to all blocks just the same, rather than just marking them "discarded".

I feel that, unless you know the SDD supports secure trim, or you always use -z, dd is safer, since blkdiscard can give you a false sense of security, and TRIM adds no assurances about wiping those hidden cells.

[–] [email protected] 1 points 2 weeks ago (1 children)

So the SSD is hiding extra, inaccessible, cells. How does blkdiscard help? Either the blocks are accessible, or they aren't. How are you getting a the hidden cells with blkdiscard?

The idea is that blkdiscard will tell the SSD's own controller to zero out everything. The controller can actually access all blocks regardless of what it exposes to your OS. But will it do it? Who knows?

I feel that, unless you know the SDD supports secure trim, or you always use -z, dd is safer, since blkdiscard can give you a false sense of security, and TRIM adds no assurances about wiping those hidden cells.

After reading all of this I would just do both... Each method fails in different ways so their sum might be better than either in isolation.

But the actual solution is to always encrypt all of your storage. Then you don't have to worry about this mess.

[–] [email protected] 1 points 1 week ago

The idea is that blkdiscard will tell the SSD's own controller to zero out everything

Just to be clear, blkdiscard alone does not zero out anything; it just marks blocks as empty. --secure tells compatible drives to additionally wipe the blocks; -z actually zeros out the contents in the blocks like dd does. The difference is that - without the secure or z options - the data is still in the cells.

always encrypt all of your storage

Yes! Although, I don't think hindsight is helpful for OP.