[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

Christophe Saout wrote:

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>

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]