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
     

22 Dec, 2017

1 commit

03 Nov, 2017

1 commit

05 Apr, 2017

1 commit

  • acb9b159c   crypto: gf128mul - define gf128mul_x_* in gf128mul.h ... Browse Code »

    The gf128mul_x_ble function is currently defined in gf128mul.c, because
    it depends on the gf128mul_table_be multiplication table.

    However, since the function is very small and only uses two values from
    the table, it is better for it to be defined as inline function in
    gf128mul.h. That way, the function can be inlined by the compiler for
    better performance.

    For consistency, the other gf128mul_x_* functions are also moved to the
    header file. In addition, the code is rewritten to be constant-time.

    After this change, the speed of the generic 'xts(aes)' implementation
    increased from ~225 MiB/s to ~235 MiB/s (measured using 'cryptsetup
    benchmark -c aes-xts-plain64' on an Intel system with CRYPTO_AES_X86_64
    and CRYPTO_AES_NI_INTEL disabled).

    Signed-off-by: Ondrej Mosnacek
    Reviewd-by: Eric Biggers
    Signed-off-by: Herbert Xu

    Ondrej Mosnáček
     

09 Mar, 2017

4 commits

17 Nov, 2016

1 commit

13 Nov, 2016

1 commit

  • d266f44b5   crypto: gf128mul - remove dead gf128mul_64k_lle code ... Browse Code »

    This code is unlikely to be useful in the future because transforms
    don't know how often keys will be changed, new algorithms are unlikely
    to use lle representation, and tables should be replaced with
    carryless multiplication instructions when available.

    Signed-off-by: Alex Cope
    Signed-off-by: Herbert Xu

    Alex Cope
     

08 Jul, 2011

1 commit

  • 625426633   crypto: gf128mul - fix call to memset() ... Browse Code »

    In gf128mul_lle() and gf128mul_bbe() r isn't completely initialized with
    zero because the size argument passed to memset() is the size of the
    pointer, not the structure it points to.

    Luckily there are no in-kernel users of those functions so the ABI
    change implied by this fix should break no existing code.

    Based on a patch by the PaX Team.

    Signed-off-by: Mathias Krause
    Cc: PaX Team
    Acked-by: David S. Miller
    Signed-off-by: Herbert Xu

    Mathias Krause
     

31 Mar, 2011

1 commit

04 Mar, 2009

1 commit

11 Oct, 2007

1 commit

  • f19f5111c   [CRYPTO] xts: XTS blockcipher mode implementation without partial blocks ... Browse Code »

    XTS currently considered to be the successor of the LRW mode by the IEEE1619
    workgroup. LRW was discarded, because it was not secure if the encyption key
    itself is encrypted with LRW.

    XTS does not have this problem. The implementation is pretty straightforward,
    a new function was added to gf128mul to handle GF(128) elements in ble format.
    Four testvectors from the specification
    http://grouper.ieee.org/groups/1619/email/pdf00086.pdf
    were added, and they verify on my system.

    Signed-off-by: Rik Snel
    Signed-off-by: Herbert Xu

    Rik Snel
     

07 Dec, 2006

1 commit

  • c494e0705   [CRYPTO] lib: table driven multiplications in GF(2^128) ... Browse Code »

    A lot of cypher modes need multiplications in GF(2^128). LRW, ABL, GCM...
    I use functions from this library in my LRW implementation and I will
    also use them in my ABL (Arbitrary Block Length, an unencumbered (correct
    me if I am wrong, wide block cipher mode).

    Elements of GF(2^128) must be presented as u128 *, it encourages automatic
    and proper alignment.

    The library contains support for two different representations of GF(2^128),
    see the comment in gf128mul.h. There different levels of optimization
    (memory/speed tradeoff).

    The code is based on work by Dr Brian Gladman. Notable changes:
    - deletion of two optimization modes
    - change from u32 to u64 for faster handling on 64bit machines
    - support for 'bbe' representation in addition to the, already implemented,
    'lle' representation.
    - move 'inline void' functions from header to 'static void' in the
    source file
    - update to use the linux coding style conventions

    The original can be found at:
    http://fp.gladman.plus.com/AES/modes.vc8.19-06-06.zip

    The copyright (and GPL statement) of the original author is preserved.

    Signed-off-by: Rik Snel
    Signed-off-by: Herbert Xu

    Rik Snel