1. 05 2月, 2022 1 次提交
  2. 09 11月, 2021 1 次提交
  3. 29 10月, 2021 1 次提交
  4. 24 9月, 2021 1 次提交
    • H
      crypto: api - Fix built-in testing dependency failures · adad556e
      Herbert Xu 提交于
      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: NVladis Dronov <vdronov@redhat.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      adad556e
  5. 17 6月, 2021 1 次提交
  6. 16 7月, 2020 1 次提交
    • E
      crypto: algapi - use common mechanism for inheriting flags · 7bcb2c99
      Eric Biggers 提交于
      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 <mpatocka@redhat.com>
      (https://lore.kernel.org/r/alpine.LRH.2.02.2006301414580.30526@file01.intranet.prod.int.rdu2.redhat.com).
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      7bcb2c99
  7. 08 5月, 2020 1 次提交
  8. 16 4月, 2020 2 次提交
    • H
      crypto: api - Fix use-after-free and race in crypto_spawn_alg · 6603523b
      Herbert Xu 提交于
      There are two problems in crypto_spawn_alg.  First of all it may
      return spawn->alg even if spawn->dead is set.  This results in a
      double-free as detected by syzbot.
      
      Secondly the setting of the DYING flag is racy because we hold
      the read-lock instead of the write-lock.  We should instead call
      crypto_shoot_alg in a safe manner by gaining a refcount, dropping
      the lock, and then releasing the refcount.
      
      This patch fixes both problems.
      
      Reported-by: syzbot+fc0674cde00b66844470@syzkaller.appspotmail.com
      Fixes: 4f87ee11 ("crypto: api - Do not zap spawn->alg")
      Fixes: 73669cc5 ("crypto: api - Fix race condition in...")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6603523b
    • E
      crypto: algapi - Avoid spurious modprobe on LOADED · beeb460c
      Eric Biggers 提交于
      Currently after any algorithm is registered and tested, there's an
      unnecessary request_module("cryptomgr") even if it's already loaded.
      Also, CRYPTO_MSG_ALG_LOADED is sent twice, and thus if the algorithm is
      "crct10dif", lib/crc-t10dif.c replaces the tfm twice rather than once.
      
      This occurs because CRYPTO_MSG_ALG_LOADED is sent using
      crypto_probing_notify(), which tries to load "cryptomgr" if the
      notification is not handled (NOTIFY_DONE).  This doesn't make sense
      because "cryptomgr" doesn't handle this notification.
      
      Fix this by using crypto_notify() instead of crypto_probing_notify().
      
      Fixes: dd8b083f ("crypto: api - Introduce notifier for new crypto algorithms")
      Cc: <stable@vger.kernel.org> # v4.20+
      Cc: Martin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Reviewed-by: NMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      beeb460c
  9. 09 1月, 2020 6 次提交
  10. 27 12月, 2019 1 次提交
    • H
      crypto: api - Retain alg refcount in crypto_grab_spawn · 5f567fff
      Herbert Xu 提交于
      This patch changes crypto_grab_spawn to retain the reference count
      on the algorithm.  This is because the caller needs to access the
      algorithm parameters and without the reference count the algorithm
      can be freed at any time.
      
      The reference count will be subsequently dropped by the crypto API
      once the instance has been registered.  The helper crypto_drop_spawn
      will also conditionally drop the reference count depending on whether
      it has been registered.
      
      Note that the code is actually added to crypto_init_spawn.  However,
      unless the caller activates this by setting spawn->dropref beforehand
      then nothing happens.  The only caller that sets dropref is currently
      crypto_grab_spawn.
      
      Once all legacy users of crypto_init_spawn disappear, then we can
      kill the dropref flag.
      
      Internally each instance will maintain a list of its spawns prior
      to registration.  This memory used by this list is shared with
      other fields that are only used after registration.  In order for
      this to work a new flag spawn->registered is added to indicate
      whether spawn->inst can be used.
      
      Fixes: d6ef2f19 ("crypto: api - Add crypto_grab_spawn primitive")
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      5f567fff
  11. 20 12月, 2019 2 次提交
    • E
      crypto: algapi - make unregistration functions return void · c6d633a9
      Eric Biggers 提交于
      Some of the algorithm unregistration functions return -ENOENT when asked
      to unregister a non-registered algorithm, while others always return 0
      or always return void.  But no users check the return value, except for
      two of the bulk unregistration functions which print a message on error
      but still always return 0 to their caller, and crypto_del_alg() which
      calls crypto_unregister_instance() which always returns 0.
      
      Since unregistering a non-registered algorithm is always a kernel bug
      but there isn't anything callers should do to handle this situation at
      runtime, let's simplify things by making all the unregistration
      functions return void, and moving the error message into
      crypto_unregister_alg() and upgrading it to a WARN().
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      c6d633a9
    • H
      crypto: api - fix unexpectedly getting generic implementation · 2bbb3375
      Herbert Xu 提交于
      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: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Reviewed-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      2bbb3375
  12. 11 12月, 2019 4 次提交
  13. 17 11月, 2019 1 次提交
  14. 13 6月, 2019 1 次提交
  15. 31 5月, 2019 1 次提交
  16. 30 5月, 2019 1 次提交
  17. 25 1月, 2019 1 次提交
  18. 11 1月, 2019 2 次提交
  19. 07 12月, 2018 6 次提交
  20. 28 9月, 2018 1 次提交
  21. 04 9月, 2018 2 次提交
  22. 21 4月, 2018 1 次提交
  23. 31 3月, 2018 1 次提交
    • H
      crypto: api - Keep failed instances alive · eb02c38f
      Herbert Xu 提交于
      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: NHerbert Xu <herbert@gondor.apana.org.au>
      eb02c38f