Re: [PATCH/proposal] dm-crypt: add digest-based iv generation mode

[Christophe Saout]

Am Fr, den 27.02.2004 schrieb Matt Mackall um 21:02:

> > We could add some functions so that everything is symmetric:
> > (the names with a star are already existing)
> > 
> > *crypto_alloc_tfm
> > \_ crypto_init_tfm
> > 
> > *crypto_free_tfm
> > \_ crypto_release_tfm
> > 
> > crypto_clone_tfm
> > \_ crypto_copy_tfm
> > 
> > crypto_get_alg_size
> > \_crypto_get_tfm_size
> > 
> > crypto_init_tfm does everything but the kmalloc
> > crypto_release_tfm everything but the kfree
> > 
> > So crypto_alloc_tfm and crypto_release_tfm can be changed to call
> > crypto_init_fdm and crypto_release_tfm plus crypto_get_alg_size/kmalloc
> > and kfree.
> > 
> > crypto_clone_tfm calls crypto_get_tfm_size, kmalloc and crypto_copy_tfm.
> > crypto_copy_tfm copies the tfm structure, cares about algorithm
> > reference counting and calls a (new) copy method. This copy method
> > should copy things in its context like kmalloc'ed structures (or
> > increment a reference count if it's a static memory structure or
> > something). (however kmalloc's should be avoided if possible, the
> > variable sized context provides some flexibility)
> > 
> > crypto_get_alg_size returns the size of the tfm structure when algorithm
> > name and flags are given, crypto_get_tfm size returns the size of an
> > existing tfm structure.
> > 
> > So we can also directly initialize a tfm structure on a stack, not only
> > copy it to a stack. Very flexible.
> 
> My original proposal was something like this. Downside with
> _initializing_ on stack is that it's much more heavy-weight. We can
> end having to sleep on pulling in an algorithm. The copy stuff,
> hopefully, can be done in any context.

This was just for completeness reasons. Why being able to copy onto the
stack but not to create on the stack. It doesn't have to be on the
stack. Assuming you want to handle a lot of context and use a mempool.
You might want to have your structure and a tfm to the end of that
structure so they are allocated together. Yes, you could also create a
kmalloc'ed tfm once and copy it to every other structure. Perhaps that's
not even so bad, because in my implementation there is one problem:

You have to know the size of the structure before initializing it. So
the user might change the underlying module why querying the size and
initializing the structure. Hmm. That can be dropped if it doesn't make
sense.

> I'd like to keep it to the minimal three new external functions until
> we have a case that really demonstrates a need for the other stuff.
> Let's keep it simple, get it merged, and go from there. The API I
> posted will work for the three other users I'm aware of, if it works
> for dm-crypt let's go with it.

I've added methods for copying the tfm context because it will fail very
badly for everything that has a pointer in the private context.
Use-after-free and these things. Ugly.

> I also want to hold off on adding ->copy until we find an algorithm
> that can't be cleanly fixed not to need it.

Hmm. It should be there, but could return -EOPNOTSUPP. Copying a
compress tfm doesn't make much sense. We need a way to detect things
that are bad in a generic way, everything else is hacky.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/