ShieldZFS detected every storage attack tested in an evaluation, while some of the write workloads used to assess it ran up to 2.3 times slower than ZFS. The preprint describes ShieldFS as a POSIX-compliant system intended to provide end-to-end integrity and freshness, meaning stored data should remain unaltered and current, for persistent storage in confidential computing without requiring application changes.
How the security test worked
The evaluated implementation, ShieldZFS, was based on the ZFS 2.3 release and added 2,500 lines of code. Performance comparisons included ext4, ext4 with dm-integrity, ZFS and ShieldZFS without CoRe.
The security evaluation comprised 63 attack scenarios for ShieldZFS and 42 for ZFS. ShieldZFS detected every attack in its test, while ZFS missed checksum-adjusted attacks involving reordered, dropped or appended ZIL blocks.
Performance varied by workload
In the reported fio comparison, ShieldZFS was up to 1.7 times slower for buffered synchronous writes and up to 2.3 times slower for direct synchronous writes than ZFS. Synchronous writes are operations that wait for storage to confirm completion.
In PostgreSQL TPC-C tests with 10- and 100-warehouse configurations, the reported ShieldZFS throughput was 1.05 times slower than ZFS in both configurations. Without CoRe, the reported throughput overhead was 0.3% for both configurations.
Filebench's varmail workload was 1.7 times slower with ShieldZFS than with ZFS, while the reported overhead without CoRe was 2.5%. ShieldZFS performed as well as ZFS on most RocksDB workloads but was 1.68 times slower on overwrite.
CoRe, the commitment registry used by the design, recorded a 90th-percentile registration latency, the point below which nine out of 10 registrations fell, of no more than 0.7 milliseconds at up to 5,000 commitments per second. Under the stated RocksDB workloads, it supported 25 to 500 concurrent ShieldZFS instances.
Recovery was also slower with ShieldZFS. For write-ahead logs (WALs) with 500 blocks, ShieldZFS took 0.66 seconds versus 0.52 seconds for ZFS; with 2,500 blocks, it took 1.80 seconds versus 1.41 seconds. That corresponds to 1.3 times the ZFS recovery time.
The result has a clear boundary
In this model, code and data inside a trusted execution environment, or TEE, are trusted, while an adversary is assumed to control the cloud software stack and all hardware components except the TEEs.
The figures also come from specified test configurations. ShieldZFS ran on VMs or confidential VMs with 32 vCPUs and 128 GB of RAM, while CoRe ran on VMs or confidential VMs with 8 vCPUs and 32 GB. The application evaluation included PostgreSQL TPC-C with 10- and 100-warehouse configurations, Filebench varmail and fileserver, and RocksDB.
No inferential statistical tests or confidence intervals were reported. The performance figures are therefore descriptive comparisons for the evaluated configurations and workloads, rather than results that can be assumed to generalize to other systems.
Taken together, the evaluation supports a bounded engineering result: in the tested ZFS-based implementation, ShieldZFS detected the tested attacks, while performance results varied by workload and configuration.
Paper data and sources
Original title: Securing Filesystems for Confidential Computing
Authors: Dimitra Giantsidi, Antoine Delignat-Lavaud, Cédric Fournet et al.
Journal/Repository: arXiv
Status: Preprint, not yet peer-reviewed
First online: 2026-08-20
DOI: Not available
Original paper · Full text