Trusted execution environments stop a privileged host from reading or modifying protected memory, but blocks leave that boundary. A secure disk normally encrypts data, authenticates it with a Merkle tree, prevents rollback through freshness metadata, and journals updates for crash consistency. AtomicDisk shows that these properties still permit a state the application never chose to commit.
The opening is cache eviction. SGX-PFS may write dirty protected-file blocks and their authentication metadata before an application issues sync. Each intermediate on-disk layout is internally valid enough to be recovered. A malicious host can capture one of these transient snapshots and later replay it. The tree proves that the blocks belong together, but not that the application designated that moment as durable.
AtomicDisk defines sync atomicity: all writes before a completed sync become committed together, or none do. It extends SGX-PFS with an internal commit operation and journal semantics that distinguish cache-evicted writes from synchronized writes. The upper filesystem and application continue to use ordinary block reads, writes, and flushes.
Integrity and freshness do not express user intent
Confidentiality prevents observation, integrity detects alteration, freshness rejects older authenticated data, and consistency ensures recovery finds a valid structure. These properties describe block validity and ordering. They do not mark which valid state an application intended to expose after restart. A host controlling I/O timing can exploit that missing semantic bit.
Consider several writes followed by one sync. The secure cache may evict subsets in different orders, updating the Merkle tree and journal each time. Every captured disk image can pass cryptographic checks. If replay restores one intermediate combination, the application sees a state between synchronization points. This is different from forging data; the adversary reuses authentic encrypted blocks and metadata generated by normal operation.
The threat model trusts the TEE hardware and software inside it while giving the host control over storage requests, responses, crashes, and replay timing. Denial of service, access-pattern side channels, and rollback of the entire disk including the root key remain outside scope. Whole-disk rollback needs a small rollback-resistant trusted store or monotonic counter.
A commit marker changes journal interpretation
AtomicDisk preserves the in-place Merkle-tree structure of SGX-PFS and modifies metadata and journal handling. Cache eviction can continue writing blocks so trusted memory does not become a capacity limit. Those records are labeled as uncommitted. Sync emits an internal commit operation that makes the preceding group recoverable as one application-visible state.
The recovery journal can contain multiple versions of one logical block. During recovery, AtomicDisk scans from the beginning and restores the first occurrence that belongs to the committed group. A bitmap records which logical blocks have already been recovered. Later occurrences from uncommitted eviction are ignored. This ordering lets the system distinguish identical cryptographic block identities by commit position.
Journal blocks form a MAC chain: each block authenticates the previous one through metadata in the next. Removing or replacing an interior block breaks the chain. The last block still needs an external freshness anchor because rolling it back resembles whole-disk rollback. AtomicDisk can integrate a trusted monotonic counter, but its evaluation focuses on eviction snapshots within the journal chain.
Atomicity is placed below existing filesystems
The prototype implements a 100 GiB secure virtual disk inside the Occlum SGX library OS. It exposes standard block I/O, so an existing filesystem does not need a transactional API or modified write path. Approximately 5,000 lines of Rust adapt SGX-PFS metadata and journal logic while leaving the Merkle tree design intact.
This layering broadens compatibility but inherits write amplification. Updating one data block can require authentication nodes and journal entries. AtomicDisk protects application sync boundaries, not arbitrary groups defined above the block interface. Filesystems that issue background flushes or translate fsync into several device commands must preserve the intended boundary through the entire stack.
The secure virtual disk also trusts all code inside the TEE. Memory-safety bugs, compromised library-OS components, or leaked keys are not repaired by sync atomicity. The property narrows a storage adversary’s valid replay points; it is one layer in a larger confidential-computing threat model.
Security evaluation counts valid snapshots
Five datacenter block traces wrote between 8 and 49 GiB and issued one sync at the end. A PFSDisk comparison, which redirects block I/O into SGX-PFS, generated 173,000 to 788,000 recoverable transient snapshots per trace. Every snapshot was a potential eviction-replay point. AtomicDisk generated exactly one valid state for each trace, corresponding to the single sync.
This metric measures security-state cardinality rather than attack success probability. Reducing the set from hundreds of thousands to one demonstrates that cache behavior no longer creates hidden commit points. The evaluation does not estimate how often a real adversary can capture every required block or how whole-disk freshness anchors behave under repeated rollback.
The authors also reproduce an eviction attack that can compromise an SGX-protected Redis deployment under the earlier semantics. AtomicDisk’s guarantee applies because recovery rejects the transient state, not because Redis learns a new transaction protocol. That transparency is the design’s operational value.
Similar to SGX-PFS does not mean encryption-only speed
The test machine used a 64-core Ice Lake Xeon, Intel DC S3500 SATA SSD, 256 GiB memory with 64 GiB SGX EPC, Linux 5.17, and SGX SDK 2.15. Microbenchmarks configured one synchronous direct-I/O job, a 1 GiB cache, 4 KiB default blocks, and sequential or random requests from 4 KiB through 256 KiB.
AtomicDisk and PFSDisk delivered similar read and write throughput because they perform the same Merkle-tree and journal work. CRYPTDISK, an encryption and integrity comparison without a Merkle tree, was 1.2 to 7.5 times faster for writes and 2.2 to 2.8 times for reads. Sync atomicity is inexpensive relative to SGX-PFS, but authenticated freshness itself remains costly.
Trace-driven throughput also matched PFSDisk. Redis produced comparable performance across all three virtual disks under its lightweight pattern and always-fsync setting. BadgerDB on AtomicDisk and PFSDisk reached 50% to 85% of CRYPTDISK throughput because sequential writes did not saturate the device and uniform small reads exposed authentication overhead.
These results bound the performance claim correctly. AtomicDisk removes a vulnerability without adding material cost to the selected protected-file baseline. It does not close the gap with a simpler encryption-only disk, and the SATA testbed does not establish behavior on NVMe, high queue depth, or remote storage.
Sync becomes a security boundary, not only a durability hint
Applications already use fsync or flush to request persistence. AtomicDisk elevates that call into the only valid externally replayable state transition. The whole stack must therefore make completion precise. Returning success before the commit record and its authentication chain are durable would reopen the gap. Losing the response after durability can cause a retry, which must not create two distinguishable committed outcomes.
Operational evidence should include committed journal sequence, last trusted freshness anchor, uncommitted bytes, eviction count, recovery decision, and sync latency. Remote attestation can verify the AtomicDisk code and configuration, but an operator also needs to prove that the underlying device honors flush ordering. Hardware volatile caches require power-loss protection or a correctly implemented barrier.
Snapshot and backup systems need the same boundary. Capturing an encrypted volume between syncs may store an image that AtomicDisk will intentionally reject. A management plane should request a sync, wait for commit evidence, and only then declare a snapshot usable. Storage efficiency cannot silently bypass the TEE’s commit protocol.
The design decision is which valid states the adversary may replay
Cryptographic storage reviews often ask whether blocks are encrypted and authenticated. AtomicDisk adds a more useful question: which authenticated disk states can recovery accept? If normal cache eviction creates many valid points, a privileged host can choose among histories without breaking a MAC.
The strongest fit is a TEE workload that uses conventional filesystems, needs transparent block storage, and treats sync as its durability contract. Systems with an application-level replicated log may already validate epochs above the disk; systems without a rollback-resistant root still need that anchor. AtomicDisk does not replace those protocols, but it removes hidden commit points underneath them.
Procurement and validation should compare secure committed transactions per second, not raw encrypted IOPS. The denominator includes Merkle-tree write amplification, sync latency, trusted-counter cost, recovery behavior, and the number of application-authorized states. AtomicDisk demonstrates that eliminating eviction-replay states can be nearly free relative to SGX-PFS, while reminding buyers that SGX-PFS itself carries substantial protection cost.
Source and copyright notice
This article is an editorial analysis by Silicon & Systems. It restates the threat model, mechanism, measurements, and limits in our own words. No source sentence, table, or figure is reproduced; the figure was created for this article. The paper is available from the USENIX FAST 2025 presentation page. Copyright remains with the authors, 2025.