1. 20 12月, 2011 1 次提交
  2. 30 11月, 2011 1 次提交
  3. 21 11月, 2011 2 次提交
  4. 09 11月, 2011 1 次提交
  5. 01 11月, 2011 1 次提交
  6. 26 10月, 2011 1 次提交
  7. 21 10月, 2011 2 次提交
  8. 22 9月, 2011 2 次提交
  9. 10 8月, 2011 1 次提交
    • M
      crypto: sha1 - SSSE3 based SHA1 implementation for x86-64 · 66be8951
      Mathias Krause 提交于
      This is an assembler implementation of the SHA1 algorithm using the
      Supplemental SSE3 (SSSE3) instructions or, when available, the
      Advanced Vector Extensions (AVX).
      
      Testing with the tcrypt module shows the raw hash performance is up to
      2.3 times faster than the C implementation, using 8k data blocks on a
      Core 2 Duo T5500. For the smalest data set (16 byte) it is still 25%
      faster.
      
      Since this implementation uses SSE/YMM registers it cannot safely be
      used in every situation, e.g. while an IRQ interrupts a kernel thread.
      The implementation falls back to the generic SHA1 variant, if using
      the SSE/YMM registers is not possible.
      
      With this algorithm I was able to increase the throughput of a single
      IPsec link from 344 Mbit/s to 464 Mbit/s on a Core 2 Quad CPU using
      the SSSE3 variant -- a speedup of +34.8%.
      
      Saving and restoring SSE/YMM state might make the actual throughput
      fluctuate when there are FPU intensive userland applications running.
      For example, meassuring the performance using iperf2 directly on the
      machine under test gives wobbling numbers because iperf2 uses the FPU
      for each packet to check if the reporting interval has expired (in the
      above test I got min/max/avg: 402/484/464 MBit/s).
      
      Using this algorithm on a IPsec gateway gives much more reasonable and
      stable numbers, albeit not as high as in the directly connected case.
      Here is the result from an RFC 2544 test run with a EXFO Packet Blazer
      FTB-8510:
      
       frame size    sha1-generic     sha1-ssse3    delta
          64 byte     37.5 MBit/s    37.5 MBit/s     0.0%
         128 byte     56.3 MBit/s    62.5 MBit/s   +11.0%
         256 byte     87.5 MBit/s   100.0 MBit/s   +14.3%
         512 byte    131.3 MBit/s   150.0 MBit/s   +14.2%
        1024 byte    162.5 MBit/s   193.8 MBit/s   +19.3%
        1280 byte    175.0 MBit/s   212.5 MBit/s   +21.4%
        1420 byte    175.0 MBit/s   218.7 MBit/s   +25.0%
        1518 byte    150.0 MBit/s   181.2 MBit/s   +20.8%
      
      The throughput for the largest frame size is lower than for the
      previous size because the IP packets need to be fragmented in this
      case to make there way through the IPsec tunnel.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Cc: Maxim Locktyukhin <maxim.locktyukhin@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      66be8951
  10. 11 7月, 2011 1 次提交
  11. 30 6月, 2011 1 次提交
  12. 16 5月, 2011 1 次提交
  13. 28 12月, 2010 1 次提交
  14. 29 11月, 2010 1 次提交
  15. 27 11月, 2010 1 次提交
    • M
      crypto: aesni-intel - Ported implementation to x86-32 · 0d258efb
      Mathias Krause 提交于
      The AES-NI instructions are also available in legacy mode so the 32-bit
      architecture may profit from those, too.
      
      To illustrate the performance gain here's a short summary of a dm-crypt
      speed test on a Core i7 M620 running at 2.67GHz comparing both assembler
      implementations:
      
      x86:                   i568       aes-ni    delta
      ECB, 256 bit:     93.8 MB/s   123.3 MB/s   +31.4%
      CBC, 256 bit:     84.8 MB/s   262.3 MB/s  +209.3%
      LRW, 256 bit:    108.6 MB/s   222.1 MB/s  +104.5%
      XTS, 256 bit:    105.0 MB/s   205.5 MB/s   +95.7%
      
      Additionally, due to some minor optimizations, the 64-bit version also
      got a minor performance gain as seen below:
      
      x86-64:           old impl.    new impl.    delta
      ECB, 256 bit:    121.1 MB/s   123.0 MB/s    +1.5%
      CBC, 256 bit:    285.3 MB/s   290.8 MB/s    +1.9%
      LRW, 256 bit:    263.7 MB/s   265.3 MB/s    +0.6%
      XTS, 256 bit:    251.1 MB/s   255.3 MB/s    +1.7%
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Reviewed-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      0d258efb
  16. 26 11月, 2010 1 次提交
    • H
      crypto: algif_skcipher - User-space interface for skcipher operations · 8ff59090
      Herbert Xu 提交于
      This patch adds the af_alg plugin for symmetric key ciphers,
      corresponding to the ablkcipher kernel operation type.
      
      Keys can optionally be set through the setsockopt interface.
      
      Once a sendmsg call occurs without MSG_MORE no further writes
      may be made to the socket until all previous data has been read.
      
      IVs and and whether encryption/decryption is performed can be
      set through the setsockopt interface or as a control message
      to sendmsg.
      
      The interface is completely synchronous, all operations are
      carried out in recvmsg(2) and will complete prior to the system
      call returning.
      
      The splice(2) interface support reading the user-space data directly
      without copying (except that the Crypto API itself may copy the data
      if alignment is off).
      
      The recvmsg(2) interface supports directly writing to user-space
      without additional copying, i.e., the kernel crypto interface will
      receive the user-space address as its output SG list.
      
      Thakns to Miloslav Trmac for reviewing this and contributing
      fixes and improvements.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      8ff59090
  17. 19 11月, 2010 2 次提交
    • H
      crypto: algif_hash - User-space interface for hash operations · fe869cdb
      Herbert Xu 提交于
      This patch adds the af_alg plugin for hash, corresponding to
      the ahash kernel operation type.
      
      Keys can optionally be set through the setsockopt interface.
      
      Each sendmsg call will finalise the hash unless sent with a MSG_MORE
      flag.
      
      Partial hash states can be cloned using accept(2).
      
      The interface is completely synchronous, all operations will
      complete prior to the system call returning.
      
      Both sendmsg(2) and splice(2) support reading the user-space
      data directly without copying (except that the Crypto API itself
      may copy the data if alignment is off).
      
      For now only the splice(2) interface supports performing digest
      instead of init/update/final.  In future the sendmsg(2) interface
      will also be modified to use digest/finup where possible so that
      hardware that cannot return a partial hash state can still benefit
      from this interface.
      
      Thakns to Miloslav Trmac for reviewing this and contributing
      fixes and improvements.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Tested-by: NMartin Willi <martin@strongswan.org>
      fe869cdb
    • H
      crypto: af_alg - User-space interface for Crypto API · 03c8efc1
      Herbert Xu 提交于
      This patch creates the backbone of the user-space interface for
      the Crypto API, through a new socket family AF_ALG.
      
      Each session corresponds to one or more connections obtained from
      that socket.  The number depends on the number of inputs/outputs
      of that particular type of operation.  For most types there will
      be a s ingle connection/file descriptor that is used for both input
      and output.  AEAD is one of the few that require two inputs.
      
      Each algorithm type will provide its own implementation that plugs
      into af_alg.  They're keyed using a string such as "skcipher" or
      "hash".
      
      IOW this patch only contains the boring bits that is required
      to hold everything together.
      
      Thakns to Miloslav Trmac for reviewing this and contributing
      fixes and improvements.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Tested-by: NMartin Willi <martin@strongswan.org>
      03c8efc1
  18. 12 9月, 2010 1 次提交
  19. 03 9月, 2010 1 次提交
  20. 06 8月, 2010 2 次提交
    • H
      crypto: testmgr - Default to no tests · 00ca28a5
      Herbert Xu 提交于
      On Thu, Aug 05, 2010 at 07:01:21PM -0700, Linus Torvalds wrote:
      > On Thu, Aug 5, 2010 at 6:40 PM, Herbert Xu <herbert@gondor.hengli.com.au> wrote:
      > >
      > > -config CRYPTO_MANAGER_TESTS
      > > -       bool "Run algolithms' self-tests"
      > > -       default y
      > > -       depends on CRYPTO_MANAGER2
      > > +config CRYPTO_MANAGER_DISABLE_TESTS
      > > +       bool "Disable run-time self tests"
      > > +       depends on CRYPTO_MANAGER2 && EMBEDDED
      >
      > Why do you still want to force-enable those tests? I was going to
      > complain about the "default y" anyway, now I'm _really_ complaining,
      > because you've now made it impossible to disable those tests. Why?
      
      As requested, this patch sets the default to y and removes the
      EMBEDDED dependency.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      00ca28a5
    • H
      crypto: testmgr - Fix test disabling option · 326a6346
      Herbert Xu 提交于
      This patch fixes a serious bug in the test disabling patch where
      it can cause an spurious load of the cryptomgr module even when
      it's compiled in.
      
      It also negates the test disabling option so that its absence
      causes tests to be enabled.
      
      The Kconfig option is also now behind EMBEDDED.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      326a6346
  21. 03 6月, 2010 2 次提交
  22. 29 3月, 2010 1 次提交
  23. 05 2月, 2010 1 次提交
  24. 07 1月, 2010 1 次提交
  25. 27 10月, 2009 1 次提交
  26. 19 10月, 2009 1 次提交
  27. 02 9月, 2009 1 次提交
  28. 20 8月, 2009 1 次提交
    • N
      crypto: fips - Depend on ansi_cprng · 4e4ed83b
      Neil Horman 提交于
      What about something like this?  It defaults the CPRNG to m and makes FIPS
      dependent on the CPRNG.  That way you get a module build by default, but you can
      change it to y manually during config and still satisfy the dependency, and if
      you select N it disables FIPS as well.  I rather like that better than making
      FIPS a tristate.  I just tested it out here and it seems to work well.  Let me
      know what you think
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      4e4ed83b
  29. 13 8月, 2009 1 次提交
  30. 06 8月, 2009 2 次提交
  31. 21 6月, 2009 1 次提交
  32. 19 6月, 2009 1 次提交
  33. 02 6月, 2009 1 次提交
    • H
      crypto: aes-ni - Add support for more modes · 2cf4ac8b
      Huang Ying 提交于
      Because kernel_fpu_begin() and kernel_fpu_end() operations are too
      slow, the performance gain of general mode implementation + aes-aesni
      is almost all compensated.
      
      The AES-NI support for more modes are implemented as follow:
      
      - Add a new AES algorithm implementation named __aes-aesni without
        kernel_fpu_begin/end()
      
      - Use fpu(<mode>(AES)) to provide kenrel_fpu_begin/end() invoking
      
      - Add <mode>(AES) ablkcipher, which uses cryptd(fpu(<mode>(AES))) to
        defer cryption to cryptd context in soft_irq context.
      
      Now the ctr, lrw, pcbc and xts support are added.
      
      Performance testing based on dm-crypt shows that cryption time can be
      reduced to 50% of general mode implementation + aes-aesni implementation.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      2cf4ac8b