aesni doesn't play nice with krb5

[Stanislav Sedov]

> On Jan 28, 2016, at 12:43 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> 
> On Wed, Jan 27, 2016 at 06:21:11PM -0800, Stanislav Sedov wrote:
>> 
>>> On Jan 27, 2016, at 3:55 PM, Alan Somers <asomers at FreeBSD.org> wrote:
>>> 
>>> 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.
>>> 
>>> 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?
>>> 
>> 
>> 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).
>> 
> 
> 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.
> 

It’s 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’s NFS encryption, it obviously
isn’t in userspace.

--
ST4096-RIPE