intel / intel/confidential-computing.sgx.sdk
high performance overhead
- Dominant language
- C++
- Stars
- 2
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
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](https://github.com/intel/linux-sgx/files/6044351/sha256.pdf)
[dnaWithoutOcalls2SDKs.pdf](https://github.com/intel/linux-sgx/files/6044353/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
Contributor guide
Research direction
Start by comparing the reported benchmark results between SGX SDK 2.7 and 2.12, using the SHA256 and string-modification plots and the note that small buffers are most affected. The payload names no source files or tests; done would mean identifying and clearly explaining the cause of the performance overhead, or documenting the remaining uncertainty.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- performance, security
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100