On 29/12/2018 12:05, Jonas Meurer wrote: > Starting with the upcoming release of Debian Buster, luks devices > created during installation will have the 'discard' option (trim feature > for flash devices) set in crypttab[1]. > > When Guilhem and me (we're the Debian cryptsetup maintainers) discussed > this topic, we agreed, that in general, having the discard option set > per default would be a nice thing to have. But we're unsure how to > implement it. Hi, we are already in this battle for several years, so there is the "upstream" approach. Just to understand my a little bit defensive approach, please read https://www.redhat.com/archives/dm-devel/2016-September/msg00061.html https://www.redhat.com/archives/dm-devel/2016-September/msg00065.html (and rest of threads) (being in a group of crazy-anal security people, as it was named, is actually an honor for me :-p) So this is "the state of affairs": - there will be no TRIM-enabled default inside kernel dm-crypt, definitely not for the current major dm-crypt module version (1.x.x) (reasons in the link above; but as you know, in Linux kernel anything can happen, so, for now, it is based on our discussion with DM maintainer) - LUKS1 will never have TRIM as the default setting in cryptsetup. Some people build hidden disks with LUKS1 as a decoy system. Not even a compile switch, sorry. - There is generic support for "discard" flag in crypttab (maintained by systemd/sysv), distros are free to use by default on installation. IOW this flags will activate LUKS1/2 device TRIM enabled. (We use this approach in Fedora already for some time.) - LUKS2 has already persistent config flag to set TRIM as default per-device, with cryptsetup 2.1 we can change persistent setting even for already active device (code is in git already). (See --persistent option for luksOpen.) - TRIM is not supported for integrity devices (LUKS2 with authenticated encryption), but this is still an experimental feature. So in short for Debian - I think you should use the same way as for Fedora, just add discard flag to crypttab during installation. I would like to set LUKS2 format as default in 2.1 release, but it will could still cause some problems :-) But for TRIM support, it should help to solve the situation for the future. And maybe LUKS2 format (but not for LUKS1) should set TRIM flag by default, really would like to see opinions here. m. p.s. Sorry, I could not resist, just a small rant... For the last few years, it seems the "storage performance" is the keyword that everyone is using (even in academic papers now). TRIM is just a small part of it. It seems that security is often being deteriorated in time. See for example the case of BitLocker enabled SED devices by default (also watch recent 35c3 talk "Self-encrypting deception"). Some people tried a similar approach in dm-crypt, and I am happy we resisted https://lkml.org/lkml/2018/5/28/1910 but without the support of people that care about security, for how long? Thanks to everyone who is helping here, even it is just an opinion in a mail discussion! We will need your help, in the 2019 year more than ever. Milan > One option would be to simply add 'discard' to all crypttab examples and > document in README.Debian that we recommend to always add 'discard' as > crypttab option for new dm-crypt devices. > > Buth then, *always* listing an option is somehow weird from a technical > perspective. If we want it to be the defualt, then it should be the > default without explicitely having to set it. > > So we wonder whether you (cryptsetup upstream would consider to make > discard the default in cryptsetup, at least for LUKS devices. > > [Certainly, enabling 'discard' for the LUKS device, isn't sufficient for > turning on trim support for the device. It might have to be enabled in > other block stack layers and filesystem still. But that's another topic > to be dealt with in downstream distributions like Debian.] > > As far as we know, the main *negative* impact of enabling the trim > feature on flash devices is, that it might reveal information on which > parts of the disk are written and which are not, even if you first > filled the disk with random data[2]. To our knowledge, that's only a > problem if you need plausible deniability, wich LUKS doesn't provide anyway. > > Our perspective is, that if you need plausible deniability, you have to > look into details anyway (it's hard to do plausible deniability right), > and people can still disable discard in those cases. > > So what do you think about making 'discard' the default in cryptsetup > for LUKS? Would you consider doing so? If not, would you be fine with > cryptsetup in Debian defaulting to 'discard' nevertheless? Could you > imagine to add a compile-time flag for doing so? In any case, an option > to *disable* the default would be needed. > > We're curious what you think about it :) > > Kind regards, > jonas, on behalf of the Debian cryptsetup team > > [1] https://salsa.debian.org/installer-team/partman-crypto/merge_requests/2 > [2] https://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html > > > _______________________________________________ > dm-crypt mailing list > dm-crypt@xxxxxxxx > https://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
