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
