this post was submitted on 24 Dec 2025
887 points (98.7% liked)
linuxmemes
28603 readers
1087 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
- Don't get baited into back-and-forth insults. We are not animals.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn, no politics, no trolling or ragebaiting.
- Don't come looking for advice, this is not the right community.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
5. π¬π§ Language/ΡΠ·ΡΠΊ/Sprache
- This is primarily an English-speaking community. π¬π§π¦πΊπΊπΈ
- Comments written in other languages are allowed.
- The substance of a post should be comprehensible for people who only speak English.
- Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
6. (NEW!) Regarding public figures
We all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations. - Keep discussions polite and free of disparagement.
- We are never in possession of all of the facts. Defamatory comments will not be tolerated.
- Discussions that get too heated will be locked and offending comments removed. Β
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
One has to find the right balance between security and comfort, and this entirely depends on the threat model one has. Nowadays, I will always enable full-disk encryption on all of my devices, even if I then decide to store the keys in TPM and unlock the disk at boot.
I have at least 5 half-broken HDDs sitting around, completely unencrypted, I have no idea if they still work, but they are surely full of private data that I would like to have purged. I fear mechanical destruction might be the only solution for some of them, but just wiping them manually is more effort than doing nothing, so I guess they will still be around for some time. And with SSDs, there is no reliableway delete all data.
With encryption? Just delete the key and you are done.
The threat model changes in the future? Easy, the data is already encrypted.
I thought there was a table method of "destruction". Like you delete or destroy the table of allocation. Even though the data is on the SSD, its not contiguous like HDD and so its spread into bits everywhere. However failing that, leave them unplugged (unpowered) and in 70Β°C plus heat, the bits will lose their electrons rapidly.
This is true. For now...
I have been trying to understand what it is that makes it impossible to reliably wipe an SSD, compared to an HDD. Why wouldn't filling the drive with 0s work?
@Logical @shadowtofu
The SSD controller does not overwrite the old physical location (unlike HDD).
It writes the new data to a different physical block.
The old block becomes βstaleβ but still contains your original data until the SSD decides to erase it later.
But if I fill a drive with nonsense data, whether SSD or HDD, shouldn't it be forced to write such data to all possible locations, thus overwriting the original data? Is am I misunderstanding something more fundamental about how this type of storage works?
@Logical Filling an SSD with zeros only affects the logical address space visible to your OSβit doesn't force the controller to erase every physical block. The old data remains in unmapped or retired areas until (or unless) the controller decides to erase it later, potentially allowing recovery with specialized tools. Some SSDs might even optimize by not physically writing zeros if they detect a full block of them, simply marking the space as erased without touching the hardware.
See what I'm still not getting though, is how there can still be unmapped or retired areas, if the drive has been filled with (meaningless) data? Let's say it isn't all zeros, but random data instead. Are there more physical blocks than is represented logically by the adress space exposed to the OS?
On big flash memory you typically have more memory on the chips, than ia presented to the OS. Flash has significantly less write cycles, before the block breaks, so the controller monitors the health and won't use it anymore when it will soon fail. Instead it uses a block from its unused extra space. (Details might be different, I'm not sure about that). This way the lifetime of the SSD is significantly improved. SD cards do the same, I think.
So the data in the retired blocks will remain and cannot be overwritten by the OS. If they are encrypted and the keys deleted, that won't matter
Okay, that makes a lot more sense then. Thanks!