linux-stable.git/crypto/sha256_generic.c, branch linux-3.2.y Linux kernel stable tree crypto: add missing crypto module aliases 2015-02-20T00:49:36+00:00 Mathias Krause minipli@googlemail.com 2015-01-11T17:17:42+00:00 fd1910098bb42815a475a53b94fdfdfe3aa38002 commit 3e14dcf7cb80b34a1f38b55bc96f02d23fdaaaaf upstream. 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 <keescook@chromium.org> Signed-off-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> [bwh: Backported to 3.2: - Adjust filenames - Drop changes to algorithms and drivers we don't have] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 3e14dcf7cb80b34a1f38b55bc96f02d23fdaaaaf upstream.

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 <keescook@chromium.org>
Signed-off-by: Mathias Krause <minipli@googlemail.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[bwh: Backported to 3.2:
 - Adjust filenames
 - Drop changes to algorithms and drivers we don't have]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
crypto: prefix module autoloading with "crypto-" 2015-02-20T00:49:36+00:00 Kees Cook keescook@chromium.org 2014-11-21T01:05:53+00:00 9ffea4cb2306945b5df5f28bb8686333fe666bf1 commit 5d26a105b5a73e5635eae0629b42fa0a90e07b7b upstream. 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 <keescook@chromium.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> [bwh: Backported to 3.2: - Adjust filenames - Drop changes to algorithms and drivers we don't have - Add aliases to generic C implementations that didn't need them before] Signed-off-by: Ben Hutchings <ben@decadent.org.uk> 
commit 5d26a105b5a73e5635eae0629b42fa0a90e07b7b upstream.

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 <keescook@chromium.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[bwh: Backported to 3.2:
 - Adjust filenames
 - Drop changes to algorithms and drivers we don't have
 - Add aliases to generic C implementations that didn't need them before]
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
crypto: sha256_generic - Add export/import support 2009-07-11T10:23:34+00:00 Herbert Xu herbert@gondor.apana.org.au 2009-07-10T05:00:27+00:00 9b2fda7b94a769af13c24582739e50664b0e27a8 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 <herbert@gondor.apana.org.au> 
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 <herbert@gondor.apana.org.au>
crypto: sha256_generic - Use 64-bit counter like sha1 2009-07-11T10:23:33+00:00 Herbert Xu herbert@gondor.apana.org.au 2009-07-10T04:54:20+00:00 3d4d277cf88e1980d905707b9c8ca61e8ad6bf0b 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 <herbert@gondor.apana.org.au> 
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 <herbert@gondor.apana.org.au>
crypto: Fix dead links 2009-03-04T06:43:52+00:00 Adrian-Ken Rueegsegger ken@codelabs.ch 2009-03-04T06:43:52+00:00 8c882f64130071eaebdc0861bee34a73e436f004 Signed-off-by: Adrian-Ken Rueegsegger <ken@codelabs.ch> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
Signed-off-by: Adrian-Ken Rueegsegger <ken@codelabs.ch>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: sha256 - Switch to shash 2008-12-25T00:02:19+00:00 Adrian-Ken Rueegsegger ken@codelabs.ch 2008-12-03T11:57:49+00:00 50e109b5b9c1f734e91a6e9b557bce48c9a88654 This patch changes sha256 and sha224 to the new shash interface. Signed-off-by: Adrian-Ken Rueegsegger <ken@codelabs.ch> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
This patch changes sha256 and sha224 to the new shash interface.

Signed-off-by: Adrian-Ken Rueegsegger <ken@codelabs.ch>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[CRYPTO] all: Clean up init()/fini() 2008-04-21T02:19:34+00:00 Kamalesh Babulal kamalesh@linux.vnet.ibm.com 2008-04-05T13:00:57+00:00 3af5b90bde5000abc739996cb03fd718e753d053 On Thu, Mar 27, 2008 at 03:40:36PM +0100, Bodo Eggert wrote: > Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote: > > > This patch cleanups the crypto code, replaces the init() and fini() > > with the <algorithm name>_init/_fini > > This part ist OK. > > > or init/fini_<algorithm name> (if the > > <algorithm name>_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 <algorithm name>_mod_init () and fini () is replaced with <algorithm name>_mod_fini. Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
On Thu, Mar 27, 2008 at 03:40:36PM +0100, Bodo Eggert wrote:
> Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:
> 
> > This patch cleanups the crypto code, replaces the init() and fini()
> > with the <algorithm name>_init/_fini
> 
> This part ist OK.
> 
> > or init/fini_<algorithm name> (if the 
> > <algorithm name>_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

	<algorithm name>_mod_init ()

and fini () is replaced with <algorithm name>_mod_fini.
 
Signed-off-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[CRYPTO] sha256-generic: Extend sha256_generic.c to support SHA-224 2008-01-10T21:16:12+00:00 Jonathan Lynch jonathan.lynch@intel.com 2007-11-10T12:08:25+00:00 cd12fb906d2591e80da9edcbd4794b9b916d7489 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 <jonathan.lynch@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
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 <jonathan.lynch@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
cleanup asm/scatterlist.h includes 2007-11-02T07:47:06+00:00 Adrian Bunk bunk@kernel.org 2007-10-30T09:35:04+00:00 87ae9afdcada236d0a1b38ce2c465a65916961dc Not architecture specific code should not #include <asm/scatterlist.h>. This patch therefore either replaces them with #include <linux/scatterlist.h> or simply removes them if they were unused. Signed-off-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Jens Axboe <jens.axboe@oracle.com> 
Not architecture specific code should not #include <asm/scatterlist.h>.

This patch therefore either replaces them with
#include <linux/scatterlist.h> or simply removes them if they were
unused.

Signed-off-by: Adrian Bunk <bunk@kernel.org>
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
[CRYPTO] sha: Add header file for SHA definitions 2007-10-10T23:55:50+00:00 Jan Glauber jang@de.ibm.com 2007-10-09T14:43:13+00:00 5265eeb2b036835021591173ac64e624baaff55c 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 <jang@de.ibm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
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 <jang@de.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>