Eric Lee / smarc-fsl-linux-kernel

10 Apr, 2015

1 commit

  • ca142584b   crypto: sha512-generic - move to generic glue implementation ... Browse Code »

    This updated the generic SHA-512 implementation to use the
    generic shared SHA-512 glue code.

    It also implements a .finup hook crypto_sha512_finup() and exports
    it to other modules. The import and export() functions and the
    .statesize member are dropped, since the default implementation
    is perfectly suitable for this module.

    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     

13 Jan, 2015

1 commit

  • 3e14dcf7c   crypto: add missing crypto module aliases ... Browse Code »

    Commit 5d26a105b5a7 ("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 5d26a105b5a7 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: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
    Cc: Kees Cook
    Signed-off-by: Mathias Krause
    Signed-off-by: Herbert Xu

    Mathias Krause
     

24 Nov, 2014

1 commit

25 Oct, 2014

1 commit

17 Oct, 2014

1 commit

  • 7185ad267   crypto: memzero_explicit - make sure to clear out sensitive data ... Browse Code »

    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: Daniel Borkmann
    Cc: Julia Lawall
    Cc: Herbert Xu
    Cc: Theodore Ts'o
    Cc: Hannes Frederic Sowa
    Acked-by: Hannes Frederic Sowa
    Acked-by: Herbert Xu
    Signed-off-by: Theodore Ts'o

    Daniel Borkmann
     

02 Oct, 2014

1 commit

28 May, 2013

1 commit

25 Apr, 2013

1 commit

01 Aug, 2012

1 commit

05 Apr, 2012

1 commit

  • 25c3d30c9   crypto: sha512 - Fix byte counter overflow in SHA-512 ... Browse Code »
    1

    The current code only increments the upper 64 bits of the SHA-512 byte
    counter when the number of bytes hashed happens to hit 2^64 exactly.

    This patch increments the upper 64 bits whenever the lower 64 bits
    overflows.

    Signed-off-by: Kent Yoder
    Cc: stable@kernel.org
    Signed-off-by: Herbert Xu

    Kent Yoder
     

16 Feb, 2012

1 commit

  • f2ea0f5f0   crypto: sha512 - use standard ror64() ... Browse Code »
    1

    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: Alexey Dobriyan
    Signed-off-by: Herbert Xu

    Alexey Dobriyan
     

05 Feb, 2012

1 commit

  • 3a92d687c   crypto: sha512 - Avoid stack bloat on i386 ... Browse Code »
    1

    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: Herbert Xu

    Herbert Xu
     

26 Jan, 2012

1 commit

15 Jan, 2012

2 commits

  • 51fc6dc8f   crypto: sha512 - reduce stack usage to safe number ... Browse Code »
    1

    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.pdf

    Signed-off-by: Alexey Dobriyan
    Cc: stable@vger.kernel.org
    Signed-off-by: Herbert Xu

    Alexey Dobriyan
     
  • 84e31fdb7   crypto: sha512 - make it work, undo percpu message schedule ... Browse Code »
    1

    commit f9e2bca6c22d75a289a349f869701214d63b5060
    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: Alexey Dobriyan
    Cc: stable@vger.kernel.org
    Signed-off-by: Herbert Xu

    Alexey Dobriyan
     

22 Jul, 2009

2 commits

25 Dec, 2008

2 commits

21 Apr, 2008

2 commits

  • 3af5b90bd   [CRYPTO] all: Clean up init()/fini() ... Browse Code »

    On Thu, Mar 27, 2008 at 03:40:36PM +0100, Bodo Eggert wrote:
    > Kamalesh Babulal wrote:
    >
    > > This patch cleanups the crypto code, replaces the init() and fini()
    > > with the _init/_fini
    >
    > This part ist OK.
    >
    > > or init/fini_ (if the
    > > _init/_fini exist)
    >
    > Having init_foo and foo_init won't be a good thing, will it? I'd start
    > confusing them.
    >
    > What about foo_modinit instead?

    Thanks for the suggestion, the init() is replaced with

    _mod_init ()

    and fini () is replaced with _mod_fini.

    Signed-off-by: Kamalesh Babulal
    Signed-off-by: Herbert Xu

    Kamalesh Babulal
     
  • 78f8b3a24   [CRYPTO] sha512: Rename sha512 to sha512_generic ... Browse Code »

    Rename sha512 to sha512_generic and add a MODULE_ALIAS for sha512
    so all sha512 implementations can be loaded automatically.

    Keep the broken tabs so git recognizes this as a rename.

    Signed-off-by: Jan Glauber
    Signed-off-by: Herbert Xu

    Jan Glauber