Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #236639
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: Whole Disk Encryption + SSD |
| Date | 2021-06-30 02:20 +0200 |
| Message-ID | <Cvw7n-3tc-1@gated-at.bofh.it> (permalink) |
| References | <Cv0TT-1C0-3@gated-at.bofh.it> <Cv6cV-4QX-1@gated-at.bofh.it> <CvkIV-5dg-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Whole Disk Encryption + SSD piorunz <piorunz@gmx.com> - 2021-06-28 17:00 +0200
Re: Whole Disk Encryption + SSD Jochen Spieker <ml@well-adjusted.de> - 2021-06-28 18:00 +0200
Re: Whole Disk Encryption + SSD David Christensen <dpchrist@holgerdanske.com> - 2021-06-28 22:40 +0200
Re: Whole Disk Encryption + SSD David Christensen <dpchrist@holgerdanske.com> - 2021-06-29 00:00 +0200
Re: Whole Disk Encryption + SSD Stefan Monnier <monnier@iro.umontreal.ca> - 2021-06-29 02:00 +0200
Re: Whole Disk Encryption + SSD <tomas@tuxteam.de> - 2021-06-29 09:50 +0200
Re: Whole Disk Encryption + SSD Stefan Monnier <monnier@iro.umontreal.ca> - 2021-06-30 00:50 +0200
Re: Whole Disk Encryption + SSD David Christensen <dpchrist@holgerdanske.com> - 2021-06-30 01:00 +0200
Re: Whole Disk Encryption + SSD Jonathan Dowland <jon+debian-user@dow.land> - 2021-06-29 11:30 +0200
Re: Whole Disk Encryption + SSD piorunz <piorunz@gmx.com> - 2021-06-29 14:10 +0200
Re: Whole Disk Encryption + SSD David Christensen <dpchrist@holgerdanske.com> - 2021-06-30 02:20 +0200
Re: Whole Disk Encryption + SSD David Wright <deblis@lionunicorn.co.uk> - 2021-07-02 05:00 +0200
Re: Whole Disk Encryption + SSD David Christensen <dpchrist@holgerdanske.com> - 2021-07-02 05:50 +0200
Useless use of "dd" Teemu Likonen <tlikonen@iki.fi> - 2021-07-02 07:50 +0200
Useful use of dd [was: Useless use of "dd"] <tomas@tuxteam.de> - 2021-07-02 09:50 +0200
Re: Useful use of dd [was: Useless use of "dd"] Teemu Likonen <tlikonen@iki.fi> - 2021-07-02 12:30 +0200
Re: Useful use of dd "Thomas Schmitt" <scdbackup@gmx.net> - 2021-07-02 13:00 +0200
Re: Useful use of dd <tomas@tuxteam.de> - 2021-07-02 13:20 +0200
Re: Useful use of dd Teemu Likonen <tlikonen@iki.fi> - 2021-07-02 13:30 +0200
Re: Useful use of dd David Christensen <dpchrist@holgerdanske.com> - 2021-07-02 23:50 +0200
Re: Useful use of dd [was: Useless use of "dd"] <tomas@tuxteam.de> - 2021-07-02 13:20 +0200
Re: Useful use of dd Michael Stone <mstone@debian.org> - 2021-07-02 14:50 +0200
Re: Useful use of dd [was: Useless use of "dd"] Kushal Kumaran <kushal@locationd.net> - 2021-07-02 21:10 +0200
Creation of empty files [was: Useful use of dd] David Christensen <dpchrist@holgerdanske.com> - 2021-07-02 23:40 +0200
Re: Creation of empty files [was: Useful use of dd] David Christensen <dpchrist@holgerdanske.com> - 2021-07-03 00:00 +0200
Re: Creation of empty files [was: Useful use of dd] Michael Stone <mstone@debian.org> - 2021-07-03 15:50 +0200
Re: Creation of empty files [was: Useful use of dd] David Christensen <dpchrist@holgerdanske.com> - 2021-07-03 23:40 +0200
Re: Creation of empty files [was: Useful use of dd] Michael Stone <mstone@debian.org> - 2021-07-04 06:00 +0200
Re: Useful use of dd [was: Useless use of "dd"] Greg Wooledge <greg@wooledge.org> - 2021-07-02 13:40 +0200
Re: Useful use of dd [was: Useless use of "dd"] <tomas@tuxteam.de> - 2021-07-02 13:40 +0200
Re: Useful use of dd [was: Useless use of "dd"] David Wright <deblis@lionunicorn.co.uk> - 2021-07-02 17:10 +0200
Re: Useful use of dd [was: Useless use of "dd"] <tomas@tuxteam.de> - 2021-07-02 17:40 +0200
Re: Useful use of dd [was: Useless use of "dd"] Gunnar Gervin <dofeelok@gmail.com> - 2021-07-03 09:20 +0200
Re: Useful use of dd [was: Useless use of "dd"] <tomas@tuxteam.de> - 2021-07-03 09:30 +0200
Useless use of shell pipelines [was: Useful use of dd] David Christensen <dpchrist@holgerdanske.com> - 2021-07-02 23:40 +0200
Re: Useless use of shell pipelines [was: Useful use of dd] l0f4r0@tuta.io - 2021-07-03 10:30 +0200
Re: Useless use of shell pipelines [was: Useful use of dd] Greg Wooledge <greg@wooledge.org> - 2021-07-03 15:40 +0200
Re: Useless use of "dd" David Christensen <dpchrist@holgerdanske.com> - 2021-07-02 21:40 +0200
Re: Whole Disk Encryption + SSD David Wright <deblis@lionunicorn.co.uk> - 2021-07-02 17:10 +0200
Re: Whole Disk Encryption + SSD Michael Stone <mstone@debian.org> - 2021-07-02 17:30 +0200
Re: Whole Disk Encryption + SSD David Christensen <dpchrist@holgerdanske.com> - 2021-07-02 20:40 +0200
csiph-web