You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have been developing a benchmark framework specially for SGX.
Initially started with SDK version 2.6/2.7 and it was working well on the benchmark program set i have.
Currently, the benchmark program set includes:
A string modifcation and pattern detection library written in SGX and multiple Intel SGX-ssl cryptographic operations like RSA encryption decryption and hashing with SHA256.
Recently, I patched the framework with one of the newest SDK versions (2.12) without doing any changes to the benchmark code.
This change of SDK versions had a huge impact on the performance overhead by almost a factor of 10.
I tried to investigate if it was because of the different microcode version or SGX driver but it was neither.
It was purely, the change between the SDK versions from 2.7 to 2.12.
I can only assume it's due to new mitigation mechanisims built in the new SDK versions. However, I can't be so sure without a clear explanation of what causing that overhead is.
Therefore, I would greatly appreciate it if someone could elaborate more about this in case it is known to you or is it a fault from my side.
The performance degredation happens only to small buffer sizes and for bigger sizes the performance slowly stabilizes like in the older SDK version, which leave me only to assume that the in-enclave allocation might be causing this
P.S.: (important) The conducted benchmarks are without enclave transitions. In other words, 1 threads outside the enclave is running for a threshold amount of time and other is executing the benchmark inside the enclave inside a loop.
Thus, the measurement completely exclude the ecall transitions of calling the corresponding benchmark functions.
Much thanks in advance
The text was updated successfully, but these errors were encountered:
Comparing between SDK 2.7 with 2.12, we have many changes. The mitigation changes, data copy changes in sgx_edger8r, random stack support, etc. These changes all have much impacts on the performance.
And you mentioned you are using SGX-SSL. SGX-SSL version is also changed in this period.
Hello there,
I have been developing a benchmark framework specially for SGX.
Initially started with SDK version 2.6/2.7 and it was working well on the benchmark program set i have.
Currently, the benchmark program set includes:
A string modifcation and pattern detection library written in SGX and multiple Intel SGX-ssl cryptographic operations like RSA encryption decryption and hashing with SHA256.
Recently, I patched the framework with one of the newest SDK versions (2.12) without doing any changes to the benchmark code.
This change of SDK versions had a huge impact on the performance overhead by almost a factor of 10.
I tried to investigate if it was because of the different microcode version or SGX driver but it was neither.
It was purely, the change between the SDK versions from 2.7 to 2.12.
I can only assume it's due to new mitigation mechanisims built in the new SDK versions. However, I can't be so sure without a clear explanation of what causing that overhead is.
Therefore, I would greatly appreciate it if someone could elaborate more about this in case it is known to you or is it a fault from my side.
I will add two plots one for the SHA256 and the other with the string modification library
sha256.pdf
dnaWithoutOcalls2SDKs.pdf
The performance degredation happens only to small buffer sizes and for bigger sizes the performance slowly stabilizes like in the older SDK version, which leave me only to assume that the in-enclave allocation might be causing this
P.S.: (important) The conducted benchmarks are without enclave transitions. In other words, 1 threads outside the enclave is running for a threshold amount of time and other is executing the benchmark inside the enclave inside a loop.
Thus, the measurement completely exclude the ecall transitions of calling the corresponding benchmark functions.
Much thanks in advance
The text was updated successfully, but these errors were encountered: