Linode.com Forum

[johns]

I would like to be able to use a crypted loopback.

Chris, thanks for already having added the CONFIG_CRYPTO_* options.

after reading
http://www.linode.com/forums/viewtopic.php?t=1242

I am not a kernel specialist, but I think the only kernel option missing to use a crypted loopback is now CONFIG_BLK_DEV_CRYPTOLOOP

In any case, I guess saman007uk and I share to same ultimate goal, to be able to use crypted filesystems within linode.

If this is easy and possible thanks in advance.

John

[caker]

I think you can already do this with losetup:

Code: LOSETUP(8)                   MAINTENANCE COMMANDS                   LOSETUP(8)

NAME
       losetup - set up and control loop devices

SYNOPSIS
       losetup [ [-e|-E] encryption ] [ -o offset ] [ -p pfd ] loop_device
       file
       losetup [ -d ] loop_device

DESCRIPTION
       losetup is used to associate loop devices with regular files  or  block
       devices,  to  detach  loop  devices  and  to query the status of a loop
       device. If only the loop_device argument is given, the  status  of  the
       corresponding loop device is shown.

   Encryption
       It is possible to specify transfer functions (for encryption/decryption
       or other purposes) using one of the -E and -e options.  There  are  two
       mechanisms to specify the desired encryption: by number and by name. If
       an encryption is specified by number then one has to make sure that the
       Linux  kernel  knows about the encryption with that number, probably by
       patching the kernel. Standard numbers that are always present are 0 (no
       encryption)  and  1  (XOR  encryption).   When the cryptoloop module is
       loaded (or compiled in), it uses number 18.  This cryptoloop module wil
       take the name of an arbitrary encryption type and finds the module that
       knows how to perform that encryption.  (Thus, either one uses a  number
       different  from  18  with the -E option, or one uses a name with the -e
       option.)

OPTIONS
       -d     Detach the file or device associated  with  the  specified  loop
              device.

       -E encryption_type
              Enable data encryption with specified number.

       -e encryption_name
              Enable data encryption with specified name.

       -o offset
              The  data start is moved offset bytes into the specified file or
              device.

       -p num Read the passphrase from file descriptor with number num instead
              of from the terminal.

RETURN VALUE
       losetup returns 0 on success, nonzero on failure. When losetup displays
       the status of a loop device, it returns 1 if the device is not  config-
       ured  and 2 if an error occurred which prevented losetup from determin-
       ing the status of the device.

FILES
       /dev/loop0, /dev/loop1, ...   loop devices (major=7)

EXAMPLE
       If you are using the loadable module you must have  the  module  loaded
       first with the command

              # insmod loop.o

       Maybe also encryption modules are needed.

              # insmod des.o # insmod cryptoloop.o

       The  following  commands  can  be  used as an example of using the loop
       device.

              # dd if=/dev/zero of=/file bs=1k count=100
              # losetup -e des /dev/loop0 /file
              Password:
              Init (up to 16 hex digits):
              # mkfs -t ext2 /dev/loop0 100
              # mount -t ext2 /dev/loop0 /mnt
               ...
              # umount /dev/loop0
              # losetup -d /dev/loop0

       If you are using the loadable module you may remove the module with the
       command

              # rmmod loop

RESTRICTION
       DES  encryption  is  painfully slow. On the other hand, XOR is terribly
       weak.

Linux                             2003-07-01                        LOSETUP(8)

Maybe someone else with encrypted loop-back can chime in here...

-Chris

[zibeli2]

Hmmm, well, it's been quite awhile since I set this up, and on my home notebook, not my linode, and from my experimentation with the 2.6.x kernels I think things are changing, but I'll try to point you in the right direction as best I can at this late Friday hour ;-).

I know when I originally set this up with on my notebook with a 2.4.x kernel, patches were required to both the kernel and to the package containing losetup (this late Friday can't recall for sure what that is, mebbe util-linux?) to use the cryto loopack device. However, in my so-far limited experimentation with 2.6.x kernels, I noticed that the kernel config help now gives a warning that the cryptoloop device "not save for journaled file systems like ext3 or Reiserfs", though in over a year using it with 2.4.x kernels and reiserfs I've never encountered any problems and also briefly compiled and used a 2.6.x kernel to access the same encrypted partition using the cryptooop device. Nonetheless, the 2.6.x kernel config help says to "use the Device Mapper crypto module instead, which can be configured to be on-disk compatible with the cryptoloop device". I began looking at the Device Mapper docs, but haven't had time so far to get it working on my notebook. However, given the kernel config help text, it's probably the thing to investigate if you have time. Let me know what you learn! ;-)

[smerritt]

Quote: the cryptoloop device "not save for journaled file systems like ext3 or Reiserfs", though in over a year using it with 2.4.x kernels and reiserfs I've never encountered any problems

The safety they're referring to involves the journaling.

Remember how a journaling FS handles a (meta)data change:
1) write to journal "making change X"
2) make change X
3) erase 1 from journal

If you do this on an ext3-fs cryptoloop device, the writes are originally scheduled in that order. However, after the encryption layer, the writes are just data writes on the encrypted file. These data writes can be performed by the kernel in any order it wants.

So, in terms of what's actually on disk, the writes might go 1, 2, 3 or 2, 1, 3. If they go 2, 1, 3 and halfway through 2 the power dies, your FS is hosed. On mount, the ext3fs driver will check the journal, decide nothing was going on, and leave half-baked data in your FS.

If the kernel doesn't panic and the power stays on, using an ext3 FS on a cryptoloop file will work. You just can't rely on the journaling to protect your data.

[johns]

Thanks all for the prompt replies

Notice the line:
# insmod cryptoloop.o
in the losetup man, this is why I suggested using the CONFIG_BLK_DEV_CRYPTOLOOP option.

However, I am unable to make it work at this time under linode. Here is what I get.

li-25:~# losetup -e aes /dev/loop0 /root/data
Password:
ioctl: LOOP_SET_STATUS: Invalid argument

BTW I am using the latest 2.4 kernel

Any ideas?
Am I missing something obvious?

John
P.S. thanks zibeli2, I have tried the Device Mapper crypto target on 2.6.x, it works

[saman007uk]

johns wrote:
li-25:~# losetup -e aes /dev/loop0 /root/data
Password:
ioctl: LOOP_SET_STATUS: Invalid argument

Exactly what I get. This happends on all kernels.

If I'm right, the following options needs to be compiled into the kernel:
Code: CONFIG_BLK_DEV_LOOP_USE_REL_BLOCK=y
CONFIG_BLK_DEV_LOOP_GEN=y
CONFIG_BLK_DEV_LOOP_CAST=n
CONFIG_BLK_DEV_LOOP_FISH2=n
--Saman

[johns]

it works with the 2.6.9-linode9 kernel
go see post:
http://www.linode.com/forums/viewtopic.php?t=1353