Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Scott Schmit]

On Mon, Feb 06, 2017 at 11:15:59AM +0100, Ondrej Kozina wrote:
> On 02/03/2017 05:42 PM, Nathanael D. Noblet wrote:
> > 
> > Also what are the risks of enabling this?
> 
> There's nice overview for it:
> http://asalor.blogspot.cz/2011/08/trim-dm-crypt-problems.html
> 
> In short (beside other facts covered in blog):
> 
> A very simple analysis of encrypted block device with discard passdown
> enabled (fstrim command on upper layer is allowed to hit block device
> underneath the dm-crypt target) may expose presence of particular fs type.
> It creates well visible patterns (interleaving chunks of zeroes with chunks
> of random data) but no ciphertext is jeopardized in any way!
> 
> Simply put with discard passdown enabled it'll be much harder to deny
> _existence_ of encrypted fs on SSDs alone.
> 
> The reasoning for the change is that most users expects theirs SSD to
> operate in full performance (moreover, overall dm-crypt performance within
> multi CPU systems was vastly improved with kernel 4.0: 
> https://kernelnewbies.org/Linux_4.0#head-c0673746b8f925cd7013db3bf2a1ae1b76a18829)
> and they experienced major performance hit after some time of use even
> though they enabled fstrim.service & co. Most complains we heard were
> exactly those above. Experienced admins are already aware of /etc/crypttab
> and may revert the change very easily and existing storage setup will not be
> affected.

Admins can revert the change, but if a TRIM has already occurred, that
can't be reversed without rewriting the affected sections of the drive.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Ondrej Kozina]

On 02/03/2017 03:40 PM, Josh Boyer wrote:


How is SSD being detected?



Well, we can detect whether bdev is spindle or not from sysfs AFAIK. But 
anyway, do we need to know? It's mostly about whether dm-crypt would 
just *allow* discard to pass through dm-crypt target in general. In 
default mode dm-crypt just advertises itself as "not supporting discard" 
and due to it other layers trying to send discard lower gets stopped by 
dm-crypt even though the underlying device (SSD, dm-thin device, 
whatever) itself may support it.


O.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Ondrej Kozina]

On 02/03/2017 06:12 PM, Chris Murphy wrote:

Further I wonder if /etc/lvm/lvm.conf needs
issue_discards = 1

Both / and /home are actually LV's which are made from the LUKS PV. So
trim pass down from dmcrypt to block device isn't enough to do
anything.


I think this is unrelated to this change request. The current kernel 
default (in dm-crypt target!) is that it silently throws away/blocks any 
discard that land on dm-crypt device. As far as I know this particular 
kernel default is not going to change in any foreseeable future for 
other reasons (It could destroy hidden volumes configured in legacy 
TrueCrypt). With this change we just *allow* the discard to pass through 
dm-crypt target. Whether other components in Fedora generate the discard 
request itself is imo of the scope for this change request.


(lvm.conf issue_discards = 1 explained Zdenek in other post)

O.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Ondrej Kozina]

On 02/03/2017 05:42 PM, Nathanael D. Noblet wrote:


Also what are the risks of enabling this?



There's nice overview for it: 
http://asalor.blogspot.cz/2011/08/trim-dm-crypt-problems.html


In short (beside other facts covered in blog):

A very simple analysis of encrypted block device with discard passdown 
enabled (fstrim command on upper layer is allowed to hit block device 
underneath the dm-crypt target) may expose presence of particular fs 
type. It creates well visible patterns (interleaving chunks of zeroes 
with chunks of random data) but no ciphertext is jeopardized in any way!


Simply put with discard passdown enabled it'll be much harder to deny 
_existence_ of encrypted fs on SSDs alone.


The reasoning for the change is that most users expects theirs SSD to 
operate in full performance (moreover, overall dm-crypt performance 
within multi CPU systems was vastly improved with kernel 4.0: 
https://kernelnewbies.org/Linux_4.0#head-c0673746b8f925cd7013db3bf2a1ae1b76a18829) 
and they experienced major performance hit after some time of use even 
though they enabled fstrim.service & co. Most complains we heard were 
exactly those above. Experienced admins are already aware of 
/etc/crypttab and may revert the change very easily and existing storage 
setup will not be affected.


O.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Josh Stone]

On 02/03/2017 08:42 AM, Nathanael D. Noblet wrote:
> Also what are the risks of enabling this?

It makes it possible for an attacker to distinguish used and unused
space on the disk, as they can see zeros instead of encrypted noise.

Whether that's a problem depends on your level of paranoia.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Chris Murphy]

On Fri, Feb 3, 2017 at 10:40 AM, Zdenek Kabelac  wrote:
> Dne 3.2.2017 v 18:23 Chris Murphy napsal(a):
>>
>> On Fri, Feb 3, 2017 at 10:18 AM, Chris Adams  wrote:
>>>
>>> Once upon a time, Chris Murphy  said:

 Further I wonder if /etc/lvm/lvm.conf needs
 issue_discards = 1

 Both / and /home are actually LV's which are made from the LUKS PV. So
 trim pass down from dmcrypt to block device isn't enough to do
 anything.
>>>
>>>
>>> LVM passes discards through automatically, assuming the block device
>>> under the PV supports them.  The issue_discards option tells LVM to
>>> issue discards itself when PV space is released (e.g. an LV is
>>> removed/reduced).
>>
>>
>> Yep. I just tested it with the default issue_discards=0 and fstrim -v
>> does work on an LV.
>>
>> Nevertheless I don't understand the benefit of this feature if
>> fstrim.service is not enabled by default; nor is a discard mount
>> option set for the file system in fstab.
>>
>
>
> Hi
>
> Please read doc about this option first

"this feature" = the proposed change, not issue_discards=0



-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Zdenek Kabelac]

Dne 3.2.2017 v 18:23 Chris Murphy napsal(a):

On Fri, Feb 3, 2017 at 10:18 AM, Chris Adams  wrote:

Once upon a time, Chris Murphy  said:

Further I wonder if /etc/lvm/lvm.conf needs
issue_discards = 1

Both / and /home are actually LV's which are made from the LUKS PV. So
trim pass down from dmcrypt to block device isn't enough to do
anything.


LVM passes discards through automatically, assuming the block device
under the PV supports them.  The issue_discards option tells LVM to
issue discards itself when PV space is released (e.g. an LV is
removed/reduced).


Yep. I just tested it with the default issue_discards=0 and fstrim -v
does work on an LV.

Nevertheless I don't understand the benefit of this feature if
fstrim.service is not enabled by default; nor is a discard mount
option set for the file system in fstab.




Hi

Please read doc about this option first - there is a very good reason
why you have 'issue_discards=0' as default.

This option is purely about discarding 'removed space' by lvm2.
So when you run  'lvremove  vg/lv'   extents occupied by such LV
is discarded. Same applies to 'lvreduce'!.

MAJOR drawback is - such operation becomes   *irreversible* - why the
common rule with lvm2 is - you could 'restore' 1 step back (unless you use 
thin-pools - with those you don't have reverting).


So if someone sets 'issue_discard=1' he automatically loses reversibility.

It should be left to admin to decides which risk he is wiling to take.

Regards


Zdenek


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Chris Murphy]

On Fri, Feb 3, 2017 at 10:18 AM, Chris Adams  wrote:
> Once upon a time, Chris Murphy  said:
>> Further I wonder if /etc/lvm/lvm.conf needs
>> issue_discards = 1
>>
>> Both / and /home are actually LV's which are made from the LUKS PV. So
>> trim pass down from dmcrypt to block device isn't enough to do
>> anything.
>
> LVM passes discards through automatically, assuming the block device
> under the PV supports them.  The issue_discards option tells LVM to
> issue discards itself when PV space is released (e.g. an LV is
> removed/reduced).

Yep. I just tested it with the default issue_discards=0 and fstrim -v
does work on an LV.

Nevertheless I don't understand the benefit of this feature if
fstrim.service is not enabled by default; nor is a discard mount
option set for the file system in fstab.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Chris Adams]

Once upon a time, Chris Murphy  said:
> Further I wonder if /etc/lvm/lvm.conf needs
> issue_discards = 1
> 
> Both / and /home are actually LV's which are made from the LUKS PV. So
> trim pass down from dmcrypt to block device isn't enough to do
> anything.

LVM passes discards through automatically, assuming the block device
under the PV supports them.  The issue_discards option tells LVM to
issue discards itself when PV space is released (e.g. an LV is
removed/reduced).

I'm not sure why issue_discards=1 is not the default, but that's a
separate issue from this change.
-- 
Chris Adams 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Chris Murphy]

Further I wonder if /etc/lvm/lvm.conf needs
issue_discards = 1

Both / and /home are actually LV's which are made from the LUKS PV. So
trim pass down from dmcrypt to block device isn't enough to do
anything.

ext4 (discard mount option or fstrim.service) -> LVM (issue_discards=1
in lvm.conf) -> dmcrypt (discard set in crypttab or
rd.luks.options=discard as boot param). If any of those is not true,
then I'm pretty sure discard isn't going to go to the real device. And
doing this by default for everyone is a bad idea because there are so
many non-queued trim SSDs floating around still.

--
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Chris Murphy]

On Fri, Feb 3, 2017 at 9:32 AM, Tomasz Torcz  wrote:
> On Fri, Feb 03, 2017 at 09:25:07AM -0700, Nathanael D. Noblet wrote:
>> On Fri, 2017-02-03 at 09:40 -0500, Josh Boyer wrote:
>> > On Mon, Jan 16, 2017 at 10:32 AM, Jan Kurik 
>> > wrote:
>> > > = System Wide Change: Enable TRIM pass down to encrypted disks =
>> > > https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt
>> > >
>> > > Change owner(s):
>> > > * Vratislav Podzimek 
>> > > * Ondrej Kozina 
>> > >
>> > >
>> > > Override kernel default for dm-crypt mappings of LUKS1 encrypted
>> > > volumes via flag put in /etc/crypttab file. This change should
>> > > affect
>> > > only newly created encrypted storage based on LUKS1 format during
>> > > installation.
>>
>> So I've got multiple systems with encrypted partitions on SSD disks.
>> Are there ways of enabling this for pre-existing partitions?
>
>   I believe putting “discard” at the the of each line in /etc/crypttab
> will do the trick.

That just causes device mapper to pass trim issued to the dmcrypt
device to the underlying block device; it doesn't actually issue trim.
Something else has to do that, like fstrim.service or discard mount
option for the file system; neither of which I'd recommend by default.
I'm not really sure what this feature is going to do on its own.


-- 
Chris Murphy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Nathanael D. Noblet]

On Fri, 2017-02-03 at 17:32 +0100, Tomasz Torcz wrote:
> > So I've got multiple systems with encrypted partitions on SSD
> > disks.
> > Are there ways of enabling this for pre-existing partitions?
> 
>   I believe putting “discard” at the the of each line in
> /etc/crypttab
> will do the trick.

Nice, Does this apply to encrypted swap partitions?

Also what are the risks of enabling this?

Thanks,
-- 
Nathanael
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Tomasz Torcz]

On Fri, Feb 03, 2017 at 09:25:07AM -0700, Nathanael D. Noblet wrote:
> On Fri, 2017-02-03 at 09:40 -0500, Josh Boyer wrote:
> > On Mon, Jan 16, 2017 at 10:32 AM, Jan Kurik 
> > wrote:
> > > = System Wide Change: Enable TRIM pass down to encrypted disks =
> > > https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt
> > > 
> > > Change owner(s):
> > > * Vratislav Podzimek 
> > > * Ondrej Kozina 
> > > 
> > > 
> > > Override kernel default for dm-crypt mappings of LUKS1 encrypted
> > > volumes via flag put in /etc/crypttab file. This change should
> > > affect
> > > only newly created encrypted storage based on LUKS1 format during
> > > installation.
> 
> So I've got multiple systems with encrypted partitions on SSD disks.
> Are there ways of enabling this for pre-existing partitions?

  I believe putting “discard” at the the of each line in /etc/crypttab
will do the trick.

-- 
Tomasz Torcz Morality must always be based on practicality.
xmpp: zdzich...@chrome.pl-- Baron Vladimir Harkonnen
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Nathanael D. Noblet]

On Fri, 2017-02-03 at 09:40 -0500, Josh Boyer wrote:
> On Mon, Jan 16, 2017 at 10:32 AM, Jan Kurik 
> wrote:
> > = System Wide Change: Enable TRIM pass down to encrypted disks =
> > https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt
> > 
> > Change owner(s):
> > * Vratislav Podzimek 
> > * Ondrej Kozina 
> > 
> > 
> > Override kernel default for dm-crypt mappings of LUKS1 encrypted
> > volumes via flag put in /etc/crypttab file. This change should
> > affect
> > only newly created encrypted storage based on LUKS1 format during
> > installation.

So I've got multiple systems with encrypted partitions on SSD disks.
Are there ways of enabling this for pre-existing partitions?

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Josh Boyer]

On Mon, Jan 16, 2017 at 10:32 AM, Jan Kurik  wrote:
> = System Wide Change: Enable TRIM pass down to encrypted disks =
> https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt
>
> Change owner(s):
> * Vratislav Podzimek 
> * Ondrej Kozina 
>
>
> Override kernel default for dm-crypt mappings of LUKS1 encrypted
> volumes via flag put in /etc/crypttab file. This change should affect
> only newly created encrypted storage based on LUKS1 format during
> installation.
>
>
> == Detailed Description ==
> User base of Fedora distribution with SSDs grows steadily and while
> the argument for kernel default setting not to enable the discard is
> still strong one it doesn't change the fact that vast majority of
> users (with SSDs) doesn't want to sacrifice better performance of
> drive with discard/trim enabled for the sake of secrecy.

How is SSD being detected?

josh
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Dominik 'Rathann' Mierzejewski]

On Monday, 16 January 2017 at 16:32, Jan Kurik wrote:
[...]
> == Detailed Description ==
> User base of Fedora distribution with SSDs grows steadily and while
> the argument for kernel default setting not to enable the discard is
> still strong one it doesn't change the fact that vast majority of
> users (with SSDs) doesn't want to sacrifice better performance of
> drive with discard/trim enabled for the sake of secrecy.

How do you know that it's a vast majority?

[...]
> For LUKS1 metadata format we don't have a space to store the new
> default in metadata and therefore we can't flip the default for new
> LUKS1 devices being formated via libcryptsetup or cryptsetup utility.
> 
> Changing the kernel default is of the table due to risk of data
   ^
I think you missed an 'f' here.|

> corruption with some TrueCrypt configurations involving hidden
> volumes.
> 
> For rotational devices the cost of enabled discard is negligible

How have you measured that? What is the exact value?

Regards,
Dominik
-- 
Fedora http://fedoraproject.org/wiki/User:Rathann
RPMFusion http://rpmfusion.org
"Faith manages."
-- Delenn to Lennier in Babylon 5:"Confessions and Lamentations"
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Jan Kurik]

= System Wide Change: Enable TRIM pass down to encrypted disks =
https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt

Change owner(s):
* Vratislav Podzimek 
* Ondrej Kozina 


Override kernel default for dm-crypt mappings of LUKS1 encrypted
volumes via flag put in /etc/crypttab file. This change should affect
only newly created encrypted storage based on LUKS1 format during
installation.


== Detailed Description ==
User base of Fedora distribution with SSDs grows steadily and while
the argument for kernel default setting not to enable the discard is
still strong one it doesn't change the fact that vast majority of
users (with SSDs) doesn't want to sacrifice better performance of
drive with discard/trim enabled for the sake of secrecy.

We're not speaking encrypted data security here and double emphasize
on it! Only the fact that blank filesystem on top of dm-crypt device
with discard enabled may create well visible patterns in ciphertext
device below on SSDs.

For LUKS1 metadata format we don't have a space to store the new
default in metadata and therefore we can't flip the default for new
LUKS1 devices being formated via libcryptsetup or cryptsetup utility.

Changing the kernel default is of the table due to risk of data
corruption with some TrueCrypt configurations involving hidden
volumes.

For rotational devices the cost of enabled discard is negligible


== Scope ==
* Proposal owners:
This change despite being system wide change due to overriding legacy
default is quite small and easy to manage.

* Other developers:
Very minor change in python-blivet. Basically we just need to store
discard keyword in /etc/crypttab lines related to new partitions
created during installation process.


* Release engineering:
N/A

* List of deliverables:
N/A

* Policies and guidelines:
Add short information in documentation we're changing long term
default and copy the reasoning there.

* Trademark approval:
N/A
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

F26 System Wide Change: Enable TRIM pass down to encrypted disks

[Jan Kurik]

= System Wide Change: Enable TRIM pass down to encrypted disks =
https://fedoraproject.org/wiki/Changes/EnableTrimOnDmCrypt

Change owner(s):
* Vratislav Podzimek 
* Ondrej Kozina 


Override kernel default for dm-crypt mappings of LUKS1 encrypted
volumes via flag put in /etc/crypttab file. This change should affect
only newly created encrypted storage based on LUKS1 format during
installation.


== Detailed Description ==
User base of Fedora distribution with SSDs grows steadily and while
the argument for kernel default setting not to enable the discard is
still strong one it doesn't change the fact that vast majority of
users (with SSDs) doesn't want to sacrifice better performance of
drive with discard/trim enabled for the sake of secrecy.

We're not speaking encrypted data security here and double emphasize
on it! Only the fact that blank filesystem on top of dm-crypt device
with discard enabled may create well visible patterns in ciphertext
device below on SSDs.

For LUKS1 metadata format we don't have a space to store the new
default in metadata and therefore we can't flip the default for new
LUKS1 devices being formated via libcryptsetup or cryptsetup utility.

Changing the kernel default is of the table due to risk of data
corruption with some TrueCrypt configurations involving hidden
volumes.

For rotational devices the cost of enabled discard is negligible


== Scope ==
* Proposal owners:
This change despite being system wide change due to overriding legacy
default is quite small and easy to manage.

* Other developers:
Very minor change in python-blivet. Basically we just need to store
discard keyword in /etc/crypttab lines related to new partitions
created during installation process.


* Release engineering:
N/A

* List of deliverables:
N/A

* Policies and guidelines:
Add short information in documentation we're changing long term
default and copy the reasoning there.

* Trademark approval:
N/A
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org