30 Aug, 2019

1 commit


27 Jul, 2019

1 commit

  • Clang sometimes makes very different inlining decisions from gcc.
    In case of the aegis crypto algorithms, it decides to turn the innermost
    primitives (and, xor, ...) into separate functions but inline most of
    the rest.

    This results in a huge amount of variables spilled on the stack, leading
    to rather slow execution as well as kernel stack usage beyond the 32-bit
    warning limit when CONFIG_KASAN is enabled:

    crypto/aegis256.c:123:13: warning: stack frame size of 648 bytes in function 'crypto_aegis256_encrypt_chunk' [-Wframe-larger-than=]
    crypto/aegis256.c:366:13: warning: stack frame size of 1264 bytes in function 'crypto_aegis256_crypt' [-Wframe-larger-than=]
    crypto/aegis256.c:187:13: warning: stack frame size of 656 bytes in function 'crypto_aegis256_decrypt_chunk' [-Wframe-larger-than=]
    crypto/aegis128l.c:135:13: warning: stack frame size of 832 bytes in function 'crypto_aegis128l_encrypt_chunk' [-Wframe-larger-than=]
    crypto/aegis128l.c:415:13: warning: stack frame size of 1480 bytes in function 'crypto_aegis128l_crypt' [-Wframe-larger-than=]
    crypto/aegis128l.c:218:13: warning: stack frame size of 848 bytes in function 'crypto_aegis128l_decrypt_chunk' [-Wframe-larger-than=]
    crypto/aegis128.c:116:13: warning: stack frame size of 584 bytes in function 'crypto_aegis128_encrypt_chunk' [-Wframe-larger-than=]
    crypto/aegis128.c:351:13: warning: stack frame size of 1064 bytes in function 'crypto_aegis128_crypt' [-Wframe-larger-than=]
    crypto/aegis128.c:177:13: warning: stack frame size of 592 bytes in function 'crypto_aegis128_decrypt_chunk' [-Wframe-larger-than=]

    Forcing the primitives to all get inlined avoids the issue and the
    resulting code is similar to what gcc produces.

    Signed-off-by: Arnd Bergmann
    Acked-by: Nick Desaulniers
    Signed-off-by: Herbert Xu

    Arnd Bergmann
     

26 Jul, 2019

2 commits

  • Add some plumbing to allow the AEGIS128 code to be built with SIMD
    routines for acceleration.

    Reviewed-by: Ondrej Mosnacek
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     
  • The generic AES code provides four sets of lookup tables, where each
    set consists of four tables containing the same 32-bit values, but
    rotated by 0, 8, 16 and 24 bits, respectively. This makes sense for
    CISC architectures such as x86 which support memory operands, but
    for other architectures, the rotates are quite cheap, and using all
    four tables needlessly thrashes the D-cache, and actually hurts rather
    than helps performance.

    Since x86 already has its own implementation of AEGIS based on AES-NI
    instructions, let's tweak the generic implementation towards other
    architectures, and avoid the prerotated tables, and perform the
    rotations inline. On ARM Cortex-A53, this results in a ~8% speedup.

    Acked-by: Ondrej Mosnacek
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     

25 Jan, 2019

1 commit

  • Precise and non-ambiguous license information is important. The recently
    added aegis header file has a SPDX license identifier, which is nice, but
    at the same time it has a contradictionary license boiler plate text.

    SPDX-License-Identifier: GPL-2.0

    versus

    * 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

    Oh well.

    As the other aegis related files are licensed under the GPL v2 or later,
    it's assumed that the boiler plate code is correct, but the SPDX license
    identifier is wrong.

    Fix the SPDX identifier and remove the boiler plate as it is redundant.

    Fixes: f606a88e5823 ("crypto: aegis - Add generic AEGIS AEAD implementations")
    Signed-off-by: Thomas Gleixner
    Cc: Ondrej Mosnacek
    Cc: Herbert Xu
    Cc: "David S. Miller"
    Cc: linux-crypto@vger.kernel.org
    Acked-by: Ondrej Mosnacek
    Signed-off-by: Herbert Xu

    Thomas Gleixner
     

08 Oct, 2018

1 commit

  • Use the correct __le32 annotation and accessors to perform the
    single round of AES encryption performed inside the AEGIS transform.
    Otherwise, tcrypt reports:

    alg: aead: Test 1 failed on encryption for aegis128-generic
    00000000: 6c 25 25 4a 3c 10 1d 27 2b c1 d4 84 9a ef 7f 6e
    alg: aead: Test 1 failed on encryption for aegis128l-generic
    00000000: cd c6 e3 b8 a0 70 9d 8e c2 4f 6f fe 71 42 df 28
    alg: aead: Test 1 failed on encryption for aegis256-generic
    00000000: aa ed 07 b1 96 1d e9 e6 f2 ed b5 8e 1c 5f dc 1c

    Fixes: f606a88e5823 ("crypto: aegis - Add generic AEGIS AEAD implementations")
    Cc: # v4.18+
    Signed-off-by: Ard Biesheuvel
    Reviewed-by: Ondrej Mosnacek
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     

19 May, 2018

1 commit

  • This patch adds the generic implementation of the AEGIS family of AEAD
    algorithms (AEGIS-128, AEGIS-128L, and AEGIS-256). The original
    authors of AEGIS are Hongjun Wu and Bart Preneel.

    At the time of writing, AEGIS is one of the finalists in CAESAR, an
    open competition intended to select a portfolio of alternatives to
    the problematic AES-GCM:

    https://competitions.cr.yp.to/caesar-submissions.html
    https://competitions.cr.yp.to/round3/aegisv11.pdf

    Signed-off-by: Ondrej Mosnacek
    Signed-off-by: Herbert Xu

    Ondrej Mosnacek