Re: HW Accelerated IPSEC?

[Kent Borg <kentborg@borg.org>]

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.