On 6/29/21 5:02 AM, piorunz wrote:
I don't trust SED, after listening to Steve Gibson analysis on state of
this feature.
Audio podcast: http://media.GRC.com/sn/SN-689.mp3
Transcript: https://www.grc.com/sn/sn-689.pdf
His findings were sourced, among other things, on work of security
researchers at the Radboud University in the Netherlands, titled:
"Self-Encrypting Deception: Weaknesses in the encryption of solid-
state drives."
https://ieeexplore.ieee.org/abstract/document/8835339
Interesting. The IEEE paper seems to cover Crucial, Samsung, and
Western Digital/Sandisk devices. I'm using Intel SSD 520 Series 2.5"
SATA drives. STFW I don't see any CVE's.
AIUI for my Intel SSD's [1], the encryption key is stored inside the
drive controller and is inaccessible to the outside world. Encryption/
decryption is always running and the bits in the storage transistors are
always encrypted. Performing a Secure Erase or Enhanced Secure Erase
will clear the storage transistors and generate a new encryption key.
The passphrase is a feature that is independent of the encryption key
and stored bits. The passphrase is accessible via the motherboard CMOS
Setup program (and specific utilities). Changing the passphrase does
not change the encryption key nor the bits in the storage transistors;
from a human viewpoint, it is instantaneous. Done correctly, data
stored on the drive remains accessible and unchanged.
I would suggest shopping for a good SSD. Per my other post, it will
likely have SED. If so, verify that the drive has no known SED
problems. You should be able to set or clear the passphrase as desired
(verify with testing as soon as you get the drive).
Will fstrim work with Debian-encrypted /home partition?
fstrim will show
trimmed gigabytes, just like on normal system?
If yes then that's in, my enquiry is solved.
fstrim(8) works on an ext4 filesystem on LUKS:
2021-06-29 16:16:32 root@dipsy ~/dipsy.tracy.holgerdanske.com/etc
# fstrim -v /scratch
/scratch: 27.7 GiB (29705924608 bytes) trimmed
2021-06-29 16:18:42 root@dipsy ~
# mount | grep scratch
/dev/mapper/sda4_crypt on /scratch type ext4 (rw,relatime)
2021-06-29 16:18:49 root@dipsy ~
# grep scratch /etc/fstab
/dev/mapper/sda4_crypt /scratch
ext4 defaults 0 2
If you use file systems other than ext4, you should test.
I would not worry about wearing out a good SSD in a daily driver laptop.
I have been using Intel SSD 520 Series 2.5" SATA in my SOHO laptops,
desktops, and servers for many years; they all work and have available
lifespans in the high 90%'s.
I prefer to preserve SSD life if I can. And with this problem, it's a
matter of proper configuring it ONCE during install, and then reap the
benefits for years to come. I don't want to throw away free performance
and longevity boost.
When I first started using SSD's, I read various articles and worried
about over-provisioning, trim, performance, lifetime, etc.. My
experience has been that simple OOTB settings are just fine for my SOHO
workloads. People running servers with workloads that hammer the SSD's
24x7 are the ones who need to worry.
David
[1]
https://www.intel.com/content/dam/www/public/us/en/documents/technology-briefs/ssd-520-aes-tech-brief.pdf
