Eric Lee / smarc-fsl-linux-kernel

25 Sep, 2020

1 commit

04 Sep, 2020

2 commits

08 Aug, 2020

1 commit

  • 453431a54   mm, treewide: rename kzfree() to kfree_sensitive() ... Browse Code »

    As said by Linus:

    A symmetric naming is only helpful if it implies symmetries in use.
    Otherwise it's actively misleading.

    In "kzalloc()", the z is meaningful and an important part of what the
    caller wants.

    In "kzfree()", the z is actively detrimental, because maybe in the
    future we really _might_ want to use that "memfill(0xdeadbeef)" or
    something. The "zero" part of the interface isn't even _relevant_.

    The main reason that kzfree() exists is to clear sensitive information
    that should not be leaked to other future users of the same memory
    objects.

    Rename kzfree() to kfree_sensitive() to follow the example of the recently
    added kvfree_sensitive() and make the intention of the API more explicit.
    In addition, memzero_explicit() is used to clear the memory to make sure
    that it won't get optimized away by the compiler.

    The renaming is done by using the command sequence:

    git grep -w --name-only kzfree |\
    xargs sed -i 's/kzfree/kfree_sensitive/'

    followed by some editing of the kfree_sensitive() kerneldoc and adding
    a kzfree backward compatibility macro in slab.h.

    [akpm@linux-foundation.org: fs/crypto/inline_crypt.c needs linux/slab.h]
    [akpm@linux-foundation.org: fix fs/crypto/inline_crypt.c some more]

    Suggested-by: Joe Perches
    Signed-off-by: Waiman Long
    Signed-off-by: Andrew Morton
    Acked-by: David Howells
    Acked-by: Michal Hocko
    Acked-by: Johannes Weiner
    Cc: Jarkko Sakkinen
    Cc: James Morris
    Cc: "Serge E. Hallyn"
    Cc: Joe Perches
    Cc: Matthew Wilcox
    Cc: David Rientjes
    Cc: Dan Carpenter
    Cc: "Jason A . Donenfeld"
    Link: http://lkml.kernel.org/r/20200616154311.12314-3-longman@redhat.com
    Signed-off-by: Linus Torvalds

    Waiman Long
     

16 Jul, 2020

3 commits

  • b8aa7dc5c   crypto: drivers - set the flag CRYPTO_ALG_ALLOCATES_MEMORY ... Browse Code »

    Set the flag CRYPTO_ALG_ALLOCATES_MEMORY in the crypto drivers that
    allocate memory.

    drivers/crypto/allwinner/sun8i-ce/sun8i-ce-core.c: sun8i_ce_cipher
    drivers/crypto/allwinner/sun8i-ss/sun8i-ss-core.c: sun8i_ss_cipher
    drivers/crypto/amlogic/amlogic-gxl-core.c: meson_cipher
    drivers/crypto/axis/artpec6_crypto.c: artpec6_crypto_common_init
    drivers/crypto/bcm/cipher.c: spu_skcipher_rx_sg_create
    drivers/crypto/caam/caamalg.c: aead_edesc_alloc
    drivers/crypto/caam/caamalg_qi.c: aead_edesc_alloc
    drivers/crypto/caam/caamalg_qi2.c: aead_edesc_alloc
    drivers/crypto/caam/caamhash.c: hash_digest_key
    drivers/crypto/cavium/cpt/cptvf_algs.c: process_request
    drivers/crypto/cavium/nitrox/nitrox_aead.c: nitrox_process_se_request
    drivers/crypto/cavium/nitrox/nitrox_skcipher.c: nitrox_process_se_request
    drivers/crypto/ccp/ccp-crypto-aes-cmac.c: ccp_do_cmac_update
    drivers/crypto/ccp/ccp-crypto-aes-galois.c: ccp_crypto_enqueue_request
    drivers/crypto/ccp/ccp-crypto-aes-xts.c: ccp_crypto_enqueue_request
    drivers/crypto/ccp/ccp-crypto-aes.c: ccp_crypto_enqueue_request
    drivers/crypto/ccp/ccp-crypto-des3.c: ccp_crypto_enqueue_request
    drivers/crypto/ccp/ccp-crypto-sha.c: ccp_crypto_enqueue_request
    drivers/crypto/chelsio/chcr_algo.c: create_cipher_wr
    drivers/crypto/hisilicon/sec/sec_algs.c: sec_alloc_and_fill_hw_sgl
    drivers/crypto/hisilicon/sec2/sec_crypto.c: sec_alloc_req_id
    drivers/crypto/inside-secure/safexcel_cipher.c: safexcel_queue_req
    drivers/crypto/inside-secure/safexcel_hash.c: safexcel_ahash_enqueue
    drivers/crypto/ixp4xx_crypto.c: ablk_perform
    drivers/crypto/marvell/cesa/cipher.c: mv_cesa_skcipher_dma_req_init
    drivers/crypto/marvell/cesa/hash.c: mv_cesa_ahash_dma_req_init
    drivers/crypto/marvell/octeontx/otx_cptvf_algs.c: create_ctx_hdr
    drivers/crypto/n2_core.c: n2_compute_chunks
    drivers/crypto/picoxcell_crypto.c: spacc_sg_to_ddt
    drivers/crypto/qat/qat_common/qat_algs.c: qat_alg_skcipher_encrypt
    drivers/crypto/qce/skcipher.c: qce_skcipher_async_req_handle
    drivers/crypto/talitos.c : talitos_edesc_alloc
    drivers/crypto/virtio/virtio_crypto_algs.c: __virtio_crypto_skcipher_do_req
    drivers/crypto/xilinx/zynqmp-aes-gcm.c: zynqmp_aes_aead_cipher

    Signed-off-by: Mikulas Patocka
    [EB: avoid overly-long lines]
    Signed-off-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Mikulas Patocka
     
  • 1d63e4557   crypto: amlogic-gxl - permit async skcipher as fallback ... Browse Code »

    Even though the amlogic-gxl driver implements asynchronous versions of
    ecb(aes) and cbc(aes), the fallbacks it allocates are required to be
    synchronous. Given that SIMD based software implementations are usually
    asynchronous as well, even though they rarely complete asynchronously
    (this typically only happens in cases where the request was made from
    softirq context, while SIMD was already in use in the task context that
    it interrupted), these implementations are disregarded, and either the
    generic C version or another table based version implemented in assembler
    is selected instead.

    Since falling back to synchronous AES is not only a performance issue,
    but potentially a security issue as well (due to the fact that table
    based AES is not time invariant), let's fix this, by allocating an
    ordinary skcipher as the fallback, and invoke it with the completion
    routine that was given to the outer request.

    Signed-off-by: Ard Biesheuvel
    Tested-by: Corentin Labbe
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     
  • 3f368b886   crypto: amlogic-gxl - default to build as module ... Browse Code »

    The AmLogic GXL crypto accelerator driver is built into the kernel if
    ARCH_MESON is set. However, given the single image policy of arm64, its
    defconfig enables all platforms by default, and so ARCH_MESON is usually
    enabled.

    This means that the AmLogic driver causes the arm64 defconfig build to
    pull in a huge chunk of the crypto stack as a builtin as well, which is
    undesirable, so let's make the amlogic GXL driver default to 'm' instead.

    Signed-off-by: Ard Biesheuvel
    Tested-by: Corentin Labbe
    Signed-off-by: Herbert Xu

    Ard Biesheuvel
     

16 Apr, 2020

1 commit

16 Jan, 2020

1 commit

  • 24775ac2f   crypto: amlogic - fix removal of module ... Browse Code »

    Removing the driver cause an oops due to the fact we clean an extra
    channel.
    Let's give the right index to the cleaning function.
    Fixes: 48fe583fe541 ("crypto: amlogic - Add crypto accelerator for amlogic GXL")

    Signed-off-by: Corentin Labbe
    Signed-off-by: Herbert Xu

    Corentin Labbe
     

09 Jan, 2020

1 commit

  • 674f368a9   crypto: remove CRYPTO_TFM_RES_BAD_KEY_LEN ... Browse Code »

    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
     

20 Dec, 2019

1 commit

  • 7d07de2c1   crypto: amlogic - add unspecified HAS_IOMEM dependency ... Browse Code »

    Currently CONFIG_CRYPTO_DEV_AMLOGIC_GXL=y implicitly depends on
    CONFIG_HAS_IOMEM=y; consequently, on architectures without IOMEM we get
    the following build error:

    ld: drivers/crypto/amlogic/amlogic-gxl-core.o: in function `meson_crypto_probe':
    drivers/crypto/amlogic/amlogic-gxl-core.c:240: undefined reference to `devm_platform_ioremap_resource'

    Fix the build error by adding the unspecified dependency.

    Reported-by: Brendan Higgins
    Signed-off-by: Brendan Higgins
    Acked-by: Corentin Labbe
    Signed-off-by: Herbert Xu

    Brendan Higgins
     

22 Nov, 2019

1 commit

  • 3d0415881   crypto: amlogic - enable working on big endian kernel ... Browse Code »

    On big endian kernel, the GXL crypto driver does not works.
    This patch do the necessary modification to permit it to work on BE
    kernel (removing bitfield and adds some cpu_to_le32).

    Fixes: 48fe583fe541 ("crypto: amlogic - Add crypto accelerator for amlogic GXL")
    Signed-off-by: Corentin Labbe
    Signed-off-by: Herbert Xu

    Corentin Labbe
     

17 Nov, 2019

1 commit

  • 56601574c   crypto: amlogic - fix two resources leak ... Browse Code »

    This patch fixes two resources leak that occur on error path.

    Reported-by: coverity-bot
    Addresses-Coverity-ID: 1487403 ("RESOURCE_LEAK")
    Addresses-Coverity-ID: 1487401 ("Resource leaks")
    Fixes: 48fe583fe541 ("crypto: amlogic - Add crypto accelerator for amlogic GXL")
    Signed-off-by: Corentin Labbe
    Reviewed-by: Kees Cook
    Signed-off-by: Herbert Xu

    Corentin Labbe
     

08 Nov, 2019

2 commits

01 Nov, 2019

1 commit

25 Oct, 2019

1 commit