| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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.
[[email protected]: fs/crypto/inline_crypt.c needs linux/slab.h]
[[email protected]: fix fs/crypto/inline_crypt.c some more]
Suggested-by: Joe Perches <[email protected]>
Signed-off-by: Waiman Long <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Acked-by: David Howells <[email protected]>
Acked-by: Michal Hocko <[email protected]>
Acked-by: Johannes Weiner <[email protected]>
Cc: Jarkko Sakkinen <[email protected]>
Cc: James Morris <[email protected]>
Cc: "Serge E. Hallyn" <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: David Rientjes <[email protected]>
Cc: Dan Carpenter <[email protected]>
Cc: "Jason A . Donenfeld" <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Linus Torvalds <[email protected]>
|
|
Based on 2 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public license version 2 as
published by the free software foundation #
extracted by the scancode license scanner the SPDX license identifier
GPL-2.0-only
has been chosen to replace the boilerplate/reference in 4122 file(s).
Signed-off-by: Thomas Gleixner <[email protected]>
Reviewed-by: Enrico Weigelt <[email protected]>
Reviewed-by: Kate Stewart <[email protected]>
Reviewed-by: Allison Randal <[email protected]>
Cc: [email protected]
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
In preparation for new akcipher verify call remove sign/verify callbacks
from RSA backends and make PKCS1 driver call encrypt/decrypt instead.
This also complies with the well-known idea that raw RSA should never be
used for sign/verify. It only should be used with proper padding scheme
such as PKCS1 driver provides.
Cc: Giovanni Cabiddu <[email protected]>
Cc: [email protected]
Cc: Tom Lendacky <[email protected]>
Cc: Gary Hook <[email protected]>
Cc: Horia Geantă <[email protected]>
Cc: Aymen Sghaier <[email protected]>
Signed-off-by: Vitaly Chikunov <[email protected]>
Reviewed-by: Horia Geantă <[email protected]>
Acked-by: Gary R Hook <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Use kmemdup rather than duplicating its implementation
Signed-off-by: YueHaibing <[email protected]>
Acked-by: Gary R Hook <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Fix sparse warning:
drivers/crypto/ccp/ccp-crypto-rsa.c:251:5:
warning: symbol 'ccp_register_rsa_alg' was not declared. Should it be static?
Signed-off-by: YueHaibing <[email protected]>
Acked-by: Gary R Hook <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
rsa-pkcs1pad uses a value returned from a RSA implementation max_size
callback as a size of an input buffer passed to the RSA implementation for
encrypt and sign operations.
CCP RSA implementation uses a hardware input buffer which size depends only
on the current RSA key length, so it should return this key length in
the max_size callback, too.
This also matches what the kernel software RSA implementation does.
Previously, the value returned from this callback was always the maximum
RSA key size the CCP hardware supports.
This resulted in this huge buffer being passed by rsa-pkcs1pad to CCP even
for smaller key sizes and then in a buffer overflow when ccp_run_rsa_cmd()
tried to copy this large input buffer into a RSA key length-sized hardware
input buffer.
Signed-off-by: Maciej S. Szmigiero <[email protected]>
Fixes: ceeec0afd684 ("crypto: ccp - Add support for RSA on the CCP")
Cc: [email protected]
Acked-by: Gary R Hook <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
A version 5 CCP can handle an RSA modulus up to 16k bits.
Signed-off-by: Gary R Hook <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|
|
Wire up the CCP as an RSA cipher provider.
Signed-off-by: Gary R Hook <[email protected]>
Signed-off-by: Herbert Xu <[email protected]>
|