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.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
