15 Nov, 2019

1 commit


09 Jul, 2019

1 commit

  • Pull crypto updates from Herbert Xu:
    "Here is the crypto update for 5.3:

    API:
    - Test shash interface directly in testmgr
    - cra_driver_name is now mandatory

    Algorithms:
    - Replace arc4 crypto_cipher with library helper
    - Implement 5 way interleave for ECB, CBC and CTR on arm64
    - Add xxhash
    - Add continuous self-test on noise source to drbg
    - Update jitter RNG

    Drivers:
    - Add support for SHA204A random number generator
    - Add support for 7211 in iproc-rng200
    - Fix fuzz test failures in inside-secure
    - Fix fuzz test failures in talitos
    - Fix fuzz test failures in qat"

    * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (143 commits)
    crypto: stm32/hash - remove interruptible condition for dma
    crypto: stm32/hash - Fix hmac issue more than 256 bytes
    crypto: stm32/crc32 - rename driver file
    crypto: amcc - remove memset after dma_alloc_coherent
    crypto: ccp - Switch to SPDX license identifiers
    crypto: ccp - Validate the the error value used to index error messages
    crypto: doc - Fix formatting of new crypto engine content
    crypto: doc - Add parameter documentation
    crypto: arm64/aes-ce - implement 5 way interleave for ECB, CBC and CTR
    crypto: arm64/aes-ce - add 5 way interleave routines
    crypto: talitos - drop icv_ool
    crypto: talitos - fix hash on SEC1.
    crypto: talitos - move struct talitos_edesc into talitos.h
    lib/scatterlist: Fix mapping iterator when sg->offset is greater than PAGE_SIZE
    crypto/NX: Set receive window credits to max number of CRBs in RxFIFO
    crypto: asymmetric_keys - select CRYPTO_HASH where needed
    crypto: serpent - mark __serpent_setkey_sbox noinline
    crypto: testmgr - dynamically allocate crypto_shash
    crypto: testmgr - dynamically allocate testvec_config
    crypto: talitos - eliminate unneeded 'done' functions at build time
    ...

    Linus Torvalds
     

13 Jun, 2019

1 commit

  • Most generic crypto algorithms declare a driver name ending in
    "-generic". The rest don't declare a driver name and instead rely on
    the crypto API automagically appending "-generic" upon registration.

    Having multiple conventions is unnecessarily confusing and makes it
    harder to grep for all generic algorithms in the kernel source tree.
    But also, allowing NULL driver names is problematic because sometimes
    people fail to set it, e.g. the case fixed by commit 417980364300
    ("crypto: cavium/zip - fix collision with generic cra_driver_name").

    Of course, people can also incorrectly name their drivers "-generic".
    But that's much easier to notice / grep for.

    Therefore, let's make cra_driver_name mandatory. In preparation for
    this, this patch makes all generic algorithms set cra_driver_name.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

18 Apr, 2019

1 commit

  • Use subsys_initcall for registration of all templates and generic
    algorithm implementations, rather than module_init. Then change
    cryptomgr to use arch_initcall, to place it before the subsys_initcalls.

    This is needed so that when both a generic and optimized implementation
    of an algorithm are built into the kernel (not loadable modules), the
    generic implementation is registered before the optimized one.
    Otherwise, the self-tests for the optimized implementation are unable to
    allocate the generic implementation for the new comparison fuzz tests.

    Note that on arm, a side effect of this change is that self-tests for
    generic implementations may run before the unaligned access handler has
    been installed. So, unaligned accesses will crash the kernel. This is
    arguably a good thing as it makes it easier to detect that type of bug.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

18 Jan, 2019

1 commit


09 Jul, 2018

1 commit

  • Many shash algorithms set .cra_flags = CRYPTO_ALG_TYPE_SHASH. But this
    is redundant with the C structure type ('struct shash_alg'), and
    crypto_register_shash() already sets the type flag automatically,
    clearing any type flag that was already there. Apparently the useless
    assignment has just been copy+pasted around.

    So, remove the useless assignment from all the shash algorithms.

    This patch shouldn't change any actual behavior.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

13 Jan, 2015

1 commit

  • 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


17 Oct, 2014

1 commit

  • 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
     

01 Aug, 2012

1 commit


25 Dec, 2008

1 commit


21 Apr, 2008

1 commit

  • 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
     

02 Nov, 2007

1 commit


26 Jun, 2006

3 commits

  • Up until now algorithms have been happy to get a context pointer since
    they know everything that's in the tfm already (e.g., alignment, block
    size).

    However, once we have parameterised algorithms, such information will
    be specific to each tfm. So the algorithm API needs to be changed to
    pass the tfm structure instead of the context pointer.

    This patch is basically a text substitution. The only tricky bit is
    the assembly routines that need to get the context pointer offset
    through asm-offsets.h.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • Various digest algorithms operate one block at a time and therefore
    keep a temporary buffer of partial blocks. This buffer does not need
    to be initialised since there is a counter which indicates what is and
    isn't valid in it.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • Some hash modules load/store data words directly. The digest layer
    should pass properly aligned buffer to update()/final() method. This
    patch also add cra_alignmask to some hash modules.

    Signed-off-by: Atsushi Nemoto
    Signed-off-by: Herbert Xu

    Atsushi Nemoto
     

10 Jan, 2006

1 commit

  • A lot of crypto code needs to read/write a 32-bit/64-bit words in a
    specific gender. Many of them open code them by reading/writing one
    byte at a time. This patch converts all the applicable usages over
    to use the standard byte order macros.

    This is based on a previous patch by Denis Vlasenko.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

17 Apr, 2005

1 commit

  • 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!

    Linus Torvalds