[dm-devel] Another experimental dm target... an encryption target

[Christophe Saout]

Hi!

It looks like Kernel programming is real fun... I hope Jon isn't going
to kill me for that.

I wrote a dm-crypt target that works like a linear target but does
encryption using the new cryptoapi in the 2.5/2.6 kernel.

The target configuration syntax is "<cipher> <key> <iv_offset> <device>
<sector>".

<cipher> is something like aes or des. It can optionally be suffixed by
the mode (like des-ecb). There are two modes: ecb and cbc. The cbc mode
uses the sector number as additional perturbation so that identical
sectors look different when they get encrypted (like zero-filled
sectors). In this case the <iv_offset> is an additional sector offset
for this, if you want to map only a part of the encrypted device and
still want to be able to read your data. cbc doesn't actually chain the
blocks because that would be bad for a random-access device, so the name
might be misleading.

<key> is the key in hex (a long string, two digits per byte).

<device> and <sector> are the same as in the linear target.

The implementation is somewhat sub-optimal. There are some issues that
lead to unnecessary complexity:

1. I could save a mempool if I could access the target_io structure (I
could, but that's really ugly). That's because I need to access my
crypt_c structure in my endio function. Because I also need to access
the original bio and I can't put two pointers in cloned_bio->bi_private
I have to allocate a crypt_io structure that contains both pointers.

2. I can't use the "new" end_io mechanism for which Joe posted a patch
some days ago. That's because I need to clone the bio (again) because I
have to associate some new pages, at least for writes.
Because of this I have to implement my own endio function for the cloned
bios. Another problem with the dm end_io handler is that the bio loses
the information about where the size of the data and it's pages so that
I can convert it. That's why I also need to clone the bio on reads. At
least I don't need to allocate additional buffers because I can decrypt
the data in place.

The bios device-mapper gives to the target are never sent down. I've got
the same problem in dm-file (at least I don't need to clone them again
so it's not a too big waste).

Perhaps this could be simplified somehow in the generic device-mapper
layer, but at the moment I'm not sure how.

So you see, at lot of room for improvements. ;)

Well, the cryptoapi is dog-slow anyway so it's not a performance waste,
just unneeded complexity.

--
Christophe Saout <christophe at saout.de>
Please avoid sending me Word or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dm-crypt.c
Type: text/x-c
Size: 14221 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20030725/aaa0597f/attachment.bin>