1. 10 Apr, 2015 1 commit
  2. 13 Jan, 2015 1 commit
    • 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: 's avatarMathias Krause <minipli@googlemail.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      3e14dcf7
  3. 24 Nov, 2014 1 commit
  4. 17 Oct, 2014 1 commit
    • Daniel Borkmann's avatar
      crypto: memzero_explicit - make sure to clear out sensitive data · 7185ad26
      Daniel Borkmann authored
      Recently, in commit 13aa93c70e71 ("random: add and use memzero_explicit()
      for clearing data"), we have found that GCC may optimize some memset()
      cases away when it detects a stack variable is not being used anymore
      and going out of scope. This can happen, for example, in cases when we
      are clearing out sensitive information such as keying material or any
      e.g. intermediate results from crypto computations, etc.
      
      With the help of Coccinelle, we can figure out and fix such occurences
      in the crypto subsytem as well. Julia Lawall provided the following
      Coccinelle program:
      
        @@
        type T;
        identifier x;
        @@
      
        T x;
        ... when exists
            when any
        -memset
        +memzero_explicit
           (&x,
        -0,
           ...)
        ... when != x
            when strict
      
        @@
        type T;
        identifier x;
        @@
      
        T x[...];
        ... when exists
            when any
        -memset
        +memzero_explicit
           (x,
        -0,
           ...)
        ... when != x
            when strict
      
      Therefore, make use of the drop-in replacement memzero_explicit() for
      exactly such cases instead of using memset().
      Signed-off-by: 's avatarDaniel Borkmann <dborkman@redhat.com>
      Cc: Julia Lawall <julia.lawall@lip6.fr>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: 's avatarHannes Frederic Sowa <hannes@stressinduktion.org>
      Acked-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: 's avatarTheodore Ts'o <tytso@mit.edu>
      7185ad26
  5. 02 Oct, 2014 1 commit
  6. 28 May, 2013 1 commit
  7. 25 Apr, 2013 1 commit
  8. 01 Aug, 2012 1 commit
  9. 05 Apr, 2012 1 commit
  10. 16 Feb, 2012 1 commit
  11. 05 Feb, 2012 1 commit
    • Herbert Xu's avatar
      crypto: sha512 - Avoid stack bloat on i386 · 3a92d687
      Herbert Xu authored
      Unfortunately in reducing W from 80 to 16 we ended up unrolling
      the loop twice.  As gcc has issues dealing with 64-bit ops on
      i386 this means that we end up using even more stack space (>1K).
      
      This patch solves the W reduction by moving LOAD_OP/BLEND_OP
      into the loop itself, thus avoiding the need to duplicate it.
      
      While the stack space still isn't great (>0.5K) it is at least
      in the same ball park as the amount of stack used for our C sha1
      implementation.
      
      Note that this patch basically reverts to the original code so
      the diff looks bigger than it really is.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      3a92d687
  12. 26 Jan, 2012 1 commit
  13. 15 Jan, 2012 3 commits
    • Alexey Dobriyan's avatar
      crypto: sha512 - use standard ror64() · b85a088f
      Alexey Dobriyan authored
      Use standard ror64() instead of hand-written.
      There is no standard ror64, so create it.
      
      The difference is shift value being "unsigned int" instead of uint64_t
      (for which there is no reason). gcc starts to emit native ROR instructions
      which it doesn't do for some reason currently. This should make the code
      faster.
      
      Patch survives in-tree crypto test and ping flood with hmac(sha512) on.
      Signed-off-by: 's avatarAlexey Dobriyan <adobriyan@gmail.com>
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      b85a088f
    • Alexey Dobriyan's avatar
      crypto: sha512 - reduce stack usage to safe number · 51fc6dc8
      Alexey Dobriyan authored
      For rounds 16--79, W[i] only depends on W[i - 2], W[i - 7], W[i - 15] and W[i - 16].
      Consequently, keeping all W[80] array on stack is unnecessary,
      only 16 values are really needed.
      
      Using W[16] instead of W[80] greatly reduces stack usage
      (~750 bytes to ~340 bytes on x86_64).
      
      Line by line explanation:
      * BLEND_OP
        array is "circular" now, all indexes have to be modulo 16.
        Round number is positive, so remainder operation should be
        without surprises.
      
      * initial full message scheduling is trimmed to first 16 values which
        come from data block, the rest is calculated before it's needed.
      
      * original loop body is unrolled version of new SHA512_0_15 and
        SHA512_16_79 macros, unrolling was done to not do explicit variable
        renaming. Otherwise it's the very same code after preprocessing.
        See sha1_transform() code which does the same trick.
      
      Patch survives in-tree crypto test and original bugreport test
      (ping flood with hmac(sha512).
      
      See FIPS 180-2 for SHA-512 definition
      http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdfSigned-off-by: 's avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      51fc6dc8
    • Alexey Dobriyan's avatar
      crypto: sha512 - make it work, undo percpu message schedule · 84e31fdb
      Alexey Dobriyan authored
      commit f9e2bca6
      aka "crypto: sha512 - Move message schedule W[80] to static percpu area"
      created global message schedule area.
      
      If sha512_update will ever be entered twice, hash will be silently
      calculated incorrectly.
      
      Probably the easiest way to notice incorrect hashes being calculated is
      to run 2 ping floods over AH with hmac(sha512):
      
      	#!/usr/sbin/setkey -f
      	flush;
      	spdflush;
      	add IP1 IP2 ah 25 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000025;
      	add IP2 IP1 ah 52 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000052;
      	spdadd IP1 IP2 any -P out ipsec ah/transport//require;
      	spdadd IP2 IP1 any -P in  ipsec ah/transport//require;
      
      XfrmInStateProtoError will start ticking with -EBADMSG being returned
      from ah_input(). This never happens with, say, hmac(sha1).
      
      With patch applied (on BOTH sides), XfrmInStateProtoError does not tick
      with multiple bidirectional ping flood streams like it doesn't tick
      with SHA-1.
      
      After this patch sha512_transform() will start using ~750 bytes of stack on x86_64.
      This is OK for simple loads, for something more heavy, stack reduction will be done
      separatedly.
      Signed-off-by: 's avatarAlexey Dobriyan <adobriyan@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: 's avatarHerbert Xu <herbert@gondor.apana.org.au>
      84e31fdb
  14. 22 Jul, 2009 2 commits
  15. 25 Dec, 2008 2 commits
  16. 21 Apr, 2008 2 commits
  17. 02 Nov, 2007 1 commit
  18. 10 Oct, 2007 1 commit
  19. 11 Dec, 2006 1 commit
  20. 26 Jun, 2006 3 commits
  21. 09 Jan, 2006 1 commit
  22. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4