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    [W:0.023 / U:0.200 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site