1. 31 Mar, 2015 3 commits
  2. 16 Mar, 2015 1 commit
  3. 13 Mar, 2015 1 commit
  4. 28 Feb, 2015 1 commit
  5. 27 Feb, 2015 1 commit
  6. 14 Jan, 2015 1 commit
    • Timothy McCaffrey's avatar
      crypto: aesni - Add support for 192 & 256 bit keys to AESNI RFC4106 · e31ac32d
      Timothy McCaffrey authored
      These patches fix the RFC4106 implementation in the aesni-intel
      module so it supports 192 & 256 bit keys.
      
      Since the AVX support that was added to this module also only
      supports 128 bit keys, and this patch only affects the SSE
      implementation, changes were also made to use the SSE version
      if key sizes other than 128 are specified.
      
      RFC4106 specifies that 192 & 256 bit keys must be supported (section
      8.4).
      
      Also, this should fix Strongswan issue 341 where the aesni module
      needs to be unloaded if 256 bit keys are used:
      
      http://wiki.strongswan.org/issues/341
      
      
      
      This patch has been tested with Sandy Bridge and Haswell processors.
      With 128 bit keys and input buffers > 512 bytes a slight performance
      degradation was noticed (~1%).  For input buffers of less than 512
      bytes there was no performance impact.  Compared to 128 bit keys,
      256 bit key size performance is approx. .5 cycles per byte slower
      on Sandy Bridge, and .37 cycles per byte slower on Haswell (vs.
      SSE code).
      
      This patch has also been tested with StrongSwan IPSec connections
      where it worked correctly.
      
      I created this diff from a git clone of crypto-2.6.git.
      
      Any questions, please feel free to contact me.
      Signed-off-by: default avatarTimothy McCaffrey <timothy.mccaffrey@unisys.com>
      Signed-off-by: default avatarJarod Wilson <jarod@redhat.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      e31ac32d
  7. 13 Jan, 2015 2 commits
    • Mathias Krause's avatar
      crypto: x86/des3_ede - drop bogus module aliases · d8219f52
      Mathias Krause authored
      
      
      This module implements variations of "des3_ede" only. Drop the bogus
      module aliases for "des".
      
      Cc: Jussi Kivilinna <jussi.kivilinna@iki.fi>
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      d8219f52
    • Mathias Krause's avatar
      crypto: add missing crypto module aliases · 3e14dcf7
      Mathias Krause authored
      Commit 5d26a105 ("crypto: prefix module autoloading with "crypto-"")
      changed the automatic module loading when requesting crypto algorithms
      to prefix all module requests with "crypto-". This requires all crypto
      modules to have a crypto specific module alias even if their file name
      would otherwise match the requested crypto algorithm.
      
      Even though commit 5d26a105 added those aliases for a vast amount of
      modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
      annotations to those files to make them get loaded automatically, again.
      This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
      with kernels v3.18 and below.
      
      Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
      won't work for crypto modules any more.
      
      Fixes: 5d26a105
      
       ("crypto: prefix module autoloading with "crypto-"")
      Cc: Kees Cook <keescook@chromium.org>
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      3e14dcf7
  8. 05 Jan, 2015 2 commits
    • Vinson Lee's avatar
      crypto: sha-mb - Add avx2_supported check. · 0b8c960c
      Vinson Lee authored
      
      
      This patch fixes this allyesconfig target build error with older
      binutils.
      
        LD      arch/x86/crypto/built-in.o
      ld: arch/x86/crypto/sha-mb/built-in.o: No such file: No such file or directory
      
      Cc: stable@vger.kernel.org # 3.18+
      Signed-off-by: default avatarVinson Lee <vlee@twitter.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      0b8c960c
    • Mathias Krause's avatar
      crypto: aesni - fix "by8" variant for 128 bit keys · 0b1e95b2
      Mathias Krause authored
      
      
      The "by8" counter mode optimization is broken for 128 bit keys with
      input data longer than 128 bytes. It uses the wrong key material for
      en- and decryption.
      
      The key registers xkey0, xkey4, xkey8 and xkey12 need to be preserved
      in case we're handling more than 128 bytes of input data -- they won't
      get reloaded after the initial load. They must therefore be (a) loaded
      on the first iteration and (b) be preserved for the latter ones. The
      implementation for 128 bit keys does not comply with (a) nor (b).
      
      Fix this by bringing the implementation back to its original source
      and correctly load the key registers and preserve their values by
      *not* re-using the registers for other purposes.
      
      Kudos to James for reporting the issue and providing a test case
      showing the discrepancies.
      Reported-by: default avatarJames Yonan <james@openvpn.net>
      Cc: Chandramouli Narayanan <mouli@linux.intel.com>
      Cc: <stable@vger.kernel.org> # v3.18
      Signed-off-by: default avatarMathias Krause <minipli@googlemail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      0b1e95b2
  9. 02 Dec, 2014 1 commit
  10. 26 Nov, 2014 1 commit
  11. 25 Nov, 2014 1 commit
  12. 24 Nov, 2014 1 commit
  13. 06 Nov, 2014 1 commit
    • Valentin Rothberg's avatar
      crypto: aesni - remove unnecessary #define · 304576a7
      Valentin Rothberg authored
      
      
      The CPP identifier 'HAS_PCBC' is defined when the Kconfig
      option CRYPTO_PCBC is set as 'y' or 'm', and is further
      used in two ifdef blocks to conditionally compile source
      code. This indirection hides the actual Kconfig dependency
      and complicates readability. Moreover, it's inconsistent
      with the rest of the ifdef blocks in the file, which
      directly reference Kconfig options.
      
      This patch removes 'HAS_PCBC' and replaces its occurrences
      with the actual dependency on 'CRYPTO_PCBC' being set as
      'y' or 'm'.
      Signed-off-by: default avatarValentin Rothberg <valentinrothberg@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      304576a7
  14. 02 Oct, 2014 3 commits
  15. 24 Sep, 2014 1 commit
  16. 26 Aug, 2014 1 commit
  17. 25 Aug, 2014 4 commits
  18. 25 Jun, 2014 2 commits
  19. 20 Jun, 2014 3 commits
    • chandramouli narayanan's avatar
      crypto: aes - AES CTR x86_64 "by8" AVX optimization · 22cddcc7
      chandramouli narayanan authored
      This patch introduces "by8" AES CTR mode AVX optimization inspired by
      Intel Optimized IPSEC Cryptograhpic library. For additional information,
      please see:
      http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=22972
      
      
      
      The functions aes_ctr_enc_128_avx_by8(), aes_ctr_enc_192_avx_by8() and
      aes_ctr_enc_256_avx_by8() are adapted from
      Intel Optimized IPSEC Cryptographic library. When both AES and AVX features
      are enabled in a platform, the glue code in AESNI module overrieds the
      existing "by4" CTR mode en/decryption with the "by8"
      AES CTR mode en/decryption.
      
      On a Haswell desktop, with turbo disabled and all cpus running
      at maximum frequency, the "by8" CTR mode optimization
      shows better performance results across data & key sizes
      as measured by tcrypt.
      
      The average performance improvement of the "by8" version over the "by4"
      version is as follows:
      
      For 128 bit key and data sizes >= 256 bytes, there is a 10-16% improvement.
      For 192 bit key and data sizes >= 256 bytes, there is a 20-22% improvement.
      For 256 bit key and data sizes >= 256 bytes, there is a 20-25% improvement.
      
      A typical run of tcrypt with AES CTR mode encryption of the "by4" and "by8"
      optimization shows the following results:
      
      tcrypt with "by4" AES CTR mode encryption optimization on a Haswell Desktop:
      ---------------------------------------------------------------------------
      
      testing speed of __ctr-aes-aesni encryption
      test 0 (128 bit key, 16 byte blocks): 1 operation in 343 cycles (16 bytes)
      test 1 (128 bit key, 64 byte blocks): 1 operation in 336 cycles (64 bytes)
      test 2 (128 bit key, 256 byte blocks): 1 operation in 491 cycles (256 bytes)
      test 3 (128 bit key, 1024 byte blocks): 1 operation in 1130 cycles (1024 bytes)
      test 4 (128 bit key, 8192 byte blocks): 1 operation in 7309 cycles (8192 bytes)
      test 5 (192 bit key, 16 byte blocks): 1 operation in 346 cycles (16 bytes)
      test 6 (192 bit key, 64 byte blocks): 1 operation in 361 cycles (64 bytes)
      test 7 (192 bit key, 256 byte blocks): 1 operation in 543 cycles (256 bytes)
      test 8 (192 bit key, 1024 byte blocks): 1 operation in 1321 cycles (1024 bytes)
      test 9 (192 bit key, 8192 byte blocks): 1 operation in 9649 cycles (8192 bytes)
      test 10 (256 bit key, 16 byte blocks): 1 operation in 369 cycles (16 bytes)
      test 11 (256 bit key, 64 byte blocks): 1 operation in 366 cycles (64 bytes)
      test 12 (256 bit key, 256 byte blocks): 1 operation in 595 cycles (256 bytes)
      test 13 (256 bit key, 1024 byte blocks): 1 operation in 1531 cycles (1024 bytes)
      test 14 (256 bit key, 8192 byte blocks): 1 operation in 10522 cycles (8192 bytes)
      
      testing speed of __ctr-aes-aesni decryption
      test 0 (128 bit key, 16 byte blocks): 1 operation in 336 cycles (16 bytes)
      test 1 (128 bit key, 64 byte blocks): 1 operation in 350 cycles (64 bytes)
      test 2 (128 bit key, 256 byte blocks): 1 operation in 487 cycles (256 bytes)
      test 3 (128 bit key, 1024 byte blocks): 1 operation in 1129 cycles (1024 bytes)
      test 4 (128 bit key, 8192 byte blocks): 1 operation in 7287 cycles (8192 bytes)
      test 5 (192 bit key, 16 byte blocks): 1 operation in 350 cycles (16 bytes)
      test 6 (192 bit key, 64 byte blocks): 1 operation in 359 cycles (64 bytes)
      test 7 (192 bit key, 256 byte blocks): 1 operation in 635 cycles (256 bytes)
      test 8 (192 bit key, 1024 byte blocks): 1 operation in 1324 cycles (1024 bytes)
      test 9 (192 bit key, 8192 byte blocks): 1 operation in 9595 cycles (8192 bytes)
      test 10 (256 bit key, 16 byte blocks): 1 operation in 364 cycles (16 bytes)
      test 11 (256 bit key, 64 byte blocks): 1 operation in 377 cycles (64 bytes)
      test 12 (256 bit key, 256 byte blocks): 1 operation in 604 cycles (256 bytes)
      test 13 (256 bit key, 1024 byte blocks): 1 operation in 1527 cycles (1024 bytes)
      test 14 (256 bit key, 8192 byte blocks): 1 operation in 10549 cycles (8192 bytes)
      
      tcrypt with "by8" AES CTR mode encryption optimization on a Haswell Desktop:
      ---------------------------------------------------------------------------
      
      testing speed of __ctr-aes-aesni encryption
      test 0 (128 bit key, 16 byte blocks): 1 operation in 340 cycles (16 bytes)
      test 1 (128 bit key, 64 byte blocks): 1 operation in 330 cycles (64 bytes)
      test 2 (128 bit key, 256 byte blocks): 1 operation in 450 cycles (256 bytes)
      test 3 (128 bit key, 1024 byte blocks): 1 operation in 1043 cycles (1024 bytes)
      test 4 (128 bit key, 8192 byte blocks): 1 operation in 6597 cycles (8192 bytes)
      test 5 (192 bit key, 16 byte blocks): 1 operation in 339 cycles (16 bytes)
      test 6 (192 bit key, 64 byte blocks): 1 operation in 352 cycles (64 bytes)
      test 7 (192 bit key, 256 byte blocks): 1 operation in 539 cycles (256 bytes)
      test 8 (192 bit key, 1024 byte blocks): 1 operation in 1153 cycles (1024 bytes)
      test 9 (192 bit key, 8192 byte blocks): 1 operation in 8458 cycles (8192 bytes)
      test 10 (256 bit key, 16 byte blocks): 1 operation in 353 cycles (16 bytes)
      test 11 (256 bit key, 64 byte blocks): 1 operation in 360 cycles (64 bytes)
      test 12 (256 bit key, 256 byte blocks): 1 operation in 512 cycles (256 bytes)
      test 13 (256 bit key, 1024 byte blocks): 1 operation in 1277 cycles (1024 bytes)
      test 14 (256 bit key, 8192 byte blocks): 1 operation in 8745 cycles (8192 bytes)
      
      testing speed of __ctr-aes-aesni decryption
      test 0 (128 bit key, 16 byte blocks): 1 operation in 348 cycles (16 bytes)
      test 1 (128 bit key, 64 byte blocks): 1 operation in 335 cycles (64 bytes)
      test 2 (128 bit key, 256 byte blocks): 1 operation in 451 cycles (256 bytes)
      test 3 (128 bit key, 1024 byte blocks): 1 operation in 1030 cycles (1024 bytes)
      test 4 (128 bit key, 8192 byte blocks): 1 operation in 6611 cycles (8192 bytes)
      test 5 (192 bit key, 16 byte blocks): 1 operation in 354 cycles (16 bytes)
      test 6 (192 bit key, 64 byte blocks): 1 operation in 346 cycles (64 bytes)
      test 7 (192 bit key, 256 byte blocks): 1 operation in 488 cycles (256 bytes)
      test 8 (192 bit key, 1024 byte blocks): 1 operation in 1154 cycles (1024 bytes)
      test 9 (192 bit key, 8192 byte blocks): 1 operation in 8390 cycles (8192 bytes)
      test 10 (256 bit key, 16 byte blocks): 1 operation in 357 cycles (16 bytes)
      test 11 (256 bit key, 64 byte blocks): 1 operation in 362 cycles (64 bytes)
      test 12 (256 bit key, 256 byte blocks): 1 operation in 515 cycles (256 bytes)
      test 13 (256 bit key, 1024 byte blocks): 1 operation in 1284 cycles (1024 bytes)
      test 14 (256 bit key, 8192 byte blocks): 1 operation in 8681 cycles (8192 bytes)
      
      crypto: Incorporate feed back to AES CTR mode optimization patch
      
      Specifically, the following:
      a) alignment around main loop in aes_ctrby8_avx_x86_64.S
      b) .rodata around data constants used in the assembely code.
      c) the use of CONFIG_AVX in the glue code.
      d) fix up white space.
      e) informational message for "by8" AES CTR mode optimization
      f) "by8" AES CTR mode optimization can be simply enabled
      if the platform supports both AES and AVX features. The
      optimization works superbly on Sandybridge as well.
      
      Testing on Haswell shows no performance change since the last.
      
      Testing on Sandybridge shows that the "by8" AES CTR mode optimization
      greatly improves performance.
      
      tcrypt log with "by4" AES CTR mode optimization on Sandybridge
      --------------------------------------------------------------
      
      testing speed of __ctr-aes-aesni encryption
      test 0 (128 bit key, 16 byte blocks): 1 operation in 383 cycles (16 bytes)
      test 1 (128 bit key, 64 byte blocks): 1 operation in 408 cycles (64 bytes)
      test 2 (128 bit key, 256 byte blocks): 1 operation in 707 cycles (256 bytes)
      test 3 (128 bit key, 1024 byte blocks): 1 operation in 1864 cycles (1024 bytes)
      test 4 (128 bit key, 8192 byte blocks): 1 operation in 12813 cycles (8192 bytes)
      test 5 (192 bit key, 16 byte blocks): 1 operation in 395 cycles (16 bytes)
      test 6 (192 bit key, 64 byte blocks): 1 operation in 432 cycles (64 bytes)
      test 7 (192 bit key, 256 byte blocks): 1 operation in 780 cycles (256 bytes)
      test 8 (192 bit key, 1024 byte blocks): 1 operation in 2132 cycles (1024 bytes)
      test 9 (192 bit key, 8192 byte blocks): 1 operation in 15765 cycles (8192 bytes)
      test 10 (256 bit key, 16 byte blocks): 1 operation in 416 cycles (16 bytes)
      test 11 (256 bit key, 64 byte blocks): 1 operation in 438 cycles (64 bytes)
      test 12 (256 bit key, 256 byte blocks): 1 operation in 842 cycles (256 bytes)
      test 13 (256 bit key, 1024 byte blocks): 1 operation in 2383 cycles (1024 bytes)
      test 14 (256 bit key, 8192 byte blocks): 1 operation in 16945 cycles (8192 bytes)
      
      testing speed of __ctr-aes-aesni decryption
      test 0 (128 bit key, 16 byte blocks): 1 operation in 389 cycles (16 bytes)
      test 1 (128 bit key, 64 byte blocks): 1 operation in 409 cycles (64 bytes)
      test 2 (128 bit key, 256 byte blocks): 1 operation in 704 cycles (256 bytes)
      test 3 (128 bit key, 1024 byte blocks): 1 operation in 1865 cycles (1024 bytes)
      test 4 (128 bit key, 8192 byte blocks): 1 operation in 12783 cycles (8192 bytes)
      test 5 (192 bit key, 16 byte blocks): 1 operation in 409 cycles (16 bytes)
      test 6 (192 bit key, 64 byte blocks): 1 operation in 434 cycles (64 bytes)
      test 7 (192 bit key, 256 byte blocks): 1 operation in 792 cycles (256 bytes)
      test 8 (192 bit key, 1024 byte blocks): 1 operation in 2151 cycles (1024 bytes)
      test 9 (192 bit key, 8192 byte blocks): 1 operation in 15804 cycles (8192 bytes)
      test 10 (256 bit key, 16 byte blocks): 1 operation in 421 cycles (16 bytes)
      test 11 (256 bit key, 64 byte blocks): 1 operation in 444 cycles (64 bytes)
      test 12 (256 bit key, 256 byte blocks): 1 operation in 840 cycles (256 bytes)
      test 13 (256 bit key, 1024 byte blocks): 1 operation in 2394 cycles (1024 bytes)
      test 14 (256 bit key, 8192 byte blocks): 1 operation in 16928 cycles (8192 bytes)
      
      tcrypt log with "by8" AES CTR mode optimization on Sandybridge
      --------------------------------------------------------------
      
      testing speed of __ctr-aes-aesni encryption
      test 0 (128 bit key, 16 byte blocks): 1 operation in 383 cycles (16 bytes)
      test 1 (128 bit key, 64 byte blocks): 1 operation in 401 cycles (64 bytes)
      test 2 (128 bit key, 256 byte blocks): 1 operation in 522 cycles (256 bytes)
      test 3 (128 bit key, 1024 byte blocks): 1 operation in 1136 cycles (1024 bytes)
      test 4 (128 bit key, 8192 byte blocks): 1 operation in 7046 cycles (8192 bytes)
      test 5 (192 bit key, 16 byte blocks): 1 operation in 394 cycles (16 bytes)
      test 6 (192 bit key, 64 byte blocks): 1 operation in 418 cycles (64 bytes)
      test 7 (192 bit key, 256 byte blocks): 1 operation in 559 cycles (256 bytes)
      test 8 (192 bit key, 1024 byte blocks): 1 operation in 1263 cycles (1024 bytes)
      test 9 (192 bit key, 8192 byte blocks): 1 operation in 9072 cycles (8192 bytes)
      test 10 (256 bit key, 16 byte blocks): 1 operation in 408 cycles (16 bytes)
      test 11 (256 bit key, 64 byte blocks): 1 operation in 428 cycles (64 bytes)
      test 12 (256 bit key, 256 byte blocks): 1 operation in 595 cycles (256 bytes)
      test 13 (256 bit key, 1024 byte blocks): 1 operation in 1385 cycles (1024 bytes)
      test 14 (256 bit key, 8192 byte blocks): 1 operation in 9224 cycles (8192 bytes)
      
      testing speed of __ctr-aes-aesni decryption
      test 0 (128 bit key, 16 byte blocks): 1 operation in 390 cycles (16 bytes)
      test 1 (128 bit key, 64 byte blocks): 1 operation in 402 cycles (64 bytes)
      test 2 (128 bit key, 256 byte blocks): 1 operation in 530 cycles (256 bytes)
      test 3 (128 bit key, 1024 byte blocks): 1 operation in 1135 cycles (1024 bytes)
      test 4 (128 bit key, 8192 byte blocks): 1 operation in 7079 cycles (8192 bytes)
      test 5 (192 bit key, 16 byte blocks): 1 operation in 414 cycles (16 bytes)
      test 6 (192 bit key, 64 byte blocks): 1 operation in 417 cycles (64 bytes)
      test 7 (192 bit key, 256 byte blocks): 1 operation in 572 cycles (256 bytes)
      test 8 (192 bit key, 1024 byte blocks): 1 operation in 1312 cycles (1024 bytes)
      test 9 (192 bit key, 8192 byte blocks): 1 operation in 9073 cycles (8192 bytes)
      test 10 (256 bit key, 16 byte blocks): 1 operation in 415 cycles (16 bytes)
      test 11 (256 bit key, 64 byte blocks): 1 operation in 454 cycles (64 bytes)
      test 12 (256 bit key, 256 byte blocks): 1 operation in 598 cycles (256 bytes)
      test 13 (256 bit key, 1024 byte blocks): 1 operation in 1407 cycles (1024 bytes)
      test 14 (256 bit key, 8192 byte blocks): 1 operation in 9288 cycles (8192 bytes)
      
      crypto: Fix redundant checks
      
      a) Fix the redundant check for cpu_has_aes
      b) Fix the key length check when invoking the CTR mode "by8"
      encryptor/decryptor.
      
      crypto: fix typo in AES ctr mode transform
      Signed-off-by: default avatarChandramouli Narayanan <mouli@linux.intel.com>
      Reviewed-by: default avatarMathias Krause <minipli@googlemail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      22cddcc7
    • Jussi Kivilinna's avatar
      crypto: des_3des - add x86-64 assembly implementation · 6574e6c6
      Jussi Kivilinna authored
      
      
      Patch adds x86_64 assembly implementation of Triple DES EDE cipher algorithm.
      Two assembly implementations are provided. First is regular 'one-block at
      time' encrypt/decrypt function. Second is 'three-blocks at time' function that
      gains performance increase on out-of-order CPUs.
      
      tcrypt test results:
      
      Intel Core i5-4570:
      
      des3_ede-asm vs des3_ede-generic:
      size    ecb-enc ecb-dec cbc-enc cbc-dec ctr-enc ctr-dec
      16B     1.21x   1.22x   1.27x   1.36x   1.25x   1.25x
      64B     1.98x   1.96x   1.23x   2.04x   2.01x   2.00x
      256B    2.34x   2.37x   1.21x   2.40x   2.38x   2.39x
      1024B   2.50x   2.47x   1.22x   2.51x   2.52x   2.51x
      8192B   2.51x   2.53x   1.21x   2.56x   2.54x   2.55x
      Signed-off-by: default avatarJussi Kivilinna <jussi.kivilinna@iki.fi>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      6574e6c6
    • George Spelvin's avatar
      crypto: crc32c-pclmul - Shrink K_table to 32-bit words · 473946e6
      George Spelvin authored
      
      
      There's no need for the K_table to be made of 64-bit words.  For some
      reason, the original authors didn't fully reduce the values modulo the
      CRC32C polynomial, and so had some 33-bit values in there.  They can
      all be reduced to 32 bits.
      
      Doing that cuts the table size in half.  Since the code depends on both
      pclmulq and crc32, SSE 4.1 is obviously present, so we can use pmovzxdq
      to fetch it in the correct format.
      
      This adds (measured on Ivy Bridge) 1 cycle per main loop iteration
      (CRC of up to 3K bytes), less than 0.2%.  The hope is that the reduced
      D-cache footprint will make up the loss in other code.
      
      Two other related fixes:
      * K_table is read-only, so belongs in .rodata, and
      * There's no need for more than 8-byte alignment
      Acked-by: default avatarTim Chen <tim.c.chen@linux.intel.com>
      Signed-off-by: default avatarGeorge Spelvin <linux@horizon.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      473946e6
  20. 04 Apr, 2014 1 commit
  21. 01 Apr, 2014 1 commit
  22. 25 Mar, 2014 3 commits
  23. 21 Mar, 2014 1 commit
    • chandramouli narayanan's avatar
      crypto: sha - SHA1 transform x86_64 AVX2 · 7c1da8d0
      chandramouli narayanan authored
      
      
      This git patch adds x86_64 AVX2 optimization of SHA1
      transform to crypto support. The patch has been tested with 3.14.0-rc1
      kernel.
      
      On a Haswell desktop, with turbo disabled and all cpus running
      at maximum frequency, tcrypt shows AVX2 performance improvement
      from 3% for 256 bytes update to 16% for 1024 bytes update over
      AVX implementation.
      
      This patch adds sha1_avx2_transform(), the glue, build and
      configuration changes needed for AVX2 optimization of
      SHA1 transform to crypto support.
      
      sha1-ssse3 is one module which adds the necessary optimization
      support (SSSE3/AVX/AVX2) for the low-level SHA1 transform function.
      With better optimization support, transform function is overridden
      as the case may be. In the case of AVX2, due to performance reasons
      across datablock sizes, the AVX or AVX2 transform function is used
      at run-time as it suits best. The Makefile change therefore appends
      the necessary objects to the linkage. Due to this, the patch merely
      appends AVX2 transform to the existing build mix and Kconfig support
      and leaves the configuration build support as is.
      Signed-off-by: default avatarChandramouli Narayanan <mouli@linux.intel.com>
      Reviewed-by: Marek Vasut's avatarMarek Vasut <marex@denx.de>
      Acked-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      7c1da8d0
  24. 26 Feb, 2014 1 commit
  25. 15 Jan, 2014 1 commit
  26. 31 Dec, 2013 1 commit