Problem Statement

1. Provider 2. Customized Image Execution Integrity Image Integrity 1. VM Image 3. Guest1 3. Guest2 Client Verifiable Resource AccountingChen Chen, Petros Maniatis, Adrian Perrig,Vyas Sekar, AmitVasudevan VM Customizer Motivation Outsourced computation is ubiquitous today (e.g., EC2, Azure, Rackspace). Accounting Integrity Customization Integrity • Potential threats • Attackers may modify/take over instances (e.g., Somorovsky et al. [CCSW ’11]) • Provider may customize VM incorrectly (e.g., Liu and Ding [ICDCS ’11]) • Scheduler vulnerabilities in hypervisors(e.g., Zhou et al. [NCA ’11]) • Provider may inflate consumption (e.g., Liu and Ding [ICDCS ’11]) • Problem Statement • Can a customer verify she received the resources charged by the service provider, while • remaining close to existing deployment models • Ease of Deployment • requiring minimal trust in the operator’s infrastructure • Small TCB • imposing low performance overhead • Efficiency 4. Consumption Report “Did I get to use the resources I was charged for?” Task Lifecycle under VRA • Desired Properties • Image Integrity • Is the provider running the correct VM? • Customization Integrity • Is the customization legitimate? • Execution Integrity • Protect VM contents at runtime • Accounting Integrity • Resources (e.g., cycles) are actually consumed Task Lifecycle 1. Client provides a VM to the provider 2. Cloud provider may customize the VM (e.g., add BIOS, hardware specific optimizations) • VM image attested before launch • Image Integrity • Only stock VM device drivers (currently) • Customization Integrity Cloud Hypervisor Launch image Alibi Layer Measure and verify 3. Cloud provider may multiplex multiple customer VMs on hardware • VM is placed in distinct memory pages • Alibi protects VM memory from hypervisor and other VMs • Execution Integrity • Current Status and Future Directions • Use nested virtualization in KVM as starting point • Adding Alibi features to KVM-nesting • Initial measurements show 7% overhead • Efficient ✓ • Modeling the lifecycle formally • Verify high-level system model • Verify that nested-virtualization implementation matches the model • Current resources: CPU, memory • Support for I/O forthcoming Verifiable Resource Accounting (VRA) High-level Design • Provider hypervisor runs nested • on top of Alibi (our accounting • hypervisor) • Easyto deploy ✓ • Provider hypervisor needs • no modification • Small TCB ✓ • Only Alibi needs to be trusted • Amenable to verification Guest OS1 Guest OS2 4. Cloud provider charges by “usage” for different resources Cloud Hypervisor e.g., Xen time Guest Page 1 Cloud Hypervisor • Alibi uses hardware counters to measure resource usage • Tracks all entry/exits • Accounting Integrity Alibi Layer e.g., minimal KVM Guest2 Guest1 Guest1 Alibi Layer Cloud Hypervisor Guest Page 2 Alibi Layer