Skip to content
Snippets Groups Projects
  1. Oct 27, 2023
  2. Oct 13, 2023
  3. Feb 13, 2023
  4. Jul 16, 2020
    • Eric Biggers's avatar
      crypto: algapi - use common mechanism for inheriting flags · 7bcb2c99
      Eric Biggers authored
      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: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      7bcb2c99
  5. Jan 09, 2020
    • Eric Biggers's avatar
      crypto: chacha20poly1305 - use crypto_grab_ahash() and simplify error paths · c282586f
      Eric Biggers authored
      
      Make the rfc7539 and rfc7539esp templates use the new function
      crypto_grab_ahash() to initialize their ahash spawn.
      
      This is needed to make all spawns be initialized in a consistent way.
      
      Also simplify the error handling by taking advantage of crypto_drop_*()
      now accepting (as a no-op) spawns that haven't been initialized yet, and
      by taking advantage of crypto_grab_*() now handling ERR_PTR() names.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c282586f
    • Eric Biggers's avatar
      crypto: skcipher - pass instance to crypto_grab_skcipher() · b9f76ddd
      Eric Biggers authored
      
      Initializing a crypto_skcipher_spawn currently requires:
      
      1. Set spawn->base.inst to point to the instance.
      2. Call crypto_grab_skcipher().
      
      But there's no reason for these steps to be separate, and in fact this
      unneeded complication has caused at least one bug, the one fixed by
      commit 6db43410 ("crypto: adiantum - initialize crypto_spawn::inst")
      
      So just make crypto_grab_skcipher() take the instance as an argument.
      
      To keep the function calls from getting too unwieldy due to this extra
      argument, also introduce a 'mask' variable into the affected places
      which weren't already using one.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      b9f76ddd
    • Eric Biggers's avatar
      crypto: remove propagation of CRYPTO_TFM_RES_* flags · af5034e8
      Eric Biggers authored
      
      The CRYPTO_TFM_RES_* flags were apparently meant as a way to make the
      ->setkey() functions provide more information about errors.  But these
      flags weren't actually being used or tested, and in many cases they
      weren't being set correctly anyway.  So they've now been removed.
      
      Also, if someone ever actually needs to start better distinguishing
      ->setkey() errors (which is somewhat unlikely, as this has been unneeded
      for a long time), we'd be much better off just defining different return
      values, like -EINVAL if the key is invalid for the algorithm vs.
      -EKEYREJECTED if the key was rejected by a policy like "no weak keys".
      That would be much simpler, less error-prone, and easier to test.
      
      So just remove CRYPTO_TFM_RES_MASK and all the unneeded logic that
      propagates these flags around.
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      af5034e8
  6. Jun 13, 2019
  7. Jun 06, 2019
    • Eric Biggers's avatar
      crypto: chacha20poly1305 - fix atomic sleep when using async algorithm · 7545b6c2
      Eric Biggers authored
      
      Clear the CRYPTO_TFM_REQ_MAY_SLEEP flag when the chacha20poly1305
      operation is being continued from an async completion callback, since
      sleeping may not be allowed in that context.
      
      This is basically the same bug that was recently fixed in the xts and
      lrw templates.  But, it's always been broken in chacha20poly1305 too.
      This was found using syzkaller in combination with the updated crypto
      self-tests which actually test the MAY_SLEEP flag now.
      
      Reproducer:
      
          python -c 'import socket; socket.socket(socket.AF_ALG, 5, 0).bind(
          	       ("aead", "rfc7539(cryptd(chacha20-generic),poly1305-generic)"))'
      
      Kernel output:
      
          BUG: sleeping function called from invalid context at include/crypto/algapi.h:426
          in_atomic(): 1, irqs_disabled(): 0, pid: 1001, name: kworker/2:2
          [...]
          CPU: 2 PID: 1001 Comm: kworker/2:2 Not tainted 5.2.0-rc2 #5
          Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-20181126_142135-anatol 04/01/2014
          Workqueue: crypto cryptd_queue_worker
          Call Trace:
           __dump_stack lib/dump_stack.c:77 [inline]
           dump_stack+0x4d/0x6a lib/dump_stack.c:113
           ___might_sleep kernel/sched/core.c:6138 [inline]
           ___might_sleep.cold.19+0x8e/0x9f kernel/sched/core.c:6095
           crypto_yield include/crypto/algapi.h:426 [inline]
           crypto_hash_walk_done+0xd6/0x100 crypto/ahash.c:113
           shash_ahash_update+0x41/0x60 crypto/shash.c:251
           shash_async_update+0xd/0x10 crypto/shash.c:260
           crypto_ahash_update include/crypto/hash.h:539 [inline]
           poly_setkey+0xf6/0x130 crypto/chacha20poly1305.c:337
           poly_init+0x51/0x60 crypto/chacha20poly1305.c:364
           async_done_continue crypto/chacha20poly1305.c:78 [inline]
           poly_genkey_done+0x15/0x30 crypto/chacha20poly1305.c:369
           cryptd_skcipher_complete+0x29/0x70 crypto/cryptd.c:279
           cryptd_skcipher_decrypt+0xcd/0x110 crypto/cryptd.c:339
           cryptd_queue_worker+0x70/0xa0 crypto/cryptd.c:184
           process_one_work+0x1ed/0x420 kernel/workqueue.c:2269
           worker_thread+0x3e/0x3a0 kernel/workqueue.c:2415
           kthread+0x11f/0x140 kernel/kthread.c:255
           ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:352
      
      Fixes: 71ebc4d1 ("crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD construction, RFC7539")
      Cc: <stable@vger.kernel.org> # v4.2+
      Cc: Martin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      7545b6c2
  8. May 30, 2019
  9. Apr 18, 2019
    • Eric Biggers's avatar
      crypto: run initcalls for generic implementations earlier · c4741b23
      Eric Biggers authored
      
      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: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      c4741b23
  10. Apr 08, 2019
    • Eric Biggers's avatar
      crypto: chacha20poly1305 - set cra_name correctly · 5e27f38f
      Eric Biggers authored
      
      If the rfc7539 template is instantiated with specific implementations,
      e.g. "rfc7539(chacha20-generic,poly1305-generic)" rather than
      "rfc7539(chacha20,poly1305)", then the implementation names end up
      included in the instance's cra_name.  This is incorrect because it then
      prevents all users from allocating "rfc7539(chacha20,poly1305)", if the
      highest priority implementations of chacha20 and poly1305 were selected.
      Also, the self-tests aren't run on an instance allocated in this way.
      
      Fix it by setting the instance's cra_name from the underlying
      algorithms' actual cra_names, rather than from the requested names.
      This matches what other templates do.
      
      Fixes: 71ebc4d1 ("crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD construction, RFC7539")
      Cc: <stable@vger.kernel.org> # v4.2+
      Cc: Martin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Reviewed-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      5e27f38f
  11. Jan 25, 2019
  12. Nov 20, 2018
    • Eric Biggers's avatar
      crypto: chacha20-generic - refactor to allow varying number of rounds · 1ca1b917
      Eric Biggers authored
      
      In preparation for adding XChaCha12 support, rename/refactor
      chacha20-generic to support different numbers of rounds.  The
      justification for needing XChaCha12 support is explained in more detail
      in the patch "crypto: chacha - add XChaCha12 support".
      
      The only difference between ChaCha{8,12,20} are the number of rounds
      itself; all other parts of the algorithm are the same.  Therefore,
      remove the "20" from all definitions, structures, functions, files, etc.
      that will be shared by all ChaCha versions.
      
      Also make ->setkey() store the round count in the chacha_ctx (previously
      chacha20_ctx).  The generic code then passes the round count through to
      chacha_block().  There will be a ->setkey() function for each explicitly
      allowed round count; the encrypt/decrypt functions will be the same.  I
      decided not to do it the opposite way (same ->setkey() function for all
      round counts, with different encrypt/decrypt functions) because that
      would have required more boilerplate code in architecture-specific
      implementations of ChaCha and XChaCha.
      
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarMartin Willi <martin@strongswan.org>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      1ca1b917
  13. Nov 16, 2018
  14. Dec 22, 2017
    • Eric Biggers's avatar
      crypto: chacha20poly1305 - validate the digest size · e57121d0
      Eric Biggers authored
      
      If the rfc7539 template was instantiated with a hash algorithm with
      digest size larger than 16 bytes (POLY1305_DIGEST_SIZE), then the digest
      overran the 'tag' buffer in 'struct chachapoly_req_ctx', corrupting the
      subsequent memory, including 'cryptlen'.  This caused a crash during
      crypto_skcipher_decrypt().
      
      Fix it by, when instantiating the template, requiring that the
      underlying hash algorithm has the digest size expected for Poly1305.
      
      Reproducer:
      
          #include <linux/if_alg.h>
          #include <sys/socket.h>
          #include <unistd.h>
      
          int main()
          {
                  int algfd, reqfd;
                  struct sockaddr_alg addr = {
                          .salg_type = "aead",
                          .salg_name = "rfc7539(chacha20,sha256)",
                  };
                  unsigned char buf[32] = { 0 };
      
                  algfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
                  bind(algfd, (void *)&addr, sizeof(addr));
                  setsockopt(algfd, SOL_ALG, ALG_SET_KEY, buf, sizeof(buf));
                  reqfd = accept(algfd, 0, 0);
                  write(reqfd, buf, 16);
                  read(reqfd, buf, 16);
          }
      
      Reported-by: default avatarsyzbot <syzkaller@googlegroups.com>
      Fixes: 71ebc4d1 ("crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD construction, RFC7539")
      Cc: <stable@vger.kernel.org> # v4.2+
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      e57121d0
  15. Nov 01, 2016
  16. Jul 18, 2016
    • Herbert Xu's avatar
      crypto: chacha20poly1305 - Use skcipher · 1e1f0061
      Herbert Xu authored
      
      This patch converts chacha20poly1305 to use the new skcipher
      interface as opposed to ablkcipher.
      
      It also fixes a buglet where we may end up with an async poly1305
      when the user asks for a async algorithm.  This shouldn't be a
      problem yet as there aren't any async implementations of poly1305
      out there.
      
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      1e1f0061
  17. Dec 09, 2015
  18. Aug 17, 2015
  19. Jul 17, 2015
  20. Jun 17, 2015
  21. Jun 04, 2015
Loading