Eric Lee / smarc-fsl-linux-kernel

18 Apr, 2019

1 commit

  • c4741b230   crypto: run initcalls for generic implementations earlier ... Browse Code »

    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

  • 5e27f38f1   crypto: chacha20poly1305 - set cra_name correctly ... Browse Code »

    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

  • 1ca1b9179   crypto: chacha20-generic - refactor to allow varying number of rounds ... Browse Code »

    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

  • e57121d08   crypto: chacha20poly1305 - validate the digest size ... Browse Code »

    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

  • 1e1f00611   crypto: chacha20poly1305 - Use skcipher ... Browse Code »

    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