PaperlayerView exact revision on arXiv

Source-linked AI summary

SnapShare: Isolation-Preserving Deduplication for Serverless Snapshots

Leonid Kondrashov, Likun Zhang, André Filipe do Pilar de Jesus, Hans Pistor, Marco Cali, Riccardo Mancini, Rodrigo Bruno, Dmitrii Ustiugov

arXiv:2610.13318v1cs.DC

TL;DR

Tenant-isolated snapshots preserve separation but leave duplicate infrastructure in storage and caches. SnapShare shares only pages that completely match provider-approved references, treating other pages as private. It reduces tail slowdown by 10% versus Sabre and 29% versus Chunks, alongside 39% lower remote storage and 38% smaller caches versus Sabre.

  • Problem

    Tenant-isolated snapshots retain duplicate infrastructure across functions, wasting cache and remote-fetch capacity even though working-set retrieval avoids fetching unaccessed pages.

    Source: §1 · p. 1, §2.1 · p. 3

  • Method

    SnapShare co-designs storage and worker caches around page-level classification: complete matches to approved references are shared, all others private, with private working sets eagerly fetched and remaining pages served on demand.

    Source: §1 · pp. 2–3

  • Results

    10% lower end-to-end tail slowdown versus Sabre and 29% versus Chunks, with 39% lower remote-storage requirements and 38% lower local-cache requirements versus Sabre.

    Source: §4.5 · p. 11

  • Takeaways & Limitations

    Footprints approach unsafe full-deduplication efficiency under a conservative approved-content boundary, while nonmatching tenant-specific pages remain private.

    Source: §1 · p. 2, §6 · p. 12

    The model permits disclosure of approved-content presence or use, excludes secrets in approved artifacts and secret-dependent accesses, and does not claim protection against all shared-hardware or resource-contention timing channels.

    Source: §2.3 · p. 4

Abstract

from arXiv · show

The efficiency of serverless computing fundamentally depends on rapid function startup, a challenge increasingly addressed by restoring from virtual machine snapshots. However, because content deduplication techniques can open timing-channel attacks that leak sensitive tenant data, production platforms like AWS Lambda instead enforce strict, zero-sharing isolation between snapshots of different tenants. While secure, this isolation precludes the deduplication of common infrastructure components, wasting per-worker cache capacity and exacerbating cold-start latency through inefficient remote fetching. Our characterization reveals that non-sensitive, shareable infrastructure accounts for roughly 70% of a typical snapshot's contents and, on average, about 50% of its working set. We present SnapShare, a cluster-wide snapshot management system that co-designs storage and caching to exploit this commonality without compromising sensitive data isolation. SnapShare classifies a snapshot page as shareable only when its full content matches that of a page from a provider-approved source; any non-matching content is treated as isolated private content. Common infrastructure components are selectively deduplicated and pinned across the cluster's worker nodes, while private data remains strictly isolated and is eagerly fetched as part of the tracked working set, falling back to on-demand retrieval only for pages that fall outside it. Implemented as an extension to Knative, SnapShare reduces end-to-end tail request slowdowns by 10-29% compared to traditional working-set and chunk-based platforms. It also reduces remote storage requirements by 39% and local cache footprints by 38%, reducing network retrieval payloads and bounding worst-case fetch delays by 10x.

1 Introduction

SnapShare targets wasted storage and cache capacity from duplicate infrastructure in isolated serverless snapshots, while preserving tenant separation to address deduplication timing-channel risks. It classifies pages against approved references and co-designs storage and caching; evaluation reports lower tail slowdown, storage use, and cache footprint.

1 Introduction

  • Deduplication can expose sensitive state through retrieval-time differences, while existing snapshot-deduplication systems share all content and cannot distinguish safe infrastructure from sensitive data.Production platforms instead enforce separate copies across security domains, including for public infrastructure state.Source: §1 · pp. 1–2
  • Common infrastructure matches account for roughly 70% of nonzero snapshot content and 50% of working sets, with base-snapshot and rootfs matches recurring ubiquitously.Image matches recur less uniformly, often among functions using the same language runtime.Source: Figure 2 · p. 2, §1 · p. 2
  • SnapShare shares only complete 4 KB matches to provider-approved references; every other page is private, while profiling separates Working Set pages from Lazy pages.A page loaded from an approved image can still be private if it contains application state.Source: §1 · p. 2
  • Operators control which references are approved and may exclude libraries or images; disabling container-image sharing still yields 31% lower cache footprint than Sabre.The reported cache savings decline from 38% to 31% when image sharing is disabled.Source: §1 · p. 2
  • SnapShare stores approved shared components once and pins common ones in worker caches; it eagerly fetches missing private working-set pages and retrieves pages outside that set on demand.This combines working-set coalescing and eager restoration with selective sharing, while reducing repeated infrastructure fetches on misses.Source: §1 · pp. 2–3
  • 10% versus Sabre and 29% versus the chunk-based baseline in geometric-mean per-function P99 request slowdowns; remote storage falls 39% and cache footprint 38% versus Sabre.Footprints remain within 6% and 3% of the unsafe fully deduplicated baseline, respectively.Source: §1 · p. 3

2 Background and Motivation

Snapshot restoration trades repeated initialization for state retrieval, so reuse in worker caches and remote-fetch volume shape its efficiency. The section measures duplication and reuse opportunities, then sets out the security model and boundaries for cross-tenant sharing.

2.1 Duplication and Local Cache Efficiency

  • 43.9% of nonzero page content is duplicate without cross-snapshot deduplication; at approximately 2 GiB per worker, full deduplication yields about 21% mean hit rate versus about 14% without deduplication.Full deduplication is an unsafe oracle because it also shares private content; the hit-rate gap narrows at larger capacities.Source: Figure 4 · p. 3, §2.1 · pp. 3–4
  • Working sets retain duplicate infrastructure across tenants, while providers limit retrieval bandwidth to preserve capacity for application traffic.REAP and FaaSnap coalesce working-set pages for eager retrieval, but do not remove the duplicate infrastructure in each tenant's working set.Source: §2.1 · p. 3

2.2 The Measured Opportunity for Selective Sharing

  • Source matches measure correspondence to reference bytes, while recurrence measures reuse potential; neither recurrence nor source membership alone constitutes security approval.The study labels unmatched content Rest and separately distinguishes working-set from lazy pages.Source: §2.2 · p. 4
  • Infrastructure matches make up roughly 70% of nonzero snapshot content and 50% of working sets; base-snapshot and rootfs matches are mostly ubiquitous, while image matches recur less uniformly.The study classifies recurrence by whether content appears in all tested functions, several functions, or only one; source matching alone does not grant approval to share.Source: §2.2 · p. 4

2.3 Security Model for Snapshot Sharing

  • An attacker can place candidate content in its snapshot and use local-reuse versus remote-retrieval timing to infer whether a victim populated a matching cache entry.The model allows arbitrary code execution in the attacker's VM and timing measurements while co-located with a victim, but not direct access to victim memory or provider cache metadata.Source: §2.3 · p. 4
  • The model trusts the provider and its reference-approval policy; secrets in approved artifacts, secret-dependent runtime accesses, and shared-hardware or resource-contention timing channels are outside the claimed protection.Private content remains tenant-separated even when its bytes match, while reuse by its owning function is permitted.Source: §2.3 · p. 4

3 SnapShare

SnapShare co-designs storage and caching around a page-level sharing boundary: only full matches to provider-approved content are shareable, while access profiles guide eager or on-demand retrieval. Its storage and restoration paths preserve tenant separation for private pages while enabling reuse of approved content.

3 SnapShare

  • SnapShare shares only complete page-content matches to provider-approved sources, keeps every non-match private, and uses working-set profiles to guide retrieval.The design combines selective sharing with coalesced working-set retrieval and individual 4 KB fetches for other pages.Source: §3 · p. 5

3.5 Implementation

  • Implementation routes cold starts through a local controller, which restores mapped state and serves later faults through cache or remote retrieval.The page-fault handler uses userfaultfd to map cached shared state and fetched private state into VM memory.Source: §3 · p. 5, §3.3.3 · p. 6

3.1 Offline Snapshot Content Classification

  • An off-path profiling VM records initialization and initial-request page faults as the Working Set; the classifier marks full approved-content matches Shared, others Private, and unaccessed pages Lazy.Matching tests current page contents, so modified pages from approved images remain Private when they no longer match.Source: §3.1 · p. 5

3.2 Memory Management Granularity

  • Working-set pages are coalesced for eager retrieval, while unaccessed pages remain individual 4 KB units fetched on demand after a later page fault.Coalescing avoids fetching surrounding pages merely because they share a chunk; lazy retrieval limits transfer size without requiring the profile to predict every access.Source: §3.2 · pp. 5–6

3.3 Co-designed Cache and Storage Layout

  • Remote storage separates shared and private working sets from shared and private lazy pages; private content retains tenant and function-version identifiers, while common approved components can be pinned in worker caches.Private working sets use LRU eviction under cache pressure, whereas pinning is a separate policy for retaining approved shared components.Source: §3.3.1 · p. 6, §3.3.2 · p. 6
  • At cold start, the controller retrieves missing shared and private working-set components, then later page faults outside the profile fetch individual pages through cache or remote storage.Shared content remains eligible for cross-tenant reuse; private content retains its tenant identity throughout restoration.Source: §3.3.3 · p. 6

3.4 Enforcing the Sharing Boundary

  • Provider approval permits sharing but does not establish that an artifact contains no secrets or has secret-independent runtime accesses; risky components need exclusion or additional safeguards.Operators can revise approved references and withdraw eligibility, including by disabling cross-tenant cache reuse and regenerating snapshot metadata for tenant-private copies.Source: §3.4 · pp. 6–7

4 Evaluation

The evaluation measures SnapShare’s performance, storage and cache footprint, and sensitivity across serverless benchmarks and a trace-driven workload. Results show lower tail slowdown and resource requirements, with bandwidth and compression comparisons testing efficiency and robustness.

4.1 Methodology

  • Evaluation covers 17 vSwarm functions and a trace-driven workload of 700 Azure Function profiles, comparing SnapShare variants with Chunks, Pages, Sabre, and unsafe Full-Dedup; all systems use streaming compression.The trace-driven workload preserves invocation inter-arrival-time and execution-duration distributions.Source: §4 · p. 7, §4.1 · pp. 7–8

4.2 End-to-End Performance

  • 5.2 aggregate P99 slowdown under a 4 GB per-node cache is 10% below Sabre and 29% below Chunks; deduplicating configurations reach a 24% maximum mean hit rate at capacities within 10% of each other.The deduplicating configurations reach that saturation point at half the cache size required by Sabre.Source: Figure 8 · p. 8, §4.2.1 · p. 8, §4.2.2 · p. 9

4.3 Per-Component Analysis

  • 39% less remote storage than Sabre and 38.4% less local cache are required by SnapShare; its footprints are within 6% and 3.2% of unsafe Full Dedup, respectively.SnapShare- reduces local cache footprint by 31.2% relative to Sabre when container-image content is excluded.Source: Figure 9 · p. 9, §4.3.1 · p. 9
  • Across 17 benchmarks, cold-start time falls 39.8% versus Chunks and 27.5% versus Sabre, with a mean Sabre reduction of 6.1%; mean fetch size falls to 10% of Chunks.For aes-go, SnapShare takes 43.4 ms versus 121.2 ms for Chunks.Source: Figure 11 · p. 9, Figure 12 · p. 10, §4.3.2 · p. 10

4.4 Sensitivity and Efficiency Analysis

  • At 10 Gbps, SnapShare’s fetch-plus-decompression stage takes 31.8 ms, 6.8× faster than Chunks; at 1 Gbps it takes 57.7 ms versus 469.3 ms for Chunks.Across the bandwidth sweep, SnapShare remains close to unsafe Full Dedup.Source: Figure 13 · p. 10, §4.4.1 · p. 10
  • Zstd matches or achieves up to 25% lower decompression latency than Sabre’s IAA on four of five workloads, supporting its use as a representative compression comparison.The comparison uses eight parallel zstd decoder threads and IAA’s default single-queue configuration.Source: Figure 14 · p. 10, §4.4.2 · p. 11

4.5 Summary and Discussion

  • 10% over Sabre and 29% over Chunks in end-to-end tail slowdown; SnapShare also reduces remote-storage requirements by 39%, local-cache requirements by 38%, and mean network retrieval volume by 56%.These are the overall results relative to the tenant-isolated Sabre baseline and chunk-based Chunks baseline.Source: §4.5 · p. 11
  • Offline profiling may miss code paths in highly dynamic monoliths, increasing on-demand fetches; sharing public infrastructure also permits timing-channel leakage of execution metadata.The authors identify adaptive asynchronous profiling as a mitigation for missed working-set pages; the threat model accepts possible inference of non-sensitive infrastructure use.Source: §4.5 · p. 11

5 Related Works

Prior work tackles cold starts through execution-environment changes, snapshot restoration optimizations, and snapshot deduplication. SnapShare addresses the security gap in deduplication by sharing only pages that match provider-approved content while keeping other snapshot pages private.

Optimizing the Execution Environment

  • Execution-environment designs reduce sandbox provisioning overhead, but do not resolve snapshot cache-efficiency issues or snapshot-fetching overhead.The paper describes these environment-level improvements as orthogonal and complementary to secure snapshot deduplication.Source: §5 · p. 11

Optimizing Snapshot Restoration

  • Restoration systems use working-set coalescing, on-demand paging, or hardware-accelerated decompression, but rely on duplicated state that SnapShare can reduce without sharing sensitive pages.Examples include REAP, FaaSnap, remote and local fork architectures, and Sabre.Source: §5 · p. 11

Snapshot Deduplication and Security

  • Snapshot-deduplication systems reduce storage through content redundancy, but cross-domain deduplication can expose content presence through side channels.Production systems such as Firecracker recommend disabling memory deduplication when strong tenant isolation is required.Source: §5 · pp. 11–12
  • Unlike approaches relying on tenant hints, SnapShare shares a page only when its complete contents exactly match a provider-approved source, leaving other pages private.The related work names VUsion and Slicedup as approaches that limit cross-domain leakage, and CPC and UPM as systems relying on hints about safe-to-share pages.Source: §5 · p. 12

6 Conclusion

SnapShare selectively deduplicates pages that exactly match provider-approved infrastructure sources and isolates all other tenant-specific data. It reduces storage, cache, fetch latency, and tail slowdown relative to safe baselines while approaching the efficiency of unsafe full deduplication.

6 Conclusion

  • SnapShare reduces remote-storage requirements by 39% and local-cache footprints by 38% versus tenant-isolated Sabre, while remaining within 6% and 3% of unsafe full deduplication, respectively.The conclusion also reports a 6.8× reduction in cold-start fetch latency over chunk-based systems and a 10–29% reduction in end-to-end tail request slowdown relative to safe baselines.Source: §6 · p. 12

Related papers

Loading 2610.13318v1…