HW Accelerated IPSEC?

HW Accelerated IPSEC?

[Kent Borg]

Does HW acceleration of IPSEC work?  I am trying to get it working on 
some new hardware, and for comparison I tried it on a Sheevaplug, 
various Linus kernels from 2.6.35 to 2.6.39.  All fail.  I reboot and 
rmmod mv_cesa and it IPSEC works on all of them.

Is the kernel broken?  Is mv_cesa broken?  Am I being stupid elsewhere?


Thanks,

-kb

Re: HW Accelerated IPSEC?

[Kent Borg]

Kent Borg wrote:
> Does HW acceleration of IPSEC work?

[...sounds of crickets...]

Let me re-phrase the question.

Should loading a crypto module (in this case mv_cesa in a Sheevaplug) 
cause IPSec to break?  (Is the crypto system wired up with IPSec?  Does 
that wiring work?)


Thanks,

-kb, the Kent who is trying verify his own new (iffy) crypto hardware 
driver, get it to work with IPSec, and was looking for some working example.

Re: HW Accelerated IPSEC?

[Herbert Xu]

Kent Borg <kentborg@borg.org> wrote:
> Kent Borg wrote:
>> Does HW acceleration of IPSEC work?
> 
> [...sounds of crickets...]
> 
> Let me re-phrase the question.
> 
> Should loading a crypto module (in this case mv_cesa in a Sheevaplug) 
> cause IPSec to break?  (Is the crypto system wired up with IPSec?  Does 
> that wiring work?)

Since your IPsec is actually breaking, then mv_cesa is probably
getting used.

Did you compile in the self-test suite (unset
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS)?

It sounds like a bug in mv_cesa.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: HW Accelerated IPSEC?

[Kent Borg]

Herbert Xu wrote:
 > Since your IPsec is actually breaking, then mv_cesa is probably 
getting used.

Yes, that makes sense.

 > Did you compile in the self-test suite (unset
 > CONFIG_CRYPTO_MANAGER_DISABLE_TESTS)?

I have it unset, and /proc/crypto is reporting all tests as passed for 
mv_cesa. (My driver, which also doesn't work with IPSec, also passes all 
the tests.)

> It sounds like a bug in mv_cesa.
>   

(Assuming I am not breaking it some how in my usage.) And a 
corresponding bug in my driver. I looked at mv_cesa and other drivers, I 
might have copied an mv_cesa bug.

I made module versions of aes_generic, sha1_generic, and sha256_generic, 
and boosted the priorities a bit. When I run IPSec through them, I see 
the use counts for my munged versions go up, and it works. So I guess I 
have shown that a module can do crypto for IPSec. Just not mv_cesa nor 
my module.

Looking at packet dumps in both the good and bad IPSec cases, it seems 
the key negotiation is working, but when a payload packet is expected 
(the first packet that I think will use the crypto module), I never see 
it in the mv_cesa case.

I was hoping that passing the self-test meant my code worked. I also 
used an encrypted lookback filesystem with both mv_cesa and my module, 
and, after I fixed my "last bug", both can handle that.

Maybe both modules are processing the data-in/data-out aspect correctly, 
but are misbehaving in some other way; a missing lock on a critical 
section, for example. For some reason IPSec gets unhappy where self-test 
and loopback are quite content. Or, maybe IPSec has a bug that is 
somehow exposed when a different HW unit gets into the act. (Which is 
why I was looking for any confirmed case of IPSec going through the 
kernel's crypto infrastructure for HW acceleration.)


Thanks,

-kb, the Kent who is looking for a way to simplify the problem.

Re: HW Accelerated IPSEC?

[Herbert Xu]

Kent Borg <kentborg@borg.org> wrote:
>
> Maybe both modules are processing the data-in/data-out aspect correctly, 
> but are misbehaving in some other way; a missing lock on a critical 
> section, for example. For some reason IPSec gets unhappy where self-test 
> and loopback are quite content. Or, maybe IPSec has a bug that is 
> somehow exposed when a different HW unit gets into the act. (Which is 
> why I was looking for any confirmed case of IPSec going through the 
> kernel's crypto infrastructure for HW acceleration.)

That is entirely possible.

One way to test whether this is a bug in IPsec or crypto is to
instantiate a cryptd instance on sha by using cryptd(sha1-generic).

If that works then it's probably a bug in your driver, otherwise
we may have an issue in IPsec itself.

Thanks!
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: HW Accelerated IPSEC?

[Kent Borg]

Herbert Xu wrote:
 > If that works then it's probably a bug in your driver, otherwise
 > we may have an issue in IPsec itself.

I think I found my bug. I discovered DMA_API_DEBUG, and it complains 
when my sha1 module loads. Looking it over it seems I can't do DMA from 
an shash, I will have to figure out how to make an ahash. (Any pointers 
on what code to crib from to best understand how an ahash works? Any 
other documentation??)

So, my sha1 module passes the self-test...just not safely.


Thanks,

- kb, the Kent who doesn't just opine about entropy.

Re: HW Accelerated IPSEC?

[Herbert Xu]

On Tue, Jun 14, 2011 at 04:51:19PM -0400, Kent Borg wrote:
> Herbert Xu wrote:
> > If that works then it's probably a bug in your driver, otherwise
> > we may have an issue in IPsec itself.
>
> I think I found my bug. I discovered DMA_API_DEBUG, and it complains  
> when my sha1 module loads. Looking it over it seems I can't do DMA from  
> an shash, I will have to figure out how to make an ahash. (Any pointers  
> on what code to crib from to best understand how an ahash works? Any  
> other documentation??)
>
> So, my sha1 module passes the self-test...just not safely.

mv_cesa uses ahash, right?

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt