Background

IBM Storage Scale is a software defined storage offering of a clustered file system bundled together with other services. Samba is included as part of the product to provide a clustered SMB file server and integration into Active Directory.

SMB security is essential for safeguarding sensitive data, maintaining network integrity, and protecting against attacks like eavesdropping, data tampering, and malware. In a modern, networked environment, strong SMB security is a fundamental part of any organization's broader cybersecurity strategy. Without proper security mechanisms, SMB communications are vulnerable to a range of serious threats that can compromise both data integrity and confidentiality. 

Key SMB Security Features are: authentication, encryption, and signing.

In SMBv2, signing was optional by default but could be configured as required.
Encryption was introduced with SMB 3.0. Prior to SMB 3.0, including in SMBv2, data transmitted over SMB was unencrypted.

Summary of Security in SMB Versions:

IBM Storage Scale supports protocol levels SMB2 and the base functionality of SMBv3 (dialect negotiation, secure negotiation, encryption of data on the wire). Different cryptographic libraries have been used for Samba in IBM Storage Scale over time. Around Samba 4.3 timeframe, there was a requirement to provide SMB encryption using CPU accelerated crypto instructions for x86_64 and ppc64le. At that time, upstream Samba did not provide crypto acceleration. To quickly deploy a solution, a code change has been added to Samba in IBM Storage Scale to use AES function from OpenSSL cryptographic library. Later in Samba 4.8, hardware acceleration was available but only for x86_64[1] not for ppc64le, so IBM Storage Scale continued using its OpenSSL implementation. Samba 4.12 switched from its in-tree security implementation to use GnuTLS[2] (and the nettle crypto library used by GnuTLS), which at that point it had hardware acceleration for x86_64 and ARM, but not for ppc64le. In the meantime there were efforts to get the missing support for ppc64le in the correct places[3]. The support was finally added to nettle 3.7 and later backported to nettle in RHEL 8.5. At that timeframe, IBM Storage Scale was using Samba 4.19, and it was decided to finally switch from patching Samba to use OpenSSL, to instead use the Samba upstream code that leverages GnuTLS and nettle (since at this point, hardware acceleration was supported in x86_64 and ppc64le).  The figure below portraits the evolution of cryptographic support over Samba versions (Upstream Samba and Scale Samba).

This report compares the performance of IBM Storage Scale Samba using OpenSSL vs GnuTLS on signing and encryption. The performance evaluation is mostly focused on ppc64le, and limited experiments were done on x86_84 as well. 

Workloads with sequential and mixed IO were used to evaluate performance of  GPFS 5.2.0 + Samba 4.17.12 (RPM packages named smb-4.17.12_gpfs_5-1) which use OpenSSL vs GPFS 5.2.1 + samba 4.19.7 (RPM packages named smb-4.19.7_gpfs_3-2) which use GnuTLS.

  
The following figure shows the environment used:

The following security setting combinations were used^[4] for ppc64le and x86_64:

• encryption and signing off (Enc F + Sig F)
• encryption off and signing on (Enc F + Sig T)
• encryption on and signing off (Enc T + Sig F)

Disclaimer: It is important to note that the studies reported below are not for comparison between ppc64le and x86_64 (the x86 servers are much older than the Power servers). The comparison is strictly between the usage of OpenSSL and GnuTLS in Scale Samba.

Evaluation Results on Power

Workload: sequential writes and reads (IOZone) using 1 Windows client

As shown in the graphs below, here are the performance results:

Impact of security features on performance

• Signing has a substantial impact on the performance of sequential write/read (up to -70%).
• Encryption also has an impact on sequential write/read, but not as much as signing.

5.2.0 (with OpenSSL) vs 5.2.1 (with GnuTLS)

• Without security features:
  • The performance for sequential write/read is similar in 5.2.0 (with OpenSSL) and 5.2.1 (with GnuTLS).
• With signing:
  • The performance for sequential write/read improved significantly (up to 250%) in 5.2.1 (with GnuTLS).
• With encryption:
  • The sequential read performance is similar in 5.2.0 (with OpenSSL) and in 5.2.1 (with GnuTLS).
  • The sequential write performance is slightly degraded in 5.2.1 (with GnuTLS) when comparing with 5.2.0 (with OpenSSL).

Workload: SPECSFS SWBUILD

The graphs below show the following:

Impact of security features on performance

• Security features do not have significant impact on SWBUILD performance (same as observed with x86_64).

5.2.0 (with OpenSSL) vs 5.2.1 (with GnuTLS)

• The maximum IOPS is 14% higher in 5.2.1 (with GnuTLS) comparing with 5.2.0 (with OpenSSL), that is 4000 OPs vs 3500 OPs.

Workload: SPECSFS DATABASE

The graphs below show the following:

Impact of security features on performance:

• Signing adds extra overhead that caused higher latency in 5.2.0 (with OpenSSL).
• Encryption does not have significant impact on DATABASE workload.

5.2.0 (with OpenSSL) vs 5.2.1 (with GnuTLS)

• Without security features:
  • The performance for DATABASE workload is similar in 5.2.0 (with OpenSSL) and 5.2.1 (with GnuTLS).
• With signing:
  • The performance is improved in 5.2.1 (with GnuTLS) comparing with 5.2.0 (with OpenSSL). Given this improvement, DATABASE performance with and without security features is similar in 5.2.1 (with GnuTLS).

Evaluation results on x86

Note: Very limited experiments were done at this time.

Workload: sequential writes and reads (IOZone) using 1 Windows client

The graphs below show the following:

Impact of security features on performance

• Both signing and encryption have significant impact on sequential write/read, up to over -80% with signing and -60% with encryption.

5.2.0 (with OpenSSL) vs 5.2.1 (with GnuTLS)

• Without security features:
  • The performance for sequential write/read is similar in 5.2.0 (with OpenSSL) and 5.2.1 (with GnuTLS).
• With signing:
  • The performance for sequential write/read improved significantly (up to 60%) in 5.2.1 (with GnuTLS).
• With encryption:
  • Sequential read performance is slightly better in 5.2.1 (with GnuTLS).

Summary

• Without security features
  • SMB performance for sequential write/read and SPECSFS DATABASE is similar in IBM Storage Scale 5.2.0 (with OpenSSL) and IBM Storage Scale 5.2.1 (with GnuTLS).
  • Maximum performance is improved for SPECSFS SWBUILD in IBM Storage Scale Scale 5.2.1 comparing with 5.2.0.
• With security features, the performance impact depends on workload characteristics.
  • For sequential workload severe performance impact was seen with signing and moderate to light impact with encryption.
  • For workloads that are very metadata intensive (like SPECSFS SWBUILD, which does not have sequential write/read operations) will not see performance improvements in IBM Storage Scale with GnuTLS.
  • Mixed workloads that have some percentage of sequential write/read (like SPECSFS DATABASE, which has 26% of sequential write and 1% of sequential read) may show performance impact with signing.
  • IBM Storage Scale 5.2.1 with GnuTLS improves the performance with signing in general. 

References

[1] smbd does not use the Intel AES instruction set for signing and encryption

https://bugzilla.samba.org/show_bug.cgi?id=13008

[2] Samba 4.12 switched from its in-tree security implementation to use GnuTLS

https://www.samba.org/samba/history/samba-4.12.0.html

https://blog.cryptomilk.org/2019/10/02/samba-and-gnutls/

[3] Nettle-3.7 release

https://lists.gnu.org/archive/html/info-gnu/2021-01/msg00002.html

[4] When encryption is enabled, there is no signing. 

https://techcommunity.microsoft.com/blog/filecab/configure-smb-signing-with-confidence/2418102 

#Highlights
#Highlights-home