aesni doesn't play nice with krb5

[Konstantin Belousov]

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.