Eric Lee / smarc-fsl-linux-kernel

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
     

09 Jul, 2019

1 commit

  • 4d2fa8b44   Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 ... Browse Code »

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

    API:
    - Test shash interface directly in testmgr
    - cra_driver_name is now mandatory

    Algorithms:
    - Replace arc4 crypto_cipher with library helper
    - Implement 5 way interleave for ECB, CBC and CTR on arm64
    - Add xxhash
    - Add continuous self-test on noise source to drbg
    - Update jitter RNG

    Drivers:
    - Add support for SHA204A random number generator
    - Add support for 7211 in iproc-rng200
    - Fix fuzz test failures in inside-secure
    - Fix fuzz test failures in talitos
    - Fix fuzz test failures in qat"

    * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (143 commits)
    crypto: stm32/hash - remove interruptible condition for dma
    crypto: stm32/hash - Fix hmac issue more than 256 bytes
    crypto: stm32/crc32 - rename driver file
    crypto: amcc - remove memset after dma_alloc_coherent
    crypto: ccp - Switch to SPDX license identifiers
    crypto: ccp - Validate the the error value used to index error messages
    crypto: doc - Fix formatting of new crypto engine content
    crypto: doc - Add parameter documentation
    crypto: arm64/aes-ce - implement 5 way interleave for ECB, CBC and CTR
    crypto: arm64/aes-ce - add 5 way interleave routines
    crypto: talitos - drop icv_ool
    crypto: talitos - fix hash on SEC1.
    crypto: talitos - move struct talitos_edesc into talitos.h
    lib/scatterlist: Fix mapping iterator when sg->offset is greater than PAGE_SIZE
    crypto/NX: Set receive window credits to max number of CRBs in RxFIFO
    crypto: asymmetric_keys - select CRYPTO_HASH where needed
    crypto: serpent - mark __serpent_setkey_sbox noinline
    crypto: testmgr - dynamically allocate crypto_shash
    crypto: testmgr - dynamically allocate testvec_config
    crypto: talitos - eliminate unneeded 'done' functions at build time
    ...

    Linus Torvalds
     

20 Jun, 2019

1 commit

19 Jun, 2019

1 commit

  • 21042e414   treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 501 ... Browse Code »

    Based on 1 normalized pattern(s):

    this program is free software you can redistribute it and or modify
    it under the terms of the gnu general public license version 2 as
    published by the free software foundation see readme and copying for
    more details

    extracted by the scancode license scanner the SPDX license identifier

    GPL-2.0-only

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

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

    Thomas Gleixner
     

25 Apr, 2019

1 commit

  • 877b5691f   crypto: shash - remove shash_desc::flags ... Browse Code »

    The flags field in 'struct shash_desc' never actually does anything.
    The only ostensibly supported flag is CRYPTO_TFM_REQ_MAY_SLEEP.
    However, no shash algorithm ever sleeps, making this flag a no-op.

    With this being the case, inevitably some users who can't sleep wrongly
    pass MAY_SLEEP. These would all need to be fixed if any shash algorithm
    actually started sleeping. For example, the shash_ahash_*() functions,
    which wrap a shash algorithm with the ahash API, pass through MAY_SLEEP
    from the ahash API to the shash API. However, the shash functions are
    called under kmap_atomic(), so actually they're assumed to never sleep.

    Even if it turns out that some users do need preemption points while
    hashing large buffers, we could easily provide a helper function
    crypto_shash_update_large() which divides the data into smaller chunks
    and calls crypto_shash_update() and cond_resched() for each chunk. It's
    not necessary to have a flag in 'struct shash_desc', nor is it necessary
    to make individual shash algorithms aware of this at all.

    Therefore, remove shash_desc::flags, and document that the
    crypto_shash_*() functions can be called from any context.

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

    Eric Biggers
     

20 Nov, 2018

1 commit

  • 1ad0f1603   crypto: drop mask=CRYPTO_ALG_ASYNC from 'cipher' tfm allocations ... Browse Code »

    'cipher' algorithms (single block ciphers) are always synchronous, so
    passing CRYPTO_ALG_ASYNC in the mask to crypto_alloc_cipher() has no
    effect. Many users therefore already don't pass it, but some still do.
    This inconsistency can cause confusion, especially since the way the
    'mask' argument works is somewhat counterintuitive.

    Thus, just remove the unneeded CRYPTO_ALG_ASYNC flags.

    This patch shouldn't change any actual behavior.

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

    Eric Biggers
     

10 Oct, 2018

1 commit

24 Jul, 2018

1 commit

  • d17504b16   wireless/lib80211: Convert from ahash to shash ... Browse Code »

    In preparing to remove all stack VLA usage from the kernel[1], this
    removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of
    the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash
    to direct shash. The stack allocation will be made a fixed size in a
    later patch to the crypto subsystem.

    [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com

    Signed-off-by: Kees Cook
    Signed-off-by: Johannes Berg

    Kees Cook
     

17 Nov, 2016

1 commit

  • 10f3366b4   wireless: fix bogus maybe-uninitialized warning ... Browse Code »

    The hostap_80211_rx() function is supposed to set up the mac addresses
    for four possible cases, based on two bits of input data. For
    some reason, gcc decides that it's possible that none of the these
    four cases apply and the addresses remain uninitialized:

    drivers/net/wireless/intersil/hostap/hostap_80211_rx.c: In function ‘hostap_80211_rx’:
    arch/x86/include/asm/string_32.h:77:14: warning: ‘src’ may be used uninitialized in this function [-Wmaybe-uninitialized]
    drivers/net/wireless/intel/ipw2x00/libipw_rx.c: In function ‘libipw_rx’:
    arch/x86/include/asm/string_32.h:77:14: error: ‘dst’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
    arch/x86/include/asm/string_32.h:78:22: error: ‘*((void *)&dst+4)’ may be used uninitialized in this function [-Werror=maybe-uninitialized]

    This warning is clearly nonsense, but changing the last case into
    'default' makes it obvious to the compiler too, which avoids the
    warning and probably leads to better object code too.

    The same code is duplicated several times in the kernel, so this
    patch uses the same workaround for all copies. The exact configuration
    was hit only very rarely in randconfig builds and I only saw it
    in three drivers, but I assume that all of them are potentially
    affected, and it's better to keep the code consistent.

    Signed-off-by: Arnd Bergmann
    Signed-off-by: Kalle Valo

    Arnd Bergmann
     

27 Jan, 2016

1 commit

04 Dec, 2015

1 commit

  • 996bf99c7   lib80211: ratelimit key index mismatch ... Browse Code »

    This indicates a driver key selection issue, but even then there's
    no point in printing it all the time, so ratelimit it. Also remove
    the priv pointer from it -- people debugging will only have a single
    device anyway and it's useless as anything but a cookie.

    Signed-off-by: Johannes Berg

    Johannes Berg
     

30 Apr, 2013

1 commit

  • 6bbefe867   hostap: Don't use create_proc_read_entry() ... Browse Code »

    Don't use create_proc_read_entry() as that is deprecated, but rather use
    proc_create_data() and seq_file instead.

    Signed-off-by: David Howells
    Acked-by: Greg Kroah-Hartman
    cc: Jouni Malinen
    cc: John W. Linville
    cc: Johannes Berg
    cc: linux-wireless@vger.kernel.org
    cc: netdev@vger.kernel.org
    cc: devel@driverdev.osuosl.org
    Signed-off-by: Al Viro

    David Howells
     

16 May, 2012

1 commit

14 Sep, 2011

1 commit

25 Nov, 2010

1 commit

27 Jul, 2010

1 commit

21 Jul, 2010

1 commit

03 Feb, 2010

2 commits

17 Mar, 2009

1 commit

22 Nov, 2008

1 commit