Scheduler-based Defenses against Cross-VM Side- channels Venkat(anathan) Varadarajan, Thomas Ristenpart, and Michael Swift 1 D EPARTMENT OF C OMPUTER S CIENCES

VMM Public Clouds (EC2, Azure, Rackspace, …) Interface VM Multi-tenancy Different customers’ virtual machines (VMs) share same server VM 2 VMM VM VMM VM VMM VM Benefits: 1.High resource utilization, 2.Low service cost Benefits: 1.High resource utilization, 2.Low service cost VM

Core Private Caches Branch Predictor Shared Resources and Isolation VM (m-VCPUs) VM (m-VCPUs) Hypervisor Core Private Caches Branch Predictor VM (m-VCPUs) VM (m-VCPUs) VM (m-VCPUs) VM (m-VCPUs) VM (m-VCPUs) VM (m-VCPUs) VM (m-VCPUs) VM (m-VCPUs) VM (m-VCPUs) VM (m-VCPUs) System shared resources (LLC, memory, disk, n/w etc.) via per-core sharing [Zhang et al’12, Ristenpart al’09] via system-level sharing [Yarom & Falkner’14, Varadarajan et al’12] Core Private Caches Branch Predictor 3

Problem: Cache-based Side- channels * 4 VM Time Core: A A V V cache sets cache ways Prime A A Probe Attacker Timing Profile Extract secret information C RYPTO _F UNCTION (s): s  secret bit if (s = 0) { O PERATION _A } if (s = 1) { O PERATION _B } Secret *Zhang, Juels, Reiter, Ristenpart, “Cross-VM Side-channels …”, CCS’12 I-cache

Requirements for Successful Side- channel 5 VM Time Core: A A V V cache sets cache ways Prime A A Probe Attacker Timing Profile Extract secret information C RYPTO _F UNCTION (s): s  secret bit if (s = 0) { O PERATION _A } if (s = 1) { O PERATION _B } Secret *Zhang, Juels, Reiter, Ristenpart, “Cross-VM Side-channels …”, CCS’12 I-cache quick preemption shared resource high-precision timer

Defenses against Side-channels 1.Sharing – Resource Partitioning [NoHype’10] – Specialized Hardware [RPcache’07] – Software-based partitioning [StealthMem’12] 2.Access to high-resolution timers – Reduce resolution [TimeWarp’12] – Removing timing channel [StopWatch’13] 3.Quick cross-VM preemptions – No prior work! 6 No countermeasures deployed by providers!

Our Solution: Soft Isolation Allow sharing but limit frequency of dangerous VM interactions Goals: 1.Secure: Controlled information leakage 2.Commodity: Easy to adopt 3.Efficient: Allow sharing, low overhead 7 … with simple changes to Hypervisor’s CPU scheduler Core (per core state) Core (per core state) Private Caches VM Hypervisor

Rest of the talk … 1.Background: Quick Preemptions & Schedulers 1.Soft-Isolation: Scheduler-based defense 1.Evaluation: Security and Performance 8

Requirement for Quick Preemptions 9 VM V V Time Core: A A cache sets Prime A A Probe cache ways Preemption Interval V V V V Rate of preemption > Rate of event to measure C RYPTO _F UNCTION (s): s  secret bit if (s = 0) { O PERATION _A } if (s = 1) { O PERATION _B } Next subsequent code/task execution … (or noise)

Why do schedulers allow quick preemptions? 10 Prime-probe attacker: Abuses BOOST priority, using interrupts. Throughput- oriented: Benefits from longer scheduler timeslices Latency-oriented: Benefits from quick wakeups, BOOST priority State-of-art CPU schedulers V V Time Core: A A V V A A < 10µs Batch VMs Interactive VMs … Malicious VM

V V Time A A A A Min. runtime (scheduler parameter) Interrupt (boosted) V V V V Soft-Isolation: Ratelimit Preemptions 11 VM Core: Available in Xen (and KVM) ratelimit_us (and sched_min_granularity_ns) Reduces VM-switches  Boosts batch-workload’s performance Minimum RunTime (MRT) guarantee  soft-isolation

MRT Guarantee and Open Questions 12 Time Core: A A V V V V 1.Can MRT defend against Cross-VM Side-channels? (security evaluation) delay 2.Trade-off between security and performance? (performance overhead) MRT value

Xen Version4.2.1 SchedulerCredit Scheduler 1 Configuration (Non-work conserving) 40% cap on DomU VCPUs with equal weight # VMs6 # VCPUs per VM2 Experimental Methodology Two VMs: 1.Attacker 2.Victim 13 MachineIntel Xeon E5645, 2.4GHz, 6 cores, single package Memory Hierarchy Private 32KB L1 (I- and D- Cache), 256KB unified L2, 12MB shared L3 & 16GB DDR3 RAM. Machine Configuration Xen Configuration Core VM Hypervisor Setting similar to public clouds (e.g. EC2)

Security Evaluation : Prime-Probe Timing Profile 14 Idle Victim VM Simple Victim VM Under Zero-MRT Alternating usage patterni-cache access timing

Security Evaluation : Prime-Probe Timing Profile 15 Simple Victim VM Under Zero-MRT Simple Victim VM Under 1ms MRT Side-channel not discernible Alternating usage pattern

Security Evaluation: ElGamal Victim 16 Avg: ops S QUARE M ULT (x, e, N): Let e n,..., e 1 be the bits of e y ← 1 for i = n down to 1 do y ← S QUARE (y) y ← M OD R EDUCE (y, N) if e i = 1 then y ← M ULT (y, x) y ← M OD R EDUCE (y, N) end if end for return y ElGamal Side-channel require multiple preemptions within single iteration for noise-reduction [Zhang et al’12]

MRT Guarantee and Open Questions 17 Time Core: A A V V V V 1.Can MRT defend against Cross-VM Side-channels? (security evaluation) delay 2.Trade-off between security and performance? (performance overhead)

Performance Evaluation: Overall System Performance 18 Core VCPU Hypervisor workload-mix Measured workload: 1.Interactive  memcached, cassandra, etc. and 2.Batch  graph500, specJBB, etc. Competing workloads: microbenchmarks  highly cache-thrashing + (interactive or batch)

Performance Evaluation: Overall System Performance 19 Avg. 95 th Percentile Latency (interactive workloads) Avg. Runtime (batch workloads) At 5ms MRT < 7% overhead

More details in the paper … Per-core State-Cleansing – Interactive VMs may still leak information – MRT + State-cleansing incur low overhead Detailed Performance and Security Analysis – 20+ graphs in the paper 20 It is cheap and easy to deploy!

Conclusion 5ms MRT + selective state-cleansing -known attacks no longer work -negligible overhead -easy to adopt Introduce new scheduler principle -soft-isolation = allow sharing + limit dangerous cross-VM interactions contact: 21