Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 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
  3. 11 12月, 2019 4 次提交
  5. 17 11月, 2019 1 次提交
  7. 13 6月, 2019 1 次提交
  9. 31 5月, 2019 1 次提交
  11. 30 5月, 2019 1 次提交
  13. 25 1月, 2019 1 次提交
  15. 11 1月, 2019 2 次提交
  17. 07 12月, 2018 6 次提交
  19. 28 9月, 2018 1 次提交
  21. 04 9月, 2018 2 次提交
  23. 21 4月, 2018 1 次提交
  25. 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
  27. 05 1月, 2018 3 次提交
    • E
      crypto: algapi - remove unused notifications · 8b55107c
      由 Eric Biggers 提交于 
      There is a message posted to the crypto notifier chain when an algorithm
is unregistered, and when a template is registered or unregistered.  But
nothing is listening for those messages; currently there are only
listeners for the algorithm request and registration messages.

Get rid of these unused notifications for now.
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      8b55107c
    • E
      crypto: algapi - convert cra_refcnt to refcount_t · ce8614a3
      由 Eric Biggers 提交于 
      Reference counters should use refcount_t rather than atomic_t, since the
refcount_t implementation can prevent overflows, reducing the
exploitability of reference leak bugs.  crypto_alg.cra_refcount is a
reference counter with the usual semantics, so switch it over to
refcount_t.
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      ce8614a3
    • E
      crypto: algapi - fix NULL dereference in crypto_remove_spawns() · 9a006742
      由 Eric Biggers 提交于 
      syzkaller triggered a NULL pointer dereference in crypto_remove_spawns()
via a program that repeatedly and concurrently requests AEADs
"authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)"
through AF_ALG, where the hashes are requested as "untested"
(CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this
causes the template to be instantiated for every request).

Although AF_ALG users really shouldn't be able to request an "untested"
algorithm, the NULL pointer dereference is actually caused by a
longstanding race condition where crypto_remove_spawns() can encounter
an instance which has had spawn(s) "grabbed" but hasn't yet been
registered, resulting in ->cra_users still being NULL.

We probably should properly initialize ->cra_users earlier, but that
would require updating many templates individually.  For now just fix
the bug in a simple way that can easily be backported: make
crypto_remove_spawns() treat a NULL ->cra_users list as empty.
Reported-by: Nsyzbot <syzkaller@googlegroups.com>
Cc: stable@vger.kernel.org
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      9a006742
  29. 03 11月, 2017 1 次提交
    • G
      crypto: change transient busy return code to -ENOSPC · 6b80ea38
      由 Gilad Ben-Yossef 提交于 
      The crypto API was using the -EBUSY return value to indicate
both a hard failure to submit a crypto operation into a
transformation provider when the latter was busy and the backlog
mechanism was not enabled as well as a notification that the
operation was queued into the backlog when the backlog mechanism
was enabled.

Having the same return code indicate two very different conditions
depending on a flag is both error prone and requires extra runtime
check like the following to discern between the cases:

	if (err == -EINPROGRESS ||
	    (err == -EBUSY && (ahash_request_flags(req) &
			       CRYPTO_TFM_REQ_MAY_BACKLOG)))

This patch changes the return code used to indicate a crypto op
failed due to the transformation provider being transiently busy
to -ENOSPC.
Signed-off-by: NGilad Ben-Yossef <gilad@benyossef.com>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6b80ea38
  31. 04 8月, 2017 1 次提交
  33. 19 6月, 2017 1 次提交
  35. 09 3月, 2017 1 次提交
    • A
      crypto: algapi - annotate expected branch behavior in crypto_inc() · 27c539ae
      由 Ard Biesheuvel 提交于 
      To prevent unnecessary branching, mark the exit condition of the
primary loop as likely(), given that a carry in a 32-bit counter
occurs very rarely.

On arm64, the resulting code is emitted by GCC as

     9a8:   cmp     w1, #0x3
     9ac:   add     x3, x0, w1, uxtw
     9b0:   b.ls    9e0 <crypto_inc+0x38>
     9b4:   ldr     w2, [x3,#-4]!
     9b8:   rev     w2, w2
     9bc:   add     w2, w2, #0x1
     9c0:   rev     w4, w2
     9c4:   str     w4, [x3]
     9c8:   cbz     w2, 9d0 <crypto_inc+0x28>
     9cc:   ret

where the two remaining branch conditions (one for size < 4 and one for
the carry) are statically predicted as non-taken, resulting in optimal
execution in the vast majority of cases.

Also, replace the open coded alignment test with IS_ALIGNED().

Cc: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      27c539ae
  37. 11 2月, 2017 1 次提交
    • A
      crypto: algapi - make crypto_xor() and crypto_inc() alignment agnostic · db91af0f
      由 Ard Biesheuvel 提交于 
      Instead of unconditionally forcing 4 byte alignment for all generic
chaining modes that rely on crypto_xor() or crypto_inc() (which may
result in unnecessary copying of data when the underlying hardware
can perform unaligned accesses efficiently), make those functions
deal with unaligned input explicitly, but only if the Kconfig symbol
HAVE_EFFICIENT_UNALIGNED_ACCESS is set. This will allow us to drop
the alignmasks from the CBC, CMAC, CTR, CTS, PCBC and SEQIV drivers.

For crypto_inc(), this simply involves making the 4-byte stride
conditional on HAVE_EFFICIENT_UNALIGNED_ACCESS being set, given that
it typically operates on 16 byte buffers.

For crypto_xor(), an algorithm is implemented that simply runs through
the input using the largest strides possible if unaligned accesses are
allowed. If they are not, an optimal sequence of memory accesses is
emitted that takes the relative alignment of the input buffers into
account, e.g., if the relative misalignment of dst and src is 4 bytes,
the entire xor operation will be completed using 4 byte loads and stores
(modulo unaligned bits at the start and end). Note that all expressions
involving misalign are simply eliminated by the compiler when
HAVE_EFFICIENT_UNALIGNED_ACCESS is defined.
Signed-off-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      db91af0f
  39. 23 1月, 2017 1 次提交
  41. 01 7月, 2016 1 次提交
  43. 25 1月, 2016 1 次提交
  45. 23 11月, 2015 1 次提交
  47. 20 10月, 2015 1 次提交
    • H
      crypto: api - Only abort operations on fatal signal · 3fc89adb
      由 Herbert Xu 提交于 
      Currently a number of Crypto API operations may fail when a signal
occurs.  This causes nasty problems as the caller of those operations
are often not in a good position to restart the operation.

In fact there is currently no need for those operations to be
interrupted by user signals at all.  All we need is for them to
be killable.

This patch replaces the relevant calls of signal_pending with
fatal_signal_pending, and wait_for_completion_interruptible with
wait_for_completion_killable, respectively.

Cc: stable@vger.kernel.org
Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      3fc89adb
  49. 14 7月, 2015 2 次提交
  51. 03 6月, 2015 1 次提交