Stress-SGX: Load and Stress your Enclaves for Fun and Profit

Pascal Felber; S\'ebastien Vaucher; Valerio Schiavoni

arxiv: 1906.11204 · v1 · pith:MPSTCOPDnew · submitted 2019-06-26 · 💻 cs.PF · cs.DC

Stress-SGX: Load and Stress your Enclaves for Fun and Profit

S\'ebastien Vaucher , Valerio Schiavoni , Pascal Felber This is my paper

Pith reviewed 2026-05-25 14:45 UTC · model grok-4.3

classification 💻 cs.PF cs.DC

keywords SGXstress testingenclavesperformance evaluationbenchmarkingtrusted execution environmentIntel processors

0 comments

The pith

Stress-SGX adapts Stress-NG by retaining only SGX-compatible stressors to test enclave performance.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces Stress-SGX as a stress-test tool for SGX-enabled nodes, derived from the Stress-NG utility but limited to stressors that remain meaningful inside enclaves. The authors describe the process of adapting legacy workloads and the resulting limitations on execution inside the trusted environment. They apply the tool to compare performance across multiple SGX machines. A sympathetic reader would care because SGX imposes strict constraints on code and memory that standard benchmarks ignore, making accurate performance evaluation otherwise unreliable.

Core claim

Stress-SGX is built by keeping only the workload injectors from Stress-NG that are meaningful in the SGX context. The authors report insights and lessons learned about porting legacy code to run inside an SGX enclave, as well as the limitations introduced by this process. They use the resulting tool to conduct a study comparing the performance of different SGX-enabled machines.

What carries the argument

The filtered subset of Stress-NG stressors retained for compatibility with SGX enclave execution.

If this is right

Users obtain an easy-to-use method to inject load into SGX enclaves and measure resulting performance.
Direct performance comparisons become feasible between different SGX hardware configurations.
Insights on porting limitations can inform choices when moving code into enclaves.
The approach demonstrates concrete restrictions that SGX places on standard workload execution.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

Results from Stress-SGX could guide decisions on enclave memory allocation or thread counts in deployed applications.
The same filtering method might apply when creating benchmarks for other trusted execution environments.
As SGX evolves, new stressors could be added to keep the tool aligned with changing hardware capabilities.

Load-bearing premise

The stressors retained from Stress-NG are sufficient to represent the workloads that matter for real SGX enclave performance.

What would settle it

A set of real SGX applications whose measured bottlenecks differ substantially from the patterns produced by Stress-SGX would show the retained stressors are not representative.

Figures

Figures reproduced from arXiv: 1906.11204 by Pascal Felber, S\'ebastien Vaucher, Valerio Schiavoni.

**Figure 1.** Figure 1: Time needed to perform 100 000 000 enclave transitions. 3 Evaluation This section presents our preliminary evaluation of Stress-SGX [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗

**Figure 2.** Figure 2: SGX performance compared to native on different types of computers, using January 2018 microcode (previous microcode had performance similar to native). applications usually forces researchers to implement single-use workloads. This paper presented Stress-SGX, an easy-to-use tool capable of stressing SGX enclaves and report on diverse metrics. We plan to extend our prototype along the following directions… view at source ↗

read the original abstract

The latest generation of Intel processors supports Software Guard Extensions (SGX), a set of instructions that implements a Trusted Execution Environment (TEE) right inside the CPU, by means of so-called enclaves. This paper presents Stress-SGX, an easy-to-use stress-test tool to evaluate the performance of SGX-enabled nodes. We build on top of the popular Stress-NG tool, while only keeping the workload injectors (stressors) that are meaningful in the SGX context. We report on several insights and lessons learned about porting legacy code to run inside an SGX enclave, as well as the limitations introduced by this process. Finally, we use Stress-SGX to conduct a study comparing the performance of different SGX-enabled machines.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Desk Editor's Note private letter to a colleague

Stress-SGX is a direct port of selected Stress-NG stressors into SGX enclaves plus porting notes and a small machine comparison.

read the letter

The paper's core contribution is a practical tool that takes Stress-NG, drops the stressors that do not make sense inside an enclave, and ships the rest with some observations on what had to change during the port. That is the new artifact, along with the reported limits on what can run under SGX and a side-by-side run on a couple of SGX machines. The work is straightforward and fills a narrow but real need for people who already have SGX hardware and want a quick way to generate load without writing their own micro-benchmarks from scratch. The porting lessons are the most useful part for anyone else who might try something similar. The comparison study is modest in scope but at least shows the tool in use. The main soft spot is exactly the one the stress-test note flags: there is no evidence that the retained stressors actually hit the behaviors that matter for real enclave workloads. The paper selects a subset based on what the authors judged meaningful, but it does not map those choices to SGX-specific costs such as EPC paging or AEX frequency, nor does it check correlation against production applications. Without that step the tool could be systematically missing or over-weighting certain effects. The empirical claims therefore rest on the assumption that the filtered set is representative, and that assumption is not tested. This is a tool paper, not a measurement study with load-bearing claims, so the gap is noticeable but not fatal to the artifact itself. People who maintain or evaluate SGX nodes would get immediate value from the released code; researchers looking for a new framework or deep performance model will not. I would send it to peer review because the artifact is concrete and the porting notes are honest, even though the representativeness question needs to be addressed in revision.

Referee Report

2 major / 2 minor

Summary. The paper presents Stress-SGX, a stress-testing tool derived from Stress-NG by retaining only a subset of workload injectors deemed meaningful for SGX enclaves. It reports lessons and limitations from porting legacy code to run inside SGX enclaves and uses the resulting tool to compare performance across different SGX-enabled machines.

Significance. If the retained stressors prove representative, the work supplies a practical, easy-to-use benchmark for SGX node evaluation and surfaces concrete porting constraints (e.g., enclave transition overheads and EPC paging effects) that are useful for both practitioners and hardware evaluators. The empirical comparison study adds concrete data points on machine-to-machine variation.

major comments (2)

[tool design / stressor selection] The central claim that the filtered Stress-NG stressors are 'meaningful in the SGX context' (abstract and tool-construction section) rests on an unvalidated selection process. No systematic mapping is provided from SGX architectural features (EPC paging, AEX frequency, enclave transitions) to the retained stressors, nor any correlation study against production SGX applications; this directly undermines the tool's claimed representativeness.
[evaluation / machine comparison] The comparison study (final evaluation section) reports performance differences across machines but does not quantify how the chosen stressors exercise the specific SGX bottlenecks identified in the porting discussion; without this linkage the empirical results cannot be confidently attributed to SGX-specific behavior rather than generic CPU stress.

minor comments (2)

[tool construction] Clarify the exact criterion used to decide which Stress-NG stressors were retained versus discarded; a table listing retained and excluded stressors with brief rationale would improve reproducibility.
[porting discussion] The porting limitations are described qualitatively; adding quantitative overhead measurements (e.g., transition cost before/after porting) would strengthen the lessons-learned section.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for the constructive feedback on Stress-SGX. The comments highlight opportunities to strengthen the justification for stressor selection and the attribution of results to SGX-specific behavior. We address each point below and will revise the manuscript to incorporate additional mapping and quantitative linkage where feasible.

read point-by-point responses

Referee: [tool design / stressor selection] The central claim that the filtered Stress-NG stressors are 'meaningful in the SGX context' (abstract and tool-construction section) rests on an unvalidated selection process. No systematic mapping is provided from SGX architectural features (EPC paging, AEX frequency, enclave transitions) to the retained stressors, nor any correlation study against production SGX applications; this directly undermines the tool's claimed representativeness.

Authors: We agree that an explicit mapping would make the selection criteria more transparent. The original selection retained stressors that could execute inside the enclave without relying on unsupported operations (e.g., certain syscalls or dynamic memory allocation patterns that trigger excessive EPC paging). We will revise the tool-construction section to add a table that systematically maps each retained stressor to the SGX features it exercises, such as enclave transitions for context-switch stressors and EPC usage for memory-bound ones. A comprehensive correlation study against production SGX workloads is outside the scope of this tool-focused paper, but we will reference existing literature on common SGX bottlenecks to support the choices. revision: yes
Referee: [evaluation / machine comparison] The comparison study (final evaluation section) reports performance differences across machines but does not quantify how the chosen stressors exercise the specific SGX bottlenecks identified in the porting discussion; without this linkage the empirical results cannot be confidently attributed to SGX-specific behavior rather than generic CPU stress.

Authors: We acknowledge the value of explicit quantification. The evaluation runs all stressors inside enclaves on SGX hardware, and the porting section already identifies transition overhead and paging as key constraints. To strengthen the linkage, we will extend the evaluation section with additional instrumentation that reports AEX frequency and EPC page-fault counts for each stressor across the tested machines. This will provide quantitative evidence that the observed differences reflect SGX-specific effects rather than purely generic CPU load. revision: yes

Circularity Check

0 steps flagged

No circularity; tool construction and empirical measurement are self-contained

full rationale

The paper describes the construction of Stress-SGX by selecting and porting a subset of Stress-NG stressors deemed relevant to SGX, followed by performance measurements on SGX hardware. No equations, fitted parameters, predictions, or derivations are present. Selection of stressors is presented as an engineering choice with acknowledged limitations, not as a derived result. No self-citations are used to justify uniqueness or load-bearing claims. The work is therefore self-contained against external benchmarks and contains no reduction of outputs to inputs by construction.

Axiom & Free-Parameter Ledger

0 free parameters · 0 axioms · 0 invented entities

This is a systems tool and benchmarking paper with no mathematical derivations, fitted parameters, or postulated entities.

pith-pipeline@v0.9.0 · 5661 in / 978 out tokens · 32638 ms · 2026-05-25T14:45:49.463204+00:00 · methodology

discussion (0)

Reference graph

Works this paper leans on

7 extracted references · 7 canonical work pages · 1 internal anchor

[1]

ERCIM News (92), 43–44 (2013)

Bourdon, A., Noureddine, A., Rouvoy, R., Seinturier, L.: PowerAPI: A software library to monitor the energy consumed at the process-level. ERCIM News (92), 43–44 (2013)

work page 2013
[2]

In: SOSP ’17

Cortez, E., Bonde, A., Muzio, A., Russinovich, M., Fontoura, M., Bianchini, R.: Resource central: Understanding and predicting workloads for improved resource management in large cloud platforms. In: SOSP ’17. pp. 153–167 (2017)

work page 2017
[3]

Intel Corporation: Intel Software Guard Extensions SDK Developer Reference for Linux OS (Nov 2017),https://frama.link/sgx20

work page 2017
[4]

King, C.I.: Stress-ng,http://kernel.ubuntu.com/~cking/stress-ng/

work page
[5]

Spectre Attacks: Exploiting Speculative Execution

Kocher, P., Genkin, D., Gruss, D., Haas, W., Hamburg, M., Lipp, M., et al.: Spectre attacks: Exploiting speculative execution. arXiv preprint arXiv:1801.01203 (2018)

work page internal anchor Pith review Pith/arXiv arXiv 2018
[6]

In: EuroSys ’17

Orenbach, M., Lifshits, P., Minkin, M., Silberstein, M.: Eleos: ExitLess OS services for SGX enclaves. In: EuroSys ’17. pp. 238–253 (2017)

work page 2017
[7]

Google research blog (Nov 2011),http:// googleresearch.blogspot.com/2011/11/more-google-cluster-data.html

Wilkes, J.: More Google cluster data. Google research blog (Nov 2011),http:// googleresearch.blogspot.com/2011/11/more-google-cluster-data.html

work page 2011

[1] [1]

ERCIM News (92), 43–44 (2013)

Bourdon, A., Noureddine, A., Rouvoy, R., Seinturier, L.: PowerAPI: A software library to monitor the energy consumed at the process-level. ERCIM News (92), 43–44 (2013)

work page 2013

[2] [2]

In: SOSP ’17

Cortez, E., Bonde, A., Muzio, A., Russinovich, M., Fontoura, M., Bianchini, R.: Resource central: Understanding and predicting workloads for improved resource management in large cloud platforms. In: SOSP ’17. pp. 153–167 (2017)

work page 2017

[3] [3]

Intel Corporation: Intel Software Guard Extensions SDK Developer Reference for Linux OS (Nov 2017),https://frama.link/sgx20

work page 2017

[4] [4]

King, C.I.: Stress-ng,http://kernel.ubuntu.com/~cking/stress-ng/

work page

[5] [5]

Spectre Attacks: Exploiting Speculative Execution

Kocher, P., Genkin, D., Gruss, D., Haas, W., Hamburg, M., Lipp, M., et al.: Spectre attacks: Exploiting speculative execution. arXiv preprint arXiv:1801.01203 (2018)

work page internal anchor Pith review Pith/arXiv arXiv 2018

[6] [6]

In: EuroSys ’17

Orenbach, M., Lifshits, P., Minkin, M., Silberstein, M.: Eleos: ExitLess OS services for SGX enclaves. In: EuroSys ’17. pp. 238–253 (2017)

work page 2017

[7] [7]

Google research blog (Nov 2011),http:// googleresearch.blogspot.com/2011/11/more-google-cluster-data.html

Wilkes, J.: More Google cluster data. Google research blog (Nov 2011),http:// googleresearch.blogspot.com/2011/11/more-google-cluster-data.html

work page 2011