Date: Thu, 30 Jan 2020 15:01:44 -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: <090ad112-dcca-6cb1-d6bf-fc7fb67ebedf@FreeBSD.org> In-Reply-To: <CAGOBvLoaemMSE3_purDPxRYNRd80V4gChNaxXLpqm9eCRhyfRw@mail.gmail.com> References: <CAGOBvLoaemMSE3_purDPxRYNRd80V4gChNaxXLpqm9eCRhyfRw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?090ad112-dcca-6cb1-d6bf-fc7fb67ebedf>