[opensuse-kernel] trim or not to trim : luks encrypted ssd

Bruno Friedmann

26 May 2014 26 May '14

09:33

A few months ago, I discovered that in mkinitrd we don't have (take care?) support for the option allow-discards for crypsetup luks drive. Trying fstrim: /: FITRIM ioctl failed: Operation not supported on plain stock 13.1 Even with the argument on boot line cryptdevice=/dev/mapper/cr_sda2:root:allow-discards I've then patched locally boot-luks.sh by adding the hard way the support by modifying the function luksopen() { local name="$1" local ask_pass="$2" eval local dev="\"\${luks_${name}}\"" eval local realname="\"\${luks_${name}_name}\"" if [ "$ask_pass" = no ]; then cryptsetup --tries=1 --allow-discards luksOpen "$dev" "$realname" ret="$?" elif luks_check_ply; then plymouth ask-for-password --prompt="Unlocking ${realname} ($dev)" | cryptsetup --tries=1 --allow-discards luksOpen "$dev" "$realname" ret="$?" else echo -e "${extd}Unlocking ${realname} ($dev)${norm}" splash_off cryptsetup --tries=1 --allow-discards luksOpen "$dev" "$realname" ret="$?" fi return "$ret" } Mostly cause my laptop has this option, part 1 is /boot unencrypted ext4 part 1 the whole rest with vg encrypted. So far so good, the discard option in fstab and manual fstrim function work after a reboot with the new initrd. My first question is : is it a good idea to have discard option for encrypted device ? My main concern is (my 2.5 years 480Gb ssd which totalize a 35000Gb write for 13000 hours powered on) behave strangely last week-end. Some binaries normally ELF became data file. (Was the case of dos2unix) which I don't run from months. rpm -Va show others like this .5.... just the md5sum has changed... Could it be linked to the fact that the ssd has work during 2.5 years without any trim? What your thought on it? -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board GPG KEY : D5C9B751C4653227 irc: tigerfoot ~~~Don't take Life too serious. Nobody gets out alive anyway!~~~ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Show replies by date

Stefan Seyfried

26 May 26 May

11:39

Am 26.05.2014 11:33, schrieb Bruno Friedmann:

...

Some binaries normally ELF became data file. (Was the case of dos2unix) which I don't run from months. rpm -Va show others like this .5.... just the md5sum has changed...

I had seen similar things on my "server" at home. No SSD involved at that time, only HDDs. Exchanging the RAM sticks solved the issue apparently (even though memtest86 did not find any errors). -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman "Your mail is 7 pages of printout. Do you seriously expect people that do openSUSE in their free time to read that? Little less Castro, little more JFK..." -- coolo -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Bruno Friedmann

15:10

On Monday 26 May 2014 13.39:43 Stefan Seyfried wrote:

...

Am 26.05.2014 11:33, schrieb Bruno Friedmann:

...
Some binaries normally ELF became data file. (Was the case of dos2unix) which I don't run from months. rpm -Va show others like this .5.... just the md5sum has changed...

I had seen similar things on my "server" at home. No SSD involved at that time, only HDDs.

Exchanging the RAM sticks solved the issue apparently (even though memtest86 did not find any errors).

I've think about that too. but I can't explain how a binary correctly written during install and never touch since (yeah I know why having it then ;-)) could be changed by a bad ram ? The binary have been read several time by backup software and this one also tell me that between last week-end something happen to that binary. Am I too naive ? :-) I also suspect a bit more "somewhat somewhere something" between the ssd & system. I've hopefully run only fstrim on / and /var my 2 system lvm (ext4 with discard) But (here I'm lucky) /home another lvm over the encrypted has also discard option, and none of the file got corruption.... /me complain if only it's a full nice crash, then call support make replacement and done :-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board GPG KEY : D5C9B751C4653227 irc: tigerfoot ~~~Don't take Life too serious. Nobody gets out alive anyway!~~~ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Markus Koßmann

15:45

Am Montag, 26. Mai 2014, 17:10:17 schrieb Bruno Friedmann:

...

On Monday 26 May 2014 13.39:43 Stefan Seyfried wrote:

...
Am 26.05.2014 11:33, schrieb Bruno Friedmann:

...
Some binaries normally ELF became data file. (Was the case of dos2unix) which I don't run from months. rpm -Va show others like this .5.... just the md5sum has changed...

I had seen similar things on my "server" at home. No SSD involved at that time, only HDDs.

Exchanging the RAM sticks solved the issue apparently (even though memtest86 did not find any errors).

I've think about that too. but I can't explain how a binary correctly written during install and never touch since (yeah I know why having it then ;-)) could be changed by a bad ram ? Md5sum reads the binary into RAM and calculates the checksum over a changed bit of the RAM copy. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Stefan Seyfried

15:55

Am 26.05.2014 17:10, schrieb Bruno Friedmann:

...

On Monday 26 May 2014 13.39:43 Stefan Seyfried wrote:

...
Am 26.05.2014 11:33, schrieb Bruno Friedmann:

...
Some binaries normally ELF became data file. (Was the case of dos2unix) which I don't run from months. rpm -Va show others like this .5.... just the md5sum has changed...

I had seen similar things on my "server" at home. No SSD involved at that time, only HDDs.

Exchanging the RAM sticks solved the issue apparently (even though memtest86 did not find any errors).

I've think about that too. but I can't explain how a binary correctly written during install and never touch since (yeah I know why having it then ;-)) could be changed by a bad ram ? The binary have been read several time by backup software and this one also tell me that between last week-end something happen to that binary.

Did you reboot since then? Maybe a reboot makes the modification go away => bad RAM. For me it was only single bit flips ("!" changed to "#" in C source files, amongst others). If you have backups of the good and the bad version, then try comparing them with "cmp -l" and check if it's only single bytes that are changed or if it is a whole block of random for example. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Bruno Friedmann

27 May 27 May

06:03

On Monday 26 May 2014 17.55:32 Stefan Seyfried wrote:

...

Am 26.05.2014 17:10, schrieb Bruno Friedmann:

...
On Monday 26 May 2014 13.39:43 Stefan Seyfried wrote:

...
Am 26.05.2014 11:33, schrieb Bruno Friedmann:

...
Some binaries normally ELF became data file. (Was the case of dos2unix) which I don't run from months. rpm -Va show others like this .5.... just the md5sum has changed...

I had seen similar things on my "server" at home. No SSD involved at that time, only HDDs.

Exchanging the RAM sticks solved the issue apparently (even though memtest86 did not find any errors).

I've think about that too. but I can't explain how a binary correctly written during install and never touch since (yeah I know why having it then ;-)) could be changed by a bad ram ? The binary have been read several time by backup software and this one also tell me that between last week-end something happen to that binary.

Did you reboot since then? Maybe a reboot makes the modification go away => bad RAM. With the suspicious ssd, yes, and the same content where affected.

...

For me it was only single bit flips ("!" changed to "#" in C source files, amongst others).

If you have backups of the good and the bad version, then try comparing them with "cmp -l" and check if it's only single bytes that are changed or if it is a whole block of random for example.

Since then, a full cleanup of the internal, stabilize a bit the laptop. with another ssd inside, everything has run smoothly the last 3 days until saturday/sunday night during a pg_dumg on nfs May 26 00:29:19 c-3po.labaroche.ioda.net kernel: BUG: unable to handle kernel paging request at ffff89022d926950 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: IP: [<ffffffff811ca2ba>] inode_lru_isolate+0x18a/0x1f0 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: PGD 0 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: Oops: 0002 [#2] PREEMPT SMP May 26 00:29:19 c-3po.labaroche.ioda.net kernel: Modules linked in: nfsv3 nfs_acl nfs fscache lockd sunrpc rfcomm fuse af_packet bnep quota_v2 quota_tree snd_hda_codec_hdmi dell_wmi sp May 26 00:29:19 c-3po.labaroche.ioda.net kernel: linear md_mod hid_logitech_dj crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel ablk_helper cryptd lrw gf128m May 26 00:29:19 c-3po.labaroche.ioda.net kernel: CPU: 1 PID: 123 Comm: kswapd0 Tainted: P D O 3.14.4-1.gbebeb6f-desktop #1 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: Hardware name: Dell Inc. Precision M4600/08V9YG, BIOS A16 12/26/2013 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: task: ffff8804131aa1d0 ti: ffff8804131ac000 task.ti: ffff8804131ac000 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: RIP: 0010:[<ffffffff811ca2ba>] [<ffffffff811ca2ba>] inode_lru_isolate+0x18a/0x1f0 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: RSP: 0018:ffff8804131adba8 EFLAGS: 00010202 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: RAX: ffff880417d18b48 RBX: ffff88022d926580 RCX: 0000000000000002 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: RDX: ffff89022d926948 RSI: ffff880417d18b40 RDI: ffff88022d926510 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: RBP: ffff88022d926510 R08: ffff8804131adc30 R09: 0000000000000000 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: R10: 0000000000000001 R11: 0000000000000800 R12: ffff880417d18b40 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: R13: ffff8804131adc38 R14: ffff88022d926488 R15: ffff880417d18b40 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: FS: 0000000000000000(0000) GS:ffff88042dc20000(0000) knlGS:0000000000000000 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: CR2: ffff89022d926950 CR3: 0000000001e0e000 CR4: 00000000000407e0 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: Stack: May 26 00:29:19 c-3po.labaroche.ioda.net kernel: ffff880417d18b48 ffff88022d926580 ffffffff811ca130 ffff8804131adc30 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: ffff89022d926948 ffffffff8116715c ffff8804131adc38 0000000000000031 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: ffff880413615c40 0000000000000000 ffff8804131adc38 ffff880413615b58 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: Call Trace: May 26 00:29:19 c-3po.labaroche.ioda.net kernel: [<ffffffff8116715c>] list_lru_walk_node+0x7c/0x160 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: [<ffffffff811ca8a9>] prune_icache_sb+0x39/0x50 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: [<ffffffff811b2862>] super_cache_scan+0xf2/0x160 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: [<ffffffff81151df7>] shrink_slab_node+0x127/0x2d0 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: [<ffffffff81153fe2>] shrink_slab+0x82/0x160 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: [<ffffffff81156817>] kswapd_shrink_zone+0x107/0x1a0 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: [<ffffffff81157bda>] kswapd+0x49a/0x810 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: [<ffffffff8107a4d6>] kthread+0xc6/0xe0 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: [<ffffffff816106fc>] ret_from_fork+0x7c/0xb0 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: Code: 92 a0 07 00 00 48 01 02 e9 31 ff ff ff 0f 1f 40 00 48 8b 43 a8 a8 08 75 56 48 83 c8 20 48 8b 13 48 89 ef 48 89 43 a8 48 8b 43 08 May 26 00:29:19 c-3po.labaroche.ioda.net kernel: RIP [<ffffffff811ca2ba>] inode_lru_isolate+0x18a/0x1f0 Which freeze the computer (even if it still ping :-) Then a reboot a 24h of work and idle and this morning a zypper ref -f show [87240.626613] zypper[23391]: segfault at 100023036c8 ip 00007f1130a8d927 sp 00007fffde48def0 error 4 in libzypp.so.1306.3.0[7f113070f000+479000] Wait a bit check so, bin etc .. and then work.... Time to dig for a full replacement I guess :-( -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board GPG KEY : D5C9B751C4653227 irc: tigerfoot ~~~Don't take Life too serious. Nobody gets out alive anyway!~~~ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Greg Freemyer

26 May 26 May

16:25

On May 26, 2014 5:33:58 AM EDT, Bruno Friedmann wrote:

...

A few months ago, I discovered that in mkinitrd we don't have (take care?) support for the option allow-discards for crypsetup luks drive.

Bruno, A lot of (if not most) SSDs set trimmed sectors to all nulls. Doing that on an encrypted partition would allow a cracker to identify encrypted data from encrypted garbage. That is not a good thing, especially if the partition is significantly underfilled. Ie a drive with only 10% utilization would have 90% nulls, so you have drastically simplified life for an attacker.

...

Trying fstrim: /: FITRIM ioctl failed: Operation not supported on plain stock 13.1 Even with the argument on boot line cryptdevice=/dev/mapper/cr_sda2:root:allow-discards

I've then patched locally boot-luks.sh by adding the hard way the support by modifying the function

luksopen() { local name="$1" local ask_pass="$2" eval local dev="\"\${luks_${name}}\"" eval local realname="\"\${luks_${name}_name}\"" if [ "$ask_pass" = no ]; then cryptsetup --tries=1 --allow-discards luksOpen "$dev" "$realname" ret="$?" elif luks_check_ply; then plymouth ask-for-password --prompt="Unlocking ${realname} ($dev)" | cryptsetup --tries=1 --allow-discards luksOpen "$dev" "$realname" ret="$?" else echo -e "${extd}Unlocking ${realname} ($dev)${norm}" splash_off cryptsetup --tries=1 --allow-discards luksOpen "$dev" "$realname" ret="$?" fi return "$ret" }

Mostly cause my laptop has this option, part 1 is /boot unencrypted ext4 part 1 the whole rest with vg encrypted.

So far so good, the discard option in fstab and manual fstrim function work after a reboot with the new initrd.

My first question is : is it a good idea to have discard option for encrypted device ?

No, see above

...

My main concern is (my 2.5 years 480Gb ssd which totalize a 35000Gb write for 13000 hours powered on) behave strangely last week-end.

Trim should help extend the life of the drive, and keep it from slowing down as it becomes full.

...

Some binaries normally ELF became data file. (Was the case of dos2unix) which I don't run from months. rpm -Va show others like this .5.... just the md5sum has changed...

Could it be linked to the fact that the ssd has work during 2.5 years without any trim?

If the SSD is changing the content of allocated sectors/pages, it is broken. SSDs have complex firmware, so could your use case have triggered a bug? Of course, firmware is just software kept in stable media.

...

What your thought on it?

Start running hardware diagnostics, but if the supposedly stable data blocks on disk are no longer stable, you have issues. But don't be too quick to blame the SSD. Both the filesystem and the SSD use multiple levels of indirection / pointers. Bad ram / cpu / controller / cables / power supply can all fail in such a way that the data pointers read from the filesystem metadata is corrupt and then the wrong sectors/pages are requested from the SSD. I would try to physically connect the SSD to another PC via a write-blocker to see if it sees the same problem. Fyi: Cool Gear has a sata to usb write-blocker that is very cost effective. $50 from Amazon. The ones I used to buy were more like $800. http://www.amazon.com/CoolGear%C2%AE-SATA-Adapter-Write-Protect-Selection/dp... At that price it is great thing for anyone that works with hardware to own. I bought 2 and I've really liked them. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Bruno Friedmann

27 May 27 May

05:58

On Monday 26 May 2014 12.25:42 Greg Freemyer wrote:

...

On May 26, 2014 5:33:58 AM EDT, Bruno Friedmann wrote:

...
A few months ago, I discovered that in mkinitrd we don't have (take care?) support for the option allow-discards for crypsetup luks drive.

Bruno,

A lot of (if not most) SSDs set trimmed sectors to all nulls.

Doing that on an encrypted partition would allow a cracker to identify encrypted data from encrypted garbage. That is not a good thing, especially if the partition is significantly underfilled. Ie a drive with only 10% utilization would have 90% nulls, so you have drastically simplified life for an attacker.

Make sense, thanks for the precision. (Mine is mostly 80% full :-) Then it look strange that other distributions have fstrim/discard allowed. We should check what dracut will do...

...

...
Trying fstrim: /: FITRIM ioctl failed: Operation not supported on plain stock 13.1 Even with the argument on boot line cryptdevice=/dev/mapper/cr_sda2:root:allow-discards

I've then patched locally boot-luks.sh by adding the hard way the support by modifying the function

luksopen() { local name="$1" local ask_pass="$2" eval local dev="\"\${luks_${name}}\"" eval local realname="\"\${luks_${name}_name}\"" if [ "$ask_pass" = no ]; then cryptsetup --tries=1 --allow-discards luksOpen "$dev" "$realname" ret="$?" elif luks_check_ply; then plymouth ask-for-password --prompt="Unlocking ${realname} ($dev)" | cryptsetup --tries=1 --allow-discards luksOpen "$dev" "$realname" ret="$?" else echo -e "${extd}Unlocking ${realname} ($dev)${norm}" splash_off cryptsetup --tries=1 --allow-discards luksOpen "$dev" "$realname" ret="$?" fi return "$ret" }

Mostly cause my laptop has this option, part 1 is /boot unencrypted ext4 part 1 the whole rest with vg encrypted.

So far so good, the discard option in fstab and manual fstrim function work after a reboot with the new initrd.

My first question is : is it a good idea to have discard option for encrypted device ?

No, see above

...
My main concern is (my 2.5 years 480Gb ssd which totalize a 35000Gb write for 13000 hours powered on) behave strangely last week-end.

Trim should help extend the life of the drive, and keep it from slowing down as it becomes full.

...
Some binaries normally ELF became data file. (Was the case of dos2unix) which I don't run from months. rpm -Va show others like this .5.... just the md5sum has changed...

Could it be linked to the fact that the ssd has work during 2.5 years without any trim?

If the SSD is changing the content of allocated sectors/pages, it is broken. SSDs have complex firmware, so could your use case have triggered a bug? Of course, firmware is just software kept in stable media.

Firmware is the latest available at corsair.

...

...
What your thought on it?

Start running hardware diagnostics, but if the supposedly stable data blocks on disk are no longer stable, you have issues.

But don't be too quick to blame the SSD. Both the filesystem and the SSD use multiple levels of indirection / pointers. Bad ram / cpu / controller / cables / power supply can all fail in such a way that the data pointers read from the filesystem metadata is corrupt and then the wrong sectors/pages are requested from the SSD.

I would try to physically connect the SSD to another PC via a write-blocker to see if it sees the same problem.

Well not that easy, due to the randomness of the symptoms ... and normally living in my lappy....

...

Fyi: Cool Gear has a sata to usb write-blocker that is very cost effective. $50 from Amazon. The ones I used to buy were more like $800. http://www.amazon.com/CoolGear%C2%AE-SATA-Adapter-Write-Protect-Selection/dp... At that price it is great thing for anyone that works with hardware to own. I bought 2 and I've really liked them.

Nice gadget (one more :-)) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board GPG KEY : D5C9B751C4653227 irc: tigerfoot ~~~Don't take Life too serious. Nobody gets out alive anyway!~~~ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Jeff Mahoney

14:11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/26/14, 12:25 PM, Greg Freemyer wrote:

...

On May 26, 2014 5:33:58 AM EDT, Bruno Friedmann wrote:

...
A few months ago, I discovered that in mkinitrd we don't have (take care?) support for the option allow-discards for crypsetup luks drive.

Bruno,

A lot of (if not most) SSDs set trimmed sectors to all nulls.

Doing that on an encrypted partition would allow a cracker to identify encrypted data from encrypted garbage. That is not a good thing, especially if the partition is significantly underfilled. Ie a drive with only 10% utilization would have 90% nulls, so you have drastically simplified life for an attacker.

Wouldn't that also imply that anyone using an encrypted partition should also fill it with random data prior to using it? I doubt that's happening in even a small minority of deployments. - -Jeff

...

...
Trying fstrim: /: FITRIM ioctl failed: Operation not supported on plain stock 13.1 Even with the argument on boot line cryptdevice=/dev/mapper/cr_sda2:root:allow-discards

I've then patched locally boot-luks.sh by adding the hard way the support by modifying the function

luksopen() { local name="$1" local ask_pass="$2" eval local dev="\"\${luks_${name}}\"" eval local realname="\"\${luks_${name}_name}\"" if [ "$ask_pass" = no ]; then cryptsetup --tries=1 --allow-discards luksOpen "$dev" "$realname" ret="$?" elif luks_check_ply; then plymouth ask-for-password --prompt="Unlocking ${realname} ($dev)" | cryptsetup --tries=1 --allow-discards luksOpen "$dev" "$realname" ret="$?" else echo -e "${extd}Unlocking ${realname} ($dev)${norm}" splash_off cryptsetup --tries=1 --allow-discards luksOpen "$dev" "$realname" ret="$?" fi return "$ret" }

Mostly cause my laptop has this option, part 1 is /boot unencrypted ext4 part 1 the whole rest with vg encrypted.

So far so good, the discard option in fstab and manual fstrim function work after a reboot with the new initrd.

My first question is : is it a good idea to have discard option for encrypted device ?

No, see above

...
My main concern is (my 2.5 years 480Gb ssd which totalize a 35000Gb write for 13000 hours powered on) behave strangely last week-end.

Trim should help extend the life of the drive, and keep it from slowing down as it becomes full.

...
Some binaries normally ELF became data file. (Was the case of dos2unix) which I don't run from months. rpm -Va show others like this .5.... just the md5sum has changed...

Could it be linked to the fact that the ssd has work during 2.5 years without any trim?

If the SSD is changing the content of allocated sectors/pages, it is broken. SSDs have complex firmware, so could your use case have triggered a bug? Of course, firmware is just software kept in stable media.

...
What your thought on it?

Start running hardware diagnostics, but if the supposedly stable data blocks on disk are no longer stable, you have issues.

But don't be too quick to blame the SSD. Both the filesystem and the SSD use multiple levels of indirection / pointers. Bad ram / cpu / controller / cables / power supply can all fail in such a way that the data pointers read from the filesystem metadata is corrupt and then the wrong sectors/pages are requested from the SSD.

I would try to physically connect the SSD to another PC via a write-blocker to see if it sees the same problem.

Fyi: Cool Gear has a sata to usb write-blocker that is very cost effective. $50 from Amazon. The ones I used to buy were more like $800.

http://www.amazon.com/CoolGear%C2%AE-SATA-Adapter-Write-Protect-Selection/dp...

At that price it is great thing for anyone that works with hardware to own. I bought 2 and I've really liked them.

Greg

- -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQIcBAEBAgAGBQJThJz2AAoJEB57S2MheeWyDrIQAK5pz82Oys6s70vbkG9p4uQy Z5Fx7iPR2Z9HGPZ5ZQcbKhrEMX0J4ljWA+KicUOF1g4CHzfFYqbD08iBc/rFRnPC zFJhVez0mjKAapihidvmEj1j5G/ZRONXYMcqqIiN44zL4umdjEVkWrpbFEE/vjRa 6UIAYlf7U3KgqOfATWn89KQvdTL0rWCEScQ0KqYLHOexRd9DodAOIfjqrRoAuJgm mZYgBF9ckmbHO77XorL59X+fSiJy2VB+H0b6Yuqf/k/ywgbv7v90S0pV0n3GgM/R 0exV35YwEEtm0ByPPCn5y9YfCu/gP1Zdwk4vc5+SlTN4pIaFqZdkg0FdyTzXu2my Jx8E8YaTrNE+b4ULcOJP48BPyDdZGwpY29SgqO5mm5zb8o8GHqcXlXOjqska1d11 loPVgoOsUdg+Pwpel321We8+NBWZ1adXU8+q+U1NV62v5VkpMi91t7XPk4T4UEbG v60c47wlLsBS/NY64ImjUigs5NQLCkJ1T+P65scBHsBcmmsk1YJNskNBQBu8mrkP 11yyyj5brlKlYv3Fa87Dfq5EDc+EomLGhc5NX74PG1S8JgbBF4KvYdz0e/6IKwzi GzbQs63AhUOrTdmZdq7w0Ula8F5fDfljyw+FHrhIX15PeJidEptb2zl6+I1lA31A fCeAj4GV7kL25qRLaN5I =JNF2 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Arvin Schnell

14:22

On Tue, May 27, 2014 at 10:11:02AM -0400, Jeff Mahoney wrote:

...

...
A lot of (if not most) SSDs set trimmed sectors to all nulls.

Doing that on an encrypted partition would allow a cracker to identify encrypted data from encrypted garbage. That is not a good thing, especially if the partition is significantly underfilled. Ie a drive with only 10% utilization would have 90% nulls, so you have drastically simplified life for an attacker.

Wouldn't that also imply that anyone using an encrypted partition should also fill it with random data prior to using it?

Otherwise an attacker can definitely see how full the filesystem is.

...

I doubt that's happening in even a small minority of deployments.

YaST at least writes some random data to the beginning of the encrypted device. But I cannot recall details of the reasoning. Regards, Arvin -- Arvin Schnell, Senior Software Engineer, Research & Development SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Jeff Mahoney

14:29

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/27/14, 10:22 AM, Arvin Schnell wrote:

...

On Tue, May 27, 2014 at 10:11:02AM -0400, Jeff Mahoney wrote:

...
...
A lot of (if not most) SSDs set trimmed sectors to all nulls.

Doing that on an encrypted partition would allow a cracker to identify encrypted data from encrypted garbage. That is not a good thing, especially if the partition is significantly underfilled. Ie a drive with only 10% utilization would have 90% nulls, so you have drastically simplified life for an attacker.

Wouldn't that also imply that anyone using an encrypted partition should also fill it with random data prior to using it?

Otherwise an attacker can definitely see how full the filesystem is.

I'm not saying it's an invalid argument -- I'm just saying that nobody is doing it. - -Jeff

...

...
I doubt that's happening in even a small minority of deployments.

YaST at least writes some random data to the beginning of the encrypted device. But I cannot recall details of the reasoning.

Regards, Arvin

- -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQIcBAEBAgAGBQJThKFfAAoJEB57S2MheeWyQa4P/j3psVzlnZyfS3bI2aiAiik4 ZIBb9GDa1iaE2zcXVTVzSfk64KYGlLOrVvsO3Fsxx3wvkLvERoj+DNAZ0gZS3U0M CJKc+ruyKr4UAp0M4fAWQrENIA5+harqX3VXtEJFSrfWFR3i5hvL6NVwhmT7LM2D KycYFirLRQWtcG76e0FFyhOOxVgOq3S5wHgrANwvq5g5KXaMLdVH1/j++PIrK6Hu c7RJwWocn552cuM/16NoPMkDYxm7hnhUte7hZR5dId1h+YPvKniAhnh1NHmT0w4T NXHg1sQa+rAOzlz3LCcOUkvb+qHboXp2blOXLpcNZb2YqbaUXLS1wFdsM73Xj5/t W5D1hVWPTlbNJLPrD1VOQRG3OEh/sQ56bSmtUPILUEUs8c+rWHV8ZXLO+2iuw+j6 uNxe0HIw/giLrLoAaxpxBU+O9Z9seTBkwDDNSg0Rh/K1uQQ2hMA02TnQPWBo6lp/ 75+vQSfrtHZz9mkwCN4gcHlV9KSpOOEHAiD9mgKIvNw7bP8Gt2k+HbZNX8/BXQKC 1OmHSAqQQhdccC41pWiTWWjgVZnVTqv3fhDWoJPIKhRe5Kxj1p2UCqrDu6Z9EEV5 cmxLjJjY2jzvHfpCzvucf5/9BYd8CufcbJw0vnn/um9UVLXYz1pILTCVVFQtED+w STt+qNTQRXmfC+eUa0wX =GyL+ -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Greg Freemyer

15:09

-- Greg Freemyer On Tue, May 27, 2014 at 10:29 AM, Jeff Mahoney wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 5/27/14, 10:22 AM, Arvin Schnell wrote:

...
On Tue, May 27, 2014 at 10:11:02AM -0400, Jeff Mahoney wrote:

...
...
A lot of (if not most) SSDs set trimmed sectors to all nulls.

Doing that on an encrypted partition would allow a cracker to identify encrypted data from encrypted garbage. That is not a good thing, especially if the partition is significantly underfilled. Ie a drive with only 10% utilization would have 90% nulls, so you have drastically simplified life for an attacker.

Wouldn't that also imply that anyone using an encrypted partition should also fill it with random data prior to using it?

Otherwise an attacker can definitely see how full the filesystem is.

I'm not saying it's an invalid argument -- I'm just saying that nobody is doing it.

I've mostly been using TrueCrypt containers recently. When you create a TrueCrypt container you choose between dynamic and regular. A dynamic container starts small and grows as you add data. A regular container is created full size. If you go with a regular container, the container is filled with encrypted random garbage at the creation of the container. If you use truecrypt with partitions / devices, then there is a quick format option. If you don't use quick format, truecrypt will fill the partition / device with encrypted garbage as part of the formatting process. I don't know what luks / cryptsetup does when it formats a partition. Greg -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Carlos E. R.

15:26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-05-27 17:09, Greg Freemyer wrote:

...

If you use truecrypt with partitions / devices, then there is a quick format option. If you don't use quick format, truecrypt will fill the partition / device with encrypted garbage as part of the formatting process.

I don't know what luks / cryptsetup does when it formats a partition.

AFAIK, nothing. The admin has to do that himself manually. I read about it years ago in the documentation, on sites that have now disappeared, so I can't locate any source, but one. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOErq4ACgkQtTMYHG2NR9VHoQCdFyEHrGB9GfZ+23LDKm4/O2WG H60An1CJlFtm0dm4hHgNrLDd5HG1ChJY =GPVc -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Carlos E. R.

15:23

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2014-05-27 16:29, Jeff Mahoney wrote:

...

On 5/27/14, 10:22 AM, Arvin Schnell wrote:

...

...
...
Wouldn't that also imply that anyone using an encrypted partition should also fill it with random data prior to using it?

...
Otherwise an attacker can definitely see how full the filesystem is.

I'm not saying it's an invalid argument -- I'm just saying that nobody is doing it.

I do. It is documented somewhere that it must be done, so I do it. For example, here: http://old-en.opensuse.org/SDB:Using_the_Crypto_File_System - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlOErg0ACgkQtTMYHG2NR9XyXACcCIM+YI3syWW+TrHetV8tAfSw vc4An1C/AAC7/j69Y0QZIT9fWgr6SCVo =/ZzL -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

Bruno Friedmann

5 Jun 5 Jun

16:52

Just a follow up ... I've not seen a kernel crash or wired result on files since a week. I've installed 4 new memory modules desactivated trim on luks removed nvidia of my 3.14 (even if now I've to shutdown manually my external monitor) Memories are Number one on my suspect list :-) So a beer for Stefan ;-) -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch openSUSE Member & Board GPG KEY : D5C9B751C4653227 irc: tigerfoot ~~~Don't take Life too serious. Nobody gets out alive anyway!~~~ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org

3620

Age (days ago)

3630

Last active (days ago)

List overview

Download

14 comments

7 participants

participants (7)

Arvin Schnell
Bruno Friedmann
Carlos E. R.
Greg Freemyer
Jeff Mahoney
Markus Koßmann
Stefan Seyfried

[opensuse-kernel] trim or not to trim : luks encrypted ssd

tags

participants (7)