kernel/git/stable/linux.git/crypto/gf128mul.c, branch master

crypto: move gf128mul library into lib/crypto

2022-11-11T10:14:59+00:00

The gf128mul library does not depend on the crypto API at all, so it can be moved into lib/crypto. This will allow us to use it in other library code in a subsequent patch without having to depend on CONFIG_CRYPTO. While at it, change the Kconfig symbol name to align with other crypto library implementations. However, the source file name is retained, as it is reflected in the module .ko filename, and changing this might break things for users. Signed-off-by: Ard Biesheuvel Signed-off-by: Herbert Xu

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

2020-08-07T18:33:22+00:00

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 - remove incorrect comment

2017-12-22T08:52:40+00:00

The comment in gf128mul_x8_ble() was copy-and-pasted from gf128mul.h and makes no sense in the new context. Remove it. Cc: Harsh Jain Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: gf128mul - The x8_ble multiplication functions

2017-11-03T13:50:43+00:00

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 - define gf128mul_x_* in gf128mul.h

2017-04-05T13:58:35+00:00

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:16+00:00

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 - rename the byte overflow tables

2017-03-09T10:34:15+00:00

Though the GF(2^128) byte overflow tables were named the "lle" and "bbe" tables, they are not actually tied to these element formats specifically, but rather to particular a "bit endianness". For example, the bbe table is actually used for both bbe and ble multiplication. Therefore, rename the tables to "le" and "be" and update the comment to explain this. Cc: Alex Cope Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: gf128mul - remove xx() macro

2017-03-09T10:34:15+00:00

The xx() macro serves no purpose and can be removed. Cc: Alex Cope Signed-off-by: Eric Biggers Signed-off-by: Herbert Xu

crypto: gf128mul - fix some comments

2017-03-09T10:34:14+00:00

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:59+00:00

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