Securing Filesystems for Confidential Computing — ShieldFS Research paper breakdown Confidential Computing · Storage Security Securing Filesystems for Confidential Computing How ShieldFS extends the security boundary of confidential computing from protected computation to persistent filesystem state — without forcing applications to change their POSIX interface.
Paper: arXiv:2608.19924 Submitted: 20 Aug 2026 Pages: 15 System: ShieldFS / ShieldZFS / CORE ☾ Dark mode 01 · THE CORE IDEA The paper in one sentence ShieldFS turns a conventional POSIX filesystem into a storage layer that can detect tampering, rollback, replay and equivocation even when the cloud provider controls the entire storage and I/O stack.
The important part is not that ShieldFS invents a completely new filesystem API.
The researchers deliberately keep the application interface familiar: applications continue using operations such as open , read , write , fsync , rename and unlink .
The security machinery is pushed underneath that interface.
Mental model TEE protects computation.
ShieldFS protects persistent state.
Confidential computing traditionally gives us a protected place to execute code and hold data in memory.
ShieldFS addresses what happens after that data has to leave the protected memory boundary and live on persistent storage.
TEE Protected computation + memory FS Persistent state becomes authenticated CORE Trusted commitment checkpoint 02 · WHY CONFIDENTIAL COMPUTING IS NOT ENOUGH The TEE protects the wrong side of the boundary — if storage is ignored Imagine a database running inside a Trusted Execution Environment.
The database's code and in-memory state are protected from a malicious cloud administrator.
That is the central promise of confidential computing.
But persistence creates a second boundary.
Once the database writes its state to a virtual disk, physical disk, or remote cloud storage, that state is no longer sitting entirely inside the TEE's protected memory.
The missing security boundary Paper motivation Trusted · Inside TEE Application code In-memory filesystem state Sensitive data while executing ShieldFS security logic Cryptographic commitments Untrusted · Cloud side Operating system Drivers / hypervisor Virtual disk Storage backend Network / I/O path The paper's threat model intentionally makes this adversary extremely powerful.
The cloud attacker can access, corrupt, swap, drop, record, inject and replay data across storage and network interfaces.
They can also crash TEEs and restart them from stale persistent snapshots.
The storage attack surface What the attacker can manipulate Application inside TEE → ShieldFS trusted filesystem logic → I/O stack untrusted → Cloud storage attacker controlled Tamper Change data or metadata.
Rollback Replace current state with an older valid state.
Fork Show different persistent histories to different TEEs.
03 · CONFIDENTIALITY ≠ INTEGRITY ≠ FRESHNESS Why encryption alone does not solve the problem This is one of the most important conceptual steps in the paper.
Suppose a database stores a sensitive value and encrypts it before putting it on disk.
An attacker may no longer be able to understand the contents.
But encryption does not automatically prove that the ciphertext currently being returned is the newest legitimate ciphertext.
Confidentiality Can an attacker learn the content? 🔒 Encryption / TEE protection Integrity Was the content modified? ✓ Authentication / cryptographic verification Freshness Is this the correct current version? ↻ Version / state continuity Rollback attack A valid old state can still be dangerous V1 valid state → V2 valid state → V3 current ⇢ V1 attacker replay Subtle point V1 can be perfectly authentic and still be wrong.
The attacker does not necessarily need to forge a new valid state.
They can replay an older state whose cryptographic authentication metadata is also valid.
04 · THREAT MODEL Assume the cloud provider is actively malicious The paper uses the standard confidential-computing threat model: the TEE's trusted computing base is protected, while the cloud-side software and storage infrastructure is considered hostile.
Trust boundary Paper §3 Trusted TEE hardware isolation Code + data in protected memory Application ShieldFS CORE TEE replicas Untrusted Cloud OS Hypervisor Drivers Storage Network interfaces Cloud-side hardware outside TEE What is explicitly out of scope?
Side-channel attacks The paper assumes the TEE protects the relevant trusted state.
Side-channel mitigations are outside the work's scope.
DRAM / physical memory attacks Examples include Rowhammer and physical memory interposer attacks.
Malicious TEE code Code running inside the TEE is trusted to correctly implement ShieldFS and the application.
TEE software supply-chain compromise The threat model assumes the TCB can be validated using remote attestation and trusted policies.
Do not overclaim ShieldFS is not "complete cloud security." Its guarantees are relative to the threat model.
If the trusted computing base itself is compromised, the paper's filesystem-level guarantees do not magically protect the system.
05 · CONFIDENTIAL COMPUTING BASICS First understand the TEE A Trusted Execution Environment is a hardware-enforced isolated execution environment.
Confidential computing also provides remote attestation, allowing a remote party to verify the TEE's configuration before releasing sensitive material.
A hardware-protected execution island Conceptual 3D model Persistent storage untrusted ShieldFS filesystem security Application state protected memory TEE boundary hardware isolation AMD SEV-SNP VM-based confidential computing.
Intel TDX Hardware isolation for trusted domains.
Arm CCA Confidential compute architecture.
The paper also notes confidential-computing capabilities in accelerators such as NVIDIA GPUs.
These technologies are background context; ShieldFS's implementation itself is evaluated using AMD SEV-SNP-protected VMs.
06 · WHY POSIX COMPATIBILITY MATTERS The application should not have to become a cryptographer POSIX gives applications a standard filesystem interface.
A database, AI service, web server or ordinary program can request persistent storage through familiar operations without knowing the underlying filesystem's internal implementation.
Drop-in security at the filesystem layer Application A unchanged Application B unchanged AI / DB unchanged ↓ POSIX open / read / write / fsync ↓ ShieldFS integrity + freshness This is a major design choice.
Instead of requiring every application developer to invent their own rollback protection, the filesystem becomes the reusable security boundary.
07 · SHIELDFS ARCHITECTURE What actually lives inside ShieldFS?
The architecture is easier to understand if we separate the system into persistent filesystem structures, cryptographic authenticators, and a small amount of trusted state that survives across TEE sessions through CORE.
System overview Based on Figure 1 of the paper Application POSIX syscalls → ShieldFS inside VM-based TEE → Virtual disk untrusted I/O → Cloud storage untrusted WAL Records filesystem updates so crash recovery can replay a consistent sequence.
Storage pool Holds persistent blocks and metadata.
Block pointers are authenticated.
CORE Trusted registry that keeps the latest filesystem commitments across TEE restarts.
08 · CRYPTOGRAPHIC COMMITMENTS The filesystem needs a compact memory of "what state is valid" ShieldFS organizes persistent filesystem state as authenticated data structures.
Instead of keeping the complete disk state inside trusted memory, it keeps compact cryptographic commitments representing the permissible state.
The important word is succinct .
The paper reports that the trusted persistent state held by the registry is only a few hundred bytes per filesystem, while intermediate authenticators can remain alongside the data in untrusted storage.
Commitment intuition A compact fingerprint of a much larger state File A File B File C Metadata ↓ Cryptographic commitment succinct representation of state ↓ CORE trusted checkpoint The commitment is not itself the data.
It is evidence against which persistent data can be verified.
09 · EMBEDDED MERKLE AUTHENTICATION How can a tiny commitment detect a change deep inside the filesystem?
One intuitive way to understand the paper's authenticated structures is through a Merkle tree.
Individual blocks have cryptographic authenticators, while parent authenticators depend on their children.
A change deep in the tree therefore propagates toward a root commitment.
Interactive Merkle-tree intuition Click "Tamper D" to see propagation Normal Tamper D If D changes, H(D) changes.
That changes H(C+D) , which changes the root.
The TEE can therefore detect that the persistent structure no longer corresponds to the trusted committed state.
Important precision ShieldFS is not simply "a Merkle tree filesystem." The paper combines authenticated filesystem structures with WAL hash chains, commitments, transactions, copy-on-write and a trusted registry.
The security property emerges from the complete protocol.
10 · WRITE-AHEAD LOG The WAL becomes an authenticated history of updates Filesystems already use write-ahead logging to survive crashes.
ShieldZFS strengthens this existing mechanism by cryptographically chaining WAL blocks together.
The paper gives the hash-chain construction: h₀ = H(0 || WB₀) hₖ = H(hₖ₋₁ || WBₖ) for k > 0 Therefore: hₖ commits to the complete sequence WB₀, WB₁, ... , WBₖ WAL becomes a cryptographic history WB₀ h₀ = H(WB₀) → WB₁ h₁ = H(h₀ || WB₁) → WB₂ h₂ = H(h₁ || WB₂) → WB₃ h₃ = H(h₂ || WB₃) This matters because a storage attacker cannot simply reorder or remove historical WAL blocks and still produce the expected chain commitment.
The paper's security evaluation specifically tests block reordering, removal and appending attacks.
11 · COPY-ON-WRITE Do not destroy the old state while creating the new state ZFS already uses copy-on-write.
Instead of overwriting a block in place, an update creates a new version at a fresh location and changes metadata to point to the new version.
Atomic state transition Before Root → Block A After update Root' → Block A' Old A can remain until it is no longer reachable.
This is extremely useful for ShieldFS because filesystem state and its cryptographic commitments need to move from one valid state to another without exposing an intermediate inconsistent state after a crash.
12 · ATOMICITY The dangerous moment: filesystem state changes but the commitment does not Suppose the old filesystem state is V10 and its commitment is C10.
A successful update must eventually produce V11 + C11.
But a crash between those operations would be disastrous if the system could later recover with V11 while still trusting C10.
The consistency invariant V10 filesystem state + C10 trusted commitment → Transaction CoW + WAL + commitment → V11 new state + C11 new commitment ShieldFS uses transactions and copy-on-write so persistent filesystem state and the relevant commitments are updated atomically.