28 Feb, 2020
1 commit
-
crypto/md5.c:26:0: warning: macro "MD5_DIGEST_WORDS" is not used [-Wunused-macros]
crypto/md5.c:27:0: warning: macro "MD5_MESSAGE_BYTES" is not used [-Wunused-macros]They are never used since commit 3c7eb3cc8360 ("md5: remove from
lib and only live in crypto").Signed-off-by: YueHaibing
Signed-off-by: Herbert Xu
13 Jun, 2019
1 commit
-
Most generic crypto algorithms declare a driver name ending in
"-generic". The rest don't declare a driver name and instead rely on
the crypto API automagically appending "-generic" upon registration.Having multiple conventions is unnecessarily confusing and makes it
harder to grep for all generic algorithms in the kernel source tree.
But also, allowing NULL driver names is problematic because sometimes
people fail to set it, e.g. the case fixed by commit 417980364300
("crypto: cavium/zip - fix collision with generic cra_driver_name").Of course, people can also incorrectly name their drivers "-generic".
But that's much easier to notice / grep for.Therefore, let's make cra_driver_name mandatory. In preparation for
this, this patch makes all generic algorithms set cra_driver_name.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
18 Apr, 2019
1 commit
-
Use subsys_initcall for registration of all templates and generic
algorithm implementations, rather than module_init. Then change
cryptomgr to use arch_initcall, to place it before the subsys_initcalls.This is needed so that when both a generic and optimized implementation
of an algorithm are built into the kernel (not loadable modules), the
generic implementation is registered before the optimized one.
Otherwise, the self-tests for the optimized implementation are unable to
allocate the generic implementation for the new comparison fuzz tests.Note that on arm, a side effect of this change is that self-tests for
generic implementations may run before the unaligned access handler has
been installed. So, unaligned accesses will crash the kernel. This is
arguably a good thing as it makes it easier to detect that type of bug.Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
09 Jul, 2018
1 commit
-
Many shash algorithms set .cra_flags = CRYPTO_ALG_TYPE_SHASH. But this
is redundant with the C structure type ('struct shash_alg'), and
crypto_register_shash() already sets the type flag automatically,
clearing any type flag that was already there. Apparently the useless
assignment has just been copy+pasted around.So, remove the useless assignment from all the shash algorithms.
This patch shouldn't change any actual behavior.
Signed-off-by: Eric Biggers
Signed-off-by: Herbert Xu
31 Mar, 2018
1 commit
-
Deduplicate le32_to_cpu_array() and cpu_to_le32_array() by moving them
to the generic header.No functional change implied.
Signed-off-by: Andy Shevchenko
Signed-off-by: Herbert Xu
24 Mar, 2017
1 commit
-
The md5_transform function is no longer used any where in the tree,
except for the crypto api's actual implementation of md5, so we can drop
the function from lib and put it as a static function of the crypto
file, where it belongs. There should be no new users of md5_transform,
anyway, since there are more modern ways of doing what it once achieved.Signed-off-by: Jason A. Donenfeld
Reviewed-by: Eric Biggers
Signed-off-by: Herbert Xu
22 Dec, 2015
1 commit
-
Some crypto drivers cannot process empty data message and return a
precalculated hash for md5/sha1/sha224/sha256.This patch add thoses precalculated hash in include/crypto.
Signed-off-by: LABBE Corentin
Signed-off-by: Herbert Xu
18 May, 2015
1 commit
-
Since MD5 IV are now available in crypto/md5.h, use them.
Signed-off-by: LABBE Corentin
Signed-off-by: Herbert Xu
24 Nov, 2014
1 commit
-
This prefixes all crypto module loading with "crypto-" so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook
Signed-off-by: Herbert Xu
07 Aug, 2011
1 commit
-
We are going to use this for TCP/IP sequence number and fragment ID
generation.Signed-off-by: David S. Miller
02 Mar, 2010
1 commit
-
As md5 now has export/import functions, it must set the attribute
statesize. Otherwise anything that relies on import/export may
fail as they will see a zero statesize.Signed-off-by: Herbert Xu
17 Jan, 2010
1 commit
-
This patch adds export/import support to md5. The exported type is
defined by struct md5_state.This is modeled after the equivalent change to sha1_generic.
Signed-off-by: Max Vozeler
Signed-off-by: Herbert Xu
25 Dec, 2008
1 commit
-
This patch changes md5 to the new shash interface.
Signed-off-by: Adrian-Ken Rueegsegger
Signed-off-by: Herbert Xu
21 Apr, 2008
1 commit
-
On Thu, Mar 27, 2008 at 03:40:36PM +0100, Bodo Eggert wrote:
> Kamalesh Babulal wrote:
>
> > This patch cleanups the crypto code, replaces the init() and fini()
> > with the _init/_fini
>
> This part ist OK.
>
> > or init/fini_ (if the
> > _init/_fini exist)
>
> Having init_foo and foo_init won't be a good thing, will it? I'd start
> confusing them.
>
> What about foo_modinit instead?Thanks for the suggestion, the init() is replaced with
_mod_init ()
and fini () is replaced with _mod_fini.
Signed-off-by: Kamalesh Babulal
Signed-off-by: Herbert Xu
26 Jun, 2006
1 commit
-
Up until now algorithms have been happy to get a context pointer since
they know everything that's in the tfm already (e.g., alignment, block
size).However, once we have parameterised algorithms, such information will
be specific to each tfm. So the algorithm API needs to be changed to
pass the tfm structure instead of the context pointer.This patch is basically a text substitution. The only tricky bit is
the assembly routines that need to get the context pointer offset
through asm-offsets.h.Signed-off-by: Herbert Xu
10 Jan, 2006
1 commit
-
A lot of crypto code needs to read/write a 32-bit/64-bit words in a
specific gender. Many of them open code them by reading/writing one
byte at a time. This patch converts all the applicable usages over
to use the standard byte order macros.This is based on a previous patch by Denis Vlasenko.
Signed-off-by: Herbert Xu
17 Apr, 2005
1 commit
-
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.Let it rip!