From: Alex Elsayed <eternaleye+usenet@gmail.com>
To: dm-crypt@saout.de
Cc: dm-devel@redhat.com
Subject: [dm-crypt] [RFC] dm-thin: Random block placement strategy?
Date: Thu, 19 Jul 2012 14:49:51 -0700 [thread overview]
Message-ID: <ju9vdv$vpa$1@dough.gmane.org> (raw)
This may be insufficiently useful to justify implementing, but I thought it
was an interesting concept.
One of the current issues with dm-crypt and discard is that enabling it can
leak information about the filesystem and usage patterns of the disk[1].
If a dm-thin device with a random block placement strategy is layered on top
of dm-crypt however, this could solve some of the issues involved and
partially mitigate others.
Such a random block placement strategy would heavily disguise any layout
patterns that could be used to identify the filesystem, most likely to the
point of being completely unrecognizable.
Issues arising from discarded blocks being nonzero are avoided by default
due to dm-thin pre-zeroing allocations (unless skip_block_zeroing is
enabled).
However, some issues would still be present:
While the *distribution* of unused sectors would be concealed, their
existence and how many there are would still be detectable.
In addition, the issues with trim and a hidden device are still present.
[1] http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
WARNING: multiple messages have this Message-ID (diff)
From: Alex Elsayed <eternaleye+usenet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: dm-crypt-4q3lyFh4P1g@public.gmane.org
Cc: dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
Subject: [RFC] dm-thin: Random block placement strategy?
Date: Thu, 19 Jul 2012 14:49:51 -0700 [thread overview]
Message-ID: <ju9vdv$vpa$1@dough.gmane.org> (raw)
This may be insufficiently useful to justify implementing, but I thought it
was an interesting concept.
One of the current issues with dm-crypt and discard is that enabling it can
leak information about the filesystem and usage patterns of the disk[1].
If a dm-thin device with a random block placement strategy is layered on top
of dm-crypt however, this could solve some of the issues involved and
partially mitigate others.
Such a random block placement strategy would heavily disguise any layout
patterns that could be used to identify the filesystem, most likely to the
point of being completely unrecognizable.
Issues arising from discarded blocks being nonzero are avoided by default
due to dm-thin pre-zeroing allocations (unless skip_block_zeroing is
enabled).
However, some issues would still be present:
While the *distribution* of unused sectors would be concealed, their
existence and how many there are would still be detectable.
In addition, the issues with trim and a hidden device are still present.
[1] http://asalor.blogspot.com/2011/08/trim-dm-crypt-problems.html
_______________________________________________
dm-crypt mailing list
dm-crypt-4q3lyFh4P1g@public.gmane.org
http://www.saout.de/mailman/listinfo/dm-crypt
next reply other threads:[~2012-07-19 22:10 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-19 21:49 Alex Elsayed [this message]
2012-07-19 21:49 ` [RFC] dm-thin: Random block placement strategy? Alex Elsayed
2012-07-20 9:50 ` [dm-crypt] [dm-devel] " Joe Thornber
2012-07-20 9:50 ` Joe Thornber
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='ju9vdv$vpa$1@dough.gmane.org' \
--to=eternaleye+usenet@gmail.com \
--cc=dm-crypt@saout.de \
--cc=dm-devel@redhat.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.