1 First-class Services First-class Services cont. ! Where possible, - PDF document

Introduction Application-Specific Service Technologies ! Leverage commodity systems and generic hardware for for Commodity OSes in Real-Time real-time applications Environments ! Eliminate cost of proprietary systems & custom hardware ! Use a common code base for diverse application Richard West and Gabriel Parmer requirements ! e.g., use existing device drivers Boston University Boston, MA ! BUT …mismatch exists between the requirements of {richwest,gabep1}@cs.bu.edu real-time applications and the service provisions of commodity OSes Computer Science Bridging the `Semantic Gap’ Bridging the `Semantic Gap’ Cont. ! There is a `semantic gap’ between the needs of applications ! Other approaches: and services provided by the system ! Special systems designed for extensibility ! Implementing functionality directly in application processes ! e.g., SPIN, VINO, Exo-/ µ -kernels (Aegis / L4), ! Pros: service/resource isolation (e.g., memory protection) Palladium ! Cons: ! Do not leverage commodity OSes ! Does not guarantee necessary responsiveness ! Do not explicitly consider real-time requirements ! Must leverage system abstractions in complex ways (bounded dispatch latencies and execution) ! Heavyweight scheduling, context-switching and IPC ! RTLinux, RTAI etc overheads ! Do not focus on isolation of service extensions from core kernel Extending Commodity Systems Objectives ! Desktop systems now support QoS-constrained applications ! Aim to extend commodity systems to: ! e.g., Windows Media Player, RealNetworks Real Player ! better meet the service needs of individual applications ! provide first-class application-specific services ! Many such systems are monolithic and not easily extended or only support limited extensibility ! Service extensions must be `QoS safe’: ! e.g., kernel modules for device drivers in Linux ! Need CPU-, memory- and I/O-space protection to ensure ! No support for extensions to override system-wide ! Service isolation service policies ! Predictable and efficient service dispatching ! Bounded execution of services 1

First-class Services First-class Services cont. ! Where possible, have same capabilities as kernel services ! Process, P i , may register a service that runs even when P i is but kernel can still revoke access rights not executing ! Grant access rights to subset of I/O-, memory-space etc ! Like a fast signal handling mechanism ! Dispatch latencies close to those of kernel-level interrupt handlers ! Example usages: ! Avoid potentially unbounded scheduling delays ! Asynchronous I/O ! Bypass kernel scheduling policies ! Resource monitoring / management ! Eliminate process context-switching ! e.g., P i wishes to adjust its CPU usage even when ! Eliminate expensive TLB flushes/reloads not running perhaps because it wasn’t getting enough CPU! Contributions SafeX – Safe Kernel Extensions ! Comparison of kernel- and user-level extension technologies ! Extension architecture for general purpose systems ! “User-level sandboxing” (ULS) versus our prior SafeX work ! Allows applications to customize system behavior ! Show how to achieve low service dispatch latency for ! Extensions run in context of a kernel “bottom half” app-specific services, while ensuring some degree of ! Enables low-latency execution in response to events & CPU-, I/O and memory protection eliminates heavyweight process scheduling SafeX Approach SafeX Features ! Supports compile- and run-time safety checks to: ! Extensions written in Popcorn & compiled into Typed ! Guarantee QoS Assembly Language (TAL) ! TAL adds typing annotations / rules to assembly code ! The QoS contract requirement ! Memory protection: ! Enforce timely & bounded execution of extensions ! Prevents forging (casting) pointers to arbitrary addresses ! The predictability requirement ! Prevents de-allocation of memory until safe ! Guarantee an extension does not improve QoS for one ! CPU protection: application at the cost of another ! The isolation requirement ! Requires resource reservation for extensions ! Guarantee internal state of the system is not jeopardized ! Aborts extensions exceeding reservations ! The integrity requirement ! SafeX decrements a counter at each timer interrupt to enforce extension time limits 2

Synchronization SafeX Service Managers ! Encapsulations of resource management subsystems ! Extensions cannot mask interrupts ! Have policies for providing service of a specific type ! Could violate CPU protection since expiration counter ! e.g., a CPU service manager has policies for CPU cannot decrement scheduling and synchronization ! Problems aborting an extension holding locks ! Run as bottom-half handlers (in Linux) ! e.g., extension runs too long ! Invoked periodically or in response to events within ! May leave resources inaccessible or in wrong state system ! Invoke monitor and handler extensions ! Extensions access shared resources via SafeX interfaces ! Can execute asynchronously to application processes that ensure mutual exclusion ! Apps may influence resource allocations even when not running Kernel Service Managers Attribute Classes & Guards ! Attribute classes store name-value pairs for various app- Kernel timer queue of bottom half (SM) specific service attributes functions ! e.g., priority-value for CPU scheduling get_attributes() Kernel Class 1 Events out Monitors policy-specific ! Access to these classes is granted to the extensions of Class 2 structures processes that acquire permission from the class creators Events in Handlers Class k set_attributes() ! Guard functions are generated by SafeX Attribute Classes Guard fn ! Responsible for mapping values in attribute classes to Kernel Service Manager kernel data structures ! Monitors & handlers operate on attribute classes ! Can enforce range and QoS guarantee checks ! name-value pairs (e.g. process priority – value) ! Service extensions with valid access rights can modify attributes SafeX Interfaces User-Level Sandboxing (ULS) ! SafeX provides get_/set_attribute () interfaces ! Provide “safe” environment for service extensions ! Extensions use these interfaces to update service ! Separate kernel from app-specific code attributes ! Use only page-level hardware protection ! Extensions are not allowed to directly access kernel data ! Can use type-safe languages e.g., Cyclone for memory structures safety of extensions, SFI etc., or require authorization by trusted source ! Interfaces can only be used by extensions having necessary capabilities ! Approach does not require (but may benefit from) special ! Capabilities are type-safe (unforgeable) pointers hardware protection features ! Segmentation ! Interfaces limit global affects of extensions ! Tagged TLBs ! Balance application control over resources with system stability 3

Sandbox Region Shared by Traditional View of Processes Processes P1 P2 Pn P1 P2 Pn Process-private Mapped data . . . . . . address space Process address space User Level Sandbox region (shared virtual address space) Extension for P2 Extension for Pn User Level Kernel Level Kernel Level Kernel events Kernel events make sandbox region user-level accessible ULS Implementation Virtual-to-Physical Memory Mapping ! Modify address spaces of all processes to contain one or Process 1 Physical Memory Process 2 more shared pages of virtual addresses ! Shared pages used for sandbox Private Mapped Data ! Normally inaccessible at user-level address space ! Kernel upcalls toggle sandbox page protection bits & Extension perform TLB invalidate on corresponding page(s) Code Sandbox Sandbox + 4MB public public read-only data ! Current x86 approach area area ! 2x4MB superpages (one data, one code) Mapped Data ! Modified libc to support mmap, brk, shmget etc Protected Protected Extension 4MB ! ELF loader to map code & data into sandbox area area Stacks ! Supports sandboxed threads that can block on syscalls ULS Implementation (2) Experimental Evaluation ! Fast Upcalls ! (a) Inter-Protection Domain Communication ! Leverage SYSEXIT/SYSENTER on x86 ! Look at overheads of IPC between thread pairs ! Support traditional IRET approach also ! Exchange 4-byte messages ! Vary the working set of one thread to assess costs ! Kernel Events ! 1.4GHz P4, patched Linux 2.4.9 kernel ! Generic interface supports delivery of events to specific extensions ! (b) Adaptive CPU service management ! Each extension has its own stack & thread struct ! Aim: to meet the needs of CPU-bound RT tasks under ! Extensions share credentials (including fds) with changing resource demands from a `disturbance’ process creator ! Compare ULS and SafeX to process-based approaches ! Events can be queued ala POSIX.4 signals ! 550 Mhz Pentium III, 256MB RAM, patched 2.4.20 Linux 4