REVIEW 3 major objections 4 minor 4 references
Building Critical Applications using Microservices
T0 review · 3 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash
Pith's one-line read The paper claims that combining microservices with SGX-based secure containers and compiler hardening is enough to build fail-stop critical applications on top of untrusted cloud software.
desk verdict A clear, well-written position paper that usefully synthesizes the author's prior SGX and fault-tolerance systems, but its central 'sufficient for fail-stop applications' claim rests on an unexamined trust in Intel SGX. read the letter →
The pith
A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.
The reading
What carries the argument
The central object is the secure container: a normal container whose single microservice runs inside an Intel SGX enclave, with files and network traffic transparently encrypted and authenticated, so the host OS and hypervisor are demoted from trusted to untrusted. Three supporting mechanisms carry the other requirements: keeping each enclave's working set inside the roughly 90 MB extended page cache so throughput stays near native; a compiler-based transformation that makes memory-unsafe accesses tolerable by continuing only when it is safe to do so; and CPU-fault detection via software lock-step using hardware transactional memory, which masks about 90% of soft errors at roughly 100% overhead, plus encoded, pseudo-randomized computation whose outputs outside the valid space reveal design faults at roughly 150% overhead. The argument works by modularity: because microservices are small, their enclaves fit in the protected cache and each service has a small system-call surface.
What would settle it
Take a fail-stop application built as the paper describes, give an attacker root-level control of the host operating system and hypervisor, and attempt to read or alter an enclave's memory, files, or network stream; if any attempt leaks secret data, silently corrupts output, or lets the application continue instead of stopping, the sufficiency claim is refuted. A demonstrated SGX vulnerability that lets privileged software read or write enclave state would likewise remove the trust anchor on which the secure-container mechanism rests.
Extended reading notes
Core claim
The paper's central claim is that trustworthy computing does not require a trustworthy foundation from the CPU up; it can be supplied per application. An application is split into microservices, and each microservice runs in a secure container, meaning a container whose process lives inside an Intel SGX enclave, so that main memory, files, and network traffic are transparently encrypted and authenticated against the host operating system and hypervisor. Because these containers look ordinary to the container engine, they work with existing cloud tooling. Existing C/C++ services are made tolerant of memory errors by compiler transformations that stop the service only when continuing would be unsafe. For CPU correctness, software-based lock-step execution and pseudo-randomized encoded processing detect soft errors and design faults. Together, the paper argues, these pieces are sufficient for fail-stop applications, where a failed component stops cleanly and is replaced, while fail-operational behavior remains open.
Load-bearing premise
The load-bearing premise is that Intel's SGX enclave truly hides the application's code and data from all software outside it; if the operating system, hypervisor, or another enclave can read or alter that state, the confidentiality, integrity, and fail-stop guarantees collapse.
Editorial extensions
If this is right
- A developer can build a crash-tolerant, confidentiality-preserving critical service on top of an ordinary Linux cloud without formally verifying the kernel, as long as the trusted parts are small SGX enclaves.
- Performance stays practical when decomposition keeps each microservice's working set within the SGX enclave cache; the paper warns that larger working sets can cause slowdowns of more than an order of magnitude.
- Legacy services written in memory-unsafe languages can be included when compiler transformations stop them before corruption escapes, preserving the application's fail-stop behavior.
- CPU soft errors and even some design faults can be handled in software on non-deterministic hardware, at overheads comparable to hardware lock-step, using transactional-memory replay and encoded execution.
- The approach is explicitly limited to fail-stop behavior; fail-operational behavior, where a system continues providing correct service through a fault, is not claimed and remains an open research direction.
Reading between the lines
- Editorial inference: because the guarantees are anchored in SGX hardware, the entire architecture inherits SGX's trust assumptions; a processor-level enclave-isolation flaw would be shared by every secure container, concentrating risk in a single hardware anchor.
- Editorial inference: the same software lock-step and encoded-execution techniques used for CPU faults could be applied across multiple enclave instances to move from fail-stop toward fail-operational behavior, a direction the paper leaves open.
- Editorial inference: the enclave cache size gives a concrete design rule for critical microservices, namely partition so each service's working set stays near or below the cache limit; if enclave memory grows, the class of applications covered by the sufficiency claim grows with it.
Signed reviews
Editorial analysis
A structured set of objections, weighed in public.
Referee Report
Summary. This position paper argues that critical applications can be built on untrusted system software by decomposing them into microservices, each running inside an Intel SGX-based secure container, and by adding compiler extensions for memory safety and fault tolerance. It claims that the combination of secure containers (SCONE), hardware-assisted fault tolerance (HAFT), encoded processing (DeltaEncoding), and boundless memory allocations (Boundless) is sufficient for fail-stop applications, while fail-operational support remains open. The paper motivates the approach by arguing that Linux and commercial CPUs cannot be made formally correct, so one must start from a smaller trust base. No new experiments or formal results are presented; the argument is based on references to prior peer-reviewed systems.
Significance. If the central claim were established, the approach would be practically significant: it would allow confidentiality, integrity, and crash-failure semantics for critical applications on commodity cloud infrastructure without verifying the OS, hypervisor, or CPU design. The paper is clearly written and honestly acknowledges open issues (e.g., SGX EPC size and fail-operational support). Its strengths are the concrete architecture and the grounding in peer-reviewed implementations (SCONE, HAFT, DeltaEncoding, Boundless) that include experimental evaluations. However, the fail-stop sufficiency claim is not demonstrated within this manuscript; it depends critically on the trustworthiness of Intel SGX, which is assumed without supporting evidence.
major comments (3)
- [Integrity and confidentiality] The claim that secure containers ensure confidentiality and integrity 'even against attacks from software with a higher privilege like the operating system or the hypervisor' depends entirely on Intel SGX being a sound hardware trust anchor. The paper's opening argument rejects Linux because it is large buggy commercial code and even introduces DeltaEncoding because CPUs can have design faults, yet SGX is itself a large, closed, commercial hardware/microcode mechanism with no correctness proof, formal verification, or fault-detection wrapper presented here. A flaw in SGX, such as a microarchitectural side channel or design error, would silently violate the confidentiality and integrity guarantees, so the system would not be fail-stop. Because this trust anchor is unargued and load-bearing for the conclusion, the authors must either justify the SGX assumption or explicitly weaken the claimed guarantees.
- [Conclusion] The statement that the approach is 'sufficient for implementing fail-stop applications' is a strong claim that requires a precise failure model and a compositional argument. The paper never defines 'fail-stop' and does not show that the combination of SCONE, HAFT, DeltaEncoding, and Boundless halts the system before any incorrect output or security breach occurs. In particular, DeltaEncoding protects computation inside the enclave but does not protect the enclave boundary itself, and the cited systems were evaluated individually, not as an integrated stack. A compositional analysis, or an explicit restriction to the assumptions under which each component was validated, is needed to support the conclusion.
- [Ensuring Correct Execution / Integrity and confidentiality] The paper combines several mechanisms but does not discuss how they interact. For example, HAFT's software lock-step and recovery using transactional memory, DeltaEncoding's randomized program mapping, and SCONE's encrypted runtime and shielded system calls may interfere with each other; the paper provides no evidence that the combined approach preserves the individual mechanisms' guarantees. Without a compositional evaluation or argument, the 'sufficient' claim exceeds what the cited papers demonstrate.
minor comments (4)
- [Ensuring Correct Execution] 'Homographic space' should be 'homomorphic space' in both occurrences.
- [Figure 1] The labels '!Strusted' and '!S' in Figure 1 are unclear; a legend or clearer text should distinguish trusted and untrusted components.
- [Application-Oriented Safety and Security] 'One need to expect vulnerabilities' is ungrammatical and should read 'One needs to expect vulnerabilities'.
- [References] The reference [DeltaEncoding] uses the symbol 'Δ-encoding' while the text consistently uses 'DeltaEncoding'; please use one form consistently.
Circularity Check
No circular derivation; the fail-stop sufficiency claim is an architectural composition of independently published, experimentally evaluated systems rather than a re-statement of the paper's inputs.
full rationale
The paper is a position/preprint that assembles previously published systems — SCONE, HAFT, Δ-encoding, and Boundless — into a microservice-based architecture for critical applications. Its central claim that the combination is sufficient for fail-stop applications is not derived from any equation in this paper, and no parameter is fitted to data and then renamed as a prediction. The supporting citations are self-authored, but they are peer-reviewed systems papers with independent implementations, experimental evaluations, and external review, so under the governing rule they count as real evidence rather than a reasoning loop. The SGX trust anchor is an unargued hardware assumption, and one could dispute whether the claim is fully established, but that is a correctness or soundness concern, not a circularity concern: the paper does not define SGX security in terms of the conclusion, nor does it invoke a self-authored uniqueness theorem to force its choice. No load-bearing step reduces by construction to its own inputs, and no renamed known result is presented as a new derivation. Therefore the appropriate circularity score is 0.
Assumptions & free parameters
assumptions (3)
- domain assumption Intel SGX provides hardware-enforced confidentiality and integrity for enclave state against privileged software.
- domain assumption The prior systems (SCONE, HAFT, DeltaEncoding, Boundless) work as reported.
- domain assumption Coverity and KSPP defect-density data accurately characterize Linux kernel security.
Cite this review
Pith. "Pith review of Building Critical Applications using Microservices." pith.science (2026). https://pith.science/paper/LBHXTNI4
@misc{pith2026190808744,
author = {Pith},
title = {Pith review of: Building Critical Applications using Microservices},
year = {2026},
howpublished = {\url{https://pith.science/paper/LBHXTNI4}},
note = {Machine review of arXiv:1908.08744}
}
read the original abstract
Microservices - combined with secure containers - facilitate new ways to build critical applications. These applications will benefit from many tools and services built for less critical software. The more stringent requirements of critical applications are addressed with the help of secure containers and compiler extensions. While this approach is sufficient for implementing fail-stop applications, there are still several open research questions regarding if and how fail-operational applications could be supported using this approach.
Reference graph
Works this paper leans on
-
[1]
The standard approach to build critical applications ensures dependability bottom up
Building Critical Applications using Microservices1 Christof Fetzer, TU Dresden More and more applications are critical for ensuring business success, mission completion or even the safety of human lives. The standard approach to build critical applications ensures dependability bottom up. One needs to base the application on a dependable foundation - a c...
work page 2016
-
[16]
[Boundless] Marc Brünink, Martin Süßkraut, Christof Fetzer, Boundless Memory Allocations for Memory Safety and High Availability, In Proceedings of The 41st Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN 2011),IEEE Computer Society,
work page 2011
-
[19]
Esslinger Forum für Kfz‐Mechatronik. (2013) [Coverity] Open Source Report 2014 - Coverity, go.coverity.com/rs/157-LQW.../2014-Coverity-Scan-Report.pdf [KSPP] Kees Cook, The State of Kernel Self Protection Project, Linux Security Summit (LSS), 2016 [HAFT] Dmitrii Kuvaiskii, Rasha Faqeh, Pramod Bhatotia, Pascal Felber, Christof Fetzer, HAFT: Hardware-assist...
work page 2013
-
[2016]
[DeltaEncoding] Dmitrii Kuvaiskii, Christof Fetzer, Δ-encoding: Practical Encoded Processing, Proceedings of The 45th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN 2015), IEEE Computer Society, 2015 (Carter Award paper). [Scone] Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth, Andre Martin, Christian Priebe, ...
work page 2015
Reviewed August 14, 2026 · model on record in the stance chip above.
Discussion (0). Continue with ORCID to comment.