On Tue, Feb 22, 2011 at 6:09 PM, Cristian Rodr?guez
<[email protected]> wrote:
> ?Hi:
>
> ?I get the error message in $Subject if I try to use /sbin/fstrim on all
> ?my filesystems BUT /boot which is the only one which is not encrypted.
>
> ?How am I supposed to "trim" dm-crypt/LUKS volumes on an SSD device ?
>
> Thanks.
First, trim is a nicety, not a 100% requirement. The FITRIM ioctl was
just introduced in 2.6.37 and it does NOT work in all environments.
ie. I don't think LVM / mdraid are supported either. But they may
just silently drop the trim commands in the block stack.
The main solution prior to 2.6.37 was wiper.sh from the hdparm
package. But it to had known limitations similar to those above.
As to your real question
I suspect that is a question you need to take to lkml or one of its
sub-mailing lists.
[email protected],
[email protected]
I monitor the ext4 one and have not seen any discussion related to
trimming dm-crypt/LUKS protected volumes that I recall.
I also wonder if wiper.sh from hdparm would work with your
filesystems. Trouble is a failure may cause major data loss. I have
no idea of the odds, I'm just very nervous about unintentionally
trimming the wrong sectors.
Mark Lord is the maintainer of hdparm. I've found him to be pretty
responsive to questions about wiper.sh, so if you can't tell from the
release notes, etc. I'd send him a email.
Greg
On Tue, 22 Feb 2011, Greg Freemyer wrote:
> On Tue, Feb 22, 2011 at 6:09 PM, Cristian Rodr?guez
> <[email protected]> wrote:
> > ?Hi:
> >
> > ?I get the error message in $Subject if I try to use /sbin/fstrim on all
> > ?my filesystems BUT /boot which is the only one which is not encrypted.
> >
> > ?How am I supposed to "trim" dm-crypt/LUKS volumes on an SSD device ?
> >
> > Thanks.
No NO NO! Big no to trimming encrypted filesystems! When you are
discarding blocks, the subsequent read from those blocks are usually "well
defined" and hence you are giving away useful information for attacker
trying to decrypt your filesystem. And I do not think dm-crypt guys will
ever allow this. wiper.sh might work, however you can as well give up on
using encrypted filesystem.
Now, there might be some way around this to allow trimming encrypted
volumes without serious security issue, but this is rather question for
dm-crypt guys.
Thanks!
-Lukas
>
> First, trim is a nicety, not a 100% requirement. The FITRIM ioctl was
> just introduced in 2.6.37 and it does NOT work in all environments.
> ie. I don't think LVM / mdraid are supported either. But they may
> just silently drop the trim commands in the block stack.
>
> The main solution prior to 2.6.37 was wiper.sh from the hdparm
> package. But it to had known limitations similar to those above.
>
> As to your real question
> I suspect that is a question you need to take to lkml or one of its
> sub-mailing lists.
>
> [email protected],
> [email protected]
>
> I monitor the ext4 one and have not seen any discussion related to
> trimming dm-crypt/LUKS protected volumes that I recall.
>
> I also wonder if wiper.sh from hdparm would work with your
> filesystems. Trouble is a failure may cause major data loss. I have
> no idea of the odds, I'm just very nervous about unintentionally
> trimming the wrong sectors.
>
> Mark Lord is the maintainer of hdparm. I've found him to be pretty
> responsive to questions about wiper.sh, so if you can't tell from the
> release notes, etc. I'd send him a email.
>
> Greg
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
El 23/02/11 07:28, Lukas Czerner escribió:
> On Tue, 22 Feb 2011, Greg Freemyer wrote:
>
>> On Tue, Feb 22, 2011 at 6:09 PM, Cristian Rodríguez
>> <[email protected]> wrote:
>>> Hi:
>>>
>>> I get the error message in $Subject if I try to use /sbin/fstrim on all
>>> my filesystems BUT /boot which is the only one which is not encrypted.
>>>
>>> How am I supposed to "trim" dm-crypt/LUKS volumes on an SSD device ?
>>>
>>> Thanks.
Lukas, thanks for your answer.
> No NO NO! Big no to trimming encrypted filesystems! When you are
> discarding blocks, the subsequent read from those blocks are usually "well
> defined" and hence you are giving away useful information for attacker
> trying to decrypt your filesystem.
I understand that there might be security issues, but so far, for this
scenario the only kind of attacker from which I need to protect my
desktop is from low-funded regular thieves that may break into my home
office, unlikely that will get pass the volume password prompt ;-)
> Now, there might be some way around this to allow trimming encrypted
> volumes without serious security issue, but this is rather question for
> dm-crypt guys.
Maybe making work the "discard" mount option ?
On Wed, 23 Feb 2011, Cristian Rodríguez wrote:
> El 23/02/11 07:28, Lukas Czerner escribió:
> > On Tue, 22 Feb 2011, Greg Freemyer wrote:
> >
> >> On Tue, Feb 22, 2011 at 6:09 PM, Cristian Rodríguez
> >> <[email protected]> wrote:
> >>> Hi:
> >>>
> >>> I get the error message in $Subject if I try to use /sbin/fstrim on all
> >>> my filesystems BUT /boot which is the only one which is not encrypted.
> >>>
> >>> How am I supposed to "trim" dm-crypt/LUKS volumes on an SSD device ?
> >>>
> >>> Thanks.
>
> Lukas, thanks for your answer.
>
> > No NO NO! Big no to trimming encrypted filesystems! When you are
> > discarding blocks, the subsequent read from those blocks are usually "well
> > defined" and hence you are giving away useful information for attacker
> > trying to decrypt your filesystem.
>
> I understand that there might be security issues, but so far, for this
> scenario the only kind of attacker from which I need to protect my
> desktop is from low-funded regular thieves that may break into my home
> office, unlikely that will get pass the volume password prompt ;-)
>
>
> > Now, there might be some way around this to allow trimming encrypted
> > volumes without serious security issue, but this is rather question for
> > dm-crypt guys.
>
> Maybe making work the "discard" mount option ?
> --
This is really a question for dm-crypt/block layer guys.
Adding [email protected] into cc.
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
On 02/23/2011 09:18 PM, Lukas Czerner wrote:
>>> Now, there might be some way around this to allow trimming encrypted
>>> volumes without serious security issue, but this is rather question for
>>> dm-crypt guys.
>>
>> Maybe making work the "discard" mount option ?
There were discussion about TRIM on dm-crypt mailing list several times.
one of it is here http://thread.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/4075/ )
Currently TRIM/discard is not intentionally supported on dm-crypt.
Security aspects are obvious (leaking of used blocks at least).
The decision cannot be done in kernel automatically, you can have different
policies, in some situation TRIM of encryption device is not problem,
in other it can be disaster.
So plan is to implement TRIM in dm-crypt but never enable it by default.
You will be able to enable it per-device using device-mapper message
with explicit user request.
(we are using the same message mechanism for wiping/resuming key when
freezing device).
In future this can be flag for LUKS2 metadata but current version of LUKS
doesn't allow such extensions.
Milan