15 Jun, 2020

1 commit

  • When a crypto template needs to be instantiated, CRYPTO_MSG_ALG_REQUEST
    is sent to crypto_chain. cryptomgr_schedule_probe() handles this by
    starting a thread to instantiate the template, then waiting for this
    thread to complete via crypto_larval::completion.

    This can deadlock because instantiating the template may require loading
    modules, and this (apparently depending on userspace) may need to wait
    for the crc-t10dif module (lib/crc-t10dif.c) to be loaded. But
    crc-t10dif's module_init function uses crypto_register_notifier() and
    therefore takes crypto_chain.rwsem for write. That can't proceed until
    the notifier callback has finished, as it holds this semaphore for read.

    Fix this by removing the wait on crypto_larval::completion from within
    cryptomgr_schedule_probe(). It's actually unnecessary because
    crypto_alg_mod_lookup() calls crypto_larval_wait() itself after sending
    CRYPTO_MSG_ALG_REQUEST.

    This only actually became a problem in v4.20 due to commit b76377543b73
    ("crc-t10dif: Pick better transform if one becomes available"), but the
    unnecessary wait was much older.

    BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207159
    Reported-by: Mike Gerow
    Fixes: 398710379f51 ("crypto: algapi - Move larval completion into algboss")
    Cc: # v3.6+
    Cc: Martin K. Petersen
    Signed-off-by: Eric Biggers
    Reported-by: Kai Lüke
    Signed-off-by: Herbert Xu

    Eric Biggers
     

09 Jan, 2020

1 commit

  • Now that all templates provide a ->create() method which creates an
    instance, installs a strongly-typed ->free() method directly to it, and
    registers it, the older ->alloc() and ->free() methods in
    'struct crypto_template' are no longer used. Remove them.

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

    Eric Biggers
     

31 May, 2019

1 commit

  • Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license as published by
    the free software foundation either version 2 of the license or at
    your option any later version

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-or-later

    has been chosen to replace the boilerplate/reference in 3029 file(s).

    Signed-off-by: Thomas Gleixner
    Reviewed-by: Allison Randal
    Cc: linux-spdx@vger.kernel.org
    Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
    Signed-off-by: Greg Kroah-Hartman

    Thomas Gleixner
     

18 Apr, 2019

1 commit

  • Use subsys_initcall for registration of all templates and generic
    algorithm implementations, rather than module_init. Then change
    cryptomgr to use arch_initcall, to place it before the subsys_initcalls.

    This is needed so that when both a generic and optimized implementation
    of an algorithm are built into the kernel (not loadable modules), the
    generic implementation is registered before the optimized one.
    Otherwise, the self-tests for the optimized implementation are unable to
    allocate the generic implementation for the new comparison fuzz tests.

    Note that on arm, a side effect of this change is that self-tests for
    generic implementations may run before the unaligned access handler has
    been installed. So, unaligned accesses will crash the kernel. This is
    arguably a good thing as it makes it easier to detect that type of bug.

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

    Eric Biggers
     

04 Sep, 2018

1 commit

  • Introduce a facility that can be used to receive a notification
    callback when a new algorithm becomes available. This can be used by
    existing crypto registrations to trigger a switch from a software-only
    algorithm to a hardware-accelerated version.

    A new CRYPTO_MSG_ALG_LOADED state is introduced to the existing crypto
    notification chain, and the register/unregister functions are exported
    so they can be called by subsystems outside of crypto.

    Signed-off-by: Martin K. Petersen
    Suggested-by: Herbert Xu
    Signed-off-by: Martin K. Petersen
    Signed-off-by: Herbert Xu

    Martin K. Petersen
     

07 Oct, 2017

1 commit


02 Mar, 2017

1 commit


28 Nov, 2016

1 commit

  • Currently we manually filter out internal algorithms using a list
    in testmgr. This is dangerous as internal algorithms cannot be
    safely used even by testmgr. This patch ensures that they're never
    processed by testmgr at all.

    This patch also removes an obsolete bypass for nivciphers which
    no longer exist.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

17 Aug, 2015

1 commit


25 Jun, 2013

1 commit

  • On Thu, Jun 20, 2013 at 10:00:21AM +0200, Daniel Borkmann wrote:
    > After having fixed a NULL pointer dereference in SCTP 1abd165e ("net:
    > sctp: fix NULL pointer dereference in socket destruction"), I ran into
    > the following NULL pointer dereference in the crypto subsystem with
    > the same reproducer, easily hit each time:
    >
    > BUG: unable to handle kernel NULL pointer dereference at (null)
    > IP: [] __wake_up_common+0x31/0x90
    > PGD 0
    > Oops: 0000 [#1] SMP
    > Modules linked in: padlock_sha(F-) sha256_generic(F) sctp(F) libcrc32c(F) [..]
    > CPU: 6 PID: 3326 Comm: cryptomgr_probe Tainted: GF 3.10.0-rc5+ #1
    > Hardware name: Dell Inc. PowerEdge T410/0H19HD, BIOS 1.6.3 02/01/2011
    > task: ffff88007b6cf4e0 ti: ffff88007b7cc000 task.ti: ffff88007b7cc000
    > RIP: 0010:[] [] __wake_up_common+0x31/0x90
    > RSP: 0018:ffff88007b7cde08 EFLAGS: 00010082
    > RAX: ffffffffffffffe8 RBX: ffff88003756c130 RCX: 0000000000000000
    > RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffff88003756c130
    > RBP: ffff88007b7cde48 R08: 0000000000000000 R09: ffff88012b173200
    > R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000282
    > R13: ffff88003756c138 R14: 0000000000000000 R15: 0000000000000000
    > FS: 0000000000000000(0000) GS:ffff88012fc60000(0000) knlGS:0000000000000000
    > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    > CR2: 0000000000000000 CR3: 0000000001a0b000 CR4: 00000000000007e0
    > DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    > DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
    > Stack:
    > ffff88007b7cde28 0000000300000000 ffff88007b7cde28 ffff88003756c130
    > 0000000000000282 ffff88003756c128 ffffffff81227670 0000000000000000
    > ffff88007b7cde78 ffffffff810722b7 ffff88007cdcf000 ffffffff81a90540
    > Call Trace:
    > [] ? crypto_alloc_pcomp+0x20/0x20
    > [] complete_all+0x47/0x60
    > [] cryptomgr_probe+0x98/0xc0
    > [] ? crypto_alloc_pcomp+0x20/0x20
    > [] kthread+0xce/0xe0
    > [] ? kthread_freezable_should_stop+0x70/0x70
    > [] ret_from_fork+0x7c/0xb0
    > [] ? kthread_freezable_should_stop+0x70/0x70
    > Code: 41 56 41 55 41 54 53 48 83 ec 18 66 66 66 66 90 89 75 cc 89 55 c8
    > 4c 8d 6f 08 48 8b 57 08 41 89 cf 4d 89 c6 48 8d 42 e
    > RIP [] __wake_up_common+0x31/0x90
    > RSP
    > CR2: 0000000000000000
    > ---[ end trace b495b19270a4d37e ]---
    >
    > My assumption is that the following is happening: the minimal SCTP
    > tool runs under ``echo 1 > /proc/sys/net/sctp/auth_enable'', hence
    > it's making use of crypto_alloc_hash() via sctp_auth_init_hmacs().
    > It forks itself, heavily allocates, binds, listens and waits in
    > accept on sctp sockets, and then randomly kills some of them (no
    > need for an actual client in this case to hit this). Then, again,
    > allocating, binding, etc, and then killing child processes.
    >
    > The problem that might be happening here is that cryptomgr requests
    > the module to probe/load through cryptomgr_schedule_probe(), but
    > before the thread handler cryptomgr_probe() returns, we return from
    > the wait_for_completion_interruptible() function and probably already
    > have cleared up larval, thus we run into a NULL pointer dereference
    > when in cryptomgr_probe() complete_all() is being called.
    >
    > If we wait with wait_for_completion() instead, this panic will not
    > occur anymore. This is valid, because in case a signal is pending,
    > cryptomgr_probe() returns from probing anyway with properly calling
    > complete_all().

    The use of wait_for_completion_interruptible is intentional so that
    we don't lock up the thread if a bug causes us to never wake up.

    This bug is caused by the helper thread using the larval without
    holding a reference count on it. If the helper thread completes
    after the original thread requesting for help has gone away and
    destroyed the larval, then we get the crash above.

    So the fix is to hold a reference count on the larval.

    Cc: # 3.6+
    Reported-by: Daniel Borkmann
    Tested-by: Daniel Borkmann
    Signed-off-by: Herbert Xu

    Herbert Xu
     

27 Jun, 2012

1 commit

  • git commit 398710379 (crypto: algapi - Move larval completion
    into algboss) replaced accidentally a call to complete_all() by
    a call to complete(). This causes a hang on crypto allocation
    if we have more than one larval waiter. This pach restores the
    call to complete_all().

    Signed-off-by: Steffen Klassert
    Signed-off-by: Herbert Xu

    Steffen Klassert
     

22 Jun, 2012

1 commit

  • It has been observed that sometimes the crypto allocation code
    will get stuck for 60 seconds or multiples thereof. This is
    usually caused by an algorithm failing to pass the self-test.

    If an algorithm fails to be constructed, we will immediately notify
    all larval waiters. However, if it succeeds in construction, but
    then fails the self-test, we won't notify anyone at all.

    This patch fixes this by merging the notification in the case
    where the algorithm fails to be constructed with that of the
    the case where it pases the self-test. This way regardless of
    what happens, we'll give the larval waiters an answer.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

06 Aug, 2010

1 commit

  • This patch fixes a serious bug in the test disabling patch where
    it can cause an spurious load of the cryptomgr module even when
    it's compiled in.

    It also negates the test disabling option so that its absence
    causes tests to be enabled.

    The Kconfig option is also now behind EMBEDDED.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

03 Jun, 2010

1 commit


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

07 Jul, 2009

1 commit

  • This patch introduces the template->create function intended
    to replace the existing alloc function. The intention is for
    create to handle the registration directly, whereas currently
    the caller of alloc has to handle the registration.

    This allows type-specific code to be run prior to registration.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

02 Jun, 2009

1 commit

  • We currently allocate temporary memory that is used for testing
    statically. This renders the testing engine non-reentrant. As
    algorithms may nest, i.e., one may construct another in order to
    carry out a part of its operation, this is unacceptable. For
    example, it has been reported that an AEAD implementation allocates
    a cipher in its setkey function, which causes it to fail during
    testing as the temporary memory is overwritten.

    This patch replaces the static memory with dynamically allocated
    buffers. We need a maximum of 16 pages so this slightly increases
    the chances of an algorithm failing due to memory shortage.
    However, as testing usually occurs at registration, this shouldn't
    be a big problem.

    Reported-by: Shasi Pulijala
    Signed-off-by: Herbert Xu

    Herbert Xu
     

18 Feb, 2009

1 commit

  • As it is an skcipher with no IV escapes testing altogether because
    we only test givcipher objects. This patch fixes the bypass logic
    to test these algorithms.

    Conversely, we're currently testing nivaead algorithms with IVs,
    which would have deadlocked had it not been for the fact that no
    nivaead algorithms have any test vectors. This patch also fixes
    that case.

    Both fixes are ugly as hell, but this ugliness should hopefully
    disappear once we move them into the per-type code (i.e., the
    AEAD test would live in aead.c and the skcipher stuff in ablkcipher.c).

    Signed-off-by: Herbert Xu

    Herbert Xu
     

29 Aug, 2008

3 commits