The Entropia Virtual Machine for Desktop Grids Brad Calder, Andrew A. Chien, Ju Wang, Don Yang

1
The Entropia Virtual Machine for Desktop
GridsBrad Calder, Andrew A. Chien, Ju Wang, Don
Yang VEE-2005

• Raju Kumar
• CS598C Virtual Machines

2
Introduction

• Desktop Grids
• Entropia Desktop Distributed Computing Grid
  (DCGrid)
• VMs for protection
• How was protection provided earlier ?

3
Overview

• DCGrid
• Goals
• Entropia VM
• Results
• Conclusion

4
DCGrid Overview
5
DCGrid Details

• Physical Node Management
• Resource and Application management
• Resource Scheduling
• Scheduling subjobs
• Job Management
• Decomposes job into subjobs, deploys subjobs and
  accumulates results
• Entropia VM

6
Entropia VM Requirements

• Desktop security
• Clean execution environment
• Unobtrusiveness
• Application security

7
Entropia VM Components
8
Entropia VM Components Contd

• Desktop Controller
• Provides unobtrusiveness
• Sandbox Execution Layer
• Provides all features including unobtrusiveness

9
Wrapping Application

• Wrapped inside EVM using binary modification
• Wrapped interpreters cmd.exe, Perl, JVM
• vm.dll as first entry in import table
• vm.dlls main() dynamically modifies loaded
  binaries and required dlls to intercept system
  calls

10
Validating Binaries

• Checksum of each binary file
• Whether sandboxed
• Integrity
• Configuration file - Checksums for all binaries
• Encrypted and transferred to EVM
• Encryption Key securely communicated
• CreateProcess for code in a new binary file
• Check if registered in configuration file
• Verify checksum

11
Desktop Control

• EVM monitors subjob usage of key resources
• If subjob uses excess resources, subjobs
  processes paused or terminated Acceptable ?
• Unobtrusiveness
• Sandbox Execution Layer resource usage
  restriction per process
• Desktop Controller resource usage restriction
  per subjob
• Processes may belong to EVM or subjob
• Separate resource control using VM Portal

12
EVM Portal Thread

• Invisible Portal thread per Sandboxed application
• Sandboxed application unaware of Portal thread
• Thread listing does not show Portal thread
• Terminating Portal thread not allowed by
  virtualizing relevant system calls
• Heart-beat maintained between Portal thread and
  Desktop Controller
• Loss of heart-beat Portal thread kills the
  sandboxed application
• When is heart-beat lost ?
• One Portal thread for each process
• Terminate
• Pause
• Resume
• On being paused, process memory paged to disk
  security issues ?

13
Enforcing Resource Limits

• If desktop usage is high, Desktop Controller
  pauses subjob (via Portal thread) all or
  nothing solution
• If pausing does not decrease usage, terminate
  is this correct ?
• Different levels of unobtrusiveness
• Highest level pause on mouse movement,
  keyboard-memory-disk I/O-CPU usage of
  non-Entropia processes Background processes in
  Windows ? Distinction between user and system
  processes in Windows ?
• Lowest level ignore keyboard and mouse usage
• Subjobs can run between keystrokes
• Subjob threads are run at lowest priorities

14
Paging Issues

• Subjob requirements
• Specified by user
• Specified by administrator (a typical value)
• Resource Scheduler schedules subjob on a client
  with sufficient resources
• Excessive Paging implications
• Active user
• Incorrect value of subjob requirement
  provided/estimated
• Enforcing Resource Limitation
• Pause/terminate subjob
• Mentions excessive memory usage as well is it
  correct ?
• Examples
• Tracing code Excessive disk usage
• Erroneous process Excessive threads

15
Resource Problems

• Failure reported to
• Resource Scheduler
• DCGrid Administrator
• Job Manager
• Categorization
• Desktop Resource Contention
• Client Black Hole
• Malformed subjob

16
Sandbox Execution Layer

• Goal
• Control subjobs interaction with OS
• Virtualize some OS components
• Subjobs access to all important system APIs is
  mediated

17
OS Interception Layer

• Device Driver intercepts hardware access
• Binary modification virtualize some APIs
• Sandbox Layer is a VMM

18
Device Driver Mediation

• Device Driver Mediation
• Provides Desktop Security feature
• Mediated interfaces cannot be bypassed
• Global mediation overhead
• Hence mediates only interfaces with resource
  access
• Dynamic Binary Modification
• Trampoline approach

19
Design Decisions

• Self-modifying code not allowed
• JIT code for JVM allowed
• Virtualized components
• Files
• Registry
• GUI
• Network
• Threads and Processes

20
Application Security

• Desktop user does not have administrator
  privileges
• Subjob runs in a separate user space
• Device driver provides complete user-space
  isolation
• File encryption
• Tampering detection

21
Results
22
Results
23
Related Work

• Existing desktop grid solutions
• Require changes to code or well-behaved
  assumptions
• Classic VMs
• Obtrusive
• JVM and .NET/MSIL based grids
• Obtrusive, not comprehensive
• VMs for desktop grids
• Obtrusive, heavy
• VMs with resource control
• Assume closed system

24
Conclusion

• EVM provides
• Desktop security
• Clean execution environment
• Unobtrusiveness
• Application security

25

• Thanks !!