DM-Crypt Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mikko Rauhala <mjrauhal@cc.helsinki.fi>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] LUKS - SSD trim
Date: Fri, 23 Apr 2010 13:20:38 +0300	[thread overview]
Message-ID: <1272018038.2669.40.camel@phantom.hip> (raw)
In-Reply-To: <4BD15F13.3040604@redhat.com>

pe, 2010-04-23 kello 10:49 +0200, Milan Broz kirjoitti:
> On 04/23/2010 12:22 AM, Richard Zidlicky wrote:
> > isn't TRIM considered information leakage in the case of dm-crypt?

It is leakage indeed, but for many purposes acceptable at least as such.

I personally would want TRIM support on my dm-crypt-on-lvm SSD to
improve lifetime and performance; I'm not too worried about leaking
empty block information. (I would be somewhat interested though if
someone knows of particular ways that empty block data could leak other
information; known-plaintext attacks against filesystem data structures
and through them against the encryption key springs to mind, but I
recognize I'm just talking out of my ass here, grasping at worst-case
straws.)

I do think that dm-crypt, as a security solution, should probably offer
optional dropping of TRIM commands when dm gains support for it; some
uses may be more sensitive (and/or some users may wish to wear thicker
tinfoil than myself). This is probably not critical, though:

> If it is problem, you should not use FS with TRIM support in the first place.
> dm-crypt basically should support TRIM if the request comes, it is just block
> device.

This would detract from the usefulness of dm-crypt, as you would be
artificially limited in what you can run on top of it to meet your
paranoia quota. However, considering in addition that many (most/all? -
at least ext4, btrfs, gfs2) filesystems that make use of TRIM on Linux
do appear on a quick glance to make this optional through the
(no)discard mount options, it wouldn't indeed be a very bad thing for
dm-crypt to Just Do It anyway.

> dm-crypt is just transparent layer, it is configured some way and
> configuration depends on your requirements and previous analysis.

A "Drop TRIMs" flag could still be useful as just such a configuration
option that you could set accordingly after said analysis, the ability
to _often_ block TRIMs higher up on the stack notwithstanding.

-- 
Mikko Rauhala <mjr@iki.fi>       - http://www.iki.fi/mjr/blog/  
The Finnish Pirate Party         - http://piraattipuolue.fi/  
World Transhumanist Association  - http://transhumanism.org/  
Singularity Institute            - http://singinst.org/  

  reply	other threads:[~2010-04-23 10:20 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-21 22:48 [dm-crypt] LUKS - SSD trim Felix Blanke
2010-04-21 23:00 ` Milan Broz
2010-04-21 23:03   ` Felix Blanke
2010-04-22  2:17     ` Arno Wagner
2010-04-22  8:42       ` mark
2010-04-22  9:37         ` Milan Broz
2010-04-22 20:12         ` Felix Blanke
2010-04-22 22:20           ` Richard Zidlicky
2010-04-22 22:22   ` Richard Zidlicky
2010-04-23  8:49     ` Milan Broz
2010-04-23 10:20       ` Mikko Rauhala [this message]
2010-04-23 11:13       ` Richard Zidlicky
2010-04-23 11:46         ` Milan Broz
2010-04-23 20:09           ` Richard Zidlicky
2010-04-23 20:45             ` Milan Broz
2010-04-23 22:59               ` Richard Zidlicky
2010-04-24 15:59                 ` Arno Wagner
2010-04-24 16:44                   ` Richard Zidlicky
2010-04-24 17:01                     ` Arno Wagner
2010-04-22  6:17 ` Heinz Diehl
2010-05-14  7:35 ` JG
  -- strict thread matches above, loose matches on Subject: below --
2010-05-27 13:14 Christoph Anton Mitterer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1272018038.2669.40.camel@phantom.hip \
    --to=mjrauhal@cc.helsinki.fi \
    --cc=dm-crypt@saout.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox