kernel/include/crypto/gf128mul.h, branch linux-5.11.y

mm, treewide: rename kzfree() to kfree_sensitive()

2020-08-07T18:33:22Z

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

crypto: gf128mul - The x8_ble multiplication functions

2017-11-03T13:50:43Z

It multiply GF(2^128) elements in the ble format. It will be used by chelsio driver to speed up gf multiplication. Signed-off-by: Harsh Jain Signed-off-by: Herbert Xu

crypto: gf128mul - switch gf128mul_x_ble to le128

2017-04-05T13:58:37Z

Currently, gf128mul_x_ble works with pointers to be128, even though it actually interprets the words as little-endian. Consequently, it uses cpu_to_le64/le64_to_cpu on fields of type __be64, which is incorrect. This patch fixes that by changing the function to accept pointers to le128 and updating all users accordingly. Signed-off-by: Ondrej Mosnacek Reviewd-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: gf128mul - define gf128mul_x_* in gf128mul.h

2017-04-05T13:58:35Z

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

crypto: gf128mul - constify 4k and 64k multiplication tables

2017-03-09T10:34:16Z

Constify the multiplication tables passed to the 4k and 64k multiplication functions, as they are not modified by these functions. Cc: Alex Cope Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: gf128mul - fix some comments

2017-03-09T10:34:14Z

Fix incorrect references to GF(128) instead of GF(2^128), as these are two entirely different fields, and fix a few other incorrect comments. Cc: Alex Cope Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: gf128mul - Zero memory when freeing multiplication table

2016-11-17T15:34:59Z

GF(2^128) multiplication tables are typically used for secret information, so it's a good idea to zero them on free. Signed-off-by: Alex Cope Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: gf128mul - remove dead gf128mul_64k_lle code

2016-11-13T09:45:06Z

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

Update broken web addresses in the kernel.

2010-10-18T09:03:14Z

The patch below updates broken web addresses in the kernel Signed-off-by: Justin P. Mattock Cc: Maciej W. Rozycki Cc: Geert Uytterhoeven Cc: Finn Thain Cc: Randy Dunlap Cc: Matt Turner Cc: Dimitry Torokhov Cc: Mike Frysinger Acked-by: Ben Pfaff Acked-by: Hans J. Koch Reviewed-by: Finn Thain Signed-off-by: Jiri Kosina

[CRYPTO] xts: XTS blockcipher mode implementation without partial blocks

2007-10-10T23:55:45Z

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