summaryrefslogtreecommitdiffstats
path: root/crypto
Commit message (Collapse)AuthorAgeFilesLines
* [CRYPTO]: Use CPU cycle counters in tcryptHerbert Xu2005-06-221-21/+95
| | | | | | | | | | | | | After using this facility for a while to test my changes to the cipher crypt() layer, I realised that I should've listend to Dave and made this thing use CPU cycle counters :) As it is it's too jittery for me to feel safe about relying on the results. So here is a patch to make it use CPU cycles by default but fall back to jiffies if the user specifies a non-zero sec value. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [CRYPTO]: Use template keys for speed tests if possibleHerbert Xu2005-06-221-22/+57
| | | | | | | | | | The existing keys used in the speed tests do not pass the 3DES quality check. This patch makes it use the template keys instead. Other algorithms can supply template keys through the same interface if needed. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [CRYPTO]: Add cipher speed testsHarald Welte2005-06-222-4/+222
| | | | | | | | | | | | | | | | | | | | | From: Reyk Floeter <reyk@vantronix.net> I recently had the requirement to do some benchmarking on cryptoapi, and I found reyk's very useful performance test patch [1]. However, I could not find any discussion on why that extension (or something providing a similar feature but different implementation) was not merged into mainline. If there was such a discussion, can someone please point me to the archive[s]? I've now merged the old patch into 2.6.12-rc1, the result can be found attached to this email. [1] http://lists.logix.cz/pipermail/padlock/2004/000010.html Signed-off-by: Harald Welte <laforge@gnumonks.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [CRYPTO]: Kill unnecessary strncpy from tcryptHerbert Xu2005-06-221-5/+5
| | | | | | | | It seems that bad code tends to get copied (see test_cipher_speed). So let's kill this idiom before it spreads any further. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [CRYPTO]: White space and coding style clean up in tcryptHerbert Xu2005-06-222-354/+336
| | | | | Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
* [CRYPTO]: Only reschedule if !in_atomic()Herbert Xu2005-05-231-1/+1
| | | | | | | | | The netlink gfp_any() problem made me double-check the uses of in_softirq() in crypto/*. It seems to me that we should be checking in_atomic() instead of in_softirq() in crypto_yield. Otherwise people calling the crypto ops with spin locks held or preemption disabled will get burnt, right? Signed-off-by: David S. Miller <davem@davemloft.net>
* [PATCH] crypto: fix null encryption/compressionPatrick McHardy2005-05-171-13/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | null_encrypt() needs to copy the data in case src and dst are disjunct, null_compress() needs to copy the data in any case as far as I can tell. I joined compress/decompress and encrypt/decrypt to avoid duplicating code. Without this patch ESP null_enc packets look like this: IP (tos 0x0, ttl 64, id 23130, offset 0, flags [DF], length: 128) 10.0.0.1 > 10.0.0.2: ESP(spi=0x0f9ca149,seq=0x4) 0x0000: 4500 0080 5a5a 4000 4032 cbef 0a00 0001 E...ZZ@.@2...... 0x0010: 0a00 0002 0f9c a149 0000 0004 0000 0000 .......I........ 0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0040: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0050: 0000 .. IP (tos 0x0, ttl 64, id 256, offset 0, flags [DF], length: 128) 10.0.0.2 > 10.0.0.1: ESP(spi=0x0e4f7b51,seq=0x2) 0x0000: 4500 0080 0100 4000 4032 254a 0a00 0002 E.....@.@2%J.... 0x0010: 0a00 0001 0e4f 7b51 0000 0002 a8a8 a8a8 .....O{Q........ 0x0020: a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 ................ 0x0030: a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 ................ 0x0040: a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 a8a8 ................ 0x0050: a8a8 .. Signed-off-by: Patrick McHardy <kaber@trash.net> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] uml: support AES i586 crypto driverPaolo 'Blaisorblade' Giarrusso2005-05-011-2/+2
| | | | | | | | | | | | | | | | | | | | We want to make possible, for the user, to enable the i586 AES implementation. This requires a restructure. - Add a CONFIG_UML_X86 to notify that we are building a UML for i386. - Rename CONFIG_64_BIT to CONFIG_64BIT as is used for all other archs - Tell crypto/Kconfig that UML_X86 is as good as X86 - Tell it that it must exclude not X86_64 but 64BIT, which will give the same results. - Tell kbuild to descend down into arch/i386/crypto/ to build what's needed. Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* [PATCH] crypto: call zlib end functions on deflate exit pathArtem B. Bityuckiy2005-04-161-0/+2
| | | | | | | | | | | | | | In the deflate_[compress|uncompress|pcompress] functions we call the zlib_[in|de]flateReset function at the beginning. This is OK. But when we unload the deflate module we don't call zlib_[in|de]flateEnd to free all the zlib internal data. It looks like a bug for me. Please, consider the attached patch. Signed-off-by: Artem B. Bityuckiy <dedekind@infradead.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
* Linux-2.6.12-rc2v2.6.12-rc2Linus Torvalds2005-04-1635-0/+16296
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!