Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

high performance overhead #679

Open
MoeMahhouk opened this issue Feb 25, 2021 · 1 comment
Open

high performance overhead #679

MoeMahhouk opened this issue Feb 25, 2021 · 1 comment

Comments

@MoeMahhouk
Copy link

MoeMahhouk commented Feb 25, 2021

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

@lzha101
Copy link
Contributor

lzha101 commented Mar 2, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants