Can we please make 'allow_discards' the default for dm-crypt?

Can we please make 'allow_discards' the default for dm-crypt?

[Linus Torvalds]

I really detest our current dm-crypt policy of not allowing discard by default.

It has this silly "but but security" reason behind it, but let's face
it: if you don't want to do discards for security reasons, then JUST
DON'T DO THEM. Or add a "no_discards" option.

Because right now, the default behavior is wrong. It's geared toward
the 0.1% crazy-anal people, and making a *default* option for those
people is just silly. The whole argument that "you can see access
patterns and how much free space there is" is just complete bullshit.
It's not what any sane person would care about.

The rest of us just want to encrypt our data on our laptops in case
they get stolen, and we don't want to not be able to do the occasional
"fstrim".

Yes, good flash doesn't need trimming all that much, but it won't
hurt. And right now we penalize people who want to do the sane good
thing.

Sure, we could say that distros should just add the "allow_discard"
flag instead, and maybe have a checkbox to say "are you a crazy anal
person" along with the "encrypt disk" checkbox. But EVEN IF the distro
were to do that, that doesn't mean that the kernel default should be
the wrong way around.

Comments?

               Linus

Re: Can we please make 'allow_discards' the default for dm-crypt?

[Milan Broz]

On 09/14/2016 04:10 AM, Linus Torvalds wrote:
> I really detest our current dm-crypt policy of not allowing discard by default.
> 
> It has this silly "but but security" reason behind it, but let's face
> it: if you don't want to do discards for security reasons, then JUST
> DON'T DO THEM. Or add a "no_discards" option.

Hi Linus,

then you are saying that the default should be "destroy all the data
on possible hidden disk" :-)

Because that should happen, if you will map "outer" volume with discards on,
and there is a hidden disk (for outer volume it is "unused" space").

And unfortunately it _is_ widely used in TrueCrypt and followers.

I am not advocating to use that feature that is even no longer
as fancy as many people see it, I am just saying that people already have
a lot of such devices that will not disappear after your rant.

It is easy to switch default in cryptsetup, it is impossible fix all
old versions of tools that just call dmsetup in Linux.

Anyway, I see the only way to switch this safely is to increase major version
of dm-crypt target and switch default in new version, this will make all
old tools incompatible. (And update tools together.)

> Because right now, the default behavior is wrong. It's geared toward
> the 0.1% crazy-anal people, and making a *default* option for those
> people is just silly. The whole argument that "you can see access
> patterns and how much free space there is" is just complete bullshit.
> It's not what any sane person would care about.

No, this is not the only argument. Even there, ignore patterns, that was
academic toy. (Years ago I did a dmcrypt pattern experiment to prove that there
is _some_ pattern possible just because many people did not believed it.)

But there are situations that such discard-by-default enables to prove that
your encrypted device has real data on it (without decryption).

You do not care, some people really do.
They can use the --crazy-anal switch, sure.

But it will not make the problem bullshit.


(There are more problems if we think about possible block-level authenticated
encryption - because of discard also wipes integrity tag, later reads should
fail with integrity errors.
Some information (in opposite direction that discard) that says "these sectors
are unused" on reads would be definitely nice. In fact it applies even
for non-auth encryption - why we should decrypt unused space and produce garbage?
Yes, on fs level we have this information but not below it.)

> The rest of us just want to encrypt our data on our laptops in case
> they get stolen, and we don't want to not be able to do the occasional
> "fstrim".
> Yes, good flash doesn't need trimming all that much, but it won't
> hurt. And right now we penalize people who want to do the sane good
> thing.

I think all people in storage will agree with this.

> Sure, we could say that distros should just add the "allow_discard"
> flag instead, and maybe have a checkbox to say "are you a crazy anal
> person" along with the "encrypt disk" checkbox. But EVEN IF the distro
> were to do that, that doesn't mean that the kernel default should be
> the wrong way around.

Sure, but I think many such distros already put allow_discards in crypttab,
and it works. For years.

Milan

p.s.
Anyone with a crazy-anal security people theme poster?
I definitely want one :-)

Re: Can we please make 'allow_discards' the default for dm-crypt?

[Linus Torvalds]

On Wed, Sep 14, 2016 at 12:06 AM, Milan Broz <gmazyland@gmail.com> wrote:
>
> then you are saying that the default should be "destroy all the data
> on possible hidden disk" :-)

No.

> Because that should happen, if you will map "outer" volume with discards on,
> and there is a hidden disk (for outer volume it is "unused" space").

But that's independent of the crypto setup, isn't it?

If the inner filesystem is some hidden crypto volume, then the outer
filesystem could be anything. And if you write to the outer filesystem
in some of the random hidden setups, you'll destroy the hidden volume
anyway. No? So you'd never write to it in the first place, much less
do "fstrim" on it.

I thought the people who used hidden ("deniable") things didn't
actually ever *use* the outer filesystem at all, exactly so that they
can just put the real encrypted thing in there and nor worry about it.

Am I missing something? What's the actual real setup?Can you explain -
in particular, can we perhaps notice it somehow, so that the normal
case at least can enable discard.

Because the reason I want to do this, of course, is that I think it
was now my fifth or sixth setup where I had to manually enable this
thing, and I have never *ever* actually wanted to disable it. And I
bet that is true for 99.99% of all users (ie the normal case).

              Linus

Re: Can we please make 'allow_discards' the default for dm-crypt?

[Mike Snitzer]

On Wed, Sep 14 2016 at 11:41am -0400,
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Wed, Sep 14, 2016 at 12:06 AM, Milan Broz <gmazyland@gmail.com> wrote:
> >
> > then you are saying that the default should be "destroy all the data
> > on possible hidden disk" :-)
> 
> No.
> 
> > Because that should happen, if you will map "outer" volume with discards on,
> > and there is a hidden disk (for outer volume it is "unused" space").
> 
> But that's independent of the crypto setup, isn't it?
> 
> If the inner filesystem is some hidden crypto volume, then the outer
> filesystem could be anything. And if you write to the outer filesystem
> in some of the random hidden setups, you'll destroy the hidden volume
> anyway. No? So you'd never write to it in the first place, much less
> do "fstrim" on it.
> 
> I thought the people who used hidden ("deniable") things didn't
> actually ever *use* the outer filesystem at all, exactly so that they
> can just put the real encrypted thing in there and nor worry about it.
> 
> Am I missing something? What's the actual real setup?Can you explain -
> in particular, can we perhaps notice it somehow, so that the normal
> case at least can enable discard.
> 
> Because the reason I want to do this, of course, is that I think it
> was now my fifth or sixth setup where I had to manually enable this
> thing, and I have never *ever* actually wanted to disable it. And I
> bet that is true for 99.99% of all users (ie the normal case).

I spoke with Ondrej (cc'd), who works closely with Milan on cryptsetup
(they are designing v2 of that interface), and the hidden volumes thing
boils down to "TrueCrypt" devices.  Which has its own userspace to setup
the device.  But cryptsetup can activate (or even create) TrueCrypt
devices too.

So the current thinking is: this is a userspace defaults problem.  The
kernel dm-crypt discard default should stay disabled as is (otherwise
TrueCrypt devices can get corrupted on discard -- will defer to Milan
and/or others to further explain how if needed).

But that the cryptsetup userspace default for luks devices (your 99.9%)
can be changed to default to enabling discards.  cryptsetup's default
for TrueCrypt devices would still be to disable discards.

Ondrej said he'd need a day to work through it further with Milan.

Mike

Re: Can we please make 'allow_discards' the default for dm-crypt?

[Milan Broz]

On 09/14/2016 05:41 PM, Linus Torvalds wrote:
> On Wed, Sep 14, 2016 at 12:06 AM, Milan Broz <gmazyland@gmail.com> wrote:
>>
>> then you are saying that the default should be "destroy all the data
>> on possible hidden disk" :-)
> 
> No.
> 
>> Because that should happen, if you will map "outer" volume with discards on,
>> and there is a hidden disk (for outer volume it is "unused" space").
> 
> But that's independent of the crypto setup, isn't it?
> 
> If the inner filesystem is some hidden crypto volume, then the outer
> filesystem could be anything. And if you write to the outer filesystem
> in some of the random hidden setups, you'll destroy the hidden volume
> anyway. No? So you'd never write to it in the first place, much less
> do "fstrim" on it.

Well, they actually should "use" outer from time to time so the data looks "recent"
and for the whole "hidden OS" they should be even able to boot to outer decoy
OS on request, just to show that something working is there.

For the TrueCrypt the whole trick that they use FAT for outer volume.
If the hidden part is for example in the second half of the volume and
if you never write more than half of available data space, its trivial allocation
logic should not overwrite hidden volume. (And vice versa, it will overwrite
only unused space from hidden volume in outer fs).

(I am just explaining this - I do not believe it is really good idea today,
it is fragile and it will not work with other fs than FAT actually.)

My point is that by enabling discard by default now we risk loosing user's data,
even if it is 0.00001%, I definitely care about it. 
(Anyone can build such a system today and expect discards are rejected.)
...

> Am I missing something? What's the actual real setup?Can you explain -
> in particular, can we perhaps notice it somehow, so that the normal
> case at least can enable discard.

I think that if we handle this in userspace, default can be enabled.
(It really makes sense for most of users.) Just do not enable it
if activating specific device types that require it for some
paranoid reasons.

If you care about normal case, it is usually LUKS (or similar format).
So I see no problem to move decision of enabling discard there.
(If anyone uses dmsetup, it is definitely not the normal ... case :)

> Because the reason I want to do this, of course, is that I think it
> was now my fifth or sixth setup where I had to manually enable this
> thing, and I have never *ever* actually wanted to disable it. And I
> bet that is true for 99.99% of all users (ie the normal case).

Yes, you are not alone. (I thought installers do this automatically.)

The problem is that for LUKS we have no on-disk option for storing
discard-enabled option (crypttab is initscript/systemd thing, cryptsetup
does not use it directly) so there should be reliable way how to disable it.
(I want to avoid updating on-disk format now, backward compatibility
is big plus currently and the format has far more problems than this one
anyway.)

For the new format (we are playing with "LUKS2" already) discard info is
already stored on-disk, so no problem to changing default
and provide user way to change it.
Just this will take time until the new format is merged and become used
in distributions.

Mike is DM maintainer, so I will use in cryptsetup whatever appears
in kernel. But I would really prefer that it is userspace decision with
discard not enabled in dm-crypt by default...

Milan