lkml.org 
[lkml]   [2011]   [Jan]   [6]   [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:
>
> 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.

The main use-case is bulk encryption/hashing in user-space. For
example, on Sparc Niagara2 you need to use SPU (Stream Processing
Unit) in order to do crypto at 10Gb/s over the network. Because
of the hardware design, it is difficult to make use of the SPU
directly in user-space, unless you dedicate the SPU to one single
thread/user.

That is why we need a crypto driver in the kernel as well as a
user-space interface exporting it, to make available a single
piece of hardware resource so that it may be used by multiple
users in user-space.

The same applies to most of the drivers in drivers/crypto, e.g.,
omap provides ARM crypto acceleration providing crypto throughput
that simply cannot be achieved by the CPU itself.

The actual encryption in user-space would be anything that is
done in bulk, such as SSH or SSL. In fact, the intention is
to implement it just once in a library such as libssl where it
could then be used automatically by all appliations.

> But in your example, it looks like you just give it the key. Which to
> me means that you're totally missing one of the major reasons for
> having a separate protection domain.

Providing such separation is not the primary objective of this API,
which is providing user-space access to off-chip crypto hardware.

However, this is something that has been considered and can be
easily added. The idea is to first add symmetric key storage
capability to the existing in-kernel keyring API. Once that is
done we can easily add a new setsockopt to the crypto user-interface
that retrieves the key from the kernel keyring instead of getting
it directly from user-space.

Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


\
 
 \ /
  Last update: 2011-01-06 23:33    [from the cache]
©2003-2011 Jasper Spaans