With Andrew Morton [interview]'s latest 2.6.3-mm1 kernel [story], he announced that Cryptoloop is being replaced with dm-crypt, a crypto layer for device mapper. Arguments rose quickly, complaining that such a significant change shouldn't happen in a "stable" kernel tree as there are programs being actively designed around Cryptoloop. Andrew Morton explained, "This is actually an argument for removing cryptolooop. People are developing against a crypto infrastructure which has well-known weaknesses. Pulling it out is an excellent way of communicating this fact. Right now, we're just deluding people."

Linux Weekly News has a writeup on the weaknesses in Cryptoloop. In an earlier thread, cryptoloop maintainer Fruhwirth Clemens said, "dm-crypt is vastly superior to cryptoloop for a number of reasons: 1) It does not suffer from loop.c bugs (There are a lot, no maintainer) 2) dm-crypt does not depend on special user space tool (util-linux) 3) dm-crypt uses mempool, which makes it rock stable compared to cryptoloop." Read on for the latest thread which provides much detail on how to use the new dm-crypt layer.

From: Bill Davidsen [email blocked]
To: Andrew Morton [email blocked]
Subject: Re: 2.6.3-mm1
Date: Wed, 18 Feb 2004 11:16:40 -0500

Andrew Morton wrote:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3/2.6.3-mm1/
> 
> - Added the dm-crypt driver: a crypto layer for device-mapper.
> 
>   People need to test and use this please.  There is documentation at
>   http://www.saout.de/misc/dm-crypt/.
> 
>   We should get this tested and merged up.  We can then remove the nasty
>   bio remapping code from the loop driver.  This will remove the current
>   ordering guarantees which the loop driver provides for journalled
>   filesystems.  ie: ext3 on cryptoloop will no longer be crash-proof.
> 
>   After that we should remove cryptoloop altogether.
> 
>   It's a bit late but cyptoloop hasn't been there for long anyway and it
>   doesn't even work right with highmem systems (that part is fixed in -mm).

What definition of "stable kernel" do you use which includes removal of 
features which were reasons to migrate to 2.6 from 2.4? This change 
would mean having to add dm to the kernel which otherwise doesn't use 
it, carry dm utilities on the system whcih are otherwise unneeded, and 
train people to use and not use dm.

I expect major things to change in a development series, but less major 
things than this have been pushed to 2.7, why is this being forced in?

-- 
bill davidsen [email blocked]
   CTO TMR Associates, Inc
   Doing interesting things with small computers since 1979



From: Brandon Low [email blocked]
Subject: Re: 2.6.3-mm1
Date: Wed, 18 Feb 2004 14:04:39 -0600

I must add my voice here in strong opposition of the removal of
cryptoloop from the 2.6 series of kernels.  This is no longer a
development series kernel, I (and others, I'm sure) have been working on
developing technologies which depend on this functionality and which
would be _very_ annoying to do with DM (liveCD-on-cryptoloop-on-iso).

Please do not drop cryptoloop!

Thanks,
--
Brandon Low
Release Coordinator
Ribstone Systems
http://www.ribstonesystems.com



From: Andrew Morton [email blocked]
Subject: Re: 2.6.3-mm1
Date: Wed, 18 Feb 2004 12:22:16 -0800

Brandon Low [email blocked] wrote:
>
> I must add my voice here in strong opposition of the removal of
>  cryptoloop from the 2.6 series of kernels.  This is no longer a
>  development series kernel, I (and others, I'm sure) have been working on
>  developing technologies which depend on this functionality and which
>  would be _very_ annoying to do with DM (liveCD-on-cryptoloop-on-iso).

Why is it problematic?

>  Please do not drop cryptoloop!

ho-hum.  Why should we retain crypto capabilities which have widely
understood vulnerabilities?

We mainly want to remove the bio remapping stuff from the loop driver
because it's horrid and deadlocks under heavy memory pressure.  Maybe we
can leave crytoloop there with big "kindergarten crypto - do not use"
labels all over it.



From: Brandon Low [email blocked]
Subject: Re: 2.6.3-mm1
Date: Wed, 18 Feb 2004 14:33:25 -0600

On Wed, 02/18/04 at 12:22:16 -0800, Andrew Morton wrote:
> Why is it problematic?
> 
Involves taking up precious CD space with the DM tools and modules...

Besides, this isn't really the point, the point is that the new dmcrypto
is only in -mm and cryptoloop is in both trees, those of us developing
applications based on cryptoloop don't have a mainline kernel to even
start testing dmcrypto against in the 2.6 series, so it is more a
political issue than a technical issue which makes the removal of a
feature like this from the 2.6 series a bad thing...  (In my humble
never contributed to the kernel opinion)

Technically speaking there is no doubt that you are correct to want to
remove cryptoloop... but if people are depending on that support to stay
in a stable kernel and are developing based on it and don't have the
time to learn dm or dmcrypto and redesign whatever may need redesigning
to use it, it strikes me as rude to pull that support.

> >  Please do not drop cryptoloop!
> 
> ho-hum.  Why should we retain crypto capabilities which have widely
> understood vulnerabilities?
> 
> We mainly want to remove the bio remapping stuff from the loop driver
> because it's horrid and deadlocks under heavy memory pressure.  Maybe we
> can leave crytoloop there with big "kindergarten crypto - do not use"
> labels all over it.
> 
DEPRECATED would probably do...

--
Brandon Low
Release Manager
Ribstone Systems
http://www.ribstonesystems.com



From: Andrew Morton [email blocked]
Subject: Re: 2.6.3-mm1
Date: Wed, 18 Feb 2004 12:52:27 -0800

Brandon Low [email blocked] wrote:
>
> but if people are depending on that support to stay
>  in a stable kernel and are developing based on it and don't have the
>  time to learn dm or dmcrypto and redesign whatever may need redesigning
>  to use it, it strikes me as rude to pull that support.

This is actually an argument for removing cryptolooop.  People are
developing against a crypto infrastructure which has well-known weaknesses.

Pulling it out is an excellent way of communicating this fact.  Right now,
we're just deluding people.



From: Brandon Low [email blocked]
Subject: Re: 2.6.3-mm1
Date: Wed, 18 Feb 2004 14:52:06 -0600

On Wed, 02/18/04 at 12:52:27 -0800, Andrew Morton wrote:
> This is actually an argument for removing cryptolooop.  People are
> developing against a crypto infrastructure which has well-known weaknesses.
> 
> Pulling it out is an excellent way of communicating this fact.  Right now,
> we're just deluding people.

Unfortunately, you have a valid point... I don't like it, because it
means work for me, but it is a valid point... 

I am just reading up on dm now, but correct me if I am wrong, I will
need to do losetup, dmcreate, mount in that order in order to use
dmcrypt on loop where with cryptoloop, I could just do "mount"... there
must be an easier way to handle this!

Thanks,

Brandon



From: Andrew Morton [email blocked]
Subject: Re: 2.6.3-mm1
Date: Wed, 18 Feb 2004 13:00:23 -0800

Brandon Low [email blocked] wrote:
>
> I am just reading up on dm now, but correct me if I am wrong, I will
> need to do losetup, dmcreate, mount in that order in order to use
> dmcrypt on loop where with cryptoloop, I could just do "mount"... there
> must be an easier way to handle this!

See Bert's email from eariler today:



Date: Wed, 18 Feb 2004 13:14:16 +0100
From: bert hubert [email blocked]

>   People need to test and use this please.  There is documentation at
>   http://www.saout.de/misc/dm-crypt/.

Works amazingly well. Starting from stock 2.6.3 I applied 'dm*' from the
broken out 2.6.3-mm1, no fuzz or offset, and ran make on the kernel I had
built this morning.

I then turned on the device mapper and its crypto support and loaded the
modules, without rebooting.

Downloaded ftp://ftp.sistina.com/pub/LVM2/device-mapper/device-mapper-latest.tgz
	./configure && make && sudo make install
	sudo ./scripts/devmap_mknod.sh (to create /dev/mapper)
Downloaded http://www.stwing.org/~sluskyb/util-linux/hashalot-0.2.0.tar.gz
	./configure && make && sudo make install	

Downloaded http://www.saout.de/misc/cryptsetup
	ran: cryptsetup -h plain create crypted /dev/hdb1
  		(the -h plain isn't necessary, I didn't have hashalot
		 earlier, and even with -h plain it wants hashalot)
		entered a passphrase (already forgotten though)
	e2fsck /dev/mapper/crypted
	mount /dev/mapper/crypted /mnt

mke2fs proved to be a significant CPU load (all sy) and took a minute or two
to run, which could be forgiven, it had to mke2fs 200G.

I then copied the entire Linux build tree to /mnt, ran make clean, make, and
12 minutes later I had a new kernel. System load was below <10% at all
times, mostly <5%.

Then I did the whole thing again but then with ext3, which worked too. System
load appeared slightly higher, the build however took 12 minutes as well.

Kudos!

Suggestions 
-----------
1) Add a reference to the hashalot location to
   http://www.saout.de/misc/dm-crypt/ and add some units to 'cryptsetup',
   something like this (probably tab/space damaged):

--- cryptsetup  2003-12-26 21:27:08.000000000 +0100
+++ cryptsetup.ahu      2004-02-18 12:46:18.000000000 +0100
@@ -229,10 +229,10 @@
                gettable "$NAME"
                echo "$DMPATH$NAME is active:"
                echo "  cipher:  $CIPHER"
-               echo "  keysize: $[${#KEY}/2]"
+               echo "  keysize: $[${#KEY}/2] bytes"
                echo "  device:  $DEVICE"
                echo "  offset:  $SKIPPED"
-               echo "  size:    $SIZE"
+               echo "  size:    $SIZE sectors"
                [ $SKIPPED -gt 0 ] && echo "   skipped: $SKIPPED"
                unset KEY
        else

  The output can be mighty confusing otherwise.

2) Remove dependence on hashalot for -h plain
3) Add pointer to hashalot on the main page
4) make make install of the device mapper userspace run the mknod script

>   filesystems.  ie: ext3 on cryptoloop will no longer be crash-proof.
(...)
>   After that we should remove cryptoloop altogether.

Big fat warnings might be wise in the meantime. I sincerely hope that 
dm-crypt can be merged sooner rather than later. It feels good and it Just
Works.



From: Christophe Saout [email blocked]
Subject: Re: 2.6.3-mm1
Date: Wed, 18 Feb 2004 23:15:37 +0100

Am Mi, den 18.02.2004 schrieb Brandon Low um 21:52:

> I am just reading up on dm now, but correct me if I am wrong, I will
> need to do losetup, dmcreate, mount in that order in order to use
> dmcrypt on loop where with cryptoloop, I could just do "mount"... there
> must be an easier way to handle this!

You don't need to know everything about dm to set up encrypted devices.

Basically dmsetup is something like losetup, only that it's much more
flexible.

To set up a device basically:

echo 0 `blockdev --getsize /dev/bla` crypt <cipher> <key> 0 /dev/bla 0 |
dmsetup create <newname>

is enough. And it's just temporary, because no special tool has been
written yet. dmsetup is the most low-level dm tool, mostly for
developers. I've written a shell script named cryptsetup for the
meantime, it asks for a passphrase and does all the magic you need.

"cryptsetup create test /dev/hda5" will ask for a passphrase and set up
/dev/mapper/test. Voila. "cryptsetup remove test" removes it and
"cryptsetup status test" shows some status information.

mount -o loop is basically a hack. mount uses parts of losetup to do an
ioctl. The encryption support as mount argument is an additional patch.
Even worse, some do passphrase hashing, some don't... it works but it's
not a very clean solution either.

BTW: dmsetup is NOT a big program. It has two parts: a libdevmapper.so
in /lib and the dmsetup binary itself. Every part is 16k in size (if
compiled statically into one binary it's just 27k), and it's still
linked against glibc. If linked against dietlibc or klibc it would be
even smaller. Nobody needs LVM tools or something. It's just a small
client for the dm ioctl, just like losetup is a client for the loop
ioctl.

There are some plans to write a unified plugin based key management
tool. You might want to have your key stored on a USB stick. Or
encrypted in the first sector of your device and you want to unlock it
using a password (so you can change your password without needing to
reencrypt your data). This would be much more flexible than most of the
crap floating around.

So, you see. NO NEED TO PANIC. Cryptoloop won't disappear over night.
There will be some nice to user interface. At the moment dm-crypt is
only a *kernel implementation* and not meant to be used by every end
user immediately. Nobody will force you to drop cryptoloop until there
is a clean solution for everybody out there.



From: Brandon Low [email blocked]
Subject: Re: 2.6.3-mm1
Date: Wed, 18 Feb 2004 18:33:01 -0600

On Wed, 02/18/04 at 23:15:37 +0100, Christophe Saout wrote:
> "cryptsetup create test /dev/hda5" will ask for a passphrase and set up
> /dev/mapper/test. Voila. "cryptsetup remove test" removes it and
> "cryptsetup status test" shows some status information.
> 
What I can't figure out yet is how to do that easily for a loopback...
use losetup first, and then cryptsetup?  I guess that's ok, just more
steps than I would prefer.

> mount -o loop is basically a hack. mount uses parts of losetup to do an
> ioctl. The encryption support as mount argument is an additional patch.
> Even worse, some do passphrase hashing, some don't... it works but it's
> not a very clean solution either.
> 
> BTW: dmsetup is NOT a big program. It has two parts: a libdevmapper.so
> in /lib and the dmsetup binary itself. Every part is 16k in size (if
> compiled statically into one binary it's just 27k), and it's still
> linked against glibc. If linked against dietlibc or klibc it would be
> even smaller. Nobody needs LVM tools or something. It's just a small
> client for the dm ioctl, just like losetup is a client for the loop
> ioctl.
> 
I was under the mistaken impression that I would need lvmtools as well
in order to use dmcrypt... cool.

> There are some plans to write a unified plugin based key management
> tool. You might want to have your key stored on a USB stick. Or
> encrypted in the first sector of your device and you want to unlock it
> using a password (so you can change your password without needing to
> reencrypt your data). This would be much more flexible than most of the
> crap floating around.

That sounds very cool, saw mention of putting it in the first part of
the device elsethread.
> 
> So, you see. NO NEED TO PANIC. Cryptoloop won't disappear over night.
> There will be some nice to user interface. At the moment dm-crypt is
> only a *kernel implementation* and not meant to be used by every end
> user immediately. Nobody will force you to drop cryptoloop until there
> is a clean solution for everybody out there.
> 
Ok ok, I'll quit panicking... this just makes it hard to decide which to
use now as I'm preparing to deploy soon... If I use cryptoloop, it is
now guaranteed to be obsolete soon, but if I use dmcrypt, it is more
work right now, but more forward looking... 

Can you point me to some useful readings related to dmcrypt,
devicemapper for loopback, etc.? Thanks!

--Brandon



From: Christophe Saout [email blocked]
Subject: Re: 2.6.3-mm1
Date: Thu, 19 Feb 2004 13:39:07 +0100

Am Do, den 19.02.2004 schrieb Brandon Low um 01:33:

> What I can't figure out yet is how to do that easily for a loopback...
> use losetup first, and then cryptsetup?  I guess that's ok, just more
> steps than I would prefer.

Yes. Block->File and Block->Crypto->Block are two different things and
should be separated out. But it would be an easy one to make cryptsetup
also call losetup if your specified backend happens to be a file. Like
mount -o loop does. The only thing I'm not sure about: How would it know
when to remove the loop device on "cryptsetup remove" and when now.
mount stores it in the mtab.

I've got some free time, I think I'm going to rewrite cryptsetup as a
small C program today.

> I was under the mistaken impression that I would need lvmtools as well
> in order to use dmcrypt... cool.

Yes, there's some FUD going around...

> > There are some plans to write a unified plugin based key management
> > tool. You might want to have your key stored on a USB stick. Or
> > encrypted in the first sector of your device and you want to unlock it
> > using a password (so you can change your password without needing to
> > reencrypt your data). This would be much more flexible than most of the
> > crap floating around.
> 
> That sounds very cool, saw mention of putting it in the first part of
> the device elsethread.

Yes, for example.

> Ok ok, I'll quit panicking... this just makes it hard to decide which to
> use now as I'm preparing to deploy soon... If I use cryptoloop, it is
> now guaranteed to be obsolete soon, but if I use dmcrypt, it is more
> work right now, but more forward looking... 
> 
> Can you point me to some useful readings related to dmcrypt,
> devicemapper for loopback, etc.? Thanks!

For dm-crypt I've set up a small page:
http://www.saout.de/misc/dm-crypt/

For device-mapper and loopback there's nothing. The loop device provides
block devices, device-mapper can use them. Nothing special here.

• Archive of above thread
• KernelTrap interview with Andrew Morton