Pith. sign in

REVIEW 2 major objections 6 minor 1 cited by

SeSeMI: Secure Serverless Model Inference on Sensitive Data

T0 review · 2 major / 6 minor · reviewed 2026-08-11 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read SeSeMI claims that serverless model inference can keep models and user requests secret from an untrusted cloud by adding three non-intrusive components to existing serverless platforms, with low latency and cost.

desk verdict A genuinely useful confidential-serverless-inference system with a missing revocation path that undercuts the headline security claim. read the letter →

arxiv 2412.11640 v1 pith:4BQ6NFSK submitted 2024-12-16 cs.CR cs.DC

Guoyu Hu , Yuncheng Wu , Gang Chen , Tien Tuan Anh Dinh , Beng Chin Ooi This is my paper · ORCID
classification cs.CRcs.DC
keywords serverlesscomputingmodelinferenceIntelSGXtrustedexecutionenvironmentaccesscontrolconfidentialremoteattestationOpenWhisk
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

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

The reading

This paper sets out to show that serverless model inference can protect both the model and the user's request data from an untrusted cloud provider, without forcing the provider to change its serverless platform. The proposed system, SeSeMI, adds three components on top of a standard serverless stack: a key service that attests enclaves and enforces access control, an enclave runtime that reuses cached keys, models, and runtimes across requests, and a packer that lets multiple models share an instance under sparse traffic. The authors argue that trusted hardware alone does not solve the problem, because users cannot directly attest ephemeral serverless instances and TEE setup is expensive; their design delegates attestation to an always-on service and amortizes setup cost. On Apache OpenWhisk with two inference frameworks, they report that hot requests, which reuse an already-loaded enclave, run at nearly the speed of plaintext serving, and that concurrent request handling cuts per-request memory and monetary cost.

What carries the argument

The central mechanism is KeyService, an always-on attestation bridge enclave that holds identity keys, model keys, request keys, and access-control tuples, and provisions keys to a SeMIRT enclave only after mutual remote attestation confirms the enclave's MRENCLAVE matches the policy. The companion mechanism is SeMIRT's key/model/runtime cache inside the enclave, which turns cold starts into warm or hot invocations; FnPacker then decides which endpoint should receive each request based on pending work and idle state.

What would settle it

Revoke a user's access by removing her entries from ACM and KS_R at KeyService, then send a fresh request from that user to a warm endpoint that has previously served her; if the endpoint answers without contacting KeyService, the claimed access-control enforcement is disproven.

Watch

Extended reading notes

Core claim

SeSeMI's central claim is that confidentiality and access control for model serving can be achieved on an unmodified serverless platform by moving trust to a KeyService enclave and by making the serving enclaves stateful. The model owner and each user first attest KeyService and register long-term keys; the owner encrypts the model and the user encrypts each request, and KeyService releases the decryption keys only to a SeMIRT enclave whose hardware-measured identity (MRENCLAVE) matches the access-control records ACM and KS_R. SeMIRT then caches the retrieved key pair, the decrypted model, and the initialized inference runtime, so a hot invocation skips enclave initialization, remote attestation, key retrieval, model loading, and runtime initialization, leaving only decryption, inference, and result encryption. FnPacker routes requests to endpoints that can switch among infrequently used models. The evaluation reports that hot invocations give up to 21x speedup over cold ones, that SeMIRT keeps latency near the model-execution cost, and that sharing enclave threads reduces memory cost by roughly 48-59% for TVM models under a bursty MMPP workload.

Load-bearing premise

Access control is enforced only when keys are first fetched: after a SeMIRT enclave has cached a user's decryption keys, it serves that user's subsequent requests without rechecking KeyService, so the system silently assumes that access-control policies never change during an enclave's lifetime.

Editorial extensions

If this is right

  • A cloud provider can offer confidential model serving by adding SGX support and deploying SeSeMI's three components, with no changes to the serverless control plane.
  • Hot requests, which hit a warm enclave with the right model and keys cached, run at near-plaintext speed, so interactive users and bursty traffic see low latency.
  • Under infrequent and unpredictable per-model traffic, FnPacker's packing reduces the number of cold starts and the model owner's memory-based bill.
  • Because SeMIRT shares one enclave across concurrent requests, the memory footprint per request drops, allowing smaller instance budgets.
  • On SGX2 hardware the bottleneck shifts from enclave memory to CPU, so inference frameworks that reduce compute or memory traffic gain more.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The access-control guarantee is only as strong as the assumption that policies do not change: KeyService has no revocation procedure, and a warm enclave that has cached a key pair will keep serving the user without recontacting KeyService.
  • The same three-component pattern — an attestation bridge, a state-reusing enclave runtime, and a model packer — could generalize to other TEE platforms and to stateful serverless workloads beyond inference.
  • If TEE cold-start and attestation costs drop in future hardware, the latency advantage of hot invocations will shrink; the durable contribution may become the attestation delegation and access-control design rather than the caching runtime.
  • FnPacker's scheduling is heuristic; a predictive version could estimate model-switch costs from arrival statistics and choose between exclusive and packed endpoints accordingly.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

2 major / 6 minor

Summary. This paper presents SeSeMI, a TEE-based confidential model inference system for serverless platforms. It introduces three components: KeyService, an enclave-based service that performs remote attestation, manages model and request decryption keys, and enforces access-control lists; SeMIRT, an SGX enclave runtime that caches decrypted models and keys, supports concurrent requests, and distinguishes cold, warm, and hot invocation paths; and FnPacker, which packs requests to infrequently used models onto shared endpoints. The system is implemented on Apache OpenWhisk and evaluated with three models (MobileNet, ResNet101, DenseNet121), two inference frameworks (TFLM, TVM), and both SGX1 and SGX2 clusters. The paper claims that SeSeMI achieves four goals: confidentiality against an untrusted cloud and unauthorized users, low latency, low cost, and no intrusive changes to the existing serverless infrastructure.

Significance. The contribution is potentially significant. The paper identifies real challenges in combining SGX with serverless computing and proposes concrete, reasonably engineered mechanisms to address them. The evaluation is extensive: micro-benchmarks of serving stages, single-node and multi-node tests, MMPP workloads, cost integrals, and SGX1/SGX2 comparisons. The code is open-sourced, and the design of SeMIRT's caching and FnPacker's scheduling is described in enough detail to be reproducible. The main weakness is security: the access-control argument is informal and, as written, does not support dynamic revocation, which is required by the stated security goal. This is a central, load-bearing gap rather than a presentation issue.

major comments (2)
  1. [IV-A, IV-B, IV-D, V] The security claim that SeSeMI "prevents inference executions from unauthorized model users" (Section III) is not supported for dynamic access-control policies. Algorithm 1 defines only USER_REGISTRATION, ADD_MODEL_KEY, GRANT_ACCESS, ADD_REQ_KEY, and KEY_PROVISIONING; it contains no operation to revoke or update ACM or KS_R entries. Section V nevertheless states that clients can "update access control policies" with KeyService, but no such operation is specified in the pseudocode or described in the implementation. Even if an update mechanism were added, Algorithm 2 lines 6-10 make a cache hit on the last (Moid, uid) pair the trigger for using retained keys without contacting KeyService again, so a warm or hot enclave would continue to serve a user whose access has been revoked until the sandbox is destroyed or the cache is evicted. The paper never states that access-control policies are static for the lifetime of warm enclaves; the OpenWhisk container timeout of 3 minutes (Table V) only bounds how long revocation would eventually take effect if a new instance were started. This is a security-relevant correctness gap in the central claim, not a stylistic issue, and should be fixed either by explicitly stating a static-policy assumption or by adding a revocation/expiry/re-check mechanism and evaluating its cost.
  2. [IV-B and IV-D] The claim in Section IV-D that SeMIRT "avoids potential problems from sharing an enclave across different models and users by running only one model and serving requests from one user per enclave" is not enforced by Algorithm 2. The pseudocode uses a single global key cache KC and caches only the last pair of decryption keys, but there is no lock, admission control, or check that prevents two concurrent EC_MODEL_INF calls with different uid values from executing in the same enclave. Under concurrency, one thread can overwrite KC while another thread is still processing a request with a previously fetched key, so requests from different users can be in flight in the same enclave at overlapping times. This contradicts the stated isolation rationale and can cause requests to be decrypted with the wrong key or to fail. The paper should either specify the concurrency control around KC and the user-association invariant, or restrict the one-user-per-enclave claim to the sequential-processing configuration described in Section V.
minor comments (6)
  1. [V] The text says clients can "update access control policies" with KeyService, but Algorithm 1 and the implementation section define no such update operation; please align the prose with the pseudocode or add the missing operation.
  2. [VI] Figures 11-14 report average latencies and cost integrals without error bars, confidence intervals, or repetition counts; please state the number of runs and the observed variance so the comparative claims can be assessed.
  3. [VI, Baselines] The Iso-reuse baseline is implemented by the authors from the descriptions in prior work because no source code is available; please state whether this implementation has been validated and whether it is released, since baseline fidelity directly affects the performance comparisons in Figures 12 and 13.
  4. [IV-B, Algorithm 2] The notation for the key cache is underspecified: KC is described as "last pair of decryption keys," but the condition on line 6 tests membership of "Moid∥uid"; please clarify the exact structure of KC and the locking discipline around it.
  5. [III and Appendix F] The non-intrusiveness claim should be qualified: Appendix F shows that OpenWhisk invokers must be configured to mount the SGX driver and aesmd into containers, which is a platform-level configuration change even if no source-code modification to the serverless platform is required.
  6. [VI-B, Figure 12a] The Native baseline is omitted from Figure 12a without an explanatory note; please add a caption statement that Native saturates below the plotted request-rate range.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found: SeSeMI's security and performance claims rest on SGX attestation, KeyService access checks, and direct experiments rather than on fitted inputs or load-bearing self-citations.

full rationale

SeSeMI is a systems and security paper; there are no fitted parameters, no parametric derivation, and no quantity that is defined in terms of the quantity it claims to predict. The security argument is a protocol argument: model and request keys are generated independently by the owner and user; KeyService stores them only after attestation (Algorithm 1); KEY_PROVISIONING checks ACM and KS_R before releasing keys; SeMIRT fetches keys only after mutual attestation; and model and request data are decrypted only inside the enclave. Each link is anchored in SGX remote attestation rather than in a prior conclusion of this paper. The evaluation compares SeSeMI against Native (standard serverless sandbox behavior) and Iso-reuse (implemented from descriptions of prior work), using standard workloads such as MMPP and MLPerf-derived patterns; no baseline is used to fit a parameter that is later reported as a prediction. The only author-overlap citation is [2], used for background on serverless model serving and as a workload source; it is not load-bearing for SeSeMI's correctness or performance claims. The closest thing to a logical gap is Section IV-D's statement that cached keys imply authorization: Algorithm 2 lines 6-10 serve hot requests from cached keys without re-consulting KeyService, and Algorithm 1 defines no revocation or update procedure for ACM or KS_R even though Section V mentions updating access-control policies. That is a genuine security limitation under dynamic policies, but it is not circular: the hot path inherits the authorization that was checked at the earlier key-provisioning step rather than defining the security predicate as its own output. It should be treated as a correctness/revocation issue, not as circular reasoning.

Assumptions & free parameters 0 free parameters · 5 assumptions · 0 invented entities

The central claim is empirical and systems-level, so the ledger consists of the TEE threat-model assumptions plus one implicit access-control premise. There are no fitted numeric parameters and no new physical entities.

assumptions (5)
  • domain assumption Intel SGX correctly implements enclave isolation and remote attestation.
    Stated in Section III threat model; all confidentiality and access-control claims depend on this.
  • domain assumption The enclave code, including SeMIRT and KeyService, contains no exploitable vulnerabilities.
    Stated in Section III: 'We assume that the code running in the enclave contains no vulnerabilities.'
  • domain assumption Side-channel, physical, and denial-of-service attacks are out of scope.
    Stated in Section III and Section IV-D; this limits the security guarantee to the listed threat model.
  • ad hoc to paper Access-control policy remains static for the lifetime of warm enclaves.
    Not stated explicitly; implied by Algorithm 2 lines 6-10 key caching and by Algorithm 1 lacking any revocation or update operation.
  • domain assumption The expected enclave identity ES can be independently computed by model owners and users from the enclave code.
    Uses the MRENCLAVE measurement property of SGX; relied on in Section III and Appendix B for access control.

how reviews work

0 comments
Cite this review

Pith. "Pith review of SeSeMI: Secure Serverless Model Inference on Sensitive Data." pith.science (2026). https://pith.science/paper/4BQ6NFSK

@misc{pith2026241211640,
  author       = {Pith},
  title        = {Pith review of: SeSeMI: Secure Serverless Model Inference on Sensitive Data},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/4BQ6NFSK}},
  note         = {Machine review of arXiv:2412.11640}
}
read the original abstract

Model inference systems are essential for implementing end-to-end data analytics pipelines that deliver the benefits of machine learning models to users. Existing cloud-based model inference systems are costly, not easy to scale, and must be trusted in handling the models and user request data. Serverless computing presents a new opportunity, as it provides elasticity and fine-grained pricing. Our goal is to design a serverless model inference system that protects models and user request data from untrusted cloud providers. It offers high performance and low cost, while requiring no intrusive changes to the current serverless platforms. To realize our goal, we leverage trusted hardware. We identify and address three challenges in using trusted hardware for serverless model inference. These challenges arise from the high-level abstraction of serverless computing, the performance overhead of trusted hardware, and the characteristics of model inference workloads. We present SeSeMI, a secure, efficient, and cost-effective serverless model inference system. It adds three novel features non-intrusively to the existing serverless infrastructure and nothing else.The first feature is a key service that establishes secure channels between the user and the serverless instances, which also provides access control to models and users' data. The second is an enclave runtime that allows one enclave to process multiple concurrent requests. The final feature is a model packer that allows multiple models to be executed by one serverless instance. We build SeSeMI on top of Apache OpenWhisk, and conduct extensive experiments with three popular machine learning models. The results show that SeSeMI achieves low latency and low cost at scale for realistic workloads.

Figures

Figures reproduced from arXiv: 2412.11640 by the authors.

Figure 1
Figure 1. Security issue of cloud model inference services. [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. shows an example of running model inference in a serverless function. The model owner first uploads the model to a cloud storage system, then deploys a function with a specific inference runtime. Most serverless platforms support Service users Serverless platform proxy thread pool Node Node Node Serverless sandbox Serverless sandbox Function Sandbox Model owner Network communication function code (model inference) i… view at source ↗
Figure 3
Figure 3. SeSeMI overview. Design goals. We build a serverless model inference system, called SeSeMI, that achieves the following four goals. • Security. SeSeMI ensures that the adversary cannot learn the model parameters or the content of user requests. It prevents inference executions from unauthorized model users. • High performance. SeSeMI ensures low latency for user re￾quests, and can scale to handle high workloads. In … view at source ↗
Figures from the paper (13 more)
Figure 4
Figure 4. Figure 4: Model serving stages inside a serverless instance. [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: Enclave ECALL & OCALL APIs and Inference APIs in SeMIRT. Host OS (Linux) Docker Serverless sandbox SeMIRT Sandbox SGX enclave access control cache thread pool encrypted model cache plaintext model cache Inference framework (TFLM/TVM) http server (libuv) thread context …
Figure 6
Figure 6. Figure 6: SeMIRT internal. warm instances, and executing multiple concurrent requests in the same enclave to reduce memory consumption per request. Out of the nine steps in [PITH_FULL_IMAGE:figures/full_fig_p006_6.png]
Figure 7
Figure 7. Figure 7: Serverless platform proxy indiscriminately chooses idle sand [PITH_FULL_IMAGE:figures/full_fig_p007_7.png]
Figure 8
Figure 8. Figure 8: Latency ratio of serving stages. TFLM-MBNET TVM-MBNET TFLM-RSNET TVM-RSNET TFLM-DSNET TVM-DSNET 10 1 10 0 10 1 10 2 Duration (s) 0.75 0.07 14.28 0.94 3.35 0.38 0.81 0.14 14.50 1.24 3.45 0.49 1.97 1.48 16.29 3.39 4.85 2.03 0.59 0.12 13.73 1.21 3.21 0.57 0.48 0.07 13.57 …
Figure 10
Figure 10. Figure 10: Enclave memory saving. (λ: runtime buffer size / model size) 0 10 20 30 #concurrent requests 0.0 2.5 5.0 7.5 10.0 Avg. latency (s) TVM-MBNET TVM-RSNET TVM-DSNET TFLM-MBNET TFLM-DSNET (a) SGX2 0 5 10 15 #concurrent requests 0.0 0.5 1.0 1.5 Avg. latency (s) TVM-1 TVM-4 …
Figure 12
Figure 12. Figure 12: MBNET and RSNET serving with hot invocations. [PITH_FULL_IMAGE:figures/full_fig_p010_12.png]
Figure 13
Figure 13. Figure 13: Latency of serving MBNET under MMPP workload. [PITH_FULL_IMAGE:figures/full_fig_p011_13.png]
Figure 14
Figure 14. Figure 14: Memory usage for serving under MMPP workload. [PITH_FULL_IMAGE:figures/full_fig_p011_14.png]
Figure 15
Figure 15. Figure 15: Enclave initialization overhead. 1 2 4 8 16 # enclave 0.0 0.5 1.0 latency (s) 16MB 128MB (a) SGX2-ECDSA 1 2 4 8 16 # enclave 0 2 4 latency (s) 16MB 128MB (b) SGX1-EPID [PITH_FULL_IMAGE:figures/full_fig_p015_15.png]
Figure 16
Figure 16. Figure 16: Remote attestation overhead. D. Memory Overhead of TEE Protection The input data and model are encrypted under our attack model when transmitted outside of enclaves. The encrypted contents are copied into the enclave and followed by de￾cryption inside. Therefore, the …
Figure 17
Figure 17. Figure 17: Execution time breakdown for SGX2 TFLM-MBNET TVM-MBNET TFLM-RSNET TVM-RSNET TFLM-DSNET TVM-DSNET 1e-04 1e-02 1e+00 1e+02 duration (s) 0.0229 0.0136 0.161 0.0834 0.0479 0.0218 1e-05 0.0381 1e-05 0.216 2e-05 0.0677 0.567 0.07 13.6 0.945 3.21 0.392 model load runtime ini…
Figure 18
Figure 18. Figure 18: Execution time breakdown outside SGX TABLE V: Configuration parameters. Name Definition Value Invoker mem￾ory (SGX2) Amount of memory per node to launch serverless instances 1GB - 64GB (default: 64GB) Invoker mem￾ory (SGX1) Amount of memory per node to launch serverle…

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. A Survey on Privacy Risks and Protection in Large Language Models

    cs.CR 2025-05 conditional novelty 2.0 of 10

    The paper surveys LLM privacy leaks and attacks, organizes them into a taxonomy, and reviews defenses without adding new empirical results.

Reference graph

Works this paper leans on

78 extracted references · 75 canonical work pages · cited by 1 Pith paper

  1. [1]

    Mark: Exploiting cloud services for cost-effective, slo-aware machine learning inference serving,

    C. Zhang, M. Yu, W. Wang, and F. Yan, “Mark: Exploiting cloud services for cost-effective, slo-aware machine learning inference serving,” in USENIX ATC, 2019, pp. 1049–1062

    work page 2019

  2. [2]

    Serverless data science - are we there yet? a case study of model serving,

    Y . Wu, T. T. A. Dinh, G. Hu, M. Zhang, Y . M. Chee, and B. C. Ooi, “Serverless data science - are we there yet? a case study of model serving,” in SIGMOD, 2022, p. 1866–1875

    work page 2022

  3. [3]

    Membership inference attacks against machine learning models,

    R. Shokri, M. Stronati, C. Song, and V . Shmatikov, “Membership inference attacks against machine learning models,” in S&P, 2017, pp. 3–18

    work page 2017

  4. [4]

    Serverless computing: One step forward, two steps back,

    J. M. Hellerstein, J. Faleiro, J. E. Gonzalez, J. Schleier-Smith, V . Sreekanti, A. Tumanov, and C. Wu, “Serverless computing: One step forward, two steps back,” in CIDR, 2019

    work page 2019

  5. [5]

    Cloud programming simplified: A berkeley view on serverless computing,

    E. Jonas, J. Schleier-Smith, V . Sreekanti, C.-C. Tsai, A. Khandelwal, Q. Pu, V . Shankar, J. Carreira, K. Krauth, N. Yadwadkar, J. E. Gonzalez, R. A. Popa, I. Stoica, and D. A. Patterson, “Cloud programming simplified: A berkeley view on serverless computing,” UC Berkeley, Tech. Rep., 2019

    work page 2019

  6. [6]

    Fsd-inference: Fully serverless distributed inference with scalable cloud communication,

    J. Oakley and H. Ferhatosmanoglu, “Fsd-inference: Fully serverless distributed inference with scalable cloud communication,” in 2024 IEEE 40th International Conference on Data Engineering (ICDE) , 2024, pp. 2109–2122

    work page 2024

  7. [7]

    Intel sgx explained,

    V . Costan and S. Devadas, “Intel sgx explained,” 2016. [Online]. Available: https://eprint.iacr.org/2016/086.pdf

    work page 2016

  8. [8]

    Arm confidential compute architecture

    Arm, “Arm confidential compute architecture.” [On- line]. Available: https://www.arm.com/architecture/security-features/ arm-confidential-compute-architecture

    work page

Show all 78 references
  1. [9]

    Amd secure encrypted virtualization (sev)

    AMD, “Amd secure encrypted virtualization (sev).” [Online]. Available: https://www.amd.com/en/developer/sev.html

  2. [10]

    Benchmarking the second generation of intel sgx hardware,

    M. El-Hindi, T. Ziegler, M. Heinrich, A. Lutsch, Z. Zhao, and C. Binnig, “Benchmarking the second generation of intel sgx hardware,” in DaMon, 2022

    2022

  3. [11]

    Serverless in the wild: Characterizing and optimizing the serverless workload at a large cloud provider,

    M. Shahrad, R. Fonseca, I. Goiri, G. Chaudhry, P. Batum, J. Cooke, E. Laureano, C. Tresness, M. Russinovich, and R. Bianchini, “Serverless in the wild: Characterizing and optimizing the serverless workload at a large cloud provider,” in USENIX ATC, 2020, pp. 205–218

    2020

  4. [12]

    Swayam: Distributed autoscaling to meet slas of machine learning inference services with resource efficiency,

    A. Gujarati, S. Elnikety, Y . He, K. S. McKinley, and B. B. Brandenburg, “Swayam: Distributed autoscaling to meet slas of machine learning inference services with resource efficiency,” in Middleware, 2017, p. 109–120

    2017

  5. [13]

    Mlperf inference benchmark,

    V . J. Reddi, C. Cheng, D. Kanter, P. Mattson, G. Schmuelling, C.-J. Wu, B. Anderson, M. Breughe, M. Charlebois, W. Chou, R. Chukka, C. Coleman, S. Davis, P. Deng, G. Diamos, J. Duke, D. Fick, J. S. Gardner, I. Hubara, S. Idgunji, T. B. Jablin, J. Jiao, T. S. John, P. Kanwar, ...

    2020

  6. [14]

    S-faas: Trustworthy and accountable function-as-a-service using intel sgx,

    F. Alder, N. Asokan, A. Kurnikov, A. Paverd, and M. Steiner, “S-faas: Trustworthy and accountable function-as-a-service using intel sgx,” in CCSW, 2019, p. 185–199

    2019

  7. [15]

    Trust more, serverless,

    S. Brenner and R. Kapitza, “Trust more, serverless,” in SYSTOR. Association for Computing Machinery, 2019, p. 33–43

    2019

  8. [16]

    Clemmys: Towards secure remote execution in faas,

    B. Trach, O. Oleksenko, F. Gregor, P. Bhatotia, and C. Fetzer, “Clemmys: Towards secure remote execution in faas,” in SYSTOR, 2019, p. 44–54

    2019

  9. [17]

    Reusable enclaves for confidential serverless computing,

    S. Zhao, P. Xu, G. Chen, M. Zhang, Y . Zhang, and Z. Lin, “Reusable enclaves for confidential serverless computing,” in 32nd USENIX Se- curity Symposium (USENIX Security 23) . Anaheim, CA: USENIX Association, 2023, pp. 4015–4032

    2023

  10. [18]

    Confidential serverless made efficient with plug-in enclaves,

    M. Li, Y . Xia, and H. Chen, “Confidential serverless made efficient with plug-in enclaves,” in ISCA. IEEE Press, 2021, p. 306–318

    2021

  11. [19]

    Intel® trust domain extensions (intel® tdx),

    Intel, “Intel® trust domain extensions (intel® tdx),” 2024. [On- line]. Available: https://www.intel.com/content/www/us/en/developer/ tools/trust-domain-extensions/overview.html

    2024

  12. [20]

    Key- stone: An open framework for architecting trusted execution environ- ments,

    D. Lee, D. Kohlbrenner, S. Shinde, K. Asanovi ´c, and D. Song, “Key- stone: An open framework for architecting trusted execution environ- ments,” in EuroSys, 2020

    2020

  13. [21]

    Vc3: Trustworthy data analytics in the cloud using sgx,

    F. Schuster, M. Costa, C. Fournet, C. Gkantsidis, M. Peinado, G. Mainar- Ruiz, and M. Russinovich, “Vc3: Trustworthy data analytics in the cloud using sgx,” in 2015 IEEE Symposium on Security and Privacy , 2015, pp. 38–54

    2015

  14. [22]

    Opaque: An oblivious and encrypted distributed analytics platform,

    W. Zheng, A. Dave, J. G. Beekman, R. A. Popa, J. E. Gonzalez, and I. Stoica, “Opaque: An oblivious and encrypted distributed analytics platform,” in NSDI, 2017, pp. 283–298

    2017

  15. [23]

    Azure sql database always encrypted,

    P. Antonopoulos, A. Arasu, K. D. Singh, K. Eguro, N. Gupta, R. Jain, R. Kaushik, H. Kodavalla, D. Kossmann, N. Ogg, R. Ramamurthy, J. Szymaszek, J. Trimmer, K. Vaswani, R. Venkatesan, and M. Zwill- ing, “Azure sql database always encrypted,” in SIGMOD, 2020, p. 1511–1525

    2020

  16. [24]

    Operon: An encrypted database for ownership-preserving data management,

    S. Wang, Y . Li, H. Li, F. Li, C. Tian, L. Su, Y . Zhang, Y . Ma, L. Yan, Y . Sun, X. Cheng, X. Xie, and Y . Zou, “Operon: An encrypted database for ownership-preserving data management,” in VLDB, 2022, p. 3332–3345

    2022

  17. [25]

    Veridb: An sgx-based verifiable database,

    W. Zhou, Y . Cai, Y . Peng, S. Wang, K. Ma, and F. Li, “Veridb: An sgx-based verifiable database,” in SIGMOD, 2021, p. 2182–2194

    2021

  18. [26]

    Tee-based general- purpose computational backend for secure delegated data processing,

    M. Sha, J. Li, S. Wang, F. Li, and K.-L. Tan, “Tee-based general- purpose computational backend for secure delegated data processing,” Proc. ACM Manag. Data , vol. 1, no. 4, dec 2023

    2023

  19. [27]

    Veritxn: Verifiable transactions for cloud-native databases with storage disaggre- gation,

    Z. Zhao, H. Pan, G. Chen, X. Du, W. Lu, and B. C. Ooi, “Veritxn: Verifiable transactions for cloud-native databases with storage disaggre- gation,” Proc. ACM Manag. Data , vol. 1, no. 4, dec 2023

    2023

  20. [28]

    Data station: delegated, trustworthy, and auditable computation to enable data-sharing consortia with a data escrow,

    S. Xia, Z. Zhu, C. Zhu, J. Zhao, K. Chard, A. J. Elmore, I. Foster, M. Franklin, S. Krishnan, and R. C. Fernandez, “Data station: delegated, trustworthy, and auditable computation to enable data-sharing consortia with a data escrow,” Proc. VLDB Endow., vol. 15, no. 11, p. 3172...

    2022

  21. [29]

    Integrating remote attestation with transport layer security,

    T. Knauth, M. Steiner, S. Chakrabarti, L. Lei, C. Xing, and M. Vij, “Integrating remote attestation with transport layer security,” CoRR, vol. abs/1801.05863, 2018

    2018 arXiv

  22. [30]

    Rising to the challenge — data security with intel confidential computing,

    Intel, “Rising to the challenge — data security with intel confidential computing,” 2022. [Online]. Available: https://community.intel.com/t5/Blogs/Products-and-Solutions/Security/ Rising-to-the-Challenge-Data-Security-with-Intel-Confidential/post/ 1353141

    2022

  23. [31]

    SCONE: Secure linux containers with intel SGX,

    S. Arnautov, B. Trach, F. Gregor, T. Knauth, A. Martin, C. Priebe, J. Lind, D. Muthukumaran, D. O’Keeffe, M. L. Stillwell, D. Goltzsche, D. Eyers, R. Kapitza, P. Pietzuch, and C. Fetzer, “SCONE: Secure linux containers with intel SGX,” in OSDI, 2016, pp. 689–703

    2016

  24. [32]

    Graphene-SGX: A practical library OS for unmodified applications on SGX,

    C. che Tsai, D. E. Porter, and M. Vij, “Graphene-SGX: A practical library OS for unmodified applications on SGX,” in USENIX ATC, 2017, pp. 645–658

    2017

  25. [33]

    An evaluation of methods to port legacy code to sgx enclaves,

    K. Shanker, A. Joseph, and V . Ganapathy, “An evaluation of methods to port legacy code to sgx enclaves,” in ESEC/FSE, 2020, p. 1077–1088

    2020

  26. [34]

    Asyncshock: Exploiting synchronisation bugs in intel sgx enclaves,

    N. Weichbrodt, A. Kurmus, P. Pietzuch, and R. Kapitza, “Asyncshock: Exploiting synchronisation bugs in intel sgx enclaves,” in ESORICS, I. Askoxylakis, S. Ioannidis, S. Katsikas, and C. Meadows, Eds., 2016, pp. 440–457

    2016

  27. [35]

    Coin attacks: On insecurity of enclave untrusted interfaces in sgx,

    M. R. Khandaker, Y . Cheng, Z. Wang, and T. Wei, “Coin attacks: On insecurity of enclave untrusted interfaces in sgx,” in ASPLOS, 2020, p. 971–985

    2020

  28. [36]

    A fault-tolerance shim for serverless computing,

    V . Sreekanti, C. Wu, S. Chhatrapati, J. E. Gonzalez, J. M. Hellerstein, and J. M. Faleiro, “A fault-tolerance shim for serverless computing,” in EuroSys, 2020

    2020

  29. [37]

    Netherite: Efficient execution of serverless workflows,

    S. Burckhardt, B. Chandramouli, C. Gillum, D. Justo, K. Kallas, C. McMahon, C. S. Meiklejohn, and X. Zhu, “Netherite: Efficient execution of serverless workflows,” in VLDB, 2022, p. 1591–1604

    2022

  30. [38]

    Starling: A scalable query engine on cloud functions,

    M. Perron, R. C. Fernandez, D. J. DeWitt, and S. Madden, “Starling: A scalable query engine on cloud functions,” in SIGMOD, 2020, pp. 131–141

    2020

  31. [39]

    Lambada: Interactive data analytics on cold data using serverless cloud infrastructure,

    I. M ¨uller, R. Marroqu ´ın, and G. Alonso, “Lambada: Interactive data analytics on cold data using serverless cloud infrastructure,” inSIGMOD, 2020, p. 115–130

    2020

  32. [40]

    Cloudburst: Stateful functions-as- a-service,

    V . Sreekanti, C. Wu, X. C. Lin, J. Schleier-Smith, J. E. Gonzalez, J. M. Hellerstein, and A. Tumanov, “Cloudburst: Stateful functions-as- a-service,” in VLDB, 2020, p. 2438–2452

    2020

  33. [41]

    Boki: Stateful serverless computing with shared logs,

    Z. Jia and E. Witchel, “Boki: Stateful serverless computing with shared logs,” in SOSP, 2021, p. 691–707

    2021

  34. [42]

    Optimizing inference serving on serverless platforms,

    A. Ali, R. Pinciroli, F. Yan, and E. Smirni, “Optimizing inference serving on serverless platforms,” in VLDB, 2022, p. 2071–2084

    2022

  35. [43]

    Infless: A native serverless system for low-latency, high-throughput inference,

    Y . Yang, L. Zhao, Y . Li, H. Zhang, J. Li, M. Zhao, X. Chen, and K. Li, “Infless: A native serverless system for low-latency, high-throughput inference,” in ASPLOS, 2022, p. 768–781

    2022

  36. [44]

    Enabling se- cure and efficient data analytics pipeline evolution with trusted execution environment,

    H. Gao, C. Yue, T. T. A. Dinh, Z. Huang, and B. C. Ooi, “Enabling se- cure and efficient data analytics pipeline evolution with trusted execution environment,” in VLDB, 2023, p. 2485–2498

    2023

  37. [45]

    Slalom: fast, verifiable and private execution of neural networks in trusted hardware,

    F. Tram `er and D. Boneh, “Slalom: fast, verifiable and private execution of neural networks in trusted hardware,” in ICLR, 2019

    2019

  38. [46]

    Securetf: A secure tensorflow framework,

    D. L. Quoc, F. Gregor, S. Arnautov, R. Kunkel, P. Bhatotia, and C. Fetzer, “Securetf: A secure tensorflow framework,” in Middleware, 2020, p. 44–59

    2020

  39. [47]

    Tensorflow lite micro: Embedded machine learning for tinyml systems,

    R. David, J. Duke, A. Jain, V . Janapa Reddi, N. Jeffries, J. Li, N. Kreeger, I. Nappier, M. Natraj, T. Wang et al., “Tensorflow lite micro: Embedded machine learning for tinyml systems,” MLSys, vol. 3, pp. 800–811, 2021

    2021

  40. [48]

    TVM: An automated End-to-End optimizing compiler for deep learning,

    T. Chen, T. Moreau, Z. Jiang, L. Zheng, E. Yan, H. Shen, M. Cowan, L. Wang, Y . Hu, L. Ceze, C. Guestrin, and A. Krishnamurthy, “TVM: An automated End-to-End optimizing compiler for deep learning,” in OSDI, 2018, pp. 578–594

    2018

  41. [49]

    SPES: Towards Optimizing Performance-Resource Trade-Off for Serverless Functions ,

    C. Lee, Z. Zhu, T. Yang, Y . Huo, Y . Su, P. He, and M. R. Lyu, “ SPES: Towards Optimizing Performance-Resource Trade-Off for Serverless Functions ,” in 2024 IEEE 40th International Conference on Data Engineering (ICDE) , 2024, pp. 165–178

    2024

  42. [50]

    Security vulnerabilities of sgx and countermeasures: A survey,

    S. Fei, Z. Yan, W. Ding, and H. Xie, “Security vulnerabilities of sgx and countermeasures: A survey,” ACM Comput. Surv., vol. 54, no. 6, jul 2021

    2021

  43. [51]

    Foreshadow: Extracting the keys to the Intel SGX kingdom with transient out-of-order execution,

    J. Van Bulck, M. Minkin, O. Weisse, D. Genkin, B. Kasikci, F. Piessens, M. Silberstein, T. F. Wenisch, Y . Yarom, and R. Strackx, “Foreshadow: Extracting the keys to the Intel SGX kingdom with transient out-of-order execution,” in Proceedings of the 27th USENIX Security Sympos...

    2018

  44. [52]

    Secure and policy-compliant query processing on heterogeneous com- putational storage architectures,

    H. Unnibhavi, D. Cerdeira, A. Barbalace, N. Santos, and P. Bhatotia, “Secure and policy-compliant query processing on heterogeneous com- putational storage architectures,” in SIGMOD, 2022, p. 1462–1477

    2022

  45. [53]

    Confidential consortium framework: Secure multiparty applications with confidentiality, integrity, and high availability,

    H. Howard, F. Alder, E. Ashton, A. Chamayou, S. Clebsch, M. Costa, A. Delignat-Lavaud, C. Fournet, A. Jeffery, M. Kerner, F. Kounelis, M. A. Kuppe, J. Maffre, M. Russinovich, and C. M. Wintersteiger, “Confidential consortium framework: Secure multiparty applications with confi...

    2023

  46. [54]

    Plundervolt: Software-based fault injection attacks against intel sgx,

    K. Murdock, D. Oswald, F. D. Garcia, J. Van Bulck, D. Gruss, and F. Piessens, “Plundervolt: Software-based fault injection attacks against intel sgx,” in 2020 IEEE Symposium on Security and Privacy (SP) , 2020, pp. 1466–1482

    2020

  47. [55]

    Oblivious multi-party machine learning on trusted processors,

    O. Ohrimenko, F. Schuster, C. Fournet, A. Mehta, S. Nowozin, K. Vaswani, and M. Costa, “Oblivious multi-party machine learning on trusted processors,” in USENIX Security Symposium, 2016, pp. 619–636

    2016

  48. [56]

    Model inversion attacks that exploit confidence information and basic countermeasures,

    M. Fredrikson, S. Jha, and T. Ristenpart, “Model inversion attacks that exploit confidence information and basic countermeasures,” in CCS, I. Ray, N. Li, and C. Kruegel, Eds. ACM, 2015, pp. 1322–1333

    2015

  49. [57]

    Stealing machine learning models via prediction apis,

    F. Tram `er, F. Zhang, A. Juels, M. K. Reiter, and T. Ristenpart, “Stealing machine learning models via prediction apis,” in Proceedings of the 25th USENIX Conference on Security Symposium , ser. SEC’16. USA: USENIX Association, 2016, p. 601–618

    2016

  50. [58]

    sgx-ra-tls,

    Intel Labs Cloud Security Research Projects, “sgx-ra-tls,” 2022. [On- line]. Available: https://github.com/cloud-security-research/sgx-ra-tls

    2022

  51. [59]

    Open source serverless cloud platform,

    OpenWhisk, “Open source serverless cloud platform,” 2023. [Online]. Available: https://openwhisk.apache.org/

    2023

  52. [60]

    Batch: Machine learning inference serving on serverless platforms with adaptive batching,

    A. Ali, R. Pinciroli, F. Yan, and E. Smirni, “Batch: Machine learning inference serving on serverless platforms with adaptive batching,” in SC, 2020, pp. 972–986

    2020

  53. [61]

    Ryoan: A distributed sandbox for untrusted computation on secret data,

    T. Hunt, Z. Zhu, Y . Xu, S. Peter, and E. Witchel, “Ryoan: A distributed sandbox for untrusted computation on secret data,” in OSDI, 2016, pp. 533–549

    2016

  54. [62]

    Groundhog: Efficient request isolation in faas,

    M. Alzayat, J. Mace, P. Druschel, and D. Garg, “Groundhog: Efficient request isolation in faas,” in EuroSys, 2023, p. 398–415

    2023

  55. [63]

    Stealthdb: a scalable encrypted database with full SQL query support,

    D. Vinayagamurthy, A. Gribov, and S. Gorbunov, “Stealthdb: a scalable encrypted database with full SQL query support,” Proc. Priv. Enhancing Technol., 2019

    2019

  56. [64]

    Enclavedb: A secure database using sgx,

    C. Priebe, K. Vaswani, and M. Costa, “Enclavedb: A secure database using sgx,” in SP, 2018, pp. 264–278

    2018

  57. [65]

    Ch- iron: Privacy-preserving machine learning as a service,

    T. Hunt, C. Song, R. Shokri, V . Shmatikov, and E. Witchel, “Ch- iron: Privacy-preserving machine learning as a service,” CoRR, vol. abs/1803.05961, 2018

    2018 arXiv

  58. [66]

    Vessels: efficient and scalable deep learning prediction on trusted processors,

    K. Kim, C. H. Kim, J. J. Rhee, X. Yu, H. Chen, D. J. Tian, and B. Lee, “Vessels: efficient and scalable deep learning prediction on trusted processors,” in SoCC, 2020, pp. 462–476

    2020

  59. [67]

    Occlumency: Privacy-preserving remote deep-learning inference using SGX,

    T. Lee, Z. Lin, S. Pushp, C. Li, Y . Liu, Y . Lee, F. Xu, C. Xu, L. Zhang, and J. Song, “Occlumency: Privacy-preserving remote deep-learning inference using SGX,” in MobiCom, 2019, pp. 46:1–46:17

    2019

  60. [68]

    Scalable memory protection in the PENGLAI enclave,

    E. Feng, X. Lu, D. Du, B. Yang, X. Jiang, Y . Xia, B. Zang, and H. Chen, “Scalable memory protection in the PENGLAI enclave,” in OSDI, 2021, pp. 275–294

    2021

  61. [69]

    Faastlane: Accelerating Function-as-a-Service workflows,

    S. Kotni, A. Nayak, V . Ganapathy, and A. Basu, “Faastlane: Accelerating Function-as-a-Service workflows,” in USENIX ATC, 2021, pp. 805–820

    2021

  62. [70]

    Fireworks: A fast, efficient, and safe serverless framework using vm-level post-jit snapshot,

    W. Shin, W.-H. Kim, and C. Min, “Fireworks: A fast, efficient, and safe serverless framework using vm-level post-jit snapshot,” in EuroSys, 2022, p. 663–677

    2022

  63. [71]

    Seuss: Skip redundant paths to make serverless fast,

    J. Cadden, T. Unger, Y . Awad, H. Dong, O. Krieger, and J. Appavoo, “Seuss: Skip redundant paths to make serverless fast,” in EuroSys, 2020

    2020

  64. [72]

    Replayable execution optimized for page sharing for a managed runtime environment,

    K.-T. A. Wang, R. Ho, and P. Wu, “Replayable execution optimized for page sharing for a managed runtime environment,” in EuroSys, 2019

    2019

  65. [73]

    SOCK: Rapid task provisioning with Serverless-Optimized containers,

    E. Oakes, L. Yang, D. Zhou, K. Houck, T. Harter, A. Arpaci- Dusseau, and R. Arpaci-Dusseau, “SOCK: Rapid task provisioning with Serverless-Optimized containers,” in USENIX ATC, 2018, pp. 57–70

    2018

  66. [74]

    SAND: Towards High-Performance serverless computing,

    I. E. Akkus, R. Chen, I. Rimac, M. Stein, K. Satzke, A. Beck, P. Aditya, and V . Hilt, “SAND: Towards High-Performance serverless computing,” in USENIX ATC, 2018, pp. 923–935

    2018

  67. [75]

    Towards serverless as commodity: A case of knative,

    N. Kaviani, D. Kalinin, and M. Maximilien, “Towards serverless as commodity: A case of knative,” in Proceedings of the 5th International Workshop on Serverless Computing . New York, NY , USA: Association for Computing Machinery, 2019, p. 13–18. [Online]. Available: https://doi...

    2019

  68. [76]

    Cloud functions version comparison,

    Google, “Cloud functions version comparison,” 2023. [On- line]. Available: https://cloud.google.com/functions/docs/concepts/ version-comparison

    2023

  69. [77]

    Fifer: Tackling resource underutilization in the serverless era,

    J. R. Gunasekaran, P. Thinakaran, N. C. Nachiappan, M. T. Kandemir, and C. R. Das, “Fifer: Tackling resource underutilization in the serverless era,” in Middleware, 2020, p. 280–295

    2020

  70. [78]

    Nightcore: Efficient and scalable serverless computing for latency-sensitive, interactive microservices,

    Z. Jia and E. Witchel, “Nightcore: Efficient and scalable serverless computing for latency-sensitive, interactive microservices,” in ASPLOS, 2021, p. 152–166. APPENDIX A. Remote Attestation in SeSeMI In SeSeMI, remote attestation is implemented with standard TLS to set up a se...

    2021

Pith tools

Reviewed August 11, 2026 · model on record in the stance chip above.