08 May, 2020
1 commit
-
The SHA-256 / SHA-224 library functions can't fail, so remove the
useless return value.Also long as the declarations are being changed anyway, also fix some
parameter names in the declarations to match the definitions.Signed-off-by: Eric Biggers
Reviewed-by: Jason A. Donenfeld
Signed-off-by: Herbert Xu
05 Sep, 2019
1 commit
-
The generic sha256 implementation from lib/crypto/sha256.c uses data
structs defined in crypto/sha.h, so lets move the function prototypes
there too.Signed-off-by: Hans de Goede
Signed-off-by: Herbert Xu
22 Aug, 2019
2 commits
-
Drop the duplicate generic sha256 (and sha224) implementation from
crypto/sha256_generic.c and use the implementation from
lib/crypto/sha256.c instead."diff -u lib/crypto/sha256.c sha256_generic.c" shows that the core
sha256_transform function from both implementations is identical and
the other code is functionally identical too.Suggested-by: Eric Biggers
Signed-off-by: Hans de Goede
Signed-off-by: Herbert Xu -
Add a bunch of missing spaces after commas and arround operators.
Note the main goal of this is to make sha256_transform and its helpers
identical in formatting too the duplcate implementation in lib/sha256.c,
so that "diff -u" can be used to compare them to prove that no functional
changes are made when further patches in this series consolidate the 2
implementations into 1.Signed-off-by: Hans de Goede
Signed-off-by: Herbert Xu
31 May, 2019
1 commit
-
Based on 1 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 as published by
the free software foundation either version 2 of the license or at
your option any later versionextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 3029 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Allison Randal
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190527070032.746973796@linutronix.de
Signed-off-by: Greg Kroah-Hartman
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
2 commits
-
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 -
sha256-generic and sha224-generic had a cra_priority of 0, so it wasn't
possible to have a lower priority SHA-256 or SHA-224 implementation, as
is desired for sha256_mb which is only useful under certain workloads
and is otherwise extremely slow. Change them to priority 100, which is
the priority used for many of the other generic algorithms.Signed-off-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
10 Apr, 2015
1 commit
-
This updates the generic SHA-256 implementation to use the
new shared SHA-256 glue code.It also implements a .finup hook crypto_sha256_finup() and exports
it to other modules. The import and export() functions and the
.statesize member are dropped, since the default implementation
is perfectly suitable for this module.Signed-off-by: Ard Biesheuvel
Signed-off-by: Herbert Xu
13 Jan, 2015
1 commit
-
Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
changed the automatic module loading when requesting crypto algorithms
to prefix all module requests with "crypto-". This requires all crypto
modules to have a crypto specific module alias even if their file name
would otherwise match the requested crypto algorithm.Even though commit 5d26a105b5a7 added those aliases for a vast amount of
modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
annotations to those files to make them get loaded automatically, again.
This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
with kernels v3.18 and below.Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
won't work for crypto modules any more.Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
Cc: Kees Cook
Signed-off-by: Mathias Krause
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
25 Oct, 2014
1 commit
-
Pull /dev/random updates from Ted Ts'o:
"This adds a memzero_explicit() call which is guaranteed not to be
optimized away by GCC. This is important when we are wiping
cryptographically sensitive material"* tag 'random_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/random:
crypto: memzero_explicit - make sure to clear out sensitive data
random: add and use memzero_explicit() for clearing data
17 Oct, 2014
1 commit
-
Recently, in commit 13aa93c70e71 ("random: add and use memzero_explicit()
for clearing data"), we have found that GCC may optimize some memset()
cases away when it detects a stack variable is not being used anymore
and going out of scope. This can happen, for example, in cases when we
are clearing out sensitive information such as keying material or any
e.g. intermediate results from crypto computations, etc.With the help of Coccinelle, we can figure out and fix such occurences
in the crypto subsytem as well. Julia Lawall provided the following
Coccinelle program:@@
type T;
identifier x;
@@T x;
... when exists
when any
-memset
+memzero_explicit
(&x,
-0,
...)
... when != x
when strict@@
type T;
identifier x;
@@T x[...];
... when exists
when any
-memset
+memzero_explicit
(x,
-0,
...)
... when != x
when strictTherefore, make use of the drop-in replacement memzero_explicit() for
exactly such cases instead of using memset().Signed-off-by: Daniel Borkmann
Cc: Julia Lawall
Cc: Herbert Xu
Cc: Theodore Ts'o
Cc: Hannes Frederic Sowa
Acked-by: Hannes Frederic Sowa
Acked-by: Herbert Xu
Signed-off-by: Theodore Ts'o
02 Oct, 2014
1 commit
-
Like SHA1, use get_unaligned_be*() on the raw input data.
Reported-by: Bob Picco
Signed-off-by: David S. Miller
Signed-off-by: Herbert Xu
03 Apr, 2013
1 commit
-
Other SHA256 routine may need to use the generic routine when
FPU is not available.Signed-off-by: Tim Chen
Signed-off-by: Herbert Xu
01 Aug, 2012
1 commit
-
Combine all shash algs to be registered and use new crypto_[un]register_shashes
functions. This simplifies init/exit code.Signed-off-by: Jussi Kivilinna
Signed-off-by: Herbert Xu
11 Jul, 2009
2 commits
-
This patch adds export/import support to sha256_generic. The exported
type is defined by struct sha256_state, which is basically the entire
descriptor state of sha256_generic.Signed-off-by: Herbert Xu
-
This patch replaces the two 32-bit counter code in sha256_generic
with the simpler 64-bit counter code from sha1.Signed-off-by: Herbert Xu
04 Mar, 2009
1 commit
-
Signed-off-by: Adrian-Ken Rueegsegger
Signed-off-by: Herbert Xu
25 Dec, 2008
1 commit
-
This patch changes sha256 and sha224 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
11 Jan, 2008
1 commit
-
Resubmitting this patch which extends sha256_generic.c to support SHA-224 as
described in FIPS 180-2 and RFC 3874. HMAC-SHA-224 as described in RFC4231
is then supported through the hmac interface.Patch includes test vectors for SHA-224 and HMAC-SHA-224.
SHA-224 chould be chosen as a hash algorithm when 112 bits of security
strength is required.Patch generated against the 2.6.24-rc1 kernel and tested against
2.6.24-rc1-git14 which includes fix for scatter gather implementation for HMAC.Signed-off-by: Jonathan Lynch
Signed-off-by: Herbert Xu
02 Nov, 2007
1 commit
-
Not architecture specific code should not #include .
This patch therefore either replaces them with
#include or simply removes them if they were
unused.Signed-off-by: Adrian Bunk
Signed-off-by: Jens Axboe
11 Oct, 2007
2 commits
-
There are currently several SHA implementations that all define their own
initialization vectors and size values. Since this values are idential
move them to a header file under include/crypto.Signed-off-by: Jan Glauber
Signed-off-by: Herbert Xu -
Loading the crypto algorithm by the alias instead of by module directly
has the advantage that all possible implementations of this algorithm
are loaded automatically and the crypto API can choose the best one
depending on its priority.Additionally it ensures that the generic implementation as well as the
HW driver (if available) is loaded in case the HW driver needs the
generic version as fallback in corner cases.Also remove the probe for sha1 in padlock's init code.
Quote from Herbert:
The probe is actually pointless since we can always probe when
the algorithm is actually used which does not lead to dead-locks
like this.Signed-off-by: Sebastian Siewior
Signed-off-by: Herbert Xu