intel / intel/confidential-computing.sgx.sdk

high performance overhead

Open
#81 2 comments 1 reaction 0 assignees View on GitHub
question
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.