08 Aug, 2020
1 commit
-
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
22 Dec, 2017
1 commit
-
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
03 Nov, 2017
1 commit
-
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
05 Apr, 2017
1 commit
-
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
09 Mar, 2017
4 commits
-
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 -
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 -
The xx() macro serves no purpose and can be removed.
Cc: Alex Cope
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu -
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
17 Nov, 2016
1 commit
-
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
13 Nov, 2016
1 commit
-
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
08 Jul, 2011
1 commit
-
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
31 Mar, 2011
1 commit
-
Fixes generated by 'codespell' and manually reviewed.
Signed-off-by: Lucas De Marchi
04 Mar, 2009
1 commit
-
Signed-off-by: Adrian-Ken Rueegsegger
Signed-off-by: Herbert Xu
11 Oct, 2007
1 commit
-
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
07 Dec, 2006
1 commit
-
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 conventionsThe original can be found at:
http://fp.gladman.plus.com/AES/modes.vc8.19-06-06.zipThe copyright (and GPL statement) of the original author is preserved.
Signed-off-by: Rik Snel
Signed-off-by: Herbert Xu