Date: Thu, 28 Jan 2016 00:48:49 -0800 From: Stanislav Sedov <stas@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Alan Somers <asomers@FreeBSD.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org> Subject: Re: aesni doesn't play nice with krb5 Message-ID: <6329AC49-E26B-4DB8-A897-77FE3C858C86@freebsd.org> In-Reply-To: <20160128084349.GJ74231@kib.kiev.ua> References: <CAOtMX2hxYQQfx7T=unLbJUtjQ2hmHHt5Dgu7E5q9EWCegh9OQQ@mail.gmail.com> <F9B17F79-93B0-4648-8BBF-827BD26FA420@FreeBSD.org> <20160128084349.GJ74231@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
> On Jan 28, 2016, at 12:43 AM, Konstantin Belousov = <kostikbel@gmail.com> wrote: >=20 > On Wed, Jan 27, 2016 at 06:21:11PM -0800, Stanislav Sedov wrote: >>=20 >>> On Jan 27, 2016, at 3:55 PM, Alan Somers <asomers@FreeBSD.org> = wrote: >>>=20 >>> I'm experimenting with Kerberized NFS, but my performance sucks when = I >>> use krb5p. I tracked the problem down to an interaction between = aesni >>> and krb5: aes_set_key in kcrypto_aes.c registers for a crypto = session >>> and requests support for two algorithms: CRYPTO_SHA1_HMAC and >>> CRYPTO_AES_CBC. aesni(4) supports the latter, but not the former. = So >>> crypto_select_driver returns cryptosoft and krb5 uses software for >>> both algorithms. >>>=20 >>> It's too bad that aesni doesn't support SHA1, but other software = like >>> OpenSSL deals with it by using hardware for AES and software for = SHA1. >>> It seems to me like krb5 could be made to do the same by registering >>> for two sessions, one for each algorithm. In fact, it seems like it >>> would be pretty easy to do. The changes would probably be confined >>> strictly to crypto_aes.c. Is there any reason why this wouldn't = work? >>>=20 >>=20 >> This sounds great to me. Might be worth checking with the upstream >> Heimdal project to see if they might have some suggestions. But we >> can definitely apply this change locally in FreeBSD as we're probably >> affected by this more than other Heimdal consumers (who do not rely = on >> encryption that much). >>=20 >=20 > Could somebody clarify whether the session initiator is the code > from user or kernel space ? My note is that utilizing AESNI through > /dev/crypto is useless, the syscall overhead and kernel bookkeeping = eats > so much time that even software AES implementations are faster than > AESNI through /dev/crypto. >=20 It=E2=80=99s actually in the kernel: sys/kgssapi/krb5/kcrypto_aes.c. = Please disregard my earlier reply as I somehow assumed we were talking about Heimdal, but now I realized that given it=E2=80=99s NFS encryption, it = obviously isn=E2=80=99t in userspace. -- ST4096-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6329AC49-E26B-4DB8-A897-77FE3C858C86>