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