[PATCH] Use Intel AES instruction set if it exists - v3
metze at samba.org
Wed Sep 6 13:54:48 UTC 2017
Am 06.09.2017 um 13:35 schrieb Andreas Schneider:
> On Tuesday, 5 September 2017 23:08:45 CEST Jeremy Allison via samba-technical
>> 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
>> 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
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,
void aes_gcm_128_digest(struct aes_gcm_128_context *ctx,
(and similar onces for aes_ccm).
So that the memcpy will be transparent to our SMB3 code.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: OpenPGP digital signature
More information about the samba-technical