Hi Milan, hi list, first, sorry for starting this thread and then not responding for such a long time. I simply didn't find the time as I'm to busy with other projects at the mmoment. Milan Broz: > 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. > > 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) Interesting read (Linus' rants left aside). Thanks for the links. > 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) Seems totally reasonable to me, given that it would put truecrypt hidden containers at risk. > - 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. I see. And since there's no sticky options in LUKS1, there's no way to enable discard only for *new* LUKS volumes. So I can follow your reasoning why you don't want to enable discard for LUKS1 per default. > - 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.) Yep, that's what Debian Installer will do starting with the release of Buster as well. > - 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.) That's great news! > - 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. Yep, we do. See the linked merge request to partman-crypto from my initial mail. But that way, we have a somewhat inconsistent situation: wihle the installer defaults to add 'discard' to new LUKS devices, that's not the case for user-generated LUKS devices. That's why I brought up the topic here in the first place. I think, we should just adjust the docs of the Debian cryptsetup package and explain to users that they should always give the 'discard' option to new devices if they don't have a good reason to not do so (i.e. have hidden volumes inside the volume, have to hide whether there's data written to the volume or want to protect against access patterns being leaked). > 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. I would be much in favour of you doing this. I see that the discard option has security implications. Absolutely. Whether those are minor or major is debatable. My take on this is, that the tradeoff is acceptable and for the vast majority of users neglectable. On the other side, having fstrim working per default even on encrypted volumes is a huge advantage. In general, I don't believe that choosing the most secure option without taking other aspects into account is always just right. Sometimes, accepting a small tradeoff towards usability can help a lot. It lowers the barrier to use cryptographical software. And users who care about more sophisticated attack vectors and want to put security first, are still free to change their settings. Cheers jonas > 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 >
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
