Re: [RFC, TCRYPT]: Catch cipher destination memory corruption

Hi Patrick: Patrick McHardy <[EMAIL PROTECTED]> wrote: > > This patch adds checks to tcrypt to catch destination buffer > corruption for cipher tests across pages, which was useful > while fixing corruption caused by the HIFN driver. This seems like a pretty useful check. Thanks, -- Visit Open

[PATCH 5/5][CRYPTO] RIPEMD: Add Kconfig entries for extended RIPEMD hash algorithms

This patch adds Kconfig entries for RIPEMD-256 and RIPEMD-320. --- crypto/Kconfig | 25 + 1 files changed, 25 insertions(+), 0 deletions(-) diff --git a/crypto/Kconfig b/crypto/Kconfig index cfc521a..5963a95 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -264,6 +264

[PATCH 4/5][CRYPTO] tcrypt: Add test vectors for RIPEMD-256 and RIPEMD-320

This patch adds test vectors for RIPEMD-256 and RIPEMD-320 hash algorithms. The test vectors are taken from --- crypto/tcrypt.c | 21 - crypto/tcrypt.h | 136 +++ 2 files change

[PATCH 3/5][CRYPTO] RIPEMD: Add support for RIPEMD-256 and RIPEMD-320

This patch adds support for the extended RIPEMD hash algorithms RIPEMD-256 and RIPEMD-320. --- crypto/Makefile |2 + crypto/rmd256.c | 362 crypto/rmd320.c | 411 +++ 3 files changed, 775 ins

[PATCH 1/5][CRYPTO] RIPEMD: fix Makefile entry for rmd128.o

This patch fixes module building for rmd128.o. --- crypto/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/crypto/Makefile b/crypto/Makefile index c21b455..1efb556 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -27,7 +27,7 @@ obj-$(CONFIG_CRYPTO_XCBC) += xc

[PATCH 2/5][CRYPTO] RIPEMD: put all common RIPEMD values in header file

This patch puts all common RIPEMD values in the appropriate header file. Initial values and constants are the same for all variants of RIPEMD. --- crypto/rmd128.c | 16 crypto/rmd160.c | 20 ++-- include/crypto/ripemd.h | 17 +

[PATCH 0/5][CRYPTO] add support for extended RIPEMD hash algorithms

These patches add RIPEMD-256/320 support to the cryptoapi and fix the makefile entry for rmd128.o The first patch contains a fix for to crypto/Makefile so rmd128.o is dependent on CONFIG_CRYPTO_RMD128. The second patch extracts all common values of the RIPEMD algorithms to the proper header file.

Re: [HIFN 01/n]: Endianess fixes

On Wed, May 07, 2008 at 02:14:28PM +0200, Patrick McHardy wrote: > Attached is the first of my fixes for the HIFN driver. I've > got it to a working state with tcrypt, IPsec and dm-crypt, a > few of the patches still need a bit work though, so I'll send > the ones that I already consider ready one

Re: [PATCH 0/3][CRYPTO] RIPEMD: add support for RIPEMD hash algorithms.

On Sun, May 04, 2008 at 05:03:30PM +0200, Adrian-Ken Rueegsegger wrote: > These patches add RIPEMD-128/160 support to the cryptoapi. > > The first patch contains the actual implementation of the hash > algorithms. It is based on the sample implementation by Antoon > Bosselaers (ESAT-COSIC) found a

[CRYPTO] tcrpyt: Get rid of change log in source

Hi: Before tcrypt drowns in change logs, let's get rid of them once and for all. commit 4e96a5d13beb851e6e00baec5c3a9eddcc03a2ac Author: Herbert Xu <[EMAIL PROTECTED]> Date: Wed May 7 22:19:38 2008 +0800 [CRYPTO] tcrpyt: Get rid of change log in source Change logs should be kept i

Re: [HIFN 01/n]: Endianess fixes

On Wed, May 07, 2008 at 03:46:12PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > Appologies for imperfect ordering :) The patchset grew while fixing > issues as I ran into them and attempts to reorder caused too many > conflicts. I believe it is more to mail system, which delivers 5 before

Re: [HIFN 01/n]: Endianess fixes

Evgeniy Polyakov wrote: On Wed, May 07, 2008 at 03:01:55PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: We can also be safe without volatile annotations. Yes, will also be taken care of by a later patch :) I just receive them in a strange order and do not know when others will arrive

[CRYPTO] cryptd: Fix EINPROGRESS notification context

Hi: While merging the ahash patch I found this buglet in cryptd. commit 34fe02eec1cf26f67070588a63252ca7a38c55c2 Author: Herbert Xu <[EMAIL PROTECTED]> Date: Wed May 7 21:10:13 2008 +0800 [CRYPTO] cryptd: Fix EINPROGRESS notification context The EINPROGRESS notifications should be

Re: [HIFN 01/n]: Endianess fixes

On Wed, May 07, 2008 at 03:01:55PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > >We can also be safe without volatile annotations. > > > > Yes, will also be taken care of by a later patch :) I just receive them in a strange order and do not know when others will arrive :) -- E

Re: [HIFN 05/n]: Fix data alignment checks

On Wed, May 07, 2008 at 03:05:48PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > As a side-note: its also not just an overseight in the documentation, > not aligning the destination buffer to a multiple of 4 results in the > HW freezing, the source buffer alignment changes work fine though.

Re: [HIFN 11/n]: Have HW invalidate src and dest descriptors after processing

Evgeniy Polyakov wrote: On Wed, May 07, 2008 at 02:53:17PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: The descriptors need to be invalidated after processing for ring cleanup to work properly and to avoid using an old destination descriptor when the src and cmd descriptors ar

Re: [PATCH 1/1] CryptoAPI: Add Async Hash Support

On Wed, May 07, 2008 at 03:09:14PM +0200, Patrick McHardy wrote: > > Cool, I started adding hashing support to HIFN until I noticed > the CrypoAPI doesn't support async hashing yet :) The other really cool thing about Loc's new interafce is that it'll let us have hash tfm objects that are reentr

Re: [HIFN 11/n]: Have HW invalidate src and dest descriptors after processing

On Wed, May 07, 2008 at 02:53:17PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > The descriptors need to be invalidated after processing for ring > cleanup to work properly and to avoid using an old destination > descriptor when the src and cmd descriptors are already set up >

Re: [HIFN 10/n]: Move command descriptor setup to seperate function

On Wed, May 07, 2008 at 02:50:29PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > commit 163c74fc4f18d086bbb7f114d55bc7dac939d6b7 > Author: Patrick McHardy <[EMAIL PROTECTED]> > Date: Wed May 7 13:11:59 2008 +0200 > > [HIFN]: Move command descriptor setup to seperate function > >

Re: [PATCH 1/1] CryptoAPI: Add Async Hash Support

Herbert Xu wrote: On Tue, Apr 22, 2008 at 10:23:23AM -0700, Loc Ho wrote: They are attached instead inline until I figure out how to not wrap long line. Thanks. I've finally finished testing and integrating it. I've merged them into one patch and dropped unrelated white-space changes. You c

Re: [HIFN 05/n]: Fix data alignment checks

Evgeniy Polyakov wrote: On Wed, May 07, 2008 at 02:45:15PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: Of the data buffers only the destination buffer needs to be aligned, see the Source Pointer description in "2.2 Source Descriptors" in the HIFN documentation. Ok, thanks for the refere

Re: [HIFN 07/n]: Use unique driver names for different algos

On Wed, May 07, 2008 at 02:32:45PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > [HIFN]: Use unique driver names for different algos > > When the CryptoAPI instantiates a new algorithm, it performs a lookup > by driver name. Since hifn uses the same name for all modes of one

Re: [HIFN 05/n]: Fix data alignment checks

On Wed, May 07, 2008 at 02:45:15PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > Of the data buffers only the destination buffer needs to be aligned, > see the Source Pointer description in "2.2 Source Descriptors" in > the HIFN documentation. Ok, thanks for the reference. -- Evge

Re: [HIFN 01/n]: Endianess fixes

Evgeniy Polyakov wrote: On Wed, May 07, 2008 at 02:14:28PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: [HIFN]: Endianess fixes HIFN uses little-endian by default, move cpu_to_le32 conversion to hifn_write_0/ hifn_write_1, add sparse annotations and fix an invalid endi

Re: [PATCH 1/1] CryptoAPI: Add Async Hash Support

On Tue, Apr 22, 2008 at 10:23:23AM -0700, Loc Ho wrote: > > They are attached instead inline until I figure out how to not wrap long > line. Thanks. I've finally finished testing and integrating it. I've merged them into one patch and dropped unrelated white-space changes. You can resubmit tho

Re: [HIFN 06/n]: Properly handle requests for less than the full scatterlist

On Wed, May 07, 2008 at 02:30:28PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > [HIFN]: Properly handle requests for less than the full scatterlist > > The scatterlist may contain more data than the crypto request, causing > an underflow of the remaining byte count while wa

Re: [HIFN 01/n]: Endianess fixes

On Wed, May 07, 2008 at 02:14:28PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > [HIFN]: Endianess fixes > > HIFN uses little-endian by default, move cpu_to_le32 conversion to > hifn_write_0/ > hifn_write_1, add sparse annotations and fix an invalid endian conversion > in

[HIFN 11/n]: Have HW invalidate src and dest descriptors after processing

commit 0b4add2721b85f3ea873b87b02c057f2b5cff7aa Author: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed May 7 13:15:44 2008 +0200 [HIFN]: Have HW invalidate src and dest descriptors after processing The descriptors need to be invalidated after processing for ring cleanup to work

Re: [HIFN 05/n]: Fix data alignment checks

Herbert Xu wrote: On Wed, May 07, 2008 at 02:26:30PM +0200, Patrick McHardy wrote: I'm not entirely sure about the alignmask change at the end of this patch, is an alignmask of 1 correct if no source buffer If no alignment is required you want 0, 1 means 2-byte aligned. Thanks, fi

[HIFN 10/n]: Move command descriptor setup to seperate function

Note: the DMA setup fixes mentioned in the changelog still need a bit of work, so I'm not sure if I'll manage to send them today. This one is fine for review or applying anyway. commit 163c74fc4f18d086bbb7f114d55bc7dac939d6b7 Author: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed May 7 13:11:59

Re: [HIFN 05/n]: Fix data alignment checks

On Wed, May 07, 2008 at 02:26:30PM +0200, Patrick McHardy wrote: > I'm not entirely sure about the alignmask change at the end of > this patch, is an alignmask of 1 correct if no source buffer If no alignment is required you want 0, 1 means 2-byte aligned. Cheers, -- Visit Openswan at http://www

Re: [HIFN 05/n]: Fix data alignment checks

Evgeniy Polyakov wrote: On Wed, May 07, 2008 at 02:26:30PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: I'm not entirely sure about the alignmask change at the end of this patch, is an alignmask of 1 correct if no source buffer alignment is required, but the destination buffer should be

Re: [HIFN 09/n]: Fix max queue length value

On Wed, May 07, 2008 at 02:38:31PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > > commit 21b18f9b22c7aa0a458c3f93fc1771a5eb5e70c8 > Author: Patrick McHardy <[EMAIL PROTECTED]> > Date: Wed May 7 13:00:10 2008 +0200 > > [HIFN]: Fix max queue length value > > All but the last

Re: [HIFN 04/n]: Handle ablkcipher_walk errors

On Wed, May 07, 2008 at 02:20:34PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > commit 7e24c849df30a5d2b0bb89165b933ea2faa747bd > Author: Patrick McHardy <[EMAIL PROTECTED]> > Date: Wed May 7 12:43:20 2008 +0200 > > [HIFN]: Handle ablkcipher_walk errors > > ablkcipher_walk m

Re: [HIFN 05/n]: Fix data alignment checks

On Wed, May 07, 2008 at 02:26:30PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > I'm not entirely sure about the alignmask change at the end of > this patch, is an alignmask of 1 correct if no source buffer > alignment is required, but the destination buffer should be > (doesn't have to be t

[HIFN 09/n]: Fix max queue length value

commit 21b18f9b22c7aa0a458c3f93fc1771a5eb5e70c8 Author: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed May 7 13:00:10 2008 +0200 [HIFN]: Fix max queue length value All but the last element of the command and result descriptor rings can be used for crypto requests, fix HIFN_QUEU

[HIFN 08/n]: Properly initialize ivsize for CBC modes

Two questions regarding this patch: - do OFB and CFB also need ivsize initialization? - the HIFN documentation doesn't mention OFB and CFB (the values are marked reserved), do they actually work? commit d4ef6dd3f4e37a37c0823fd09c53657af63c8d88 Author: Patrick McHardy <[EMAIL PROTECTED]> Date:

[HIFN 07/n]: Use unique driver names for different algos

commit 02cabb7369102c475dfa33dbb6787db1855a7062 Author: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed May 7 12:54:30 2008 +0200 [HIFN]: Use unique driver names for different algos When the CryptoAPI instantiates a new algorithm, it performs a lookup by driver name. Since hifn

[HIFN 06/n]: Properly handle requests for less than the full scatterlist

commit 4f3353b225b7123cf9c04cb9ae3b987f0671ee26 Author: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed May 7 12:52:53 2008 +0200 [HIFN]: Properly handle requests for less than the full scatterlist The scatterlist may contain more data than the crypto request, causing an underfl

Re: [HIFN 03/n]: Indicate asynchronous processing to crypto API

Evgeniy Polyakov wrote: Hi. On Wed, May 07, 2008 at 02:19:36PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: hifn_setup_crypto() needs to return -EINPROGRESS on success to indicate asynchronous processing to the crypto API. This also means it must not return the errno code r

[HIFN 05/n]: Fix data alignment checks

I'm not entirely sure about the alignmask change at the end of this patch, is an alignmask of 1 correct if no source buffer alignment is required, but the destination buffer should be (doesn't have to be though) 4 byte aligned? commit f76618d53e82c8905214e889a3f79f1816c680fb Author: Patrick McHa

Re: [HIFN 02/n]: Remove printk_ratelimit() for debugging printk

On Wed, May 07, 2008 at 02:15:38PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > [HIFN]: Remove printk_ratelimit() for debugging printk > > Without debugging this spams the log with "printk: N messages surpressed" > without any actual messages on error. With debugging its mo

Re: [HIFN 03/n]: Indicate asynchronous processing to crypto API

Hi. On Wed, May 07, 2008 at 02:19:36PM +0200, Patrick McHardy ([EMAIL PROTECTED]) wrote: > hifn_setup_crypto() needs to return -EINPROGRESS on success to indicate > asynchronous processing to the crypto API. This also means it must not > return the errno code returned by hifn_process_

[HIFN 04/n]: Handle ablkcipher_walk errors

commit 7e24c849df30a5d2b0bb89165b933ea2faa747bd Author: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed May 7 12:43:20 2008 +0200 [HIFN]: Handle ablkcipher_walk errors ablkcipher_walk may return a negative error value, handle this properly instead of treating it as a huge number

[HIFN 03/n]: Indicate asynchronous processing to crypto API

commit 835b2aece80670cd439ff74e51a647836f73d0ca Author: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed May 7 12:42:06 2008 +0200 [HIFN]: Indicate asynchronous processing to crypto API hifn_setup_crypto() needs to return -EINPROGRESS on success to indicate asynchronous processin

[HIFN 02/n]: Remove printk_ratelimit() for debugging printk

commit 9dbbaf326c4033cd8d973cb6bf10298faf50180c Author: Patrick McHardy <[EMAIL PROTECTED]> Date: Wed May 7 12:38:01 2008 +0200 [HIFN]: Remove printk_ratelimit() for debugging printk Without debugging this spams the log with "printk: N messages surpressed" without any actual m

[HIFN 01/n]: Endianess fixes

Attached is the first of my fixes for the HIFN driver. I've got it to a working state with tcrypt, IPsec and dm-crypt, a few of the patches still need a bit work though, so I'll send the ones that I already consider ready one by one. commit aa543b1fcddd097b5129a9a3056f888737d88102 Author: Patric

[RFC, TCRYPT]: Catch cipher destination memory corruption

This patch adds checks to tcrypt to catch destination buffer corruption for cipher tests across pages, which was useful while fixing corruption caused by the HIFN driver. It works by always clearing xbuf before the cipher operation and counts how many bytes beyond the end of each buffer pointed t