kernel/drivers/crypto/ccree/cc_aead.c, branch linux-rolling-stable

crypto: ccree - Fix typo in comment

2024-10-05T05:22:05Z

Corrected typos in comment: Asynchronize->Asynchronous, encryped->encrypted, decryped->decrypted, fallabck->fallback. Signed-off-by: Yu Jiaoliang Signed-off-by: Herbert Xu

crypto: ccree - Silence gcc format-truncation false positive warnings

2023-11-17T11:16:28Z

The heuristics used by gcc triggers false positive truncation warnings in hifn_alg_alloc. The warning triggered by the strings here are clearly false positives (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95755). Add checks on snprintf calls to silence these warnings, including the one for cra_driver_name even though it does not currently trigger a gcc warning. Signed-off-by: Herbert Xu

crypto: ccree - Set DMA alignment explicitly

2022-12-09T10:45:00Z

This driver has been implicitly relying on kmalloc alignment to be sufficient for DMA. This may no longer be the case with upcoming arm64 changes. This patch changes it to explicitly request DMA alignment from the Crypto API. Signed-off-by: Herbert Xu

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: ccree - remove duplicated include from cc_aead.c

2020-03-30T00:50:48Z

Remove duplicated include. Signed-off-by: YueHaibing Signed-off-by: Herbert Xu

crypto: ccree - refactor AEAD IV in AAD handling

2020-03-12T12:00:16Z

Our handling of ciphers with IV trailing the AAD was correct but overly complicated. Refactor to simplify and possibly save one DMA burst. This has the added bonus of behaving the same as the generic rfc4543 implementation for none compliants inputs where the IV in the iv field was not the same as the IV in the AAD. There should be no change in behaviour with correct inputs. Signed-off-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu

crypto: ccree - use crypto_ipsec_check_assoclen()

2020-03-12T12:00:16Z

Use crypto_ipsec_check_assoclen() instead of home grown functions. Clean up some unneeded code as a result. Delete stale comments while we're at it. Signed-off-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu

crypto: ccree - only check condition if needed

2020-03-12T12:00:16Z

Move testing of condition to after the point we decide if we need it or not. Signed-off-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu

crypto: ccree - remove ancient TODO remarks

2020-03-12T12:00:16Z

Remove left over ancient and now misleading TODO remarks. Signed-off-by: Gilad Ben-Yossef Signed-off-by: Herbert Xu

crypto: ccree - use devm_k[mz]alloc() for AEAD data

2020-02-22T01:25:46Z

As the lifetime of the AEAD data matches the lifetime of the driver, AEAD data can be allocated using the managed allocators. While at it, simplify cc_aead_free() by removing an unneeded cast, and an unneeded check (aead_handle is always valid here). Signed-off-by: Geert Uytterhoeven Signed-off-by: Herbert Xu