{"id":"14c856d5-91d9-43f1-b130-50a7c226789b","arxiv_id":"1908.08744","paper_version":1,"verdict":"UNVERDICTED","confidence":"MODERATE","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"Critical applications can be built from microservices in SGX secure containers with compiler-based memory safety, but fail-operational behavior remains unsolved.","lead":"This paper argues that critical applications can be built by splitting them into microservices that run inside SGX-based secure containers, with compiler extensions for extra memory safety. It summarizes the author's prior systems and says the approach is good enough for fail-stop applications, while fail-operational support is still an open question.","discovery_kind":"review","skeptic_critique":{"model":"deepseek-v4-flash","headline":"SGX is the unargued trust anchor for the fail-stop claim; the paper rejects OS/CPU trust for bugs but never applies that standard to SGX, whose failure would collapse confidentiality and integrity.","rationale":"The reader's verdict of UNVERDICTED is appropriate because the paper is a position statement with no artifacts, formal derivations, or experimental results. My stress-test agrees with the reader's weakest assumption: SGX is the load-bearing trust anchor. I want to sharpen one point: the paper's internal skeptical standard makes the gap more than an external risk. The paper argues that Linux cannot be trusted because it has bugs and even that CPUs cannot be trusted for execution, yet it treats SGX as a black-box trusted component without applying the same standard. This is not an ad hominem; it is a gap in the argument. Subsequent microarchitectural attacks on SGX confirm that the assumption was not merely academic, but even without hindsight the paper provides no reason to believe SGX delivers the advertised boundary. I considered whether a more central gap is the composition of crash-restartable microservices into fail-stop semantics, and that concern is real: partial effects, duplicate messages, and state persistence across restarts are not addressed. However, the SGX anchor is more decisive because if SGX fails, the confidentiality and integrity guarantees collapse regardless of how the microservices are composed. Therefore I do not change the reader's verdict: the work remains unverdictable as a research claim, and the identified dependency leaves the strong conclusion unsupported.","tokens_in":3166,"tokens_out":8692,"duration_ms":97548,"concrete_test":"Run the SCONE secure-container implementation from the cited [Scone] paper on an affected Intel CPU and mount a page-fault or cache side-channel attack, such as a Foreshadow proof-of-concept, against an enclave holding a known secret while a hostile OS/hypervisor process observes the enclave's access pattern. If the secret is recovered, SGX does not provide the transparent confidentiality the argument requires and the fail-stop claim collapses. If the attack is mitigated, the specific test is inconclusive for other side channels, so also audit the Intel SGX specification and SCONE source to confirm which resources are actually protected by SGX rather than by the untrusted container engine.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The strongest claim, that microservices plus SGX secure containers and compiler extensions are sufficient for fail-stop applications, is load-bearing on Intel SGX being a sound hardware trust anchor. The paper's own opening argument undercuts this: it dismisses Linux because millions of lines of commercial code always contain bugs, and it even adds DeltaEncoding because CPUs can have design faults. Yet SGX is a large, closed, commercial hardware/microcode mechanism that provides memory encryption, attestation, and enclave switching, and the paper gives no correctness proof, no formal verification, and no fault-detection wrapper for it. If SGX has a flaw, for example a microarchitectural side channel or a design error, an attacker controlling the operating system or hypervisor can violate the claimed confidentiality and integrity even against attacks from software with higher privilege, and can cause incorrect outputs before the application stops. The paper's DeltaEncoding mechanism protects computation inside an enclave, not the enclave boundary itself, so it does not catch this failure mode. Consequently, sufficient for implementing fail-stop applications is not established: the conclusion rests on an unargued trust anchor that the paper's own skeptical standards would reject. The cited SCONE paper documents a design, not a security proof, and this position paper adds no independent support.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":3397,"tokens_out":4078,"duration_ms":42697,"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":[{"comment":"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.","section":"Integrity and confidentiality"},{"comment":"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.","section":"Conclusion"},{"comment":"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.","section":"Ensuring Correct Execution / Integrity and confidentiality"}],"minor_comments":[{"comment":"'Homographic space' should be 'homomorphic space' in both occurrences.","section":"Ensuring Correct Execution"},{"comment":"The labels '!Strusted' and '!S' in Figure 1 are unclear; a legend or clearer text should distinguish trusted and untrusted components.","section":"Figure 1"},{"comment":"'One need to expect vulnerabilities' is ungrammatical and should read 'One needs to expect vulnerabilities'.","section":"Application-Oriented Safety and Security"},{"comment":"The reference [DeltaEncoding] uses the symbol 'Δ-encoding' while the text consistently uses 'DeltaEncoding'; please use one form consistently.","section":"References"}],"recommendation":"major_revision","confidential_remarks":"This manuscript appears to be a lightly edited version of a 2016 IEEE S&P magazine article. If the journal expects original research, the novelty is minimal and the contribution type (position paper vs. research article) should be clarified. The paper leans heavily on five self-authored prior papers, which is understandable given the topic, but an independent validation of the fail-stop claim, or an explicit statement that the claim is conditional on SGX trust, would materially strengthen the case."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know two things about this one before you schedule it for a session. First, it is not a research paper: it is a concise position piece, originally in IEEE Security & Privacy, that re-presents work from the author's group (SCONE, HAFT, DeltaEncoding, Boundless) as a recipe for building fail-stop critical applications on commodity cloud infrastructure. Second, the recipe's load-bearing ingredient is Intel SGX, and the paper never gives that ingredient the same skeptical scrutiny it applies to Linux or to CPU design faults.\n\nWhat the paper does well is mostly framing. The opening argument against formal verification of Linux is fair and well stated: 20 million lines of code, empirical density of bugs, and decades of security fixes make a proof-of-correctness approach hard to sell for commodity systems. The turn to \"application-oriented safety and security\" is a genuine perspective shift, and the paper is honest about limits: it flags the EPC size problem, it says secure containers protect against privileged software, and it explicitly leaves fail-operational systems as an open question. For a reader who has not followed the group's prior work, this is a useful map.\n\nNow the soft spot, and it is proportionate to how central it is. The conclusion says the approach \"is sufficient for implementing fail-stop applications.\" That claim depends on SGX being a sound trust anchor for confidentiality and integrity. The paper dismisses Linux because large closed software always has bugs, and it adds DeltaEncoding because CPUs can have design faults. Those standards are not applied to SGX itself: a large closed hardware/microcode mechanism with no proof, no verification, and no fault-detection wrapper. DeltaEncoding protects computation inside an enclave; it does not protect the enclave boundary. If SGX has a flaw — a side channel, a microcode bug, an attestation weakness — the confidentiality and integrity guarantees collapse, and the fail-stop sufficiency claim falls with them. The stress-test note is right that this is the weakest assumption. I would not call the paper circular; it points to real peer-reviewed systems. But \"sufficient\" is stronger than the evidence supports.\n\nWho should read this: practitioners or researchers looking for a short framing of how microservices plus SGX might tackle critical workloads, and anyone teaching a course on dependable systems. It would make a good reading-group discussion piece precisely because the SGX trust issue is easy to argue about.\n\nMy recommendation: let a serious referee look at it for a systems or practice-oriented venue, but ask the authors to either soften \"sufficient\" to \"promising\" or address the SGX trust anchor head-on. For a top-tier research venue it lacks new results, but as a position statement it deserves engagement rather than a desk reject.","headline":"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.","tokens_in":3867,"tokens_out":2007,"would_cite":false,"duration_ms":24022,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["microservices","Intel SGX","secure containers","fail-stop applications","critical systems","cloud security","fault tolerance","compiler-based hardening"],"falsifier":"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.","tokens_in":2969,"feed_emoji":"🔐","tokens_out":9062,"duration_ms":92562,"temperature":0.7,"pith_summary":"This paper argues that critical applications do not have to wait for a formally verified operating system or CPU. Its claim is that by decomposing an application into small microservices, running each one inside a hardware-isolated secure container built on Intel SGX, and hardening unsafe legacy code with compiler extensions, a developer can meet the confidentiality, integrity, and correct-execution requirements of fail-stop applications even on an untrusted cloud stack. The practical payoff would be that safety- and business-critical services can reuse ordinary Linux, commodity container platforms, and cloud infrastructure, as long as each enclave's working set stays small. The paper is explicit that the approach is sufficient for fail-stop, not yet for fail-operational, applications; the latter is left as an open research question.","feed_headline":"Microservices plus secure enclaves can carry fail-stop critical apps","feed_subtitle":"If right, crash-safe, confidential services can run on ordinary clouds without a verified OS.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Builds the secure container that runs a microservice inside an SGX enclave with transparently encrypted files, memory, and network, providing the core integrity and confidentiality mechanism.","marker":"[Scone]"},{"why":"Supplies the compiler transformation that tolerates out-of-bounds memory accesses and stops the service only when continuing would be unsafe, protecting legacy C/C++ microservices.","marker":"[Boundless]"},{"why":"Shows software-based lock-step execution on hardware transactional memory that detects and masks most CPU soft errors at about 100 percent resource overhead.","marker":"[HAFT]"},{"why":"Shows pseudo-randomized encoded processing that detects wrong CPU executions, covering design faults beyond soft errors at about 150 percent overhead.","marker":"[DeltaEncoding]"},{"why":"Provides empirical defect-density data for Linux and open-source code, supporting the premise that the underlying operating system is not dependable enough to trust.","marker":"[Coverity]"},{"why":"Documents that security-relevant kernel bugs remain undiscovered for about five years, reinforcing the need to protect applications independently of kernel correctness.","marker":"[KSPP]"},{"why":"Establishes the formal-verification baseline for a 10,000-line microkernel that the paper contrasts with the millions of lines of Linux.","marker":"[Heiser]"}],"fun_headline_variants":["SGX microservices achieve fail-stop criticality without trusted OS","Fail-stop critical apps via SGX-enclosed microservices","Microservices in enclaves: crash-safe, not fail-operational","Per-app trust replaces verified OS for critical microservices","Secure containers make fail-stop critical apps possible"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["SGX microservices achieve fail-stop criticality without trusted OS","Fail-stop critical apps via SGX-enclosed microservices","Microservices in enclaves: crash-safe, not fail-operational","Per-app trust replaces verified OS for critical microservices","Secure containers make fail-stop critical apps possible"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.00111,"raw_usage":{"total_tokens":4536,"prompt_tokens":766,"completion_tokens":3770,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":382,"completion_tokens_details":{"reasoning_tokens":3690}},"tokens_in":382,"tokens_out":3770,"duration_ms":25901,"temperature":1.0,"reasoning_tokens":3690,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-14T11:29:52.102877+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[],"review_version":1}