On May 26, 2014 5:33:58 AM EDT, Bruno Friedmann
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