PaperlayerView exact revision on arXiv

Source-linked AI summary

CVM-Store: A Secure Storage System for Confidential Virtual Machines

Thore Sommer, Masanori Misono, Dimitrios Stavrakakis, Pramod Bhatotia

arXiv:2610.34560v1cs.CR

TL;DR

CVMs leave persistent storage outside their trust boundary, exposing stored workload data to the cloud provider. CVM-STORE combines a hardened userspace I/O engine with workload-aware CIF protection and an epoch-batched trusted counter service. With full CIF protections, it stays close to raw NVMe bandwidth on large objects.

  • Problem

    CVMs protect data in use but leave persistent storage exposed to provider access, corruption, and replay, making confidentiality, integrity, and freshness necessary for stored data.

    Source: §I · pp. 1–2

  • Method

    CVM-STORE combines a hardened userspace I/O engine, access-pattern-aware CIF primitives, and an asynchronous trusted counter service that externalizes monotonic state via epoch-based batching.

    Source: §I · p. 2

  • Results

    With full CIF protections, CVM-STORE stays within ≈1% (write) and 1–19% (read) of raw NVMe bandwidth on large objects from a single core.

    Source: §I · p. 2

  • Takeaways & Limitations

    The trusted counter interval of 1–281 ms lets applications tune the performance-freshness trade-off.

    Source: §I · p. 2

    Data written since the last trusted-counter synchronization point may be lost after an adversarial restart.

    Source: E. Limitations · p. 11

Abstract

from arXiv · show

Stateful cloud workloads require high-performance persistent storage when running on untrusted cloud infrastructure. Confidential Virtual Machines (CVMs) promise to protect these workloads through hardware-enforced memory encryption and isolation without requiring application changes. However, they protect only data in use; persistent storage lies outside the CVM trust boundary, exposing all stateful data to the cloud provider. Extending the trust boundary to persistent storage presents inherent challenges. High-bandwidth workloads require near-raw NVMe throughput, yet the default kernel CVM I/O stacks are inadequate, and userspace I/O libraries are not designed with CVM use cases in mind. Access patterns and storage semantics vary between workloads, necessitating access-pattern-aware security abstractions rather than uniform block-level encryption. In order to mitigate against rollback, freshness is needed, but CVMs lack hardware primitives for this purpose, requiring alternative solutions. We present CVM-Store, a storage system that co-designs a high-throughput userspace I/O engine with CIF (confidentiality, integrity, freshness) data protection. The key insight is that neither authenticated encryption nor I/O is a bottleneck by itself, but their naive combination is. CVM-Store exploits this by interleaving them, eliminating redundant copies and OS/hypervisor mediation. CIF guarantees are provided as composable primitives that adapt protection to workload access patterns, from which we derive three concrete authenticated abstractions: a KVS, a log, and a filesystem. An asynchronous trusted counter service provides freshness guarantees with epoch-based batching, which enables rollback protection without dedicated hardware support. CVM-Store delivers full CIF guarantees within $\approx$1% (write) and 1-19% (read) of raw NVMe bandwidth for large objects.

I. INTRODUCTION

CVMs protect data in use but leave persistent storage exposed to an untrusted cloud provider, while existing I/O and storage-protection approaches do not meet the combined performance and CIF requirements. CVM-STORE combines a hardened userspace I/O engine, access-pattern-aware protection, and epoch-batched freshness; its full-CIF implementation approaches raw NVMe bandwidth on large objects.

A. Confidential Virtual Machines (CVMs)

  • CVMs use hardware-enforced memory encryption and isolation, and attestation and sealing can bind provisioned data to evidence of a CVM's initial state.CVMs enable unmodified applications to run on untrusted infrastructure; sealing encrypts sensitive data so only the CVM with the sealing key can decrypt it.Source: §I · p. 1, A. Confidential Virtual Machines (CVMs) · p. 2

I. INTRODUCTION

  • CVMs protect data in use but leave persistent storage under provider control, where data can be read, corrupted, or replayed.CVM storage therefore needs confidentiality, integrity, freshness, and a way to bind stored data to a verified identity.Source: §I · p. 1
  • CVM-STORE combines a hardened kernel-bypass I/O engine with access-pattern-aware CIF primitives and an asynchronous, epoch-batched trusted counter service.Its attestation and sealing pipeline binds provisioned keys and counter state to the attested CVM identity.Source: §I · p. 2
  • CVM-STORE hardens the userspace I/O path for untrusted devices and interleaves encryption with in-flight DMA instead of serializing the operations.The design avoids redundant copies and OS or hypervisor mediation, addressing the mismatch between userspace I/O frameworks and the CVM threat model.Source: §I · pp. 1–2
  • With full CIF protections, CVM-STORE stays within ≈1% (write) and 1–19% (read) of raw NVMe bandwidth on large objects from a single core.The implementation targets AMD SEV-SNP and outperforms unencrypted CVM kernel I/O.Source: §I · p. 2
  • CVM-STORE demonstrates access-pattern-aware protection through a key-value store, shared log, and filesystem.Its primitives adapt integrity structures to each abstraction rather than applying uniform block-level protection.Source: §I · p. 2

B. CVM I/O Architecture

CVMs require shared-memory bounce buffers because devices cannot DMA into protected memory, and kernel I/O incurs copying and context-switch overhead. CVM-STORE’s motivation is to combine hardened userspace I/O with workload-aware CIF protection and freshness mechanisms.

B. CVM I/O Architecture

  • Userspace I/O frameworks map device registers into userspace, but CVM DMA still requires bounce buffers and exposes the system to potentially malicious device behavior.NVMe uses submission and completion queues for parallel command processing; devices fetch submitted commands, perform DMA, and post completions.Source: B. CVM I/O Architecture · p. 2, C. Modern Cloud Storage Devices · p. 3

III. MOTIVATION AND KEY IDEAS

  • CVMs achieve only up to 90% of VM write throughput and 77% of read throughput via the kernel I/O stack, motivating lower-overhead CVM storage I/O.Protected memory requires bounce buffers, adding at least two memory copies per operation; userspace frameworks reduce kernel overhead but do not remove this requirement or the need to harden device interactions.Source: §III · p. 3
  • Large-object workloads span write-once bulk data, append-only logs, and key-addressed objects, so uniform block-level protection can impose unnecessary cryptographic work.Write-once files can use a static Merkle tree, while append-only logs can use counter-chained MACs; the passages report authenticated block encryption with AES-XTS+sha256 reducing throughput by 37–56%.Source: §III · p. 3
  • CVMs lack a local hardware freshness primitive, so rollback protection requires externalizing counter state to a trusted party and synchronizing freshness updates.Epoch-based batching trades performance against the rollback window: per-write synchronization bounds it to one write, while batching allows reversion to the last committed epoch.Source: §III · p. 4
  • Existing storage approaches do not simultaneously provide high-throughput secure I/O, access-pattern-aware CIF protection, and fresh attested state.CVM-STORE’s proposed direction is to integrate CIF into the I/O engine, lift enforcement to workload-specific abstractions, and embed counter values in persistent structures.Source: §III · p. 4

IV. OVERVIEW

CVM-STORE combines a userspace NVMe I/O engine with a service that manages metadata, crash consistency, and CIF enforcement. Its deployment binds provisioning and counter synchronization to attestation before applications use its storage abstractions.

A. System Architecture

  • CVM-STORE targets applications requiring high-performance storage when devices and the storage stack are exposed to an untrusted cloud provider.Its architecture comprises an I/O engine, control-path service, trusted parties for attestation and provisioning, and an external trusted counter service.Source: A. System Architecture · pp. 4–5
  • CVM-STORE offers a key-value store, shared log, and filesystem whose integrity metadata is co-designed with access patterns rather than applied uniformly at block level.The shared log targets append-only data; the filesystem supports random reads for write-once bulk data, with more Merkle-tree CIF overhead.Source: A. System Architecture · pp. 4–5
  • The I/O engine uses SPDK Blobstore for userspace storage access and applies modern AEAD protection in the I/O path while optimizing bounce-buffer copying.The engine also hardens SPDK’s device-facing boundary against untrusted NVMe controllers.Source: A. System Architecture · p. 5

B. System Deployment and Workflow

  • Before runtime, the user verifies CVM attestation evidence and provisions configuration and keys sealed to the attested CVM; the service establishes trusted counter synchronization.At runtime, the service manages blobs and metadata while the I/O engine transfers data, encrypting and adding integrity metadata and counter values on writes, then decrypting and validating on reads.Source: B. System Deployment and Workflow · p. 5

C. Programming Model and APIs

CVM-STORE exposes storage APIs tailored to application access patterns and protects persistent data through a hardened userspace I/O engine. Its security claims assume trusted CVM hardware and software, attestation, cryptography, and external services.

C. Programming Model and APIs

  • CVM-STORE guarantees confidentiality and integrity through authenticated encryption and freshness through trusted counter validation across its storage abstractions.Its stated durability guarantee allows unsynchronized operations to be lost after an adversarial restart, but never to reappear as stale data.Source: C. Programming Model and APIs · p. 5, D. Threat Model and Security Goal · p. 6
  • Applications choose among a KVS for immutable key-value objects, a shared log for append-only sequential access, and a filesystem for write-once files with sequential and random reads.The APIs treat objects as whole rather than supporting in-place mutation, and applications embed the CVM-STORE library instead of using POSIX.Source: C. Programming Model and APIs · pp. 5–6

D. Threat Model and Security Goal

  • CVM-STORE’s TCB includes CVM firmware, hardware, and in-CVM software, while the hypervisor, host OS, and storage devices are untrusted.The model excludes side-channel, denial-of-service, and physical attacks; metadata confidentiality is not provided, though metadata integrity and freshness are ensured.Source: D. Threat Model and Security Goal · p. 6

A. I/O Engine

  • The I/O engine builds on SPDK for userspace NVMe access and organizes blobs into unprotected metadata, optional encrypted metadata, and encrypted data chunks.It interleaves encryption and integrity protection with DMA-shared-memory transfers, avoiding additional copies while overlapping encryption or decryption with in-flight I/O.Source: A. I/O Engine · p. 6
  • The crypto subsystem uses authenticated encryption and Merkle-tree verification, with MAC leaves and cached validated nodes to reduce verification work.By default it uses AEGIS-128X4; the passage reports it is nearly 6× faster than AES-256-GCM, and says the system saturates a modern NVMe device on one core for large data-intensive workloads.Source: A. I/O Engine · p. 6
  • CVM-STORE separates private driver state from DMA-accessible NVMe descriptors and validates controller completion identifiers before indexing tracker state.Invalid completion identifiers fail the queue, preventing a forged completion from causing an out-of-bounds access; VFIO direct BAR mapping also avoids expensive MMIO hypercalls.Source: A. I/O Engine · pp. 6–7

B. Trusted Counter

CVM-STORE externalizes monotonic counter state and batches synchronization in epochs to balance freshness against latency. Its service integrates counter validation with metadata management, attestation, provisioning, and access-pattern-specific storage abstractions.

B. Trusted Counter

  • CVM-STORE uses an external trusted counter service because CVMs lack monotonic counters, separating durable metadata persistence from freshness synchronization.Epoch length and synchronization mode set the vulnerability window: blocking mode holds mutations until commit and can lose at most one epoch, while non-blocking mode can lose up to two for lower latency.Source: B. Trusted Counter · p. 7

C. CVM-STORE Services

  • The service maintains storage metadata and uses copy-on-write updates for atomicity, deferring stale-blob cleanup until metadata synchronization succeeds.It embeds trusted counter values in persistent data, batches counter increments with storage operations, and validates counter values and metadata authentication at startup before granting access.Source: C. CVM-STORE Services · pp. 7–8

D. Attestation and Provisioning

  • Attestation and provisioning bind configuration and on-disk keys to the CVM identity, with re-attestation and re-provisioning required after reboot or migration.The counter service rejects cloned or restored copies.Source: D. Attestation and Provisioning · p. 8

E. Data Sealing and Unsealing

  • The sealing operations let users provision data for an attested CVM and export or restore internal state using configured keys.For data provisioning, a trusted party can write with simulated counters and then provision the resulting counter value to the freshness service without trusted-counter round trips during the write.Source: E. Data Sealing and Unsealing · p. 8

A. Key-Value Store (KVS)

  • The KVS stores one key-value pair per blob and targets large values read sequentially, trading memory proportional to key count for fast lookup and rollback checks.On startup it reconstructs the key map from blobs, discards blobs exceeding the metadata counter, selects the higher valid counter for duplicate keys, and verifies a multiset hash.Source: A. Key-Value Store (KVS) · pp. 8–9
  • The KVS encrypts each value and its key-counter metadata, then validates the stored key and counter against the in-memory map before returning a requested value.Updates replace objects; deleted blobs are deallocated only after metadata synchronization.Source: A. Key-Value Store (KVS) · p. 9

B. Shared Log

CVM-STORE’s shared log and filesystem pair workload-specific data layouts with CIF checks for authenticated access. The security analysis describes how those checks detect tampering, replay, and inconsistent state.

B. Shared Log

  • The shared log authenticates entry data and counter metadata, caches expected counters, and checks the chain and inode boundary counters on open and retrieval.Append updates the trusted counter; truncation updates the inode and cache while deferring blob reclamation until metadata synchronization.Source: B. Shared Log · p. 9

C. Filesystem

  • The filesystem treats files as immutable, name-addressed objects and uses a static Merkle tree to verify chunks during random-access reads.Chunks are encrypted with nonces derived from a file nonce and chunk number; verified data is returned only after CIF checks.Source: C. Filesystem · pp. 9–10

A. General Attack Vectors

  • The general attack analysis says attestation rejects compromised instances, AEAD detects blob tampering, and bounds checks constrain manipulated device descriptors.Keys are provisioned through attestation and remain in protected CVM memory.Source: A. General Attack Vectors · p. 10

VII. SECURITY ANALYSIS

  • Trusted counters synchronized with an external party detect replayed storage state, while copy-on-write metadata, deferred cleanup, and restart revalidation address crash-induced inconsistency.The synchronization interval bounds freshness, so data written since the last synchronization may be exposed to rollback.Source: A. General Attack Vectors · p. 10

B. Attacks on KVS

The security analysis explains how CVM-STORE’s abstractions detect stale or rearranged data, and identifies operational boundaries. Its implementation targets SEV-SNP while describing a vendor-agnostic design.

B. Attacks on KVS

  • On each KVS GET, CVM-STORE checks a blob’s key and counter against its in-memory map; startup hashes reconstructed key-counter pairs to detect unauthorized deletion.Legitimate deletions atomically update the metadata hash and defer physical deallocation until the next synchronization.Source: B. Attacks on KVS · p. 10

C. Attacks on Shared Log

  • The shared log’s AEAD-protected counter chain and inode boundary counters expose entry splicing, truncation, and reordering during reads or log-open validation.A splice must have mutually consistent entry, predecessor, and successor counters and MACs.Source: C. Attacks on Shared Log · pp. 10–11

D. Attacks on Filesystem

  • Filesystem chunks are checked against a trusted-counter-protected Merkle root, detecting chunk replacement and whole-file replay before plaintext is returned.Replayed metadata, including the superblock, is rejected at startup when its trusted counter is stale.Source: D. Attacks on Filesystem · p. 11

E. Limitations

  • Metadata such as file sizes and access patterns remains visible; freshness depends on an external counter service, and adversarial restarts may lose writes since the last synchronization.Side-channel and physical attacks and denial of service are outside the stated threat model.Source: E. Limitations · p. 11

VIII. IMPLEMENTATION

  • The implementation targets AMD SEV-SNP using a userspace SPDK library, while the design is described as applicable to Intel TDX and Arm CCA.The implementation includes memory-type-aware DPDK allocation and SPDK changes; its attestation flow uses a verifier to validate CVM evidence and release sealed configuration.Source: §VIII · p. 11, Figure 8 · p. 12

IX. EVALUATION

CVM-STORE’s evaluation reports strong performance on targeted data-heavy workloads, with weaker results on small-object, high-thread workloads. It compares storage interfaces and applications against ext4 and Rollbaccine under specified test settings.

A. Experimental Setup

  • Experiments compare CVM-STORE with ext4 and Rollbaccine on two SEV-SNP servers and a 3.8 TB NVMe, using matched durability settings.The I/O analysis includes 1- and 8-thread workloads, synthetic interface tests, YCSB KVS updates, sequential log operations, and filesystem reads.Source: A. Experimental Setup · p. 12, B. I/O Analysis · p. 12

B. I/O Analysis

  • For large sequential file reads, one CVM-STORE thread sustains 13.0–13.3 GiB/s from 256 MB, or 96–99% of the device, versus 30% for ext4 and 19% for Rollbaccine.The KVS reaches 4.7–4.9 GiB/s at 256 MB and 1 GB; shared-log appends reach 95–99% of device write bandwidth from 1 MB.Source: B. I/O Analysis · p. 12

C. End-to-end Performance

  • Checkpoint saves reach 6.53–6.55 GB/s on CVM-STORE’s Filesystem and Shared Log, matching ext4 and exceeding Rollbaccine’s 5.61 GB/s by 1.17×.Filesystem loading reaches 11.5 GB/s, within 2.3% of both baselines; Shared Log loading is 15% slower because retrieval is partly serialized.Source: C. End-to-end Performance · p. 13, Figure 9 · p. 13
  • Redis performance exceeds Rollbaccine by 1.95–2.27× with per-operation durability and by 1.32× at 50 clients with once-per-second batching.Against ext4, Redis is on par or trails by 6–15%.Source: C. End-to-end Performance · p. 13
  • Across end-to-end workloads, CVM-STORE matches or outperforms both baselines on targeted data-heavy tasks but trails ext4 on small-object, high-thread workloads.The mail workload reaches 0.29× ext4; small operations cannot amortize per-operation metadata and Blobstore handling costs.Source: C. End-to-end Performance · p. 13, Figure 9 · p. 13

D. Read/Write Amplification

CVM-STORE reports low metadata and integrity-structure amplification, small runtime overhead for full CIF protection, and measured costs for attestation and sealing.

D. Read/Write Amplification

  • SPDK adds one 4 KiB metadata page per blob, CVM-STORE adds a block for AEAD metadata, and KVS and log add encrypted freshness metadata; filesystem Merkle-tree overhead is below 0.002%.The study compares application-visible I/O with bytes written through SPDK bdev, not physical NVMe write amplification.Source: D. Read/Write Amplification · p. 13, Table VII · p. 13

E. Ablation Study

  • Full CIF protection adds 0.4–0.9% runtime; staging copies add 8–16%, AES-256-GCM adds 19–21%, no I/O overlap adds 70–76%, and the kernel NVMe driver adds 59–68%.The crypto pipeline spans 51–56% of runtime, but only 0.4–0.5% is visible end-to-end because most work overlaps in-flight DMA.Source: E. Ablation Study · pp. 13–14, Figure 10 · p. 13

F. Attestation and Sealing

  • Attestation and sealing startup takes 188.35 ms on the CVM and 87.43 ms on the trusted party; sealing and unsealing scale from 0.03–0.06 s at 100 MB to 150.2 s at 1 TB.Filesystem and shared-log recovery validate metadata in 0.07–0.15 s, while KVS recovery reads all entries during reconstruction.Source: F. Attestation and Sealing · p. 14, Table VIII · p. 14, Table IX · p. 14

G. Trusted Counter

With a modeled 5 ms service RTT, epoch length and workload determine the overhead of adding freshness to durability. The paper places this trade-off in the context of related secure-storage work and concludes that CVM-STORE combines CIF protection with near-raw NVMe bandwidth.

G. Trusted Counter

  • At the worst case, freshness adds 7.3–9.7% overhead across all three workloads; filesystem and shared log are near 8% at a 1 ms epoch and close to 2.5% at the widest epochs.KVS overhead is 1–3% across epochs because the workload mixes reads and writes and some epochs do not require synchronization.Source: G. Trusted Counter · p. 14, Figure 11 · p. 14

X. RELATED WORK

  • Related systems span single-node and distributed TEE storage, databases, and generic block-security mechanisms, while CVM-STORE targets diverse CVM access patterns with CIF guarantees.The Confidential Data Hub uses kernel I/O backends that do not provide full integrity or freshness; CVM-STORE also adapts userspace I/O to CVM storage workloads.Source: §X · p. 14

XI. CONCLUSION

  • CVM-STORE’s conclusion is that full CIF remains within ≈1% (write) and 1–19% (read) of raw NVMe bandwidth on large objects, while applications can tune freshness cost through epoch length.Source: §XI · p. 15

APPENDIX A TRUSTED COUNTER, FRESHNESS & DURABILITY

The appendix describes how CVM-STORE batches trusted-counter commits, binds provisioning and recovery to attestation, and coordinates instance lifecycle and device access. It also documents SPDK DMA hardening, the reproducibility artifact, and its hardware requirements.

APPENDIX A TRUSTED COUNTER, FRESHNESS & DURABILITY

  • Only commit() contacts the external trusted party, publishing a reserved counter once per epoch rather than paying a round trip for each operation.next() supplies monotonic values for per-operation tags and per-epoch stamps without I/O; Table X presents the interface.Source: Appendix A · p. 18, Table X · p. 19
  • The freshness protocol requires monotonic authenticated commits, durability before acknowledgment, and a replay-protected channel bound to the attested CVM.Epoch triggers can be operation-, time-, or event-based; ORDERED schedules commit after metadata writes, while PARALLEL overlaps them.Source: Appendix A · pp. 18–19
  • With blocking synchronization, a crash loses at most one configured window, while throughput is roughly window/(window+D+RTT); without it, the loss bound can reach two generations.Table XI presents durability and freshness configuration; the epoch setting selects the rollback window.Source: Appendix A · p. 19, Table XI · p. 19

APPENDIX B INSTANCE LIFECYCLE

  • Deployment, migration, and recovery require trusted-party coordination to attest and provision CVM instances and synchronize their store epoch; live migration is unsupported.A restarted CVM is treated as new because its sealing key is gone, and stale restored state is detected against the freshness service.Source: Appendix B · pp. 19–20, Figure 12 · p. 19

APPENDIX C SPDK HARDENING & DMA ALLOCATIONS

  • SPDK hardening adds completion-queue bounds checks and places only required tracker data and appropriately sized I/O buffers in DMA memory.The appendix lists NVMe queue management, blobstore metadata, and I/O buffer pools as DMA-accessible structures.Source: Appendix C · p. 20, Table XII · p. 20

APPENDIX D ARTIFACT APPENDIX

  • The artifact includes CVM-STORE, example clients, patched kernels and DPDK/SPDK, ported applications, and a framework that automates evaluation experiments.Its repository pins components as Nix flake inputs for reproducible builds.Source: Appendix D · p. 21, 1) How to access · p. 21

2) Hardware dependencies: •

  • The documented hardware setup calls for an AMD SEV-SNP server, at least 64 physical cores and 320 GB RAM, and a dedicated 3.8 TB-or-larger NVMe SSD.A slower or Gen 4 NVMe can demonstrate functionality but not the absolute performance numbers.Source: 2) Hardware dependencies: • · p. 21

3) Software dependencies: •

The artifact section specifies its software and installation workflow, then maps the paper’s major claims to evaluation experiments. Those claims cover I/O performance, application workloads, amplification, protection overhead, attestation and sealing, and epoch tuning.

3) Software dependencies: •

  • The artifact instructions require a Linux host with SEV-SNP support, IOMMU and vfio-pci, plus Nix with flakes; Docker and root access are also listed dependencies.Source: 3) Software dependencies: • · p. 21

4) Benchmarks:

B. Artifact Installation & Configuration

C. Major Claims

  • For large objects, one core with full CIF is within ≈1% (write) and 1–19% (read) of raw NVMe bandwidth, while single-threaded ext4 and Rollbaccine reach 18–30% on reads.Source: C. Major Claims · p. 21
  • CVM-STORE matches or outperforms both baselines on large-object application workloads, trailing only on small-object or high-thread-count workloads.Source: C. Major Claims · p. 21
  • The three abstractions keep read/write amplification below 1‰, while full CIF costs ≈1% runtime and naively implementing any one protection part costs up to 76%.Source: C. Major Claims · p. 21
  • Attestation is a one-time overhead, sealing scales linearly with data, and widening epochs reduces filesystem and shared-log overhead from 8–10% to ≈2.5%.Source: C. Major Claims · p. 21

D. Evaluation

The artifact evaluation automates experiment runs and associates benchmark families with their outputs. Its quick subset is faster but uses less data, so absolute measurements may differ from the paper; users can customize benchmark settings.

D. Evaluation

  • The evaluation harness automates runs for motivation, I/O characteristics, applications, ablation and amplification, attestation and sealing, and trusted-counter epochs.The quick command runs a representative subset in about a day; the complete set may take several weeks, mainly because fio requires the NVMe to reach steady state.Source: D. Evaluation · pp. 21–22
  • Quick runs use less data, so their absolute numbers may differ from the paper, although ratios and curve shapes are expected to be similar on matching hardware.Source: D. Evaluation · p. 21

E. Customization

  • The artifact documentation describes manual benchmark execution and customization of VM size, storage backends, crypto variants, durability and freshness settings, and workloads.Source: E. Customization · p. 22
Loading 2610.34560v1…