HW Accelerated IPSEC?

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

[...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.

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 <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Yes, that makes sense.

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.)

(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.

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 <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

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.

mv_cesa uses ahash, right?

Cheers,

Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt