Source-linked AI summary
Determinating Timing Channels in Compute Clouds
Amittai Aviram, Sen Hu, Bryan Ford, Ramakrishna Gummadi
TL;DR
Cloud timing channels are pervasive, difficult to detect, and costly to control through resource partitioning. The paper proposes provider-enforced deterministic execution, and preliminary prototype results suggest efficient support for coarse-grained parallel workloads, while high-resolution application timing remains a practical challenge.
Problem
Cloud timing channels let colocated customers infer sensitive information, are difficult for providers to detect, and make resource partitioning incompatible with efficient statistical sharing.
Method
The paper uses provider-enforced deterministic execution to make cloud job outputs depend on explicit inputs rather than internal execution timing.
Results
Coarse-grained parallel benchmarks run nearly as fast and sometimes faster on Determinator than Linux, with md5 achieving more than 2× Linux’s speedup on 12 cores.
Takeaways & Limitations
Deterministic execution can eliminate exploitability of internal cloud timing channels without undermining cloud elasticity through resource partitioning.
Takeaways & Limitations
Application-level software that depends on high-resolution timers remains a pragmatic challenge for timing-channel control mechanisms.
Abstract
from arXiv · showhide
Timing side-channels represent an insidious security challenge for cloud computing, because: (a) massive parallelism in the cloud makes timing channels pervasive and hard to control; (b) timing channels enable one customer to steal information from another without leaving a trail or raising alarms; (c) only the cloud provider can feasibly detect and report such attacks, but the provider's incentives are not to; and (d) resource partitioning schemes for timing channel control undermine statistical sharing efficiency, and, with it, the cloud computing business model. We propose a new approach to timing channel control, using provider-enforced deterministic execution instead of resource partitioning to eliminate timing channels within a shared cloud domain. Provider-enforced determinism prevents execution timing from affecting the results of a compute task, however large or parallel, ensuring that a task's outputs leak no timing information apart from explicit timing inputs and total compute duration. Experiments with a prototype OS for deterministic cloud computing suggest that such an approach may be practical and efficient. The OS supports deterministic versions of familiar APIs such as processes, threads, shared memory, and file systems, and runs coarse-grained parallel tasks as efficiently and scalably as current timing channel-ridden systems.
1. INTRODUCTION
The cloud model amplifies timing-channel risks through pervasive shared-resource signals, difficult detection, and incentives that discourage provider reporting. The paper proposes provider-enforced deterministic execution and presents a prototype suggesting efficient parallel cloud computation.
- 1. INTRODUCTION: Timing attacks in shared clouds can expose one customer’s information to another without reliable detection or alarms.Cloud customers cannot inspect one another’s computations, while provider monitoring may conflict with privacy concerns.
- 1. INTRODUCTION: Massive cloud parallelism creates implicit high-resolution clocks in caches, interconnects, and other shared resources, even when explicit timers are disabled.A thread can itself implement a reference clock, allowing timing attacks to persist despite OS or VM timer virtualization.
- 1. INTRODUCTION: The paper studies internal cloud timing channels independently of specific attacks and seeks controls compatible with cloud requirements.Its focus is the cloud-internal problem rather than side channels arising from client communication with cloud services.
- 1. INTRODUCTION: Provider-enforced deterministic execution aggregates internal timing channels into one controllable boundary channel while preserving flexible resource allocation.The prototype provides preliminary evidence that parallel cloud applications may run efficiently without sacrificing provider flexibility.
2. TIMING CHANNELS IN THE CLOUD
Cloud timing channels arise broadly from parallel shared resources, can turn insider capabilities into outsider attacks, and are difficult for providers to detect. Resource partitioning or scheduling noise limits statistical multiplexing and therefore threatens cloud elasticity.
- 2. TIMING CHANNELS IN THE CLOUD: Parallel hardware creates numerous implicit timing channels: shared caches, interconnects, and other resources can be modulated even without explicit clocks.A busy thread can serve as a high-resolution reference clock through shared-memory activity.
- 2. TIMING CHANNELS IN THE CLOUD: Cloud colocation turns timing attacks from insider threats into outsider threats because providers may run arbitrary customers’ computations on shared machines.The supplied passages frame this as a consequence of the cloud business model’s permissive execution environment.
- 2. TIMING CHANNELS IN THE CLOUD: Timing attacks are unlikely to raise alarms because customers cannot monitor peers and providers may avoid monitoring to protect privacy.Successful attacks leave no compromised protection mechanism for detection, while provider intervention can invite privacy concerns.
- 2. TIMING CHANNELS IN THE CLOUD: A timing-hardened architecture instead dispatches deterministic jobs through gateways and returns results independent of internal timing.The figure caption identifies gateways, deterministic jobs, and outputs dependent only on explicit inputs.
- 2. TIMING CHANNELS IN THE CLOUD: Resource partitioning and injected scheduling noise reduce providers’ ability to statistically multiplex shared hardware efficiently.Without statistical multiplexing, the cloud loses elasticity and approaches private infrastructure hosting.
3. A TIMING-HARDENED CLOUD
The proposed architecture makes cloud jobs deterministic so outputs depend on explicit inputs rather than internal execution timing, while retaining provider-controlled load balancing and shared hardware. It fits large compute-bound workloads most naturally but constrains customer access to fine-grained timing information.
- 3. A TIMING-HARDENED CLOUD: Provider-enforced determinism closes internal timing channels across shared resources, leaving only a controllable timing channel at the cloud boundary.The architecture treats the cloud like a deterministic batch processor whose job outputs are independent of internal operation timing.
- 3. A TIMING-HARDENED CLOUD: Gateways accept explicit job inputs, dispatch work units across servers, and return outputs determined only by those inputs.Internal communication and load-balancing timing may vary, but provider enforcement prevents them from affecting computed results.
- 3. A TIMING-HARDENED CLOUD: Jobs can update persistent customer data transactionally, with writes remaining invisible externally and to other jobs until completion.Each job effectively executes within a provider-enforced transaction.
- 3. A TIMING-HARDENED CLOUD: The provider can statistically multiplex customers’ jobs on shared hardware without static partitioning or scheduling noise injection.Only the job’s total completion time remains externally visible as timing information.
- 3. A TIMING-HARDENED CLOUD: Large parallel compute-bound applications fit the architecture most naturally, while interactive applications may also be feasible through gateway-submitted jobs.The paper identifies scientific computing, rendering, data analysis, and possible interactive web applications as relevant settings.
- 3. A TIMING-HARDENED CLOUD: Customers lose fine-grained internal timing information needed for some profiling and application-specific optimization or load balancing.Development on private or exclusively leased infrastructure can restore access to full machine timing information.
4. A DETERMINISTIC CLOUD OS
Determinator explores provider-enforced deterministic execution for multi-process parallel cloud computations, using familiar abstractions while evaluating efficiency on parallel workloads.
- 4. A DETERMINISTIC CLOUD OS: Determinator enforces determinism on multi-process parallel computations while supporting fork/join synchronization, shared memory, and file systems.The prototype is intended to assess key design challenges for timing-hardened cloud computing.
- 4. A DETERMINISTIC CLOUD OS: Processes execute in parallel but remain internally deterministic because each process has private registers and address space and cannot share physical memory directly.Kernel-controlled interaction occurs through explicit process operations rather than concurrent shared-state execution.
- 4. A DETERMINISTIC CLOUD OS: Deterministic consistency merges child memory changes into the parent without speculation or re-execution, making parallel effects repeatable and predictable.The model is exposed through a thread fork/join API that emulates shared-memory parallelism.
- 4.5 Preliminary Results: Coarse-grained md5, matmult, and qsort benchmarks run nearly as fast or faster on Determinator than Linux, while fine-grained benchmarks incur higher costs.The performance comparison uses deterministic Determinator execution normalized to nondeterministic Ubuntu Linux execution across 1–12 cores.
- 4.5 Preliminary Results: Removing high-resolution timers from Linux reduces Apache throughput by about 20%, suggesting that timer removal is not a simple high-throughput remedy.The web server and TCP/IP stack rely on high-resolution timers for estimating client latency and cache sizes.
- 4.5 Preliminary Results: Application-level dependencies on high-resolution timers remain a pragmatic challenge, while provider-controlled kernels or VMMs can safely use such timers for TCP.The paper leaves further evaluation of these application-level challenges to future work.
5. RELATED WORK
Prior approaches include resource partitioning, deterministic programming, user-level scheduling, and replay systems, but each has important scope or efficiency limitations for cloud-wide enforcement.
- 5. RELATED WORK: Resource partitioning can harden specific timing channels but requires hardware changes, reduces performance, and limits statistical multiplexing.These costs undermine the cloud business model’s reliance on efficient shared-resource use.
- 5. RELATED WORK: Deterministic languages provide programming benefits but cannot run legacy or multi-process parallel code, while user-level schedulers cannot supervise multiple interacting processes.These approaches therefore do not provide general cloud-wide enforcement.
- 5. RELATED WORK: SMP-ReVirt can enforce determinism on multiprocessor guests but replays prior nondeterministic executions and has too high a performance cost for everyday use.The paper contrasts this with executing guests deterministically from the start.
6. CONCLUSION
The paper proposes provider-enforced deterministic execution as a general way to eliminate internal cloud timing-channel exploitability without resource partitioning, while preliminary results support feasibility for some applications.
- 6. CONCLUSION: Provider-enforced determinism eliminates exploitability of internal timing channels independent of the shared resource, without undermining cloud elasticity through resource partitioning.The authors present this as a general approach rather than a channel-specific defense.
- 6. CONCLUSION: Preliminary Determinator results suggest the architecture may be feasible and efficient for some applications, but support for fine-grained, interactive, storage-intensive, and legacy workloads remains unresolved.The conclusion identifies these capabilities as questions for further exploration.