05 Jul, 2019

3 commits


18 Apr, 2019

3 commits

  • Generic GCM is likely to end up using a hardware accelerator to do
    part of the job. Allocating hash, iv and result in a contiguous memory
    area increases the risk of dma mapping multiple ranges on the same
    cacheline. Also having dma and cpu written data on the same cacheline
    will cause coherence issues.

    Signed-off-by: Franck LENORMAND
    (cherry picked from commit 03d7978eea76a53e5e964d67898e10d143ddb83d)
    Signed-off-by: Vipul Kumar

    Franck LENORMAND
     
  • As per commit 76c6739477fa ("crypto: gcm - move to generic async
    completion"), make changes to fix the below compilation error.

    crypto/gcm.c: In function ‘crypto_gcm_setkey’:
    crypto/gcm.c:107:35: error: field ‘result’ has incomplete type
    struct crypto_gcm_setkey_result result ____cacheline_aligned;
    ^~~~~~
    scripts/Makefile.build:303: recipe for target 'crypto/gcm.o' failed
    make[1]: *** [crypto/gcm.o] Error 1
    Makefile:1052: recipe for target 'crypto' failed

    Signed-off-by: Vipul Kumar

    Vipul Kumar
     
  • CAAM uses DMA to transfer data to and from memory, if
    DMA and CPU accessed data share the same cacheline cache
    pollution will occur. Marking the result as cacheline aligned
    moves it to a separate cache line.

    Signed-off-by: Radu Solea
    (Vipul: Fixed merge conflicts)
    Signed-off-by: Vipul Kumar

    Radu Solea
     

22 Dec, 2017

1 commit


03 Nov, 2017

1 commit


22 Sep, 2017

1 commit


23 May, 2017

1 commit

  • crypto_gcm_setkey() was using wait_for_completion_interruptible() to
    wait for completion of async crypto op but if a signal occurs it
    may return before DMA ops of HW crypto provider finish, thus
    corrupting the data buffer that is kfree'ed in this case.

    Resolve this by using wait_for_completion() instead.

    Reported-by: Eric Biggers
    Signed-off-by: Gilad Ben-Yossef
    CC: stable@vger.kernel.org
    Signed-off-by: Herbert Xu

    Gilad Ben-Yossef
     

01 Nov, 2016

2 commits


25 Oct, 2016

1 commit


02 Oct, 2016

1 commit

  • The cipher block size for GCM is 16 bytes, and thus the CTR transform
    used in crypto_gcm_setkey() will also expect a 16-byte IV. However,
    the code currently reserves only 8 bytes for the IV, causing
    an out-of-bounds access in the CTR transform. This patch fixes
    the issue by setting the size of the IV buffer to 16 bytes.

    Fixes: 84c911523020 ("[CRYPTO] gcm: Add support for async ciphers")
    Signed-off-by: Ondrej Mosnacek
    Signed-off-by: Herbert Xu

    Ondrej Mosnáček
     

18 Jul, 2016

1 commit


20 Jun, 2016

1 commit


03 Sep, 2015

1 commit

  • Pull SG updates from Jens Axboe:
    "This contains a set of scatter-gather related changes/fixes for 4.3:

    - Add support for limited chaining of sg tables even for
    architectures that do not set ARCH_HAS_SG_CHAIN. From Christoph.

    - Add sg chain support to target_rd. From Christoph.

    - Fixup open coded sg->page_link in crypto/omap-sham. From
    Christoph.

    - Fixup open coded crypto ->page_link manipulation. From Dan.

    - Also from Dan, automated fixup of manual sg_unmark_end()
    manipulations.

    - Also from Dan, automated fixup of open coded sg_phys()
    implementations.

    - From Robert Jarzmik, addition of an sg table splitting helper that
    drivers can use"

    * 'for-4.3/sg' of git://git.kernel.dk/linux-block:
    lib: scatterlist: add sg splitting function
    scatterlist: use sg_phys()
    crypto/omap-sham: remove an open coded access to ->page_link
    scatterlist: remove open coded sg_unmark_end instances
    crypto: replace scatterwalk_sg_chain with sg_chain
    target/rd: always chain S/G list
    scatterlist: allow limited chaining without ARCH_HAS_SG_CHAIN

    Linus Torvalds
     

17 Aug, 2015

2 commits


14 Jul, 2015

1 commit

  • This patch converts rfc4106 to the new calling convention where
    the IV is now part of the AD and needs to be skipped. This patch
    also makes use of the new type-safe way of freeing instances.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

17 Jun, 2015

1 commit

  • This patch converts generic gcm and its associated transforms to
    the new AEAD interface. The biggest reward is in code reduction
    for rfc4543 where it used to do IV stitching which is no longer
    needed as the IV is already part of the AD on input.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

22 May, 2015

1 commit


13 May, 2015

1 commit


26 Nov, 2014

1 commit

  • This adds the module loading prefix "crypto-" to the template lookup
    as well.

    For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
    includes the "crypto-" prefix at every level, correctly rejecting "vfat":

    net-pf-38
    algif-hash
    crypto-vfat(blowfish)
    crypto-vfat(blowfish)-all
    crypto-vfat

    Reported-by: Mathias Krause
    Signed-off-by: Kees Cook
    Acked-by: Mathias Krause
    Signed-off-by: Herbert Xu

    Kees Cook
     

24 Nov, 2014

1 commit


01 Aug, 2014

1 commit


07 Oct, 2013

1 commit

  • When comparing MAC hashes, AEAD authentication tags, or other hash
    values in the context of authentication or integrity checking, it
    is important not to leak timing information to a potential attacker,
    i.e. when communication happens over a network.

    Bytewise memory comparisons (such as memcmp) are usually optimized so
    that they return a nonzero value as soon as a mismatch is found. E.g,
    on x86_64/i5 for 512 bytes this can be ~50 cyc for a full mismatch
    and up to ~850 cyc for a full match (cold). This early-return behavior
    can leak timing information as a side channel, allowing an attacker to
    iteratively guess the correct result.

    This patch adds a new method crypto_memneq ("memory not equal to each
    other") to the crypto API that compares memory areas of the same length
    in roughly "constant time" (cache misses could change the timing, but
    since they don't reveal information about the content of the strings
    being compared, they are effectively benign). Iow, best and worst case
    behaviour take the same amount of time to complete (in contrast to
    memcmp).

    Note that crypto_memneq (unlike memcmp) can only be used to test for
    equality or inequality, NOT for lexicographical order. This, however,
    is not an issue for its use-cases within the crypto API.

    We tried to locate all of the places in the crypto API where memcmp was
    being used for authentication or integrity checking, and convert them
    over to crypto_memneq.

    crypto_memneq is declared noinline, placed in its own source file,
    and compiled with optimizations that might increase code size disabled
    ("Os") because a smart compiler (or LTO) might notice that the return
    value is always compared against zero/nonzero, and might then
    reintroduce the same early-return optimization that we are trying to
    avoid.

    Using #pragma or __attribute__ optimization annotations of the code
    for disabling optimization was avoided as it seems to be considered
    broken or unmaintained for long time in GCC [1]. Therefore, we work
    around that by specifying the compile flag for memneq.o directly in
    the Makefile. We found that this seems to be most appropriate.

    As we use ("Os"), this patch also provides a loop-free "fast-path" for
    frequently used 16 byte digests. Similarly to kernel library string
    functions, leave an option for future even further optimized architecture
    specific assembler implementations.

    This was a joint work of James Yonan and Daniel Borkmann. Also thanks
    for feedback from Florian Weimer on this and earlier proposals [2].

    [1] http://gcc.gnu.org/ml/gcc/2012-07/msg00211.html
    [2] https://lkml.org/lkml/2013/2/10/131

    Signed-off-by: James Yonan
    Signed-off-by: Daniel Borkmann
    Cc: Florian Weimer
    Signed-off-by: Herbert Xu

    James Yonan
     

03 May, 2013

1 commit

  • Pull crypto update from Herbert Xu:

    - XTS mode optimisation for twofish/cast6/camellia/aes on x86

    - AVX2/x86_64 implementation for blowfish/twofish/serpent/camellia

    - SSSE3/AVX/AVX2 optimisations for sha256/sha512

    - Added driver for SAHARA2 crypto accelerator

    - Fix for GMAC when used in non-IPsec secnarios

    - Added generic CMAC implementation (including IPsec glue)

    - IP update for crypto/atmel

    - Support for more than one device in hwrng/timeriomem

    - Added Broadcom BCM2835 RNG driver

    - Misc fixes

    * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (59 commits)
    crypto: caam - fix job ring cleanup code
    crypto: camellia - add AVX2/AES-NI/x86_64 assembler implementation of camellia cipher
    crypto: serpent - add AVX2/x86_64 assembler implementation of serpent cipher
    crypto: twofish - add AVX2/x86_64 assembler implementation of twofish cipher
    crypto: blowfish - add AVX2/x86_64 implementation of blowfish cipher
    crypto: tcrypt - add async cipher speed tests for blowfish
    crypto: testmgr - extend camellia test-vectors for camellia-aesni/avx2
    crypto: aesni_intel - fix Kconfig problem with CRYPTO_GLUE_HELPER_X86
    crypto: aesni_intel - add more optimized XTS mode for x86-64
    crypto: x86/camellia-aesni-avx - add more optimized XTS code
    crypto: cast6-avx: use new optimized XTS code
    crypto: x86/twofish-avx - use optimized XTS code
    crypto: x86 - add more optimized XTS-mode for serpent-avx
    xfrm: add rfc4494 AES-CMAC-96 support
    crypto: add CMAC support to CryptoAPI
    crypto: testmgr - add empty test vectors for null ciphers
    crypto: testmgr - add AES GMAC test vectors
    crypto: gcm - fix rfc4543 to handle async crypto correctly
    crypto: gcm - make GMAC work when dst and src are different
    hwrng: timeriomem - added devicetree hooks
    ...

    Linus Torvalds
     

25 Apr, 2013

2 commits


02 Apr, 2013

1 commit

  • rfc4543(gcm(*)) code for GMAC assumes that assoc scatterlist always contains
    only one segment and only makes use of this first segment. However ipsec passes
    assoc with three segments when using 'extended sequence number' thus in this
    case rfc4543(gcm(*)) fails to function correctly. Patch fixes this issue.

    Reported-by: Chaoxing Lin
    Tested-by: Chaoxing Lin
    Cc: stable@vger.kernel.org
    Signed-off-by: Jussi Kivilinna
    Signed-off-by: Herbert Xu

    Jussi Kivilinna
     

04 Feb, 2013

1 commit

  • Replace PTR_ERR followed by ERR_PTR by ERR_CAST, to be more concise.

    The semantic patch that makes this change is as follows:
    (http://coccinelle.lip6.fr/)

    //
    @@
    expression err,x;
    @@
    - err = PTR_ERR(x);
    if (IS_ERR(x))
    - return ERR_PTR(err);
    + return ERR_CAST(x);
    //

    Signed-off-by: Julia Lawall
    Signed-off-by: Herbert Xu

    Julia Lawall
     

02 Dec, 2010

1 commit


17 Jan, 2010

1 commit

  • This patch adds the RFC4543 (GMAC) wrapper for GCM similar to the
    existing RFC4106 wrapper. The main differences between GCM and GMAC are
    the contents of the AAD and that the plaintext is empty for the latter.

    Signed-off-by: Tobias Brunner
    Signed-off-by: Herbert Xu

    Tobias Brunner
     

16 Nov, 2009

1 commit

  • The flow of the complete function (xxx_done) in gcm.c is as follow:

    void complete(struct crypto_async_request *areq, int err)
    {
    struct aead_request *req = areq->data;

    if (!err) {
    err = async_next_step();
    if (err == -EINPROGRESS || err == -EBUSY)
    return;
    }

    complete_for_next_step(areq, err);
    }

    But *areq may be destroyed in async_next_step(), this makes
    complete_for_next_step() can not work properly. To fix this, one of
    following methods is used for each complete function.

    - Add a __complete() for each complete(), which accept struct
    aead_request *req instead of areq, so avoid using areq after it is
    destroyed.

    - Expand complete_for_next_step().

    The fixing method is based on the idea of Herbert Xu.

    Signed-off-by: Huang Ying
    Signed-off-by: Herbert Xu

    Huang Ying
     

06 Aug, 2009

1 commit

  • Remove the dedicated GHASH implementation in GCM, and uses the GHASH
    digest algorithm instead. This will make GCM uses hardware accelerated
    GHASH implementation automatically if available.

    ahash instead of shash interface is used, because some hardware
    accelerated GHASH implementation needs asynchronous interface.

    Signed-off-by: Huang Ying
    Signed-off-by: Herbert Xu

    Huang Ying
     

11 Jan, 2008

4 commits