From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: Crypto Update for 2.6.38 Date: Fri, 7 Jan 2011 07:04:51 -0500 Message-ID: <20110107120451.GA22347@hmsreliant.think-freely.org> References: <20100519020603.GA19654@gondor.apana.org.au> <20100521104404.GA29530@gondor.apana.org.au> <20100804140448.GA4042@gondor.apana.org.au> <20101024061625.GA23715@gondor.apana.org.au> <20110106000157.GA16089@gondor.apana.org.au> <20110106211645.GA26184@gondor.apana.org.au> <20110106213932.GA26538@gondor.apana.org.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Herbert Xu , "David S. Miller" , Linux Kernel Mailing List , Linux Crypto Mailing List To: Linus Torvalds Return-path: Received: from charlotte.tuxdriver.com ([70.61.120.58]:37438 "EHLO smtp.tuxdriver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750960Ab1AGMFK (ORCPT ); Fri, 7 Jan 2011 07:05:10 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-crypto-owner@vger.kernel.org List-ID: On Thu, Jan 06, 2011 at 02:13:17PM -0800, Linus Torvalds wrote: > On Thu, Jan 6, 2011 at 1:39 PM, Herbert Xu 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