16 Jul, 2020

1 commit

  • The flag CRYPTO_ALG_ASYNC is "inherited" in the sense that when a
    template is instantiated, the template will have CRYPTO_ALG_ASYNC set if
    any of the algorithms it uses has CRYPTO_ALG_ASYNC set.

    We'd like to add a second flag (CRYPTO_ALG_ALLOCATES_MEMORY) that gets
    "inherited" in the same way. This is difficult because the handling of
    CRYPTO_ALG_ASYNC is hardcoded everywhere. Address this by:

    - Add CRYPTO_ALG_INHERITED_FLAGS, which contains the set of flags that
    have these inheritance semantics.

    - Add crypto_algt_inherited_mask(), for use by template ->create()
    methods. It returns any of these flags that the user asked to be
    unset and thus must be passed in the 'mask' to crypto_grab_*().

    - Also modify crypto_check_attr_type() to handle computing the 'mask'
    so that most templates can just use this.

    - Make crypto_grab_*() propagate these flags to the template instance
    being created so that templates don't have to do this themselves.

    Make crypto/simd.c propagate these flags too, since it "wraps" another
    algorithm, similar to a template.

    Based on a patch by Mikulas Patocka
    (https://lore.kernel.org/r/alpine.LRH.2.02.2006301414580.30526@file01.intranet.prod.int.rdu2.redhat.com).

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

    Eric Biggers
     

08 May, 2020

1 commit


29 Jan, 2020

1 commit

  • Pull crypto updates from Herbert Xu:
    "API:
    - Removed CRYPTO_TFM_RES flags
    - Extended spawn grabbing to all algorithm types
    - Moved hash descsize verification into API code

    Algorithms:
    - Fixed recursive pcrypt dead-lock
    - Added new 32 and 64-bit generic versions of poly1305
    - Added cryptogams implementation of x86/poly1305

    Drivers:
    - Added support for i.MX8M Mini in caam
    - Added support for i.MX8M Nano in caam
    - Added support for i.MX8M Plus in caam
    - Added support for A33 variant of SS in sun4i-ss
    - Added TEE support for Raven Ridge in ccp
    - Added in-kernel API to submit TEE commands in ccp
    - Added AMD-TEE driver
    - Added support for BCM2711 in iproc-rng200
    - Added support for AES256-GCM based ciphers for chtls
    - Added aead support on SEC2 in hisilicon"

    * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (244 commits)
    crypto: arm/chacha - fix build failured when kernel mode NEON is disabled
    crypto: caam - add support for i.MX8M Plus
    crypto: x86/poly1305 - emit does base conversion itself
    crypto: hisilicon - fix spelling mistake "disgest" -> "digest"
    crypto: chacha20poly1305 - add back missing test vectors and test chunking
    crypto: x86/poly1305 - fix .gitignore typo
    tee: fix memory allocation failure checks on drv_data and amdtee
    crypto: ccree - erase unneeded inline funcs
    crypto: ccree - make cc_pm_put_suspend() void
    crypto: ccree - split overloaded usage of irq field
    crypto: ccree - fix PM race condition
    crypto: ccree - fix FDE descriptor sequence
    crypto: ccree - cc_do_send_request() is void func
    crypto: ccree - fix pm wrongful error reporting
    crypto: ccree - turn errors to debug msgs
    crypto: ccree - fix AEAD decrypt auth fail
    crypto: ccree - fix typo in comment
    crypto: ccree - fix typos in error msgs
    crypto: atmel-{aes,sha,tdes} - Retire crypto_platform_data
    crypto: x86/sha - Eliminate casts on asm implementations
    ...

    Linus Torvalds
     

09 Jan, 2020

4 commits

  • Initializing a crypto_aead_spawn currently requires:

    1. Set spawn->base.inst to point to the instance.
    2. Call crypto_grab_aead().

    But there's no reason for these steps to be separate, and in fact this
    unneeded complication has caused at least one bug, the one fixed by
    commit 6db43410179b ("crypto: adiantum - initialize crypto_spawn::inst")

    So just make crypto_grab_aead() take the instance as an argument.

    To keep the function calls from getting too unwieldy due to this extra
    argument, also introduce a 'mask' variable into the affected places
    which weren't already using one.

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

    Eric Biggers
     
  • Initializing a crypto_skcipher_spawn currently requires:

    1. Set spawn->base.inst to point to the instance.
    2. Call crypto_grab_skcipher().

    But there's no reason for these steps to be separate, and in fact this
    unneeded complication has caused at least one bug, the one fixed by
    commit 6db43410179b ("crypto: adiantum - initialize crypto_spawn::inst")

    So just make crypto_grab_skcipher() take the instance as an argument.

    To keep the function calls from getting too unwieldy due to this extra
    argument, also introduce a 'mask' variable into the affected places
    which weren't already using one.

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

    Eric Biggers
     
  • The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the
    ->setkey() functions provide more information about errors. But these
    flags weren't actually being used or tested, and in many cases they
    weren't being set correctly anyway. So they've now been removed.

    Also, if someone ever actually needs to start better distinguishing
    ->setkey() errors (which is somewhat unlikely, as this has been unneeded
    for a long time), we'd be much better off just defining 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 CRYPTO_TFM_RES_MASK and all the unneeded logic that
    propagates these flags around.

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

    Eric Biggers
     
  • 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
     

11 Dec, 2019

1 commit

  • The essiv and hmac templates refuse to use any hash algorithm that has a
    ->setkey() function, which includes not just algorithms that always need
    a key, but also algorithms that optionally take a key.

    Previously the only optionally-keyed hash algorithms in the crypto API
    were non-cryptographic algorithms like crc32, so this didn't really
    matter. But that's changed with BLAKE2 support being added. BLAKE2
    should work with essiv and hmac, just like any other cryptographic hash.

    Fix this by allowing the use of both algorithms without a ->setkey()
    function and algorithms that have the OPTIONAL_KEY flag set.

    Signed-off-by: Eric Biggers
    Acked-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Eric Biggers
     

10 Dec, 2019

1 commit

  • Replace all the occurrences of FIELD_SIZEOF() with sizeof_field() except
    at places where these are defined. Later patches will remove the unused
    definition of FIELD_SIZEOF().

    This patch is generated using following script:

    EXCLUDE_FILES="include/linux/stddef.h|include/linux/kernel.h"

    git grep -l -e "\bFIELD_SIZEOF\b" | while read file;
    do

    if [[ "$file" =~ $EXCLUDE_FILES ]]; then
    continue
    fi
    sed -i -e 's/\bFIELD_SIZEOF\b/sizeof_field/g' $file;
    done

    Signed-off-by: Pankaj Bharadiya
    Link: https://lore.kernel.org/r/20190924105839.110713-3-pankaj.laxminarayan.bharadiya@intel.com
    Co-developed-by: Kees Cook
    Signed-off-by: Kees Cook
    Acked-by: David Miller # for net

    Pankaj Bharadiya
     

22 Nov, 2019

1 commit


01 Nov, 2019

1 commit

  • Now that all "blkcipher" algorithms have been converted to "skcipher",
    remove the blkcipher algorithm type.

    The skcipher (symmetric key cipher) algorithm type was introduced a few
    years ago to replace both blkcipher and ablkcipher (synchronous and
    asynchronous block cipher). The advantages of skcipher include:

    - A much less confusing name, since none of these algorithm types have
    ever actually been for raw block ciphers, but rather for all
    length-preserving encryption modes including block cipher modes of
    operation, stream ciphers, and other length-preserving modes.

    - It unified blkcipher and ablkcipher into a single algorithm type
    which supports both synchronous and asynchronous implementations.
    Note, blkcipher already operated only on scatterlists, so the fact
    that skcipher does too isn't a regression in functionality.

    - Better type safety by using struct skcipher_alg, struct
    crypto_skcipher, etc. instead of crypto_alg, crypto_tfm, etc.

    - It sometimes simplifies the implementations of algorithms.

    Also, the blkcipher API was no longer being tested.

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

    Eric Biggers
     

04 Sep, 2019

1 commit

  • Implement a template that wraps a (skcipher,shash) or (aead,shash) tuple
    so that we can consolidate the ESSIV handling in fscrypt and dm-crypt and
    move it into the crypto API. This will result in better test coverage, and
    will allow future changes to make the bare cipher interface internal to the
    crypto subsystem, in order to increase robustness of the API against misuse.

    Signed-off-by: Ard Biesheuvel
    Acked-by: Herbert Xu
    Tested-by: Milan Broz
    Signed-off-by: Mike Snitzer

    Ard Biesheuvel