PaperlayerView exact revision on arXiv

Source-linked AI summary

A software approach to defeating side channels in last-level caches

Ziqiao Zhou, Michael K. Reiter, Yinqian Zhang

arXiv:1603.05615v1cs.CR

TL;DR

LLC-based access-driven side channels let security domains leak information through shared caches, creating a problem for isolated cloud tenants. The paper introduces CacheBar, which dynamically separates shared pages and limits cacheability in Linux containers. Formal analysis and experiments show mitigated attacks with modest PaaS overheads, including virtually unnoticeable server-throughput cost.

  • Problem

    Shared LLCs let attackers extract fine-grained victim information across security domains, including cloud tenants, without requiring victim preemption.

  • Method

    CacheBar uses copy-on-access for shared pages and cacheability management to limit attacker-visible LLC lines, implemented for Linux containers.

  • Results

    CacheBar mitigates FLUSH-RELOAD and PRIME-PROBE attacks through formal analysis and empirical evaluation, with modest overheads for PaaS workloads.

  • Takeaways & Limitations

    The software-only design provides a deployable systems-level defense for containerized PaaS environments without relying on hardware redesign.

  • Takeaways & Limitations

    Corner cases around FLUSH-RELOAD and physical-page merging were difficult to evaluate experimentally and were assessed through manual implementation inspection.

Abstract

from arXiv · show

We present a software approach to mitigate access-driven side-channel attacks that leverage last-level caches (LLCs) shared across cores to leak information between security domains (e.g., tenants in a cloud). Our approach dynamically manages physical memory pages shared between security domains to disable sharing of LLC lines, thus preventing "Flush-Reload" side channels via LLCs. It also manages cacheability of memory pages to thwart cross-tenant "Prime-Probe" attacks in LLCs. We have implemented our approach as a memory management subsystem called CacheBar within the Linux kernel to intervene on such side channels across container boundaries, as containers are a common method for enforcing tenant isolation in Platform-as-a-Service (PaaS) clouds. Through formal verification, principled analysis, and empirical evaluation, we show that CacheBar achieves strong security with small performance overheads for PaaS workloads.

1 INTRODUCTION

LLC sharing enables fine-grained side channels across security domains without requiring victim preemption. CacheBar addresses FLUSH-RELOAD and PRIME-PROBE attacks through page isolation and cacheability management in Linux containers.

  • 1 INTRODUCTION: LLC-based attacks can extract fine-grained information without preempting the victim, unlike earlier attacks using per-core caches.FLUSH-RELOAD and PRIME-PROBE attacks exploit LLCs shared across cores.
  • 1 INTRODUCTION: FLUSH-RELOAD requires shared physical pages, which arise from shared libraries, copy-on-write, and memory deduplication.The attacker flushes a cache-line-sized portion of a shared page before reloading it.
  • 1 INTRODUCTION: CacheBar uses copy-on-access to give mutually distrusting domains separate physical-page copies after temporally proximate accesses.When accesses are sufficiently spaced, copies can be deduplicated to recover the original memory footprint.
  • 1 INTRODUCTION: Cacheability management limits the cache lines per set that a malicious tenant can probe, reducing visibility into a victim’s memory demand.The mechanism manages cacheable pages rather than modifying applications or cache hardware.
  • 1 INTRODUCTION: The Linux implementation supports both defenses across containers, targeting Platform-as-a-Service workloads with formal verification and security-performance evaluation.The contributions include model checking, principled parameter derivation, and empirical evaluation.

2 RELATED WORK

Prior defenses modify hardware, applications, protected pages, timing, or scheduling, but can require unavailable hardware changes, application changes, or substantial overheads. The paper motivates a systems-level defense as a more deployable general approach.

  • 2 RELATED WORK: Hardware redesigns may not reach installed systems soon, motivating defenses deployable through existing system software.The paper notes little evidence that mainstream CPU manufacturers will deploy proposed hardware defenses in the foreseeable future.
  • 2 RELATED WORK: Application-level protections can introduce substantial runtime overheads, with overhead increasing as tools become more general.These approaches include limiting sensitive-data branching and application-specific side-channel-free implementations.
  • 2 RELATED WORK: Designated LLC-resident pages can protect contents from PRIME-PROBE and FLUSH-RELOAD, but require developers to identify protected data and modify applications.This application dependence limits the generality of such systems-level approaches.
  • 2 RELATED WORK: Timing-side-channel defenses include fuzzing real-time sources and altering CPU scheduling, but changing timing can interfere with legitimate real-time uses.The paper treats LLC attacks as a particular instance of timing side channels.

3 COPY-ON-ACCESS FOR FLUSH-RELOAD DEFENSE

CacheBar’s copy-on-access mechanism dynamically manages shared physical pages so temporally proximate accesses by different security domains receive separate copies, disrupting FLUSH-RELOAD observation. Its Linux implementation tracks page states, ownership, mappings, and copies, while model checking and implementation refinements address identified leakage paths.

  • 3.1 Design: Copy-on-access prevents FLUSH-RELOAD by copying a shared physical page when another security domain accesses it, making the victim’s subsequent access invisible to the attacker’s copy.The design targets pages shared through mechanisms such as shared libraries, copy-on-write, and memory deduplication.
  • 3.1 Design: CACHEBAR classifies physical pages as UNMAPPED, EXCLUSIVE, SHARED, or ACCESSED and transitions them according to mappings, recent accesses, and domain ownership.An access by another domain to an ACCESSED page allocates an EXCLUSIVE copy, while timers and unmapping drive additional state changes.
  • 3.2 Implementation: All PTEs for SHARED pages receive a reserved COA bit, so the first access faults, clears that bit for the accessing process, and changes the page to ACCESSED.Later accesses by the same domain proceed without faults until another domain accesses the page and triggers copying.
  • 3.2 Implementation: The implementation augments Linux page management with copy tracking, container-aware mapping counters, and ownership metadata to maintain page states and merge duplicated pages.The counter records, for each physical page, how many processes in each container have mapped it; copy lists preserve relationships needed for deduplication.
  • 3.3 Security: The same state transitions make the defense effective against both FLUSH-RELOAD and FLUSH-FLUSH attacks.In the implementation, clflush induces transitions equivalent to those caused by RELOAD.
  • 3.3 Security: Model checking with Spin formally verified the copy-on-access design, while implementation changes enforcing LLC flushes after timer-induced transitions eliminated the leakage found in the initial model.The initial model exposed leaks caused by periodic transitions to SHARED; the refined model revealed no further information leakage.

4 CACHEABILITY MANAGEMENT FOR PRIME-PROBE DEFENSE

CACHEBAR limits PRIME-PROBE leakage by probabilistically reconfiguring each domain’s cache-line budget and enforcing it through page-granular cacheability queues. This restricts observable evictions while balancing security against cache use and performance.

  • 4.1 Design: Probabilistic cache-line budgets cloud the victim demand observed through PRIME-PROBE evictions.An attacker may observe no evictions below a threshold, cannot distinguish sufficiently large victim demands, and cannot tell demand from the victim’s assigned budget.
  • 4.2 Implementation: CACHEBAR enforces each domain’s budget by allowing at most k_i same-color pages to remain domain-cacheable for a cache set.Pages mapping to the same cache set share a color, and only domain-cacheable pages can contribute cache lines in that set.
  • 4.2 Implementation: On a non-cacheable page fault, the handler admits the page, evicts the least-recently-used queued page, flushes its cache lines, and updates translation state.The NC bit controls page faults; removed pages are flushed with clflush, and processor TLBs are flushed for correctness.
  • 4.2 Implementation: A daemon periodically counts PTE ACCESSED bits and reorders each domain’s cacheable queue by recent access count.This maintains the queue’s LRU ordering while coordinating with CACHEBAR’s copy-on-access state management.
  • 4.3 Security: The security analysis models k_i as the number of cache lines available to domain i and optimizes their distributions to balance leakage and cache utilization.Page-fault costs make accessing more than k_i pages impractical for a PRIME-PROBE attacker; the final optimization balances Eqn. 1 and Eqn. 10 using γ, δ, and ε.

5 EVALUATION

CACHEBAR was evaluated against FLUSH-RELOAD and PRIME-PROBE attacks and across several containerized workloads. It prevented clear FLUSH-RELOAD timing separation, reduced PRIME-PROBE classification accuracy, and generally imposed modest performance overheads.

  • 5.2.1 FLUSH-RELOAD Attacks: CACHEBAR made shared and unshared FLUSH-RELOAD reload timings no longer separable, unlike unmodified Linux.The evaluation used 500,000 trials with sender and receiver processes isolated in different containers.
  • 5.3 Performance Evaluation: CACHEBAR imposed minimal throughput impact on Apache+PHP-FPM workloads, while increasing response time by around 20%.Figure 10 compares four- and sixteen-container deployments under SSL requests without connection reuse.
  • 5.3 Performance Evaluation: Across alternative webserver-language combinations, throughput overheads were modest; the worst case was a 25% degradation for Python over Apache+cgi.Other tested combinations experienced substantially smaller degradations.
  • 5.3 Performance Evaluation: Common Faban operations incurred 2%–15% overhead, while rare register, update, and logout operations exceeded 25% overhead.The cited evaluation characterizes the common operations as suffering little responsiveness loss.
  • 5.3 Performance Evaluation: CACHEBAR affected CloudSuite media streaming least among the evaluated applications in both throughput and response time.The workload served 3.1GB static video files at different quality levels.

6 CONCLUSION

The paper presents two software defenses for LLC side channels, formally analyzes them, and evaluates their security and performance in PaaS workloads.

  • CacheBar combines copy-on-access for shared physical pages with cacheability management to defend against FLUSH-RELOAD and PRIME-PROBE attacks.The mechanisms target mutually distrusting security domains and limit the cache lines an attacker can access.
  • Formal analysis using model checking and probabilistic analysis, together with empirical evaluation, confirms that the defenses mitigate LLC side channels.
  • CacheBar imposes modest overheads for PaaS workloads, including a virtually unnoticeable cost on server throughput.

A PLATFORM-AS-A-SERVICE CLOUD

PaaS clouds let users deploy web applications while sharing infrastructure, so providers commonly use multi-tenancy and Linux containers for isolation.

  • PaaS clouds support web applications through programming languages, application middleware, databases, and managed infrastructure.
  • Public PaaS offerings are commonly multi-tenant, with multiple customers sharing a machine and Linux containers providing operating-system-level isolation.
  • The evaluated attacks primarily target web servers because malicious tenants can execute arbitrary code there, while databases and middleware are typically shared but not directly controlled by users.

B EVALUATION OF CACHEBAR’S MEMORY SAVINGS

CACHEBAR’s copy-on-access mechanism uses less memory than disabling cross-container sharing while still isolating containers from FLUSH-RELOAD side channels.

  • The evaluation compares CACHEBAR with unmodified Linux and a nonshared configuration by measuring memory overhead as the number of webserver containers increases.
  • CACHEBAR’s memory overhead remains substantially below that of disabling cross-container sharing, even when server load induces page copying.At maximum throughput load, the overhead approaches but does not exceed that of disabling cross-container sharing.
  • Under modest load, CACHEBAR copies some memory pages and shows a more noticeable increase in container memory usage.
  • Copy-on-access offers a better balance between minimizing memory footprints and isolating containers than simply disabling cross-container sharing.
Loading 1603.05615v1…