20 Aug, 2020

1 commit

  • The header file algapi.h includes skbuff.h unnecessarily since
    all we need is a forward declaration for struct sk_buff. This
    patch removes that inclusion.

    Unfortunately skbuff.h pulls in a lot of things and drivers over
    the years have come to rely on it so this patch adds a lot of
    missing inclusions that result from this.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

09 Jan, 2020

1 commit

  • The CRYPTO_TFM_RES_BAD_KEY_LEN flag was apparently meant as a way to
    make the ->setkey() functions provide more information about errors.

    However, no one actually checks for this flag, which makes it pointless.

    Also, many algorithms fail to set this flag when given a bad length key.
    Reviewing just the generic implementations, this is the case for
    aes-fixed-time, cbcmac, echainiv, nhpoly1305, pcrypt, rfc3686, rfc4309,
    rfc7539, rfc7539esp, salsa20, seqiv, and xcbc. But there are probably
    many more in arch/*/crypto/ and drivers/crypto/.

    Some algorithms can even set this flag when the key is the correct
    length. For example, authenc and authencesn set it when the key payload
    is malformed in any way (not just a bad length), the atmel-sha and ccree
    drivers can set it if a memory allocation fails, and the chelsio driver
    sets it for bad auth tag lengths, not just bad key lengths.

    So even if someone actually wanted to start checking this flag (which
    seems unlikely, since it's been unused for a long time), there would be
    a lot of work needed to get it working correctly. But it would probably
    be much better to go back to the drawing board and just define 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 this flag.

    Signed-off-by: Eric Biggers
    Reviewed-by: Horia Geantă
    Signed-off-by: Herbert Xu

    Eric Biggers
     

17 Nov, 2019

1 commit

  • Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface")
    dated 20 august 2015 introduced the new skcipher API which is supposed to
    replace both blkcipher and ablkcipher. While all consumers of the API have
    been converted long ago, some producers of the ablkcipher remain, forcing
    us to keep the ablkcipher support routines alive, along with the matching
    code to expose [a]blkciphers via the skcipher API.

    So switch this driver to the skcipher API, allowing us to finally drop the
    ablkcipher code in the near future.

    Cc: Heiko Stuebner
    Signed-off-by: Ard Biesheuvel
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     

22 Aug, 2019

1 commit


09 Aug, 2019

1 commit


05 Jun, 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 and conditions of the gnu general public license
    version 2 as published by the free software foundation

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

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

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

    Thomas Gleixner
     

21 May, 2019

1 commit


18 Apr, 2019

2 commits


22 Feb, 2019

2 commits

  • For chain mode in cipher(eg. AES-CBC/DES-CBC), the iv is continuously
    updated in the operation. The new iv value should be written to device
    register by software.

    Reported-by: Eric Biggers
    Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288")
    Cc: # v4.5+
    Signed-off-by: Zhang Zhijie
    Signed-off-by: Herbert Xu

    Zhang Zhijie
     
  • In some cases, the nents of src scatterlist is different from
    dst scatterlist. So two variables are used to handle the nents
    of src&dst scatterlist.

    Reported-by: Eric Biggers
    Fixes: 433cd2c617bf ("crypto: rockchip - add crypto driver for rk3288")
    Cc: # v4.5+
    Signed-off-by: Zhang Zhijie
    Signed-off-by: Herbert Xu

    Zhang Zhijie
     

25 Jan, 2019

1 commit

  • CRYPTO_TFM_REQ_WEAK_KEY confuses newcomers to the crypto API because it
    sounds like it is requesting a weak key. Actually, it is requesting
    that weak keys be forbidden (for algorithms that have the notion of
    "weak keys"; currently only DES and XTS do).

    Also it is only one letter away from CRYPTO_TFM_RES_WEAK_KEY, with which
    it can be easily confused. (This in fact happened in the UX500 driver,
    though just in some debugging messages.)

    Therefore, make the intent clear by renaming it to
    CRYPTO_TFM_REQ_FORBID_WEAK_KEYS.

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

    Eric Biggers
     

02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

22 Aug, 2017

1 commit


03 Aug, 2017

2 commits


24 Aug, 2016

1 commit

  • If devm_add_action() fails we are explicitly calling the cleanup to free
    the resources allocated. Lets use the helper devm_add_action_or_reset()
    and return directly in case of error, as we know that the cleanup function
    has been already called by the helper if there was any error.

    Signed-off-by: Sudip Mukherjee
    Reviewed-by: Heiko Stuebner
    Signed-off-by: Herbert Xu

    Sudip Mukherjee
     

28 Feb, 2016

1 commit


04 Dec, 2015

1 commit

  • Lockdep warns about a possible deadlock resulting from the use of regular
    spin_locks:

    =================================
    [ INFO: inconsistent lock state ]
    4.4.0-rc2+ #2724 Not tainted
    ---------------------------------
    inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
    ksoftirqd/0/3 [HC0[0]:SC1[1]:HE1:SE0] takes:
    (&(&crypto_info->lock)->rlock){+.?...}, at: [] rk_crypto_tasklet_cb+0x24/0xb4 [rk_crypto]
    {SOFTIRQ-ON-W} state was registered at:
    [] lock_acquire+0x178/0x218
    [] _raw_spin_lock+0x54/0x64
    [] rk_handle_req+0x7c/0xbc [rk_crypto]
    [] rk_des_ecb_encrypt+0x2c/0x30 [rk_crypto]
    [] rk_aes_ecb_encrypt+0x18/0x1c [rk_crypto]
    [] skcipher_encrypt_ablkcipher+0x64/0x68
    [] __test_skcipher+0x2a8/0x8dc
    [] test_skcipher+0x38/0xc4
    [] alg_test_skcipher+0x90/0xb0
    [] alg_test+0x1e8/0x280
    [] cryptomgr_test+0x34/0x54
    [] kthread+0xf4/0x10c
    [] ret_from_fork+0x14/0x24
    irq event stamp: 10672
    hardirqs last enabled at (10672): [] tasklet_action+0x48/0x104
    hardirqs last disabled at (10671): [] tasklet_action+0x20/0x104
    softirqs last enabled at (10658): [] __do_softirq+0x358/0x49c
    softirqs last disabled at (10669): [] run_ksoftirqd+0x40/0x80

    other info that might help us debug this:
    Possible unsafe locking scenario:

    CPU0
    ----
    lock(&(&crypto_info->lock)->rlock);

    lock(&(&crypto_info->lock)->rlock);

    *** DEADLOCK ***

    Fix this by moving to irq-disabling spinlocks.

    Signed-off-by: Heiko Stuebner
    Signed-off-by: Herbert Xu

    Heiko Stuebner
     

27 Nov, 2015

1 commit

  • Crypto driver support:
    ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
    You can alloc tags above in your case.

    And other algorithms and platforms will be added later on.

    Signed-off-by: Zain Wang
    Tested-by: Heiko Stuebner
    Signed-off-by: Herbert Xu

    Zain Wang