Re: [PATCH] implement in-kernel keys & keyring management

[David Howells]

James Morris <jmorris@xxxxxxxxxx>
> I'm not disagreeing with the above, but what about performance?  Part of
> the reason I suggested Netlink is that it's likely to be more efficient to
> send messages over a socket than to exec a program for each key request
> from the kernel.
> 
> It's difficult to know if performance will actually be an issue without
> understanding the potential workload more.  What if many thousands of
> clients are connected to a fileserver?  Would calling /sbin/request-key
> for each key request be likely to cause performance problems?

I have put in one thing to mitigate this problem. There's a construction
queue. If a user has a key under userspace construction with a particular type
and description, then anyone else who wants the same key will have to wait for
the key construction to complete, and then repeat their search.

The assumption is that the constructor will instantiate the key and link it
into one of the calling process's keyrings (probably the session
keyring). This then acts as a cache, where subsequent key accesses should
hopefully find it.

However, there are two issues this.

 (1) Key lookup failure: I think that maybe I need to add the concept of a
     "negative" key.

     Key search would then proceed in this manner: the keyring tree is
     searched for a positive key, terminating the search when one is
     found. Any matching negative keys are noted in passing, but nothing is
     done about them until the search fails; in which case an error will be
     returned immediately rather than going to userspace.

 (2) What if the new key is not made available to the next process that wants
     it, perhaps because it's in a different session? Should it be possible
     for the constructor to say "don't use this key, use that one instead",
     and substitute an existing key from its cache?

David
-
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/