Eric Lee / smarc-fsl-linux-kernel

26 Sep, 2018

1 commit

  • c818695c7   evm: Don't deadlock if a crypto algorithm is unavailable ... Browse Code »

    [ Upstream commit e2861fa71641c6414831d628a1f4f793b6562580 ]

    When EVM attempts to appraise a file signed with a crypto algorithm the
    kernel doesn't have support for, it will cause the kernel to trigger a
    module load. If the EVM policy includes appraisal of kernel modules this
    will in turn call back into EVM - since EVM is holding a lock until the
    crypto initialisation is complete, this triggers a deadlock. Add a
    CRYPTO_NOLOAD flag and skip module loading if it's set, and add that flag
    in the EVM case in order to fail gracefully with an error message
    instead of deadlocking.

    Signed-off-by: Matthew Garrett
    Acked-by: Herbert Xu
    Signed-off-by: Mimi Zohar
    Signed-off-by: Sasha Levin
    Signed-off-by: Greg Kroah-Hartman

    Matthew Garrett
     

17 Feb, 2018

2 commits

  • 2f00eb279   crypto: hash - prevent using keyed hashes without setting key ... Browse Code »

    commit 9fa68f620041be04720d0cbfb1bd3ddfc6310b24 upstream.

    Currently, almost none of the keyed hash algorithms check whether a key
    has been set before proceeding. Some algorithms are okay with this and
    will effectively just use a key of all 0's or some other bogus default.
    However, others will severely break, as demonstrated using
    "hmac(sha3-512-generic)", the unkeyed use of which causes a kernel crash
    via a (potentially exploitable) stack buffer overflow.

    A while ago, this problem was solved for AF_ALG by pairing each hash
    transform with a 'has_key' bool. However, there are still other places
    in the kernel where userspace can specify an arbitrary hash algorithm by
    name, and the kernel uses it as unkeyed hash without checking whether it
    is really unkeyed. Examples of this include:

    - KEYCTL_DH_COMPUTE, via the KDF extension
    - dm-verity
    - dm-crypt, via the ESSIV support
    - dm-integrity, via the "internal hash" mode with no key given
    - drbd (Distributed Replicated Block Device)

    This bug is especially bad for KEYCTL_DH_COMPUTE as that requires no
    privileges to call.

    Fix the bug for all users by adding a flag CRYPTO_TFM_NEED_KEY to the
    ->crt_flags of each hash transform that indicates whether the transform
    still needs to be keyed or not. Then, make the hash init, import, and
    digest functions return -ENOKEY if the key is still needed.

    The new flag also replaces the 'has_key' bool which algif_hash was
    previously using, thereby simplifying the algif_hash implementation.

    Reported-by: syzbot
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu
    Signed-off-by: Greg Kroah-Hartman

    Eric Biggers
     
  • 8d906d183   crypto: hash - annotate algorithms taking optional key ... Browse Code »

    commit a208fa8f33031b9e0aba44c7d1b7e68eb0cbd29e upstream.

    We need to consistently enforce that keyed hashes cannot be used without
    setting the key. To do this we need a reliable way to determine whether
    a given hash algorithm is keyed or not. AF_ALG currently does this by
    checking for the presence of a ->setkey() method. However, this is
    actually slightly broken because the CRC-32 algorithms implement
    ->setkey() but can also be used without a key. (The CRC-32 "key" is not
    actually a cryptographic key but rather represents the initial state.
    If not overridden, then a default initial state is used.)

    Prepare to fix this by introducing a flag CRYPTO_ALG_OPTIONAL_KEY which
    indicates that the algorithm has a ->setkey() method, but it is not
    required to be called. Then set it on all the CRC-32 algorithms.

    The same also applies to the Adler-32 implementation in Lustre.

    Also, the cryptd and mcryptd templates have to pass through the flag
    from their underlying algorithm.

    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu
    Signed-off-by: Greg Kroah-Hartman

    Eric Biggers
     

10 Apr, 2017

1 commit

  • f437a3f47   crypto: api - Extend algorithm name limit to 128 bytes ... Browse Code »

    With the new explicit IV generators, we may now exceed the 64-byte
    length limit on the algorithm name, e.g., with

    echainiv(authencesn(hmac(sha256-generic),cbc(des3_ede-generic)))

    This patch extends the length limit to 128 bytes.

    Reported-by: Alexander Sverdlin
    Signed-off-by: Herbert Xu
    Acked-by: Alexander Sverdlin
    Tested-by: Alexander Sverdlin

    Herbert Xu
     

18 Dec, 2016

1 commit

  • 0aaf2146e   Merge tag 'docs-4.10-2' of git://git.lwn.net/linux ... Browse Code »

    Pull more documentation updates from Jonathan Corbet:
    "This converts the crypto DocBook to Sphinx"

    * tag 'docs-4.10-2' of git://git.lwn.net/linux:
    crypto: doc - optimize compilation
    crypto: doc - clarify AEAD memory structure
    crypto: doc - remove crypto_alloc_ablkcipher
    crypto: doc - add KPP documentation
    crypto: doc - fix separation of cipher / req API
    crypto: doc - fix source comments for Sphinx
    crypto: doc - remove crypto API DocBook
    crypto: doc - convert crypto API documentation to Sphinx

    Linus Torvalds
     

14 Dec, 2016

1 commit

01 Dec, 2016

1 commit

25 Oct, 2016

2 commits

18 Jul, 2016

2 commits

  • 3a01d0ee2   crypto: skcipher - Remove top-level givcipher interface ... Browse Code »

    This patch removes the old crypto_grab_skcipher helper and replaces
    it with crypto_grab_skcipher2.

    As this is the final entry point into givcipher this patch also
    removes all traces of the top-level givcipher interface, including
    all implicit IV generators such as chainiv.

    The bottom-level givcipher interface remains until the drivers
    using it are converted.

    Signed-off-by: Herbert Xu

    Herbert Xu
     
  • 4e6c3df4d   crypto: skcipher - Add low-level skcipher interface ... Browse Code »

    This patch allows skcipher algorithms and instances to be created
    and registered with the crypto API. They are accessible through
    the top-level skcipher interface, along with ablkcipher/blkcipher
    algorithms and instances.

    This patch also introduces a new parameter called chunk size
    which is meant for ciphers such as CTR and CTS which ostensibly
    can handle arbitrary lengths, but still behave like block ciphers
    in that you can only process a partial block at the very end.

    For these ciphers the block size will continue to be set to 1
    as it is now while the chunk size will be set to the underlying
    block size.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

23 Jun, 2016

1 commit

  • 4e5f2c400   crypto: kpp - Key-agreement Protocol Primitives API (KPP) ... Browse Code »

    Add key-agreement protocol primitives (kpp) API which allows to
    implement primitives required by protocols such as DH and ECDH.
    The API is composed mainly by the following functions
    * set_secret() - It allows the user to set his secret, also
    referred to as his private key, along with the parameters
    known to both parties involved in the key-agreement session.
    * generate_public_key() - It generates the public key to be sent to
    the other counterpart involved in the key-agreement session. The
    function has to be called after set_params() and set_secret()
    * generate_secret() - It generates the shared secret for the session

    Other functions such as init() and exit() are provided for allowing
    cryptographic hardware to be inizialized properly before use

    Signed-off-by: Salvatore Benedetto
    Signed-off-by: Herbert Xu

    Salvatore Benedetto
     

07 Jun, 2016

1 commit

15 Apr, 2016

1 commit

06 Feb, 2016

1 commit

27 Jan, 2016

1 commit

17 Aug, 2015

2 commits

22 Jun, 2015

1 commit

  • 3e90950d3   crypto: algif_aead - Temporarily disable all AEAD algorithms ... Browse Code »

    As the AEAD conversion is still ongoing, we do not yet wish to
    export legacy AEAD implementations to user-space, as their calling
    convention will change.

    This patch actually disables all AEAD algorithms because some of
    them (e.g., cryptd) will need to be modified to propagate this flag.

    Subsequent patches will reenable them on an individual basis.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

19 Jun, 2015

1 commit

  • edf18b910   crypto: api - Add CRYPTO_MINALIGN_ATTR to struct crypto_alg ... Browse Code »

    The struct crypto_alg is embedded into various type-specific structs
    such as aead_alg. This is then used as part of instances such as
    struct aead_instance. It is also embedded into the generic struct
    crypto_instance. In order to ensure that struct aead_instance can
    be converted to struct crypto_instance when necessary, we need to
    ensure that crypto_alg is aligned properly.

    This patch adds an alignment attribute to struct crypto_alg to
    ensure this.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

17 Jun, 2015

1 commit

04 Jun, 2015

1 commit

22 May, 2015

1 commit

  • 2d0f230fe   crypto: aead - Rename aead_alg to old_aead_alg ... Browse Code »

    This patch is the first step in the introduction of a new AEAD
    alg type. Unlike normal conversions this patch only renames the
    existing aead_alg structure because there are external references
    to it.

    Those references will be removed after this patch.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

13 May, 2015

1 commit

  • 5d1d65f8b   crypto: aead - Convert top level interface to new style ... Browse Code »

    This patch converts the top-level aead interface to the new style.
    All user-level AEAD interface code have been moved into crypto/aead.h.

    The allocation/free functions have switched over to the new way of
    allocating tfms.

    This patch also removes the double indrection on setkey so the
    indirection now exists only at the alg level.

    Apart from these there are no user-visible changes.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

22 Apr, 2015

2 commits

21 Apr, 2015

1 commit

  • d0e83059a   crypto: rng - Convert crypto_rng to new style crypto_type ... Browse Code »

    This patch converts the top-level crypto_rng to the "new" style.
    It was the last algorithm type added before we switched over
    to the new way of doing things exemplified by shash.

    All users will automatically switch over to the new interface.

    Note that this patch does not touch the low-level interface to
    rng implementations.

    Signed-off-by: Herbert Xu

    Herbert Xu
     

31 Mar, 2015

1 commit

  • 06ca7f68d   crypto: api - prevent helper ciphers from being used ... Browse Code »

    Several hardware related cipher implementations are implemented as
    follows: a "helper" cipher implementation is registered with the
    kernel crypto API.

    Such helper ciphers are never intended to be called by normal users. In
    some cases, calling them via the normal crypto API may even cause
    failures including kernel crashes. In a normal case, the "wrapping"
    ciphers that use the helpers ensure that these helpers are invoked
    such that they cannot cause any calamity.

    Considering the AF_ALG user space interface, unprivileged users can
    call all ciphers registered with the crypto API, including these
    helper ciphers that are not intended to be called directly. That
    means, with AF_ALG user space may invoke these helper ciphers
    and may cause undefined states or side effects.

    To avoid any potential side effects with such helpers, the patch
    prevents the helpers to be called directly. A new cipher type
    flag is added: CRYPTO_ALG_INTERNAL. This flag shall be used
    to mark helper ciphers. These ciphers can only be used if the
    caller invoke the cipher with CRYPTO_ALG_INTERNAL in the type and
    mask field.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

20 Jan, 2015

1 commit

  • 379dcfb40   crypto: doc - remove colons in comments ... Browse Code »

    As documented in Documentation/kernel-doc-nano-HOWTO.txt lines
    terminated with a colon are treated as headings.

    The current layout of the documentation when compiling the kernel
    crypto API DocBook documentation is messed up by by treating some lines
    as headings. The patch removes colons from comments that shall not be
    treated as headings.

    Signed-off-by: Stephan Mueller
    Signed-off-by: Herbert Xu

    Stephan Mueller
     

08 Jan, 2015

1 commit

24 Nov, 2014

1 commit

13 Nov, 2014

6 commits

01 Aug, 2014

1 commit

25 Mar, 2012

1 commit

  • ed2d265d1   Merge tag 'bug-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux ... Browse Code »

    Pull cleanup from Paul Gortmaker:
    "The changes shown here are to unify linux's BUG support under the one
    file. Due to historical reasons, we have some BUG code
    in bug.h and some in kernel.h -- i.e. the support for BUILD_BUG in
    linux/kernel.h predates the addition of linux/bug.h, but old code in
    kernel.h wasn't moved to bug.h at that time. As a band-aid, kernel.h
    was including to pseudo link them.

    This has caused confusion[1] and general yuck/WTF[2] reactions. Here
    is an example that violates the principle of least surprise:

    CC lib/string.o
    lib/string.c: In function 'strlcat':
    lib/string.c:225:2: error: implicit declaration of function 'BUILD_BUG_ON'
    make[2]: *** [lib/string.o] Error 1
    $
    $ grep linux/bug.h lib/string.c
    #include
    $

    We've included for the BUG infrastructure and yet we
    still get a compile fail! [We've not kernel.h for BUILD_BUG_ON.] Ugh -
    very confusing for someone who is new to kernel development.

    With the above in mind, the goals of this changeset are:

    1) find and fix any include/*.h files that were relying on the
    implicit presence of BUG code.
    2) find and fix any C files that were consuming kernel.h and hence
    relying on implicitly getting some/all BUG code.
    3) Move the BUG related code living in kernel.h to
    4) remove the asm/bug.h from kernel.h to finally break the chain.

    During development, the order was more like 3-4, build-test, 1-2. But
    to ensure that git history for bisect doesn't get needless build
    failures introduced, the commits have been reorderd to fix the problem
    areas in advance.

    [1] https://lkml.org/lkml/2012/1/3/90
    [2] https://lkml.org/lkml/2012/1/17/414"

    Fix up conflicts (new radeon file, reiserfs header cleanups) as per Paul
    and linux-next.

    * tag 'bug-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux:
    kernel.h: doesn't explicitly use bug.h, so don't include it.
    bug: consolidate BUILD_BUG_ON with other bug code
    BUG: headers with BUG/BUG_ON etc. need linux/bug.h
    bug.h: add include of it to various implicit C users
    lib: fix implicit users of kernel.h for TAINT_WARN
    spinlock: macroize assert_spin_locked to avoid bug.h dependency
    x86: relocate get/set debugreg fcns to include/asm/debugreg.

    Linus Torvalds
     

05 Mar, 2012

1 commit

  • 187f1882b   BUG: headers with BUG/BUG_ON etc. need linux/bug.h ... Browse Code »

    If a header file is making use of BUG, BUG_ON, BUILD_BUG_ON, or any
    other BUG variant in a static inline (i.e. not in a #define) then
    that header really should be including and not just
    expecting it to be implicitly present.

    We can make this change risk-free, since if the files using these
    headers didn't have exposure to linux/bug.h already, they would have
    been causing compile failures/warnings.

    Signed-off-by: Paul Gortmaker

    Paul Gortmaker