Re: [PATCH 01/19] User-space API definition

[Miloslav Trmac <mitr@redhat.com>]

----- "Herbert Xu" <herbert@gondor.hengli.com.au> wrote:
> On Mon, Aug 23, 2010 at 11:37:40AM -0400, Miloslav Trmac wrote:
> >
> > I can see almost no overlap between the two sets of requirements. 
> Probably the only common use case is handling session keys (e.g. keys
> used in a kerberos ticket), which should be stored in the kernel for
> the duration of the session, made available to each process in the
> session, and available as keys for kernel crypto.  Such keys will be
> in the minority, though, and it seems to me the best approach for
> handling these is to allow key export/import from/to keyring keys in
> addition to export/import from/to data in userspace: the long-term
> storage would be handled by the existing keyring API, which stores the
> key as unformatted binary data, and import into the crypto context
> would convert the key into the internal representation more suitable
> for crypto.
> > 
> > I have seriously considered the keyring API, and this is what I came
> up with - but I'd love to be shown a better way.
> 
> FWIW adding a second key management system to the kernel is
> totally out of the question.
> 
> If the existing system doesn't work for you, find a way to build
> on it so that it does.  Adding a second system that pretty much
> does the same thing is unacceptable.
It does _not_ do the same thing, same as ramfs and file descriptors do not do the same thing although they are both related to files.

The kernel keyring service is basically a system-wide data storage service.  /dev/crypto needs a quick way to refer to short-lived, usually process-local, kernel-space data structures from userspace.

Imagine that instead of
    thread = clone(..., CLONE_THREAD);
you needed to do
    thread_fd = mkstemp("/proc/XXX");
    fork(thread_fd);
That's how "just using the existing keyring" would look like.

Adapting the existing keyring to match the /dev/crypto use case better would make the keyring API at least 25% larger, and introduce completely different key identification and lifetime semantics for a set of keys.

If you can see a way the two can be cleanly integrated, please don't just tell us that we have to do it, tell us how.
 
> Also, the key management for secret keys that you've added should
> not be the only mode offered to the user.  Most people do not need
> the separation between key setting and encryption/decryption.
The "key ID" is not embedded into encryption operation requests (it uses a struct nlattr), so it would be quite possible to supply the raw key instead.
    Mirek