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

[Jon Bendtsen]

Christophe Saout wrote:
> Hi!
> 
> It looks like Kernel programming is real fun... I hope Jon isn't going
> to kill me for that.

Does a kill-filter count ;-P


> 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.

Well this does kind of make my project redundant and moot :(
Besides, since i now "seen" the code you did (well, i replied
to the email, but not studied the code) then perhaps my professor
might possibly will raise questions as to whether or not i really
developed the code myself.


> 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. ;)

you're not gonna get any more ideas from me


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

If it was so dog-slow, and an unneeded complexity, why did you make it?





JonB