Date: Fri, 31 Jan 2020 09:57:28 -0800 From: John Baldwin <jhb@FreeBSD.org> To: Patryk Duda <pdk@semihalf.com>, freebsd-arch@freebsd.org Subject: Re: CFT: Open Crypto Framework Changes: Round 1 Message-ID: <1a9aff1f-9ed4-5f51-9456-7bcdccd98678@FreeBSD.org> In-Reply-To: <090ad112-dcca-6cb1-d6bf-fc7fb67ebedf@FreeBSD.org> References: <CAGOBvLoaemMSE3_purDPxRYNRd80V4gChNaxXLpqm9eCRhyfRw@mail.gmail.com> <090ad112-dcca-6cb1-d6bf-fc7fb67ebedf@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/30/20 3:01 PM, John Baldwin wrote: > On 1/9/20 7:53 AM, Patryk Duda wrote: >> Hi John, >> >> I tested ocf_rework branch on device which has cesa support. Output from >> "cryptocheck -vz -a all" doesn't differ when kernel was compiled from >> ocf_rework and from e0f7c88b6c (commit before changes). In both cases I can >> get the same number of interrupts generated by cesa using "vmstat -i". >> Nevertheless when I'm running IPSec (Strongswan acts as IKE daemon) >> software crypto is used instead of cesa. Performance is poor and no cesa >> interrupts are generated. When running kernel built from commit e0f7c88b6c >> IPSec works fine. Strongswan is configured to use only AES128 CBC + SHA256 >> HMAC. This combination is supported by cesa, confirmed by cryptocheck. In >> my opinion something between IPSec and cesa is broken. > > Hmm, thanks for testing. I just rechecked and ccr(4) and aesni(4) both work > with IPsec. The sessions created by the "eta" cryptocheck tests should match > the sessions IPsec creates that cesa would have a chance to test. Ah, I guess > they might differ in the csp_auth_mlen parameter. > > Can you add some printfs to see if cesa_auth_supported is failing, and if so > is it due to not liking the value of csp_auth_mlen? I added some pretty > conservative checks on valid mlen values, but I could probably relax those > to allow any length up to the size of the hash. After looking further, I'm pretty sure this was the issue since SHA2 256 would use half of the hash which is not 96 bits. I've pushed a fix to the branch that should address this. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1a9aff1f-9ed4-5f51-9456-7bcdccd98678>