19 Aug, 2020

1 commit

  • This patch moves crypto_yield into internal.h as it's only used
    by internal code such as skcipher. It also adds a missing inclusion
    of sched.h which is required for cond_resched.

    The header files in internal.h have been cleaned up to remove some
    ancient junk and add some more specific inclusions.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

09 Jul, 2020

1 commit

  • 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
    Cc: Dan Streetman
    Cc: Vitaly Wool
    Cc: Andrew Morton
    Cc: Jonathan Cameron
    Signed-off-by: Barry Song
    Signed-off-by: Herbert Xu

    Barry Song
     

16 Apr, 2020

1 commit

  • 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: 4f87ee118d16 ("crypto: api - Do not zap spawn->alg")
    Fixes: 73669cc55646 ("crypto: api - Fix race condition in...")
    Cc:
    Signed-off-by: Herbert Xu

    Herbert Xu
     

11 Dec, 2019

3 commits

  • 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: 6bfd48096ff8 ("[CRYPTO] api: Added spawns")
    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • 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: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     
  • 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: 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
     

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
     

31 Mar, 2018

1 commit


05 Jan, 2018

2 commits

  • 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: Eric Biggers
    Signed-off-by: Herbert Xu

    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: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

22 Dec, 2017

1 commit


21 Oct, 2016

1 commit


25 Jan, 2016

1 commit


23 Apr, 2015

1 commit


21 Apr, 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
     

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
     

21 Oct, 2011

2 commits


10 Mar, 2010

1 commit


14 Jul, 2009

2 commits


08 Jul, 2009

1 commit


18 Jun, 2009

1 commit

  • FIPS-140 requires that all random number generators implement continuous self
    tests in which each extracted block of data is compared against the last block
    for repetition. The ansi_cprng implements such a test, but it would be nice if
    the hw rng's did the same thing. Obviously its not something thats always
    needed, but it seems like it would be a nice feature to have on occasion. I've
    written the below patch which allows individual entropy stores to be flagged as
    desiring a continuous test to be run on them as is extracted. By default this
    option is off, but is enabled in the event that fips mode is selected during
    bootup.

    Signed-off-by: Neil Horman
    Acked-by: Matt Mackall
    Signed-off-by: Herbert Xu

    Neil Horman
     

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

  • This is based on a report and patch by Geert Uytterhoeven.

    The functions crypto_alloc_tfm and create_create_tfm return a
    pointer that needs to be adjusted by the caller when successful
    and otherwise an error value. This means that the caller has
    to check for the error and only perform the adjustment if the
    pointer returned is valid.

    Since all callers want to make the adjustment and we know how
    to adjust it ourselves, it's much easier to just return adjusted
    pointer directly.

    The only caveat is that we have to return a void * instead of
    struct crypto_tfm *. However, this isn't that bad because both
    of these functions are for internal use only (by types code like
    shash.c, not even algorithms code).

    This patch also moves crypto_alloc_tfm into crypto/internal.h
    (crypto_create_tfm is already there) to reflect this.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

25 Dec, 2008

1 commit

  • This patch reintroduces a completely revamped crypto_alloc_tfm.
    The biggest change is that we now take two crypto_type objects
    when allocating a tfm, a frontend and a backend. In fact this
    simply formalises what we've been doing behind the API's back.

    For example, as it stands crypto_alloc_ahash may use an
    actual ahash algorithm or a crypto_hash algorithm. Putting
    this in the API allows us to do this much more cleanly.

    The existing types will be converted across gradually.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

29 Aug, 2008

4 commits


10 Jul, 2008

1 commit


11 Jan, 2008

2 commits

  • This patch makes crypto_alloc_ablkcipher/crypto_grab_skcipher always
    return algorithms that are capable of generating their own IVs through
    givencrypt and givdecrypt. Each algorithm may specify its default IV
    generator through the geniv field.

    For algorithms that do not set the geniv field, the blkcipher layer will
    pick a default. Currently it's chainiv for synchronous algorithms and
    eseqiv for asynchronous algorithms. Note that if these wrappers do not
    work on an algorithm then that algorithm must specify its own geniv or
    it can't be used at all.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • The scatterwalk infrastructure is used by algorithms so it needs to
    move out of crypto for future users that may live in drivers/crypto
    or asm/*/crypto.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

11 Oct, 2007

1 commit

  • When scatterwalk is built as a module digest.c was broken because it
    requires the crypto_km_types structure which is in scatterwalk. This
    patch removes the crypto_km_types structure by encoding the logic into
    crypto_kmap_type directly.

    In fact, this even saves a few bytes of code (not to mention the data
    structure itself) on i386 which is about the only place where it's
    needed.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

07 Feb, 2007

2 commits


21 Sep, 2006

2 commits