David Christensen wrote: ... > Yes, things get very bad when bad people control the SSD firmware. I > can only hope the firmware in my SSD's is legitimate, and updates are > cryptographically signed. > > > When using d-i to initialize a physical volume for encryption, I have > seen the option to fill the volume with random bytes. AIUI 'discard' > and 'trim' would gradually defeat such security-by-obfuscation as blocks > are erased, but it does make sense if the incremental security gain is > justified. I don't do it to my SSD's because I want to save their erase > cycles. > > > Please clarify "somewhat scrubbed".
in older days when devices were larger and you had onsite engineers who knew what they were doing they could change the heads position to pick up magnetic patterns from the disk. SSDs don't have the floating head position stuff to fiddle with but they do have badblocks and overprovisioning that perhaps can leak information that wasn't intended on being available, but i admit i'm not at all current on any of this. i don't plan on doing anything other than creating the new partition table and file systems and i'm not doing anything on this machine i consider top security or needing zero after writing or any other kind of random or encrypted overhead. i rarely run programs i download other than the ones i've written or ones supplied by Debian packages. Samsung doesn't have a utility for Linux so i don't have any current tools figured out yet for anything other than what i've used before (fdisk, parted, dd). i'm still assuming that if i want to zero a disk (or parts of it) or to write random info i can use dd on the entire device (and /dev/zero and/or /dev/random or similar). out of habit i normally use sync to make sure buffers are written and not waiting via the io cache before i do anything that might affect the file systems or backups. songbird
