Eric Lee / smarc-fsl-linux-kernel

19 Mar, 2021

1 commit

04 Dec, 2020

1 commit

  • 0464e0ef4   crypto: aegis128 - avoid spurious references crypto_aegis128_update_simd ... Browse Code »

    Geert reports that builds where CONFIG_CRYPTO_AEGIS128_SIMD is not set
    may still emit references to crypto_aegis128_update_simd(), which
    cannot be satisfied and therefore break the build. These references
    only exist in functions that can be optimized away, but apparently,
    the compiler is not always able to prove this.

    So add some explicit checks for CONFIG_CRYPTO_AEGIS128_SIMD to help the
    compiler figure this out.

    Tested-by: Geert Uytterhoeven
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     

27 Nov, 2020

3 commits

  • ac50aec41   crypto: aegis128 - expose SIMD code path as separate driver ... Browse Code »

    Wiring the SIMD code into the generic driver has the unfortunate side
    effect that the tcrypt testing code cannot distinguish them, and will
    therefore not use the latter to fuzz test the former, as it does for
    other algorithms.

    So let's refactor the code a bit so we can register two implementations:
    aegis128-generic and aegis128-simd.

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

    Ard Biesheuvel
     
  • 97b70180b   crypto: aegis128/neon - move final tag check to SIMD domain ... Browse Code »

    Instead of calculating the tag and returning it to the caller on
    decryption, use a SIMD compare and min across vector to perform
    the comparison. This is slightly more efficient, and removes the
    need on the caller's part to wipe the tag from memory if the
    decryption failed.

    While at it, switch to unsigned int when passing cryptlen and
    assoclen - we don't support input sizes where it matters anyway.

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

    Ard Biesheuvel
     
  • 02685906d   crypto: aegis128 - wipe plaintext and tag if decryption fails ... Browse Code »

    The AEGIS spec mentions explicitly that the security guarantees hold
    only if the resulting plaintext and tag of a failed decryption are
    withheld. So ensure that we abide by this.

    While at it, drop the unused struct aead_request *req parameter from
    crypto_aegis128_process_crypt().

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

    Ard Biesheuvel
     

09 Jan, 2020

1 commit

  • 674f368a9   crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN ... Browse Code »

    The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to
    make the ->setkey() functions provide more information about errors.

    However, no one actually checks for this flag, which makes it pointless.

    Also, many algorithms fail to set this flag when given a bad length key.
    Reviewing just the generic implementations, this is the case for
    aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309,
    rfc7539, rfc7539esp, salsa20, seqiv, and xcbc. But there are probably
    many more in arch/*/crypto/ and drivers/crypto/.

    Some algorithms can even set this flag when the key is the correct
    length. For example, authenc and authencesn set it when the key payload
    is malformed in any way (not just a bad length), the atmel-sha and ccree
    drivers can set it if a memory allocation fails, and the chelsio driver
    sets it for bad auth tag lengths, not just bad key lengths.

    So even if someone actually wanted to start checking this flag (which
    seems unlikely, since it's been unused for a long time), there would be
    a lot of work needed to get it working correctly. But it would probably
    be much better to go back to the drawing board and just define different
    return values, like -EINVAL if the key is invalid for the algorithm vs.
    -EKEYREJECTED if the key was rejected by a policy like "no weak keys".
    That would be much simpler, less error-prone, and easier to test.

    So just remove this flag.

    Signed-off-by: Eric Biggers
    Reviewed-by: Horia Geantă
    Signed-off-by: Herbert Xu

    Eric Biggers
     

25 Oct, 2019

2 commits

30 Aug, 2019

1 commit

15 Aug, 2019

1 commit

02 Aug, 2019

1 commit

  • c9f1fd4f2   Revert "crypto: aegis128 - add support for SIMD acceleration" ... Browse Code »

    This reverts commit ecc8bc81f2fb3976737ef312f824ba6053aa3590
    ("crypto: aegis128 - provide a SIMD implementation based on NEON
    intrinsics") and commit 7cdc0ddbf74a19cecb2f0e9efa2cae9d3c665189
    ("crypto: aegis128 - add support for SIMD acceleration").

    They cause compile errors on platforms other than ARM because
    the mechanism to selectively compile the SIMD code is broken.

    Repoted-by: Heiko Carstens
    Reported-by: Stephen Rothwell
    Signed-off-by: Herbert Xu

    Herbert Xu
     

26 Jul, 2019

1 commit