1. 09 Jan, 2020 12 commits
    • Gary R Hook's avatar
      crypto: ccp - Update MAINTAINERS for CCP driver · e91e785e
      Gary R Hook authored
      Remove Gary R Hook as CCP maintainer.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      e91e785e
    • Christian Lamparter's avatar
      crypto: crypto4xx - use GFP_KERNEL for big allocations · 30a50e44
      Christian Lamparter authored
      The driver should use GFP_KERNEL for the bigger allocation
      during the driver's crypto4xx_probe() and not GFP_ATOMIC in
      my opinion.
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      30a50e44
    • Christian Lamparter's avatar
      crypto: crypto4xx - reduce memory fragmentation · b87b2c4d
      Christian Lamparter authored
      With recent kernels (>5.2), the driver fails to probe, as the
      allocation of the driver's scatter buffer fails with -ENOMEM.
      
      This happens in crypto4xx_build_sdr(). Where the driver tries
      to get 512KiB (=PPC4XX_SD_BUFFER_SIZE * PPC4XX_NUM_SD) of
      continuous memory. This big chunk is by design, since the driver
      uses this circumstance in the crypto4xx_copy_pkt_to_dst() to
      its advantage:
      "all scatter-buffers are all neatly organized in one big
      continuous ringbuffer; So scatterwalk_map_and_copy() can be
      instructed to copy a range of buffers in one go."
      
      The PowerPC arch does not have support for DMA_CMA. Hence,
      this patch reorganizes the order in which the memory
      allocations are done. Since the driver itself is responsible
      for some of the issues.
      Signed-off-by: default avatarChristian Lamparter <chunkeey@gmail.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      b87b2c4d
    • Eric Biggers's avatar
      crypto: remove propagation of CRYPTO_TFM_RES_* flags · af5034e8
      Eric Biggers authored
      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: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      af5034e8
    • Eric Biggers's avatar
      crypto: remove CRYPTO_TFM_RES_WEAK_KEY · c4c4db0d
      Eric Biggers authored
      The CRYPTO_TFM_RES_WEAK_KEY 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.
      There are also no tests that verify that all algorithms actually set (or
      don't set) it correctly.
      
      This is also the last remaining CRYPTO_TFM_RES_* flag, which means that
      it's the only thing still needing all the boilerplate code which
      propagates these flags around from child => parent tfms.
      
      And if someone ever needs to distinguish this error in the future (which
      is somewhat unlikely, as it's been unneeded for a long time), it would
      be much better to just define a new return value like -EKEYREJECTED.
      That would be much simpler, less error-prone, and easier to test.
      
      So just remove this flag.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c4c4db0d
    • Eric Biggers's avatar
      crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN · 674f368a
      Eric Biggers authored
      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: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarHoria Geantă <horia.geanta@nxp.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      674f368a
    • Eric Biggers's avatar
      crypto: remove CRYPTO_TFM_RES_BAD_BLOCK_LEN · 5c925e8b
      Eric Biggers authored
      The flag CRYPTO_TFM_RES_BAD_BLOCK_LEN is never checked for, and it's
      only set by one driver.  And even that single driver's use is wrong
      because the driver is setting the flag from ->encrypt() and ->decrypt()
      with no locking, which is unsafe because ->encrypt() and ->decrypt() can
      be executed by many threads in parallel on the same tfm.
      
      Just remove this flag.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      5c925e8b
    • Eric Biggers's avatar
      crypto: remove unused tfm result flags · f9d89b85
      Eric Biggers authored
      The tfm result flags CRYPTO_TFM_RES_BAD_KEY_SCHED and
      CRYPTO_TFM_RES_BAD_FLAGS are never used, so remove them.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      f9d89b85
    • Eric Biggers's avatar
      crypto: atmel-sha - fix error handling when setting hmac key · b529f198
      Eric Biggers authored
      HMAC keys can be of any length, and atmel_sha_hmac_key_set() can only
      fail due to -ENOMEM.  But atmel_sha_hmac_setkey() incorrectly treated
      any error as a "bad key length" error.  Fix it to correctly propagate
      the -ENOMEM error code and not set any tfm result flags.
      
      Fixes: 81d8750b ("crypto: atmel-sha - add support to hmac(shaX)")
      Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
      Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
      Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarTudor Ambarus <tudor.ambarus@microchip.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      b529f198
    • Eric Biggers's avatar
      crypto: artpec6 - return correct error code for failed setkey() · b828f905
      Eric Biggers authored
      ->setkey() is supposed to retun -EINVAL for invalid key lengths, not -1.
      
      Fixes: a21eb94f ("crypto: axis - add ARTPEC-6/7 crypto accelerator driver")
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Lars Persson <lars.persson@axis.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Acked-by: default avatarLars Persson <lars.persson@axis.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      b828f905
    • Eric Biggers's avatar
      crypto: chelsio - fix writing tfm flags to wrong place · bd56cea0
      Eric Biggers authored
      The chelsio crypto driver is casting 'struct crypto_aead' directly to
      'struct crypto_tfm', which is incorrect because the crypto_tfm isn't the
      first field of 'struct crypto_aead'.  Consequently, the calls to
      crypto_tfm_set_flags() are modifying some other field in the struct.
      
      Also, the driver is setting CRYPTO_TFM_RES_BAD_KEY_LEN in
      ->setauthsize(), not just in ->setkey().  This is incorrect since this
      flag is for bad key lengths, not for bad authentication tag lengths.
      
      Fix these bugs by removing the broken crypto_tfm_set_flags() calls from
      ->setauthsize() and by fixing them in ->setkey().
      
      Fixes: 324429d7 ("chcr: Support for Chelsio's Crypto Hardware")
      Cc: <stable@vger.kernel.org> # v4.9+
      Cc: Atul Gupta <atul.gupta@chelsio.com>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      bd56cea0
    • Eric Biggers's avatar
      crypto: skcipher - remove skcipher_walk_aead() · 70ffa8fd
      Eric Biggers authored
      skcipher_walk_aead() is unused and is identical to
      skcipher_walk_aead_encrypt(), so remove it.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      70ffa8fd
  2. 04 Jan, 2020 4 commits
  3. 27 Dec, 2019 17 commits
  4. 20 Dec, 2019 7 commits