Re: Crypto Update for 2.6.38

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux