16 Jul, 2020

1 commit

  • 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
    (https://lore.kernel.org/r/alpine.LRH.2.02.2006301414580.30526@file01.intranet.prod.int.rdu2.redhat.com).

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

    Eric Biggers
     

09 Jan, 2020

3 commits

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

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

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

    Eric Biggers
     

09 Jul, 2019

1 commit

  • Pull crypto updates from Herbert Xu:
    "Here is the crypto update for 5.3:

    API:
    - Test shash interface directly in testmgr
    - cra_driver_name is now mandatory

    Algorithms:
    - Replace arc4 crypto_cipher with library helper
    - Implement 5 way interleave for ECB, CBC and CTR on arm64
    - Add xxhash
    - Add continuous self-test on noise source to drbg
    - Update jitter RNG

    Drivers:
    - Add support for SHA204A random number generator
    - Add support for 7211 in iproc-rng200
    - Fix fuzz test failures in inside-secure
    - Fix fuzz test failures in talitos
    - Fix fuzz test failures in qat"

    * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (143 commits)
    crypto: stm32/hash - remove interruptible condition for dma
    crypto: stm32/hash - Fix hmac issue more than 256 bytes
    crypto: stm32/crc32 - rename driver file
    crypto: amcc - remove memset after dma_alloc_coherent
    crypto: ccp - Switch to SPDX license identifiers
    crypto: ccp - Validate the the error value used to index error messages
    crypto: doc - Fix formatting of new crypto engine content
    crypto: doc - Add parameter documentation
    crypto: arm64/aes-ce - implement 5 way interleave for ECB, CBC and CTR
    crypto: arm64/aes-ce - add 5 way interleave routines
    crypto: talitos - drop icv_ool
    crypto: talitos - fix hash on SEC1.
    crypto: talitos - move struct talitos_edesc into talitos.h
    lib/scatterlist: Fix mapping iterator when sg->offset is greater than PAGE_SIZE
    crypto/NX: Set receive window credits to max number of CRBs in RxFIFO
    crypto: asymmetric_keys - select CRYPTO_HASH where needed
    crypto: serpent - mark __serpent_setkey_sbox noinline
    crypto: testmgr - dynamically allocate crypto_shash
    crypto: testmgr - dynamically allocate testvec_config
    crypto: talitos - eliminate unneeded 'done' functions at build time
    ...

    Linus Torvalds
     

13 Jun, 2019

1 commit

  • - Use sg_init_one() instead of sg_init_table() then sg_set_buf().

    - Remove unneeded calls to sg_init_table() prior to scatterwalk_ffwd().

    - Simplify initializing the poly tail block.

    - Simplify computing padlen.

    This doesn't change any actual behavior.

    Cc: Martin Willi
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

06 Jun, 2019

1 commit

  • 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: 71ebc4d1b27d ("crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD construction, RFC7539")
    Cc: # v4.2+
    Cc: Martin Willi
    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
     

08 Apr, 2019

1 commit

  • 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: 71ebc4d1b27d ("crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD construction, RFC7539")
    Cc: # v4.2+
    Cc: Martin Willi
    Signed-off-by: Eric Biggers
    Reviewed-by: Martin Willi
    Signed-off-by: Herbert Xu

    Eric Biggers
     

25 Jan, 2019

1 commit


20 Nov, 2018

1 commit

  • 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: Ard Biesheuvel
    Acked-by: Martin Willi
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

16 Nov, 2018

1 commit


22 Dec, 2017

1 commit

  • 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
    #include
    #include

    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: syzbot
    Fixes: 71ebc4d1b27d ("crypto: chacha20poly1305 - Add a ChaCha20-Poly1305 AEAD construction, RFC7539")
    Cc: # v4.2+
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Eric Biggers
     

01 Nov, 2016

2 commits


18 Jul, 2016

1 commit

  • 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: Herbert Xu

    Herbert Xu
     

09 Dec, 2015

1 commit


17 Aug, 2015

1 commit


17 Jul, 2015

3 commits


17 Jun, 2015

1 commit


04 Jun, 2015

2 commits