<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/crypto, branch v3.0.22</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v3.0.22</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v3.0.22'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2012-02-20T20:48:14+00:00</updated>
<entry>
<title>crypto: sha512 - use standard ror64()</title>
<updated>2012-02-20T20:48:14+00:00</updated>
<author>
<name>Alexey Dobriyan</name>
<email>adobriyan@gmail.com</email>
</author>
<published>2012-01-14T18:44:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7b5644ec051e133d59249b7f19d2d8fef9a8d323'/>
<id>urn:sha1:7b5644ec051e133d59249b7f19d2d8fef9a8d323</id>
<content type='text'>
commit f2ea0f5f04c97b48c88edccba52b0682fbe45087 upstream.

Use standard ror64() instead of hand-written.
There is no standard ror64, so create it.

The difference is shift value being "unsigned int" instead of uint64_t
(for which there is no reason). gcc starts to emit native ROR instructions
which it doesn't do for some reason currently. This should make the code
faster.

Patch survives in-tree crypto test and ping flood with hmac(sha512) on.

Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: sha512 - Avoid stack bloat on i386</title>
<updated>2012-02-20T20:48:12+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2012-02-05T04:09:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=c29e3ddfbd904f0b7cf600c04c4263c71c1f4830'/>
<id>urn:sha1:c29e3ddfbd904f0b7cf600c04c4263c71c1f4830</id>
<content type='text'>
commit 3a92d687c8015860a19213e3c102cad6b722f83c upstream.

Unfortunately in reducing W from 80 to 16 we ended up unrolling
the loop twice.  As gcc has issues dealing with 64-bit ops on
i386 this means that we end up using even more stack space (&gt;1K).

This patch solves the W reduction by moving LOAD_OP/BLEND_OP
into the loop itself, thus avoiding the need to duplicate it.

While the stack space still isn't great (&gt;0.5K) it is at least
in the same ball park as the amount of stack used for our C sha1
implementation.

Note that this patch basically reverts to the original code so
the diff looks bigger than it really is.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: sha512 - Use binary and instead of modulus</title>
<updated>2012-02-20T20:48:12+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2012-01-26T04:03:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=d122aed32ad780e0c337551121c36a5d5e1c2ee0'/>
<id>urn:sha1:d122aed32ad780e0c337551121c36a5d5e1c2ee0</id>
<content type='text'>
commit 58d7d18b5268febb8b1391c6dffc8e2aaa751fcd upstream.

The previous patch used the modulus operator over a power of 2
unnecessarily which may produce suboptimal binary code.  This
patch changes changes them to binary ands instead.

Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: sha512 - reduce stack usage to safe number</title>
<updated>2012-02-03T17:18:53+00:00</updated>
<author>
<name>Alexey Dobriyan</name>
<email>adobriyan@gmail.com</email>
</author>
<published>2012-01-14T18:40:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3ce5564096c4444197e6f7dc83a9dbc63392b084'/>
<id>urn:sha1:3ce5564096c4444197e6f7dc83a9dbc63392b084</id>
<content type='text'>
commit 51fc6dc8f948047364f7d42a4ed89b416c6cc0a3 upstream.

For rounds 16--79, W[i] only depends on W[i - 2], W[i - 7], W[i - 15] and W[i - 16].
Consequently, keeping all W[80] array on stack is unnecessary,
only 16 values are really needed.

Using W[16] instead of W[80] greatly reduces stack usage
(~750 bytes to ~340 bytes on x86_64).

Line by line explanation:
* BLEND_OP
  array is "circular" now, all indexes have to be modulo 16.
  Round number is positive, so remainder operation should be
  without surprises.

* initial full message scheduling is trimmed to first 16 values which
  come from data block, the rest is calculated before it's needed.

* original loop body is unrolled version of new SHA512_0_15 and
  SHA512_16_79 macros, unrolling was done to not do explicit variable
  renaming. Otherwise it's the very same code after preprocessing.
  See sha1_transform() code which does the same trick.

Patch survives in-tree crypto test and original bugreport test
(ping flood with hmac(sha512).

See FIPS 180-2 for SHA-512 definition
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf

Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: sha512 - make it work, undo percpu message schedule</title>
<updated>2012-02-03T17:18:52+00:00</updated>
<author>
<name>Alexey Dobriyan</name>
<email>adobriyan@gmail.com</email>
</author>
<published>2012-01-14T18:27:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7ca6029f1a492528e65bc676113eeb1acf3779e4'/>
<id>urn:sha1:7ca6029f1a492528e65bc676113eeb1acf3779e4</id>
<content type='text'>
commit 84e31fdb7c797a7303e0cc295cb9bc8b73fb872d upstream.

commit f9e2bca6c22d75a289a349f869701214d63b5060
aka "crypto: sha512 - Move message schedule W[80] to static percpu area"
created global message schedule area.

If sha512_update will ever be entered twice, hash will be silently
calculated incorrectly.

Probably the easiest way to notice incorrect hashes being calculated is
to run 2 ping floods over AH with hmac(sha512):

	#!/usr/sbin/setkey -f
	flush;
	spdflush;
	add IP1 IP2 ah 25 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000025;
	add IP2 IP1 ah 52 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000052;
	spdadd IP1 IP2 any -P out ipsec ah/transport//require;
	spdadd IP2 IP1 any -P in  ipsec ah/transport//require;

XfrmInStateProtoError will start ticking with -EBADMSG being returned
from ah_input(). This never happens with, say, hmac(sha1).

With patch applied (on BOTH sides), XfrmInStateProtoError does not tick
with multiple bidirectional ping flood streams like it doesn't tick
with SHA-1.

After this patch sha512_transform() will start using ~750 bytes of stack on x86_64.
This is OK for simple loads, for something more heavy, stack reduction will be done
separatedly.

Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>crypto: cryptd - Use subsys_initcall to prevent races with aesni</title>
<updated>2011-11-11T17:37:17+00:00</updated>
<author>
<name>Herbert Xu</name>
<email>herbert@gondor.apana.org.au</email>
</author>
<published>2011-08-19T08:11:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6dd160db729a0c96cc640a848e6df88ca6c19d2a'/>
<id>urn:sha1:6dd160db729a0c96cc640a848e6df88ca6c19d2a</id>
<content type='text'>
commit b2bac6acf86d05d8af0499f37d91ecac15722803 upstream.

As cryptd is depeneded on by other algorithms such as aesni-intel,
it needs to be registered before them.  When everything is built
as modules, this occurs naturally.  However, for this to work when
they are built-in, we need to use subsys_initcall in cryptd.

Tested-by: Josh Boyer &lt;jwboyer@redhat.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Cc: Kerin Millar &lt;kerframil@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>crypto: ghash - Avoid null pointer dereference if no key is set</title>
<updated>2011-10-25T05:10:17+00:00</updated>
<author>
<name>Nick Bowler</name>
<email>nbowler@elliptictech.com</email>
</author>
<published>2011-10-20T12:16:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bf9f0eb856b58c7b35b38f7fc7340a889e7905e3'/>
<id>urn:sha1:bf9f0eb856b58c7b35b38f7fc7340a889e7905e3</id>
<content type='text'>
commit 7ed47b7d142ec99ad6880bbbec51e9f12b3af74c upstream.

The ghash_update function passes a pointer to gf128mul_4k_lle which will
be NULL if ghash_setkey is not called or if the most recent call to
ghash_setkey failed to allocate memory.  This causes an oops.  Fix this
up by returning an error code in the null case.

This is trivially triggered from unprivileged userspace through the
AF_ALG interface by simply writing to the socket without setting a key.

The ghash_final function has a similar issue, but triggering it requires
a memory allocation failure in ghash_setkey _after_ at least one
successful call to ghash_update.

  BUG: unable to handle kernel NULL pointer dereference at 00000670
  IP: [&lt;d88c92d4&gt;] gf128mul_4k_lle+0x23/0x60 [gf128mul]
  *pde = 00000000
  Oops: 0000 [#1] PREEMPT SMP
  Modules linked in: ghash_generic gf128mul algif_hash af_alg nfs lockd nfs_acl sunrpc bridge ipv6 stp llc

  Pid: 1502, comm: hashatron Tainted: G        W   3.1.0-rc9-00085-ge9308cf #32 Bochs Bochs
  EIP: 0060:[&lt;d88c92d4&gt;] EFLAGS: 00000202 CPU: 0
  EIP is at gf128mul_4k_lle+0x23/0x60 [gf128mul]
  EAX: d69db1f0 EBX: d6b8ddac ECX: 00000004 EDX: 00000000
  ESI: 00000670 EDI: d6b8ddac EBP: d6b8ddc8 ESP: d6b8dda4
   DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
  Process hashatron (pid: 1502, ti=d6b8c000 task=d6810000 task.ti=d6b8c000)
  Stack:
   00000000 d69db1f0 00000163 00000000 d6b8ddc8 c101a520 d69db1f0 d52aa000
   00000ff0 d6b8dde8 d88d310f d6b8a3f8 d52aa000 00001000 d88d502c d6b8ddfc
   00001000 d6b8ddf4 c11676ed d69db1e8 d6b8de24 c11679ad d52aa000 00000000
  Call Trace:
   [&lt;c101a520&gt;] ? kmap_atomic_prot+0x37/0xa6
   [&lt;d88d310f&gt;] ghash_update+0x85/0xbe [ghash_generic]
   [&lt;c11676ed&gt;] crypto_shash_update+0x18/0x1b
   [&lt;c11679ad&gt;] shash_ahash_update+0x22/0x36
   [&lt;c11679cc&gt;] shash_async_update+0xb/0xd
   [&lt;d88ce0ba&gt;] hash_sendpage+0xba/0xf2 [algif_hash]
   [&lt;c121b24c&gt;] kernel_sendpage+0x39/0x4e
   [&lt;d88ce000&gt;] ? 0xd88cdfff
   [&lt;c121b298&gt;] sock_sendpage+0x37/0x3e
   [&lt;c121b261&gt;] ? kernel_sendpage+0x4e/0x4e
   [&lt;c10b4dbc&gt;] pipe_to_sendpage+0x56/0x61
   [&lt;c10b4e1f&gt;] splice_from_pipe_feed+0x58/0xcd
   [&lt;c10b4d66&gt;] ? splice_from_pipe_begin+0x10/0x10
   [&lt;c10b51f5&gt;] __splice_from_pipe+0x36/0x55
   [&lt;c10b4d66&gt;] ? splice_from_pipe_begin+0x10/0x10
   [&lt;c10b6383&gt;] splice_from_pipe+0x51/0x64
   [&lt;c10b63c2&gt;] ? default_file_splice_write+0x2c/0x2c
   [&lt;c10b63d5&gt;] generic_splice_sendpage+0x13/0x15
   [&lt;c10b4d66&gt;] ? splice_from_pipe_begin+0x10/0x10
   [&lt;c10b527f&gt;] do_splice_from+0x5d/0x67
   [&lt;c10b6865&gt;] sys_splice+0x2bf/0x363
   [&lt;c129373b&gt;] ? sysenter_exit+0xf/0x16
   [&lt;c104dc1e&gt;] ? trace_hardirqs_on_caller+0x10e/0x13f
   [&lt;c129370c&gt;] sysenter_do_call+0x12/0x32
  Code: 83 c4 0c 5b 5e 5f c9 c3 55 b9 04 00 00 00 89 e5 57 8d 7d e4 56 53 8d 5d e4 83 ec 18 89 45 e0 89 55 dc 0f b6 70 0f c1 e6 04 01 d6 &lt;f3&gt; a5 be 0f 00 00 00 4e 89 d8 e8 48 ff ff ff 8b 45 e0 89 da 0f
  EIP: [&lt;d88c92d4&gt;] gf128mul_4k_lle+0x23/0x60 [gf128mul] SS:ESP 0068:d6b8dda4
  CR2: 0000000000000670
  ---[ end trace 4eaa2a86a8e2da24 ]---
  note: hashatron[1502] exited with preempt_count 1
  BUG: scheduling while atomic: hashatron/1502/0x10000002
  INFO: lockdep is turned off.
  [...]

Signed-off-by: Nick Bowler &lt;nbowler@elliptictech.com&gt;
Signed-off-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
</entry>
<entry>
<title>crypto: Move md5_transform to lib/md5.c</title>
<updated>2011-08-16T01:31:35+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2011-08-04T02:45:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2468b895fc7dcbc436cb02f0707ab8d7cb2f0aa7'/>
<id>urn:sha1:2468b895fc7dcbc436cb02f0707ab8d7cb2f0aa7</id>
<content type='text'>
We are going to use this for TCP/IP sequence number and fragment ID
generation.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;
</content>
</entry>
<entry>
<title>net+crypto: Use vmalloc for zlib inflate buffers.</title>
<updated>2011-06-29T12:48:41+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2011-06-29T12:48:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7ab24bfdf9a9a9f87ac8e5ad9a25f80b5b947be7'/>
<id>urn:sha1:7ab24bfdf9a9a9f87ac8e5ad9a25f80b5b947be7</id>
<content type='text'>
They are 64K and result in order-4 allocations, even with SLUB.

Therefore, just like we always have for the deflate buffers, use
vmalloc.

Reported-by: Martin Jackson &lt;mjackson220.list@gmail.com&gt;
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6</title>
<updated>2011-05-21T00:24:14+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2011-05-21T00:24:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=052497553e5dedc04c43800820c1d5788201cc71'/>
<id>urn:sha1:052497553e5dedc04c43800820c1d5788201cc71</id>
<content type='text'>
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: (45 commits)
  crypto: caam - add support for sha512 variants of existing AEAD algorithms
  crypto: caam - remove unused authkeylen from caam_ctx
  crypto: caam - fix decryption shared vs. non-shared key setting
  crypto: caam - platform_bus_type migration
  crypto: aesni-intel - fix aesni build on i386
  crypto: aesni-intel - Merge with fpu.ko
  crypto: mv_cesa - make count_sgs() null-pointer proof
  crypto: mv_cesa - copy remaining bytes to SRAM only when needed
  crypto: mv_cesa - move digest state initialisation to a better place
  crypto: mv_cesa - fill inner/outer IV fields only in HMAC case
  crypto: mv_cesa - refactor copy_src_to_buf()
  crypto: mv_cesa - no need to save digest state after the last chunk
  crypto: mv_cesa - print a warning when registration of AES algos fail
  crypto: mv_cesa - drop this call to mv_hash_final from mv_hash_finup
  crypto: mv_cesa - the descriptor pointer register needs to be set just once
  crypto: mv_cesa - use ablkcipher_request_cast instead of the manual container_of
  crypto: caam - fix printk recursion for long error texts
  crypto: caam - remove unused keylen from session context
  hwrng: amd - enable AMD hw rnd driver for Maple PPC boards
  hwrng: amd - manage resource allocation
  ...
</content>
</entry>
</feed>
