-----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 <bruno@ioda-net.ch> 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