lkml.org 
[lkml]   [2011]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Crypto Update for 2.6.38
    On Thu, Jan 06, 2011 at 02:13:17PM -0800, Linus Torvalds wrote:
    > On Thu, Jan 6, 2011 at 1:39 PM, Herbert Xu <herbert@gondor.hengli.com.au> wrote:
    > > On Thu, Jan 06, 2011 at 01:23:19PM -0800, Linus Torvalds wrote:
    > >>
    > >> Explanations of interface. Code. Who uses it? What are the actual
    > >> performance benefits on real code?
    > >
    > > You snipped out the bit in my reply where I expanded on it:
    >
    > You didn't expand on it AT ALL.
    >
    > You just mentioned "the interface". I haven't seen WHAT THAT INTERFACE IS!
    >
    > How hard is that to understand?
    >
    > > Here is the original cover email for the patches:
    >
    > Ok, this is more like it. This is roughly what I wanted to see:
    >
    > > : Here is a sample hash program (note that these only illustrate
    > > : what the interface looks like and are not meant to be good examples
    > > : of coding :)
    >
    > But I'm still missing the part where you show that there is any actual
    > use case that makes sense, and that actually improves performance.
    > Maybe it's been posted somewhere else, but the thing is, you're asking
    > _me_ to pull, and as a result you need to convince _me_ that this is a
    > good idea. So if it's been posted/discussed extensively elsewhere,
    > please point to those discussions.
    >
    > I really don't like adding interfaces that don't have hard uses
    > associated with them. We've done it in the past, and it tends to be a
    > morass and a bad idea. That's been true even when the idea has been my
    > own, and thus obviously genius-level and clearly the RightThing(tm),
    > like "splice()". And it's why I push back on new interfaces when I see
    > them.
    >
    > Btw, it doesn't have to be about performance per se. Does this allow
    > people to use keys without actually _seeing_ those keys? Your example
    > implies that that is not the case, but that's actually one of the few
    > reasons to actually support a kernel crypto interface - the ability to
    > have private personal keys around, but not having to actually let
    > possibly untrusted programs see them.
    >
    This actually is an indirect feature of this interface. Using it, you can open
    a algorithm socket, select a specific alg, assign a key, and then pass that
    socket descriptor over a unix socket to an another process using an
    SCM_RIGHTS ancilliary message. The receiving process can then use children
    acceppted from that passed socket to preform the configured crypto operation
    without any knoweldge of the keys used in it. I can write a demo app if you
    like.

    Regards
    Neil



    \
     
     \ /
      Last update: 2011-01-07 13:07    [W:4.181 / U:0.144 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site