linux-toradex.git/crypto/md5.c, branch v3.10.78 Linux kernel for Apalis and Colibri modules crypto: prefix module autoloading with "crypto-" 2015-01-30T01:40:57+00:00 Kees Cook keescook@chromium.org 2014-11-21T01:05:53+00:00 e635e0d5b0adac839b91cc593babcb812cba3f18 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> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
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>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
crypto: Move md5_transform to lib/md5.c 2011-08-07T01:32:45+00:00 David S. Miller davem@davemloft.net 2011-08-04T02:45:10+00:00 bc0b96b54a21246e377122d54569eef71cec535f We are going to use this for TCP/IP sequence number and fragment ID generation. Signed-off-by: David S. Miller <davem@davemloft.net> 
We are going to use this for TCP/IP sequence number and fragment ID
generation.

Signed-off-by: David S. Miller <davem@davemloft.net>
crypto: md5 - Set statesize 2010-03-02T13:58:16+00:00 Herbert Xu herbert@gondor.apana.org.au 2010-03-02T13:58:16+00:00 eebb111f5f4aa7b91ffc046b84b24c1b75e391d1 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 <herbert@gondor.apana.org.au> 
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 <herbert@gondor.apana.org.au>
crypto: md5 - Add export support 2010-01-17T10:55:31+00:00 Max Vozeler max@hinterhof.net 2010-01-17T10:55:31+00:00 7d6f75eb21b84cdc5dfb09789974f02b42a89058 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 <max@hinterhof.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 
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 <max@hinterhof.net>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
crypto: md5 - Switch to shash 2008-12-25T00:02:18+00:00 Adrian-Ken Rueegsegger ken@codelabs.ch 2008-12-03T11:57:12+00:00 14b75ba70da925a9f040a7575cb46ad7d394b117 This patch changes md5 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 md5 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] all: Pass tfm instead of ctx to algorithms 2006-06-26T07:34:39+00:00 Herbert Xu herbert@gondor.apana.org.au 2006-05-16T12:09:29+00:00 6c2bb98bc33ae33c7a33a133a4cd5a06395fece5 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 <herbert@gondor.apana.org.au> 
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 <herbert@gondor.apana.org.au>
[CRYPTO] Use standard byte order macros wherever possible 2006-01-09T22:15:34+00:00 Herbert Xu herbert@gondor.apana.org.au 2005-10-30T10:25:15+00:00 06ace7a9bafeb9047352707eb79e8eaa0dfdf5f2 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 <herbert@gondor.apana.org.au> 
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 <herbert@gondor.apana.org.au>
Linux-2.6.12-rc2 2005-04-16T22:20:36+00:00 Linus Torvalds torvalds@ppc970.osdl.org 2005-04-16T22:20:36+00:00 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 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! 
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!