Reducio: Optimized Confidential Serverless Cloud Deployments for Enterprise Customers

• Prior designs require complex cloud-infrastructure modifications, large in-memory Zygote caches, and can suffer poor invocation latency under eviction; 21 Zygotes alone consume ≃5.15GiB.Source: §I · p. 1
• REDUCIO combines a self-contained CVM security monitor based on intra-kernel privilege isolation with partial, layer-wise snapshot retention guided by invocation patterns and memory availability.A predictive time-series algorithm weighs function arrivals, memory overheads, and startup latency across cache levels to retain or pre-warm snapshots, or evict them to save memory.Source: §I · pp. 1–2
• To enable secure Copy-on-Write fork, REDUCIO adds memory-management-unit checks during fork and page faults, validating kernel-declared intentions at key lifecycle events.Incorrect or undeclared intentions cause the monitor to abort both parent and child processes.Source: §I · pp. 1–2
• REDUCIO’s secure-Copy-on-Write function startup latency is comparable to prior work,.Source: §I · p. 2
• REDUCIO’s partial caching and predictive algorithm uses 64% less memory on average than prior work while retaining 19.3% of the geometric mean function performance.Source: §I · p. 2

II. SYSTEM AND DEPLOYMENT MODEL

• Enterprise customers may invoke hundreds of thousands of functions per hour and receive customized solutions and direct support.Source: §II · p. 2
• Clients seek data protection from cloud administrators and other tenants, low invocation latency, support for varied languages and runtime versions, and low per-function cost.The passage notes that multiple runtime versions are common in confidential serverless functions.Source: §II · p. 2
• LiveWell, Booz Allen, and Portbase illustrate sensitive health, malware-defense, and logistics workloads using serverless computing.LiveWell analyzes health habits and biometrics for over 150,000 daily users; Booz Allen uses AWS Lambda for malware-defense AI and takes privacy measures; Portbase processes sensitive logistics information with AWS Lambda.Source: §II · p. 2

III. BACKGROUND ON CONFIDENTIAL SERVERLESS

• Confidential serverless uses hardware-assisted trusted execution environments to address serverless privacy risks, with CVMs offered as a promising platform foundation.Source: §III · p. 2
• Intel TDX, AMD SEV,, and ARM CCA support CVMs, whose encrypted, integrity-protected memory isolates the guest software stack from hosts, devices, and other VMs.The hardware prevents external components from accessing or modifying the guest kernel and application runtime state.Source: §III · p. 2
• CVM remote attestation provides a signed report measuring initial state, which remote verifiers use to check authenticity and integrity before provisioning secrets.Source: §III · pp. 2–3
• CVM custom data can support secure-channel establishment with a remote verifier through authenticated key exchange protocols.Source: §III · p. 3

A. Optimized Isolated Function Execution inside a CVM

• Fresh CVM boot for each invocation makes short-lived functions slow and costly, while CVM memory isolation rules out memory-sharing optimizations.Launching a CVM requires loading and measuring a guest OS and language runtime, with cold-start latency dominating function execution time.Source: A. Optimized Isolated Function… · p. 3
• A dedicated serverless platform inside a CVM can rapidly deploy function containers and apply memory optimizations, but its privileged software stack could steal user data.Secure container mechanisms are needed to isolate userspace containers from the provider-controlled privileged stack.Source: A. Optimized Isolated Function… · p. 3

B. Potential Existing Solutions and their Limitations

• Prior CVM isolation designs use trusted microkernels (CoFunc), hardware VM partitioning (Veil and Wallet), or intra-kernel monitors (Erebor).CoFunc isolates containers through process contexts and page tables; Veil and Wallet use AMD VMPLs; Erebor uses Nested Kernel principles.Source: B. Potential Existing Solutions and… · p. 3
• CoFunc cannot provide the required multi-party isolation, while Wallet [53] and CoFunc require platform-specific mechanisms and host-side changes that hinder portability and deployment.Wallet’s VMPL approach also requires host hypervisor and paravisor changes and ties the design to AMD SEV-SNP; CoFunc shifts core OS services to the host hypervisor, complicating deployment and migration.Source: B. Potential Existing Solutions and… · pp. 3–4
• Erebor lacks runtime validation for fork, so it incurs an average function boot latency of 4.6s in the reported experiments.Wallet and CoFunc use in-memory zygotes of initialized, pre-measured runtimes and dependencies to enable fast copy-on-write forks instead of loading and measuring from scratch.Source: B. Potential Existing Solutions and… · p. 4
• 21 Python function zygotes consume ∼5.14GiB in total, and diverse runtimes and dependencies can require separate, large zygotes.Keeping tens of thousands of zygotes resident to minimize startup latency creates scalability and monetary costs for cloud providers.Source: B. Potential Existing Solutions and… · p. 4, Figure 2 · p. 4
• A basic on-demand cache that retains functions until timeout consumes around 2.8× more memory during function execution than Reducio’s optimized algorithm.Zygotes must be evicted under low function utilization or high memory pressure, a condition existing solutions do not address.Source: B. Potential Existing Solutions and… · p. 4

V. THREAT MODEL

• The host OS and hypervisor are untrusted,, and may exploit CVM interfaces or malicious workloads; the CVM kernel is also adversary-controlled.The host may use I/O or networking to infer data or pretend to be a user to access co-located functions.Source: §V · p. 4
• Each function must run in isolation because it may process different downstream customers’ data; developers are trusted to supply code and dependency manifests.Manifests list required runtimes and libraries with integrity measurements such as SHA-256 hashes; functions are assumed to run solely on CPUs.Source: §V · p. 4
• The model excludes micro-architectural side channels, denial-of-service, and physical attacks, and assumes hardware is patched against the stated defects.The side-channel and hardware-defect exclusions cite,, [20], [41] and [39],,,, respectively.Source: §V · p. 4

VI. REDUCIO DESIGN

• The intra-kernel security monitor isolates client functions without requiring CVM partitioning features such as VMPL or delegation of the I/O stack from the host hypervisor.The monitor builds on Nested Kernel principles adapted for CVMs,.Source: §VI · p. 5
• Each function runs in an isolated Trusted Process with a LibOS, while two-stage measurement and attestation validate the runtime, manifest, dependencies, and loaded components before user data is accepted.The LibOS provides a container-like environment common in cloud systems,, and the two-stage approach follows.Source: §VI · p. 5
• Secure Copy-on-Write fork validation extensions for Trusted Processes support efficient function caching and fast startup.These extensions follow the philosophy of intra-kernel monitors and address L2.Source: §VI · p. 5
• Partial caching selectively retains, evicts, or pre-warms Zygotes according to invocation patterns and resource availability to reduce cold-start latency and the number of snapshots kept in memory.This addresses L3b.Source: §VI · p. 5

A. Intra-Kernel Monitor Extensions for Fork Validation

• REDUCIO adds monitor calls and instruments fork and page-fault paths to validate secure CoW forks, supporting efficient function caching and fast startup.The monitor protects trusted-process memory, including forked processes, from access by untrusted components such as the OS kernel.Source: A. Intra-Kernel Monitor Extensions for… · p. 5
• Fork validation requires shared protected pages to belong to related processes, use consistent virtual addresses, be explicitly declared CoW, and leave parent and child with equal mapped-page counts.These are invariants Inv1–Inv4 enforced during fork.Source: A. Intra-Kernel Monitor Extensions for… · p. 5
• The fork callgraph is instrumented to track events and validate invariants: the monitor establishes the parent–child relationship, validates declared page tables and CoW mappings, then checks read-only CoW pages and equal mapped-page counts at finalization.The child is not scheduled unless the kernel calls finalize_fork.Source: A. Intra-Kernel Monitor Extensions for… · pp. 5–6
• On page faults, the kernel must declare new protected pages and use protected_copy, which checks page ownership and copies only between related processes’ protected pages.The monitor associates the copied page with the original page’s virtual address, and subsequent mapping requests are validated.Source: A. Intra-Kernel Monitor Extensions for… · p. 6
• During update_mapping, REDUCIO validates declared page tables and process identifiers, permitting protected-page mappings only when the page and virtual address satisfy the process or declared-CoW rules.Mappings are aborted when a page belongs to another identifier and the process is not a declared fork or the page is not declared CoW, or when a CoW page has a different parent identifier.Source: A. Intra-Kernel Monitor Extensions for… · p. 6

Function caching layers and rationale

• REDUCIO uses secure forks and a trusted library OS for partial process caching, unlike prior approaches based on partial file-system caching,.The three cache layers are Bare, Runtime, and Warm; instances are forked from the layer expected to provide the lowest startup latency.Source: B. Layered Predictive Function Process… · p. 6
• Bare instances preload the LibOS and GNU C libraries, use secure forks from an in-memory parent, and can be warmed to run any requested function.Bare instances consume little memory, but only the LibOS can be CoW-shared from this layer; CoW sharing of components varies by layer.Source: B. Layered Predictive Function Process… · p. 7
• Runtime instances preload a language runtime, dependencies, and standard libraries; each runtime version is distinct, and an instance can run any function written for it.Instance size varies with the maintained language runtimes.Source: B. Layered Predictive Function Process… · p. 7
• Warm instances have loaded all dependencies for one user function, so they can load user data and execute with the lowest invocation latency.Warm instances correspond to Zygotes in prior confidential serverless systems,.Source: B. Layered Predictive Function Process… · p. 7

Predictive cache warmup and eviction

• A time-series predictor models each function’s arrivals as a Poisson distribution, keeping functions Warm in advance and gradually evicting them to lower-memory layers when demand falls.The coordinator uses predicted invocation patterns to reduce memory waste while minimizing startup latency.Source: B. Layered Predictive Function Process… · p. 7
• For each request, the coordinator forks from the fastest available layer—Warm, then Runtime, then Bare—and starts further instances to avoid sequential waits for forks.Instances remain alive until a TTL based on predicted inter-arrival time and a provider-configured cost function accounting for startup latency and memory footprint; Runtime and Warm layers are warmed even when requests are not arriving.Source: B. Layered Predictive Function Process… · p. 7

REDUCIO-MONITOR

• The monitor extends Erebor with 1,210 lines of code for six new SMCs enabling secure Copy-on-Write fork, while retaining secure monitor–kernel context switches.The prototype uses Erebor’s existing trusted-process support for serverless functions.Source: §VII · p. 7

Kernel instrumentation

• The kernel instrumentation adds about 500 lines for registering and validating fork operations, and requires Intel PKS- and TDX-compatible kernels; the prototype uses Intel kernel 6.8.0.The instrumentation invokes the newly designed SMCs.Source: §VII · p. 7

Function Library OS (LibOS)

• The function LibOS uses Gramine,, also used by a recent confidential serverless system, with 1,205 added lines supporting forking at different function layers.Gramine provides POSIX compatibility for running different functions.Source: §VII · pp. 7–8

REDUCIO-COORDINATOR

• The 1,700-line Python coordinator starts a Parent LibOS, populates and tracks function-layer caches, and iteratively checks cache layers when spawning an instance for an invocation.During boot, it creates function instances through the fork syscall and tracks each process’s layer.Source: §VII · p. 8

Function orchestrator

• The RainbowCake OpenWhisk orchestrator, uses about 1,200 lines of Scala shim code to pass commands to the VM server while preserving OpenWhisk’s internal data structures.The shim provides the container-like system OpenWhisk requires.Source: §VII · p. 8

Validating the correctness of Copy-on-Write fork

• Monitor invariants prevent malicious translations by requiring related processes, same-address nonwrite shared mappings, and equal mapped-page counts after fork.These checks preserve the parent and child mappings and identical state.Source: §VIII · p. 8
• The deprivileged kernel cannot directly access protected pages; the monitor permits copying only read-only Copy-on-Write pages to pre-declared protected pages of related processes.These restrictions prevent access to protected parent or child data.Source: §VIII · p. 8

Enabling confidentiality with partial container caching

• Pre-warmed Bare and Runtime states contain no user-specific information, and fresh trusted processes prevent cached instances from exposing data across functions.Once a function reaches User state, further forks are prohibited and writable user-level pages are Copy-on-Write from shared states.Source: §VIII · p. 8
• Hash verification rejects substituted shared-state components, and protected-memory isolation prevents the untrusted OS from modifying or replacing cached layers.The LibOS checks loaded components against developer-provided hashes when shared states are generated.Source: §VIII · p. 8

A. Experimental Setup

• Experiments ran on an Intel Xeon 6510P server with 32 physical cores, 128GiB memory, and a TDX guest VM assigned 8 vCPUs and 24GiB.The host ran Ubuntu 24.04 with Linux v6.8.0; the guest ran Ubuntu 24.04 with Linux 6.6 and Intel-TDX module version 1.5.05.46.Source: A. Experimental Setup · p. 8
• Workloads included Python benchmarks from SeBS, workloads used by recent confidential-serverless work, and Microsoft Azure Functions production traces.The paper describes SeBS as widely used and notes prior evaluations using it,.Source: A. Experimental Setup · p. 8
• REDUCIO uses partial caching; Baseline-OD loads functions on invocation with confidential forking, while Baseline-FC keeps all benchmarked functions cached as an oracle.All three configurations use a TDX CVM; Baseline-OD is similar to systems demonstrated by Wallet and CoFunc.Source: A. Experimental Setup · pp. 8–9

B. Micro-Benchmarks

• Compared to Native, REDUCIO incurs 3.48× overhead for fork+execve and 5.84× for pagefault benchmarks.For a 196MiB program, CoW fork takes ∼10 ms on average; the measured overhead stems from paging SMCs and is amortized at runtime.Source: B. Micro-Benchmarks · p. 9
• Warm startup is often 10–20× faster than Bare and Runtime, and up to 25× faster for functions with large dependency trees.Warm restores a nearly execution-ready snapshot, bypassing the expensive dependency-loading path.Source: B. Micro-Benchmarks · p. 9, Figure 6 · p. 9
• Bare uses ∼2MB, Runtime ∼9MB, and Warm ranges from 25MB to over 700MB depending on application complexity.Bare holds lightweight LibOS kernel states; Runtime retains the initialized language runtime; Warm also captures application-specific runtime state and dependency pages.Source: B. Micro-Benchmarks · p. 9, Figure 6 · p. 9

C. Serverless Workloads Analysis

• Benchmarks used one-hour Azure traces matched by trigger and sampled to assigned CoV; cache management used α=0.996, IAT quantile 0.8, and sliding window 6.The invoker evenly distributed each minute's scheduled calls across that minute.Source: C. Serverless Workloads Analysis · pp. 9–10
• REDUCIO's geometric-mean latency was 384 ms versus 320 ms for Baseline-OD and 322 ms for Baseline-FC, while its p99 was 8385 ms versus 3307 ms and 2687 ms, respectively.REDUCIO incurs more cold starts than the single-cold-start Baseline-OD and full-cache Baseline-FC, so its p99 is worse; its geometric mean is comparatively close to both.Source: C. Serverless Workloads Analysis · p. 10, Figure 8 · p. 10
• Function-balanced geometric means of per-function average end-to-end latency were 1208 ms for REDUCIO, 738 ms for Baseline-OD, and 500 ms for Baseline-FC.Per-function differences track CoV and invocation rate: sparse workloads perform worst with predictive caching, while bursty workloads benefit most.Source: C. Serverless Workloads Analysis · p. 10, Figure 9 · p. 10
• REDUCIO used 58% less memory than Baseline-OD and 64% less than Baseline-FC; those baselines used 2.4x and 2.8x more memory, respectively.The paper attributes the reduction to predictive caching's effect on the size of the memory cache.Source: C. Serverless Workloads Analysis · p. 10
• REDUCIO's function-memory cost was $0.06 versus $0.16 for Benchmark-OD and $0.18 for Benchmark-FC, lowering costs by 2.4x and 2.8x, respectively.The stated x86 cost rate is $0.0000133334 per GB×S.Source: C. Serverless Workloads Analysis · p. 10

X. RELATED WORK

• Hypervisor-layer techniques use VMX for process isolation,,, and trusted hypervisors to harden operating systems.Source: §X · p. 10
• Because confidential-cloud hypervisors are untrusted, hypervisor-based designs are unsuitable; REDUCIO instead aligns with intra-kernel isolation,,,, [32].Source: §X · pp. 10–11
• Intra-kernel monitors use hardware memory-protection primitives such as protection keys and privileged-instruction trapping to create a minimal trusted execution layer.Source: §X · p. 11
• Serverless caching work reduces cold starts through tuned container keep-alive policies, cost-aware Greedy-Dual caching in FaaSCache, and node selection in IceBreaker.Source: §X · p. 11
• Partial-caching systems share initialization state through unikernel snapshots in SEUSS and layer-wise container caching in RainbowCake.Source: §X · p. 11
• REDUCIO extends layered caching and eviction policies into trusted processes, supporting secure fork over layered function-caching states for isolated function processes.Source: §X · p. 11

XI. CONCLUSION

• REDUCIO combines an intra-kernel monitor design with intelligent predictive caching to optimize the memory-latency trade-off in a deployment-friendly confidential serverless platform.The platform is designed from the ground up to optimize this trade-off.Source: §XI · p. 11