Hi list, 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. 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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
