Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
  1. May 31, 2024
  2. May 10, 2024
  3. Sep 20, 2023
  4. Jun 23, 2023
  5. Apr 20, 2023
  6. Feb 13, 2023
  7. Nov 25, 2022
    • Eric Biggers's avatar
      crypto: api - compile out crypto_boot_test_finished when tests disabled · 06bd9c96
      Eric Biggers authored
      
      The crypto_boot_test_finished static key is unnecessary when self-tests
      are disabled in the kconfig, so optimize it out accordingly, along with
      the entirety of crypto_start_tests().  This mainly avoids the overhead
      of an unnecessary static_branch_enable() on every boot.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      06bd9c96
    • Eric Biggers's avatar
      crypto: api - optimize algorithm registration when self-tests disabled · a7008584
      Eric Biggers authored
      
      Currently, registering an algorithm with the crypto API always causes a
      notification to be posted to the "cryptomgr", which then creates a
      kthread to self-test the algorithm.  However, if self-tests are disabled
      in the kconfig (as is the default option), then this kthread just
      notifies waiters that the algorithm has been tested, then exits.
      
      This causes a significant amount of overhead, especially in the kthread
      creation and destruction, which is not necessary at all.  For example,
      in a quick test I found that booting a "minimum" x86_64 kernel with all
      the crypto options enabled (except for the self-tests) takes about 400ms
      until PID 1 can start.  Of that, a full 13ms is spent just doing this
      pointless dance, involving a kthread being created, run, and destroyed
      over 200 times.  That's over 3% of the entire kernel start time.
      
      Fix this by just skipping the creation of the test larval and the
      posting of the registration notification entirely, when self-tests are
      disabled.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      a7008584
  8. Aug 26, 2022
  9. Aug 19, 2022
  10. Mar 02, 2022
    • Nicolai Stange's avatar
      crypto: api - allow algs only in specific constructions in FIPS mode · d6097b8d
      Nicolai Stange authored
      Currently we do not distinguish between algorithms that fail on
      the self-test vs. those which are disabled in FIPS mode (not allowed).
      Both are marked as having failed the self-test.
      
      Recently the need arose to allow the usage of certain algorithms only
      as arguments to specific template instantiations in FIPS mode. For
      example, standalone "dh" must be blocked, but e.g. "ffdhe2048(dh)" is
      allowed. Other potential use cases include "cbcmac(aes)", which must
      only be used with ccm(), or "ghash", which must be used only for
      gcm().
      
      This patch allows this scenario by adding a new flag FIPS_INTERNAL to
      indicate those algorithms that are not FIPS-allowed. They can then be
      used as template arguments only, i.e. when looked up via
      crypto_grab_spawn() to be more specific. The FIPS_INTERNAL bit gets
      propagated upwards recursively into the surrounding template
      instances, until the construction eventually matches an explicit
      testmgr entry with ->fips_allowed being set, if any.
      
      The behaviour to skip !->fips_allowed self-test executions in FIPS
      mode will be retained. Note that this effectively means that
      FIPS_INTERNAL algorithms are handled very similarly to the INTERNAL
      ones in this regard. It is expected that the FIPS_INTERNAL algorithms
      will receive sufficient testing when the larger constructions they're
      a part of, if any, get exercised by testmgr.
      
      Note that as a side-effect of this patch algorithms which are not
      FIPS-allowed will now return ENOENT instead of ELIBBAD. Hopefully
      this is not an issue as some people were relying on this already.
      
      Link: https://lore.kernel.org/r/YeEVSaMEVJb3cQkq@gondor.apana.org.au
      
      
      Originally-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarNicolai Stange <nstange@suse.de>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.de>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      d6097b8d
  11. Feb 04, 2022
  12. Oct 29, 2021
  13. Oct 01, 2021
  14. Sep 24, 2021
    • Herbert Xu's avatar
      crypto: api - Fix built-in testing dependency failures · adad556e
      Herbert Xu authored
      
      When complex algorithms that depend on other algorithms are built
      into the kernel, the order of registration must be done such that
      the underlying algorithms are ready before the ones on top are
      registered.  As otherwise they would fail during the self-test
      which is required during registration.
      
      In the past we have used subsystem initialisation ordering to
      guarantee this.  The number of such precedence levels are limited
      and they may cause ripple effects in other subsystems.
      
      This patch solves this problem by delaying all self-tests during
      boot-up for built-in algorithms.  They will be tested either when
      something else in the kernel requests for them, or when we have
      finished registering all built-in algorithms, whichever comes
      earlier.
      
      Reported-by: default avatarVladis Dronov <vdronov@redhat.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      adad556e
  15. Mar 12, 2021
  16. Aug 07, 2020
    • Waiman Long's avatar
      mm, treewide: rename kzfree() to kfree_sensitive() · 453431a5
      Waiman Long authored
      As said by Linus:
      
        A symmetric naming is only helpful if it implies symmetries in use.
        Otherwise it's actively misleading.
      
        In "kzalloc()", the z is meaningful and an important part of what the
        caller wants.
      
        In "kzfree()", the z is actively detrimental, because maybe in the
        future we really _might_ want to use that "memfill(0xdeadbeef)" or
        something. The "zero" part of the interface isn't even _relevant_.
      
      The main reason that kzfree() exists is to clear sensitive information
      that should not be leaked to other future users of the same memory
      objects.
      
      Rename kzfree() to kfree_sensitive() to follow the example of the recently
      added kvfree_sensitive() and make the intention of the API more explicit.
      In addition, memzero_explicit() is used to clear the memory to make sure
      that it won't get optimized away by the compiler.
      
      The renaming is done by using the command sequence:
      
        git grep -w --name-only kzfree |\
        xargs sed -i 's/kzfree/kfree_sen...
      453431a5
  17. Jul 09, 2020
    • Barry Song's avatar
      crypto: api - permit users to specify numa node of acomp hardware · 7bc13b5b
      Barry Song authored
      
      For a Linux server with NUMA, there are possibly multiple (de)compressors
      which are either local or remote to some NUMA node. Some drivers will
      automatically use the (de)compressor near the CPU calling acomp_alloc().
      However, it is not necessarily correct because users who send acomp_req
      could be from different NUMA node with the CPU which allocates acomp.
      
      Just like kernel has kmalloc() and kmalloc_node(), here crypto can have
      same support.
      
      Cc: Seth Jennings <sjenning@redhat.com>
      Cc: Dan Streetman <ddstreet@ieee.org>
      Cc: Vitaly Wool <vitaly.wool@konsulko.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarBarry Song <song.bao.hua@hisilicon.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      7bc13b5b
  18. Apr 16, 2020
  19. Dec 20, 2019
    • Herbert Xu's avatar
      crypto: api - fix unexpectedly getting generic implementation · 2bbb3375
      Herbert Xu authored
      When CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y, the first lookup of an
      algorithm that needs to be instantiated using a template will always get
      the generic implementation, even when an accelerated one is available.
      
      This happens because the extra self-tests for the accelerated
      implementation allocate the generic implementation for comparison
      purposes, and then crypto_alg_tested() for the generic implementation
      "fulfills" the original request (i.e. sets crypto_larval::adult).
      
      This patch fixes this by only fulfilling the original request if
      we are currently the best outstanding larval as judged by the
      priority.  If we're not the best then we will ask all waiters on
      that larval request to retry the lookup.
      
      Note that this patch introduces a behaviour change when the module
      providing the new algorithm is unregistered during the process.
      Previously we would have failed with ENOENT, after the patch we
      will instead redo the lookup.
      
      Fixes: 9a8a6b3f ("crypto: testmgr - fuzz hashes against...")
      Fixes: d435e10e ("crypto: testmgr - fuzz skciphers against...")
      Fixes: 40153b10
      
       ("crypto: testmgr - fuzz AEADs against...")
      Reported-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Reviewed-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      2bbb3375
  20. Dec 11, 2019
    • Herbert Xu's avatar
      crypto: api - Fix race condition in crypto_spawn_alg · 73669cc5
      Herbert Xu authored
      The function crypto_spawn_alg is racy because it drops the lock
      before shooting the dying algorithm.  The algorithm could disappear
      altogether before we shoot it.
      
      This patch fixes it by moving the shooting into the locked section.
      
      Fixes: 6bfd4809
      
       ("[CRYPTO] api: Added spawns")
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      73669cc5
    • Eric Biggers's avatar
      crypto: cipher - remove crt_u.cipher (struct cipher_tfm) · e8cfed5e
      Eric Biggers authored
      
      Of the three fields in crt_u.cipher (struct cipher_tfm), ->cit_setkey()
      is pointless because it always points to setkey() in crypto/cipher.c.
      
      ->cit_decrypt_one() and ->cit_encrypt_one() are slightly less pointless,
      since if the algorithm doesn't have an alignmask, they are set directly
      to ->cia_encrypt() and ->cia_decrypt().  However, this "optimization"
      isn't worthwhile because:
      
      - The "cipher" algorithm type is the only algorithm still using crt_u,
        so it's bloating every struct crypto_tfm for every algorithm type.
      
      - If the algorithm has an alignmask, this "optimization" actually makes
        things slower, as it causes 2 indirect calls per block rather than 1.
      
      - It adds extra code complexity.
      
      - Some templates already call ->cia_encrypt()/->cia_decrypt() directly
        instead of going through ->cit_encrypt_one()/->cit_decrypt_one().
      
      - The "cipher" algorithm type never gives optimal performance anyway.
        For that, a higher-level type such as skcipher needs to be used.
      
      Therefore, just remove the extra indirection, and make
      crypto_cipher_setkey(), crypto_cipher_encrypt_one(), and
      crypto_cipher_decrypt_one() be direct calls into crypto/cipher.c.
      
      Also remove the unused function crypto_cipher_cast().
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      e8cfed5e
    • Eric Biggers's avatar
      crypto: compress - remove crt_u.compress (struct compress_tfm) · c441a909
      Eric Biggers authored
      
      crt_u.compress (struct compress_tfm) is pointless because its two
      fields, ->cot_compress() and ->cot_decompress(), always point to
      crypto_compress() and crypto_decompress().
      
      Remove this pointless indirection, and just make crypto_comp_compress()
      and crypto_comp_decompress() be direct calls to what used to be
      crypto_compress() and crypto_decompress().
      
      Also remove the unused function crypto_comp_cast().
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c441a909
    • Eric Biggers's avatar
      crypto: api - remove another reference to blkcipher · 0a940d4e
      Eric Biggers authored
      
      Update a comment to refer to crypto_alloc_skcipher() rather than
      crypto_alloc_blkcipher() (the latter having been removed).
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      0a940d4e
  21. Nov 16, 2019
    • Herbert Xu's avatar
      crypto: api - Add softdep on cryptomgr · 8ab23d54
      Herbert Xu authored
      
      The crypto API requires cryptomgr to be present for probing to work
      so we need a softdep to ensure that cryptomgr is added to the
      initramfs.
      
      This was usually not a problem because until very recently it was
      not practical to build crypto API as module but with the recent
      work to eliminate direct AES users this is now possible.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      8ab23d54
  22. Nov 01, 2019
    • Eric Biggers's avatar
      crypto: skcipher - remove the "blkcipher" algorithm type · c65058b7
      Eric Biggers authored
      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 ...
      c65058b7
  23. May 30, 2019
  24. Jul 18, 2018
  25. Apr 20, 2018
  26. Mar 30, 2018
    • Herbert Xu's avatar
      crypto: api - Keep failed instances alive · eb02c38f
      Herbert Xu authored
      This patch reverts commit 9c521a20
      
       ("crypto: api - remove
      instance when test failed") and fixes the underlying problem
      in a different way.
      
      To recap, prior to the reverted commit, an instance that fails
      a self-test is kept around.  However, it would satisfy any new
      lookups against its name and therefore the system may accumlulate
      an unbounded number of failed instances for the same algorithm
      name.
      
      The reverted commit fixed it by unregistering the instance.  Hoever,
      this still does not prevent the creation of the same failed instance
      over and over again each time the name is looked up.
      
      This patch fixes it by keeping the failed instance around, just as
      we would if it were a normal algorithm.  However, the lookup code
      has been udpated so that we do not attempt to create another
      instance as long as this failed one is still registered.  Of course,
      you could still force a new creation by deleting the instance from
      user-space.
      
      A new error (ELIBBAD) has been commandeered for this purpose and
      will be returned when all registered algorithm of a given name
      have failed the self-test.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      eb02c38f
    • Herbert Xu's avatar
      crypto: api - Make crypto_alg_lookup static · 3ca1e994
      Herbert Xu authored
      
      The function crypto_alg_lookup is only usd within the crypto API
      and should be not be exported to the modules.  This patch marks
      it as a static function.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      3ca1e994
    • Herbert Xu's avatar
      crypto: api - Remove unused crypto_type lookup function · 4989d4f0
      Herbert Xu authored
      
      The lookup function in crypto_type was only used for the implicit
      IV generators which have been completely removed from the crypto
      API.
      
      This patch removes the lookup function as it is now useless.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      4989d4f0
  27. Jan 05, 2018
  28. Dec 22, 2017
  29. Nov 03, 2017
  30. Mar 02, 2017
  31. Nov 28, 2016
  32. Oct 20, 2016