Eric Lee / smarc-fsl-linux-kernel

22 Apr, 2015

1 commit

16 Apr, 2015

1 commit

  • cb906953d   Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 ... Browse Code »

    Pull crypto update from Herbert Xu:
    "Here is the crypto update for 4.1:

    New interfaces:
    - user-space interface for AEAD
    - user-space interface for RNG (i.e., pseudo RNG)

    New hashes:
    - ARMv8 SHA1/256
    - ARMv8 AES
    - ARMv8 GHASH
    - ARM assembler and NEON SHA256
    - MIPS OCTEON SHA1/256/512
    - MIPS img-hash SHA1/256 and MD5
    - Power 8 VMX AES/CBC/CTR/GHASH
    - PPC assembler AES, SHA1/256 and MD5
    - Broadcom IPROC RNG driver

    Cleanups/fixes:
    - prevent internal helper algos from being exposed to user-space
    - merge common code from assembly/C SHA implementations
    - misc fixes"

    * git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (169 commits)
    crypto: arm - workaround for building with old binutils
    crypto: arm/sha256 - avoid sha256 code on ARMv7-M
    crypto: x86/sha512_ssse3 - move SHA-384/512 SSSE3 implementation to base layer
    crypto: x86/sha256_ssse3 - move SHA-224/256 SSSE3 implementation to base layer
    crypto: x86/sha1_ssse3 - move SHA-1 SSSE3 implementation to base layer
    crypto: arm64/sha2-ce - move SHA-224/256 ARMv8 implementation to base layer
    crypto: arm64/sha1-ce - move SHA-1 ARMv8 implementation to base layer
    crypto: arm/sha2-ce - move SHA-224/256 ARMv8 implementation to base layer
    crypto: arm/sha256 - move SHA-224/256 ASM/NEON implementation to base layer
    crypto: arm/sha1-ce - move SHA-1 ARMv8 implementation to base layer
    crypto: arm/sha1_neon - move SHA-1 NEON implementation to base layer
    crypto: arm/sha1 - move SHA-1 ARM asm implementation to base layer
    crypto: sha512-generic - move to generic glue implementation
    crypto: sha256-generic - move to generic glue implementation
    crypto: sha1-generic - move to generic glue implementation
    crypto: sha512 - implement base layer for SHA-512
    crypto: sha256 - implement base layer for SHA-256
    crypto: sha1 - implement base layer for SHA-1
    crypto: api - remove instance when test failed
    crypto: api - Move alg ref count init to crypto_check_alg
    ...

    Linus Torvalds
     

16 Mar, 2015

1 commit

03 Mar, 2015

1 commit

  • 1b7841404   net: Remove iocb argument from sendmsg and recvmsg ... Browse Code »

    After TIPC doesn't depend on iocb argument in its internal
    implementations of sendmsg() and recvmsg() hooks defined in proto
    structure, no any user is using iocb argument in them at all now.
    Then we can drop the redundant iocb argument completely from kinds of
    implementations of both sendmsg() and recvmsg() in the entire
    networking stack.

    Cc: Christoph Hellwig
    Suggested-by: Al Viro
    Signed-off-by: Ying Xue
    Signed-off-by: David S. Miller

    Ying Xue
     

14 Jan, 2015

1 commit

29 Dec, 2014

1 commit

  • 5afdfd22e   crypto: algif_rng - add random number generator support ... Browse Code »

    This patch adds the random number generator support for AF_ALG.

    A random number generator's purpose is to generate data without
    requiring the caller to provide any data. Therefore, the AF_ALG
    interface handler for RNGs only implements a callback handler for
    recvmsg.

    The following parameters provided with a recvmsg are processed by the
    RNG callback handler:

    * sock - to resolve the RNG context data structure accessing the
    RNG instance private to the socket

    * len - this parameter allows userspace callers to specify how
    many random bytes the RNG shall produce and return. As the
    kernel context for the RNG allocates a buffer of 128 bytes to
    store random numbers before copying them to userspace, the len
    parameter is checked that it is not larger than 128. If a
    caller wants more random numbers, a new request for recvmsg
    shall be made.

    The size of 128 bytes is chose because of the following considerations:

    * to increase the memory footprint of the kernel too much (note,
    that would be 128 bytes per open socket)

    * 128 is divisible by any typical cryptographic block size an
    RNG may have

    * A request for random numbers typically only shall supply small
    amount of data like for keys or IVs that should only require
    one invocation of the recvmsg function.

    Note, during instantiation of the RNG, the code checks whether the RNG
    implementation requires seeding. If so, the RNG is seeded with output
    from get_random_bytes.

    A fully working example using all aspects of the RNG interface is
    provided at http://www.chronox.de/libkcapi.html

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

    Stephan Mueller