Re: SDD partitioning and allocations
On 7/13/25 04:37, songbird wrote:
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.
Okay. It's all analog at some level and quantum mechanics at the bottom.
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 >
Your Samsung drives may have hardware encryption. If they are anything
like my Intel SSD 520 Series drives, encryption is running all of the
time, you can set or unset the user password at any time, and
performance is the same both ways. The downsides are that you must
enter the user password into the console at boot, and the disk may not
unlock when moved to a different computer (I never figured out why).
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).
You can do a security erase with hdparm(8):
https://mackonsti.wordpress.com/2011/11/22/ssd-secure-erase-ata-command/
The crux is getting the drive into a state where security is not frozen.
I have a computer whose BIOS Setup allows me to enable hot-swap on a
motherboard SATA port. The port is cabled to a hot-swap bay. I boot a
live Debian disk, insert the target drive (Intel SSD 520 Series 60 GB)
into the hot-swap bay, and do the work.
1. Verify security is not frozen:
2017-08-19 15:41:18 root@laalaa ~
# hdparm -I /dev/sda | grep frozen
not frozen
2. Set the user password:
2017-08-19 15:42:02 root@laalaa ~
# hdparm --user-master u --security-set-pass Eins /dev/sda
security_password: "Eins"
/dev/sda:
Issuing SECURITY_SET_PASS command, password="Eins", user=user, mode=high
3. Issue the security erase command:
2017-08-19 15:46:57 root@laalaa ~
# time hdparm --user-master u --security-erase Eins /dev/sda
security_password: "Eins"
/dev/sda:
Issuing SECURITY_ERASE command, password="Eins", user=user
real 0m17.384s
user 0m0.000s
sys 0m0.000s
4. Look at the drive information:
2017-08-19 15:49:09 root@laalaa ~
# hdparm -I /dev/sda
<snip>
5. Verify the drive is empty:
2017-08-19 15:49:43 root@laalaa ~
# time hexdump /dev/sda
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
df99e6000
real 7m16.389s
user 3m9.112s
sys 0m50.172s
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).
I have been doing software encryption for many years, so `dd
if=/dev/zero bs=1M /dev/sdX` is good enough for a HDD. If and when I
want more security, I will use shred(1).
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
Using sync(1) is wise -- I cannot name a specific tool, but I do recall
experiencing userland tools exiting before their asynchronous writes
completed and data was on disk.
David
Reply to: