Shredding my SSDs (NVMe) under linux?
from sp3ctre@feddit.org to linux@lemmy.ml on 19 May 09:11
https://feddit.org/post/12705964
from sp3ctre@feddit.org to linux@lemmy.ml on 19 May 09:11
https://feddit.org/post/12705964
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
threaded - newest
Don’t ever write any really private data to the SSD in cleartext. Use an encrypted file system. “Erase” by throwing away the key. That said, for modern fast SSD’s the performance overhead of the encryption might be a problem. For the old SATA SSD in my laptop, I don’t notice it.
How so? I’ve been running LUKS on modern NVMEs for years and there is just the same maybe at worst 10% hit in write/read speeds.
That's also my experience. There isn't really any noticeable performance hit, even on modern SSDs. It should be the same amount of data coming from the SSD anyway, since the SSD isn't even the part doing the cryptography (with LUKS), so it shouldn't have any effect. And the CPU handles the decryption just fine
There is no discernible performance hit
Just use
blkdiscard.TIL! Or should I say TILL! (Today I learned (more about) Linux)
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.
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":
I agree dd isn’t useful for individual files. I contend that if I have an SSD of size X, and I write X amount of random bytes to it, there’s nothing magic about the SSD construction that will preserve any previous information on the drive. Wear leveling can not magically make the drive store more data than it can hold.
Well, in fact it can. That's "overprovisioning". The SSD has some amount of reserved space as replacement for bad cells, and maybe to speed things up. So if you overwrite 100% of what you've access to on the SSD, you'd still have X amount of data you didn't catch. But loosely speaking you're right. If you overwrite the entire SSD and not just files or one partition or something like that, you'd force it to replace most of the content.
I wouldn't recommend it, though. There is secure erase, blkdiscard and some nvme format commands which do it the right way. And 'dd' is just a method that get's it about right (though not 100%) in one specific case.
Hum. I read that
blkdiscardonly marks the blocks (cells?) as empty, and doesn’t change the contents; and that a sophisticated enough lab can still read the bits.In particular, the disk has to claim to support “Deterministic read ZEROs after TRIM”; if it doesn’t, you have no guarantee of erasure. Without knowing anything about the make and model,
blkdiscardwould be categorically less secure.Right?
Yes, thanks. Just invalidating or trimming the memory doesn't cut it. OP wants it erased so it needs to be one of the proper erase commands. I think blkdiscard also has flags for that, so I believe you could do it with that command as well, if it's supported by the device and you append the correct options. (zero, secure) I think other commands are easier to use (if supported).
But it can store more data than it tells you it can. All drives are actually lying about their capacity; they all have extra sectors to replace bad ones.
Not that much extra.
i was just in the same situation and stumbled upon an issue, but more on that later.
nvme cli might be what you are looking for, the arch wiki has got a good tutorial wiki.archlinux.org/title/Solid_state_drive/NVMe
but: it depends on how you connect the nvme ssd to your system. if you use an external enclosure/adapter the nvme would show up as /dev/sda because it is not attached to the proper interface. i did not manage to get nvme cli to work in that case.
but, and that is the much easier way to solve that issue: the bios is your friend. most modern bios provide a secure erase nvme option. so just stick the nvme ssd in your computer and try to do it that way. only took a couple of seconds due to the way it works on nvme ssds as far as i understand.
that said: i’ve got two older WD nvme ssds that i could’t format using four (!) different PC’s and their bioses, non of the manufactures software for windows or bootable usb sticks would work either (tried the latter on three different PC’s) and the external enclosure solution provided no help either. only the bios of an older asrock board easily accepted the nvme and managed to secure erase it. no clue what went wrong the first times but at least they are clean now.
Would ‘overwrite with zeroes’ in gnome Disks work?
No, ssds have a ton of wear leveling where data is shifted around and not deleted. Deleting data wears out the SSD, so it is held as much as possible with the controller. SSDs are like 10% bigger than advertised just to prolong the life.
Even if you write the whole thing with random data then zeros, it will still have blocks in unaccessible (to normal users) places that contain old data.
Always best to use disk encryption or keep any sensitive data in filesystem encryption like plasma vaults or fscrypt.
Thankfully it is largely just a few commands with built in tools to tell the drive firmware to secure erase
SATA SSD: acceptdefaults.com/2023/…/secure-erase-an-ssd/
NVME SSD: acceptdefaults.com/…/secure-erase-an-nvme-drive/
This. And then when it’s done, use a hex editor and look at the raw disk to make sure it actually worked. Some manufacturers don’t implement it properly.
Sorry, but can you explain a little, how this is done exactly? What should I see, when everything worked correctly?
Preferably all zeroes, possibly random data or a fixed string. Certainly not anything readable.
No, you don’t want all zeroesz, you want random data.
Within Linux you can quite easily do this yourself too
According to the upvotes, this seems to be the way. I will try that, thank you!
I did some light reading. I see claims that wear leveling only ever writes only to zeroed sectors. Let me get this straight:
If I have a 1TB ssd, and I write 1TB of SecretData, and then I delete and write 1TB of garbage to the disk, it’s not actually holding 2TB of data, with the SecretData hidden underneath wear leveling? That’s the claim? And if I overwrite that with another 1TB of garbage it’s holding, what now, 3TB of data? Each data sequence hidden somehow by the magic of wear leveling?
Skeptical Ruaraidh is skeptical. Wear leveling ensures data on an SSD is written to free sectors with the lowest write count. It can’t possibly be retaining data if data the maximum size of the device is written to it.
I see a popular comment on SO saying you can’t trust
ddon SSDs, and I challenge that: in this case, wiping an entire disk by dumping /dev/random must clean the SSD of all other data. Otherwise, someone’s invented the storage version of a perpetual motion device. To be safe, sync and read it, and maybe dumb again, but I really can’t see how an SSD world hold more data than it can.dd if=/dev/random of=/dev/sdX bs=2048 count=524288If you’re clever enough to be using zsh as your shell:
repeat 3 (dd if=/dev/random of=/dev/sdX bs=2048 count=524288 ; sync ; dd if=/dev/sdX ba=2048)You reduce every single cell’s write lifespan by 2 times; with modern life spans of 3,000-100,000 writes per cell, it’s not significant.
Someone mentioned
blkdiscard. If you really aren’t concerned about forensic analysis, this is probably the fastest and least impactful answer: it won’t affect cell lives by even a measly 2 writes. But it also doesn’t actually remove the data, it just tells the SSD that those cells are free and empty. Probably really hard to reconstruct data from that, but also probably not impossible.ddis a shredding option: safer, slower, and with a tiny impact on drive lifespan./dev/random, seriously? This will take ages and have no advantages over/dev/zero. Even when you really need to fill your drive with random data, use/dev/urandom, there’s a chance that this will finish in couple days at least. And no, there’s no guarantee that it will wipe all blocks because there are reserved blocks that only device firmware can access and rotate. Some data on rotated blocks still can be accessible for forensic analysis if you care about this.I think most modern distros use urandom for random too. These days, the PRNG is strong enough it doesn’t need to stop and wait for more entropy.
for future reference, encrypt your drives from the get-go. even if it’s not a mobile device, you can use on-device keys to unlock it without a pass-phrase.
source: used
shredon a couple of 3.5" 4 TB drives before selling them, took ages…I will take that into consideration. I already encrypted my older laptop (hard drive) with LUKS. Is there something special, when it comes to encrypting SSD’s? Do you experience speed losses of SSD after doing so?
every mobile device I ever owned is encrypted and protected with a reasonably secure pass-phrase so losing it is no big deal. it is conceivable someone could forensic the shit out of my setup but that is highly unlikely; it’s far more likely it’ll get wiped and sold or parted out.
I’ve done no benchmarks but I haven’t experienced any issues ever. the oldest linux device I own is a 2011 MBP (i7-2635qm, so quadcore) and I don’t perceive any speed degradation; it’s possible 1st gen Core i5/i7 could have issues as those don’t have AES-NI in hardware or sumsuch plus they’re SATA2 only, but those would be 15+ years old at this point.
with btrfs that has on-the-fly compression, copy-on-write, and deduping, everything works seamlessly, even when I have database-spanking applications in local development.
so the only thing I’ve changed recently is encrypting every device I have, not just the mobile ones. the standalone devices get unlocked with a key-file from the local filesystem so they boot without the prompt. selling/giving away any of those drives, mechanical or SSD, is now a non-issue.