[PATCH] Use Intel AES instruction set if it exists - v3

[Stefan Metzmacher]

Am 06.09.2017 um 13:35 schrieb Andreas Schneider:
> On Tuesday, 5 September 2017 23:08:45 CEST Jeremy Allison via samba-technical 
> wrote:
>> Hi all,
>>
>> Off-list Justin @ Netgear has been doing
>> some performance measurements between native
>> Samba AES, the libnettle crypto library and
>> Intel AES instructions.
>>
>> Whilst doing that he discovered that on Debian 9,
>> and Ubuntu 17.04 and before, libnettle has been
>> built without AES instruction support and is thus
>> much *slower* than our native crypto. On Fedora
>> and SuSE it's correctly built and so provides better
>> performance, although the native Intel AES code is
>> still the fastest.
>>
>> I don't have permission to publish his absolute numbers,
>> but have a work-around here of publishing comparative
>> results (hope that's OK Justin, but it's easier to
>> ask for forgiveness than wait for permission:-).
>> Consider native Samba as performance 1.000. We have:
>>
>> Native Samba AES code:			1.000
>> Intel AES code:				2.386
>> libnettle --enable-fat (Fedora|SuSE):	1.704
>> libnettle (Debian|Ubuntu):		0.818
>>
>> As you can see, Intel AES code gives a significant
>> advantage.
>>
>> Given that, after discussions offline with Andreas
>> (who has to support FIPS certification for Fedora)
>> and Metze, here is a patchset that allows configure
>> time selection of AES crypto.
>>
>> --accel-aes=none (default - use Samba native crypto)
>>
>> --accel-aes=nettle|libnettle (Use libnettle)
>>
>> --accel-aes=intelaesni (Use third_party code)
>>
>> Part of this is a WHATSNEW that specifies that
>> the --accel-aes=intelaesni and supporting code
>> is a temporary fix and WILL be removed from Samba
>> once libnettle reaches performance parity.
>>
>> Andreas, let me know if this meets your requirements.
> 
> I've talked to Nikos. GnuTLS uses the AES-NI assembler code from OpenSSL and 
> it is much much faster than what libnettle offers:
> 
> Benchmark with libnettle:
> GNUTLS_CPUID_OVERRIDE=1 gnutls-cli --benchmark-ciphers
> 
> Benchmark with GnuTLS AES-NI:
> gnutls-cli --benchmark-ciphers
> 
> Since GnuTLS 3.4 (we require 3.4.7 right now) there are new AEAD cipher 
> functions. Maybe this is going into the direction metze wants to have, see
> 
> https://www.gnutls.org/manual/html_node/Symmetric-algorithms.html

It's not what I'm looking for as it means we would have to use talloc
and memcpy in smb2_signing_[en|de]crypt_pdu(), but with a speed
of AES-128-GCM 1.40 GB/sec it might be a good start. So we better take
the cost of talloc and memcpy then the cost of aes-gcm, but we'll have
to test that first.

But first we should convert to an api like this:

void aes_gcm_128_init(struct aes_gcm_128_context *ctx,
                      const uint8_t K[AES_BLOCK_SIZE],
                      const uint8_t IV[AES_GCM_128_IV_SIZE]);
void aes_gcm_128_update(struct aes_gcm_128_context *ctx,
                        const struct iovec *a_iov, size_t a_iov_count,
                        struct iovec *m, size_t m_iov_count,
			bool forward);
void aes_gcm_128_digest(struct aes_gcm_128_context *ctx,
                        uint8_t T[AES_BLOCK_SIZE]);

(and similar onces for aes_ccm).

So that the memcpy will be transparent to our SMB3 code.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170906/da45c571/signature.sig>