All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fruhwirth Clemens <clemens-dated-1073042053.4811@endorphin.org>
To: Andrew Morton <akpm@osdl.org>
Cc: Christophe Saout <christophe@saout.de>,
	linux-kernel@vger.kernel.org, thornber@sistina.com
Subject: Re: loop driver, device-mapper and crypto
Date: Tue, 23 Dec 2003 12:14:12 +0100	[thread overview]
Message-ID: <20031223111412.GA4593@ghanima.endorphin.org> (raw)
In-Reply-To: <20031222140305.61823850.akpm@osdl.org>

[-- Attachment #1: Type: text/plain, Size: 2061 bytes --]

On Mon, Dec 22, 2003 at 02:03:05PM -0800, Andrew Morton wrote:
> Christophe Saout <christophe@saout.de> wrote:
> >
> > In 2.6 we have a device-mapper which does such things in a much more
> > generic way. I've already talked to a bunch of people working on loop
> > and cryptoloop (also with Clemens Fruhwirth, the cryptoloop maintainer)
> > and they all agreed that device-mapper is probably the most correct way
> > to go, and would be happier if the loop driver was used for files only.
> 
> I'm not a crypto-loop user, so I am not in a position to judge whether
> using dm for crypto-on-disk is feature-sufficient and adequate from an
> operational point of view.

First of all, eventhou I'm the maintainer of cryptoloop, when Christophe
posted the first time I immediately recognized that dm-crypt is vastly
superior to cryptoloop for a number of reasons:

.) It does not suffer from loop.c bugs (There are a lot, no maintainer)
.) dm-crypt does not depend on special user space tool (util-linux)
.) dm-crypt uses mempool, which makes it rock stable compared to cryptoloop. 

From an operational point of view, patching util-linux has been the most
troublesome point. Lot's of incompatible inofficial patches floating around
in the net, while the last release of util-linux provides a broken and IMHO
insecure why of setting up cryptokeys. Further: To fix the design flaw of
unencrypted/unhashed IV vectors one has to add another setup parameter.
That's where I really do like the flexible interface dm has.

> However I suspect that there will be a migration issue, and that we should
> continue to work to get crypto-loop functioning well, plan to remove it
> from 2.8, yes?

We should support cryptoloop. No new features, but working well. At the same
time we should declare it 'deprecated' and provide dm-crypt as alternative.
I'm happy to provide documentation on how to migrate.

I will review Christophe's patch as well as test compatiblity with
cryptoloop. Expect my results in a few days.

Regards, Clemens

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

      reply	other threads:[~2003-12-23 11:13 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-22 21:42 loop driver, device-mapper and crypto Christophe Saout
2003-12-22 21:49 ` [PATCH 1/2] Add dm-daemon Christophe Saout
2003-12-23 12:27   ` Christoph Hellwig
2003-12-23 15:10     ` Joe Thornber
2003-12-22 21:52 ` [PATCH 2/2][RFC] Add dm-crypt target Christophe Saout
2003-12-22 23:07   ` Jeff Garzik
2003-12-22 23:24     ` Mike Fedyk
2003-12-22 23:29       ` Jeff Garzik
2003-12-22 23:50         ` Mike Fedyk
2003-12-23  0:10           ` Christophe Saout
2003-12-23  2:53   ` Rusty Russell
2003-12-23 13:13   ` Christoph Hellwig
2003-12-23 13:36     ` Christophe Saout
2003-12-23 15:15       ` Joe Thornber
2003-12-23 15:31         ` Jeff Garzik
2003-12-23 15:43           ` Joe Thornber
2003-12-23 17:01             ` Christophe Saout
2003-12-23 17:15               ` Joe Thornber
2003-12-23 17:14                 ` Jeff Garzik
2003-12-22 22:03 ` loop driver, device-mapper and crypto Andrew Morton
2003-12-23 11:14   ` Fruhwirth Clemens [this message]

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=20031223111412.GA4593@ghanima.endorphin.org \
    --to=clemens-dated-1073042053.4811@endorphin.org \
    --cc=akpm@osdl.org \
    --cc=christophe@saout.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=thornber@sistina.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.