Efficient Software-Based Fault IsolationRobert Wahbe Steven LuccoThomas E. AndersonSusan L. GrahamComputer Science DivisionUniversity of CaliforniaBerkeley, CA 94720AbstractOne way to provide fault isolation among cooperatingsoftware modules is to place each in its own addressspace. However, for tightly-coupled modules, this so-lution incurs prohibitive context switch overhead, Inthis paper, we present a software approach to imple-menting fault isolation within a single address space.Our approach has two parts. First, we load the codeand data for a distrusted module into its ownfault do-main, alogically separate portion of the application’saddress space. Second, we modify the object code of adistrusted module to prevent it from writing or jump-ing to an address outside its fault domain. Both thesesoftware operations are portable and programming lan-guage independent.Our approach poses a tradeoff relative to hardwarefault isolation: substantially faster communication be-tween fault domains, at a cost of slightly increasedexecution time for distrusted modules. We demon-strate that for frequently communicating modules, im-plementing fault isolation in software rather than hard-ware can substantially improve end-to-end applicationperformance.This work was supported in part by the National Sci-ence Foundation (CDA-8722788), Defense Advanced ResearchProjects Agency (DARPA) under grant MDA972-92-.J-1028 andcontracts D ABT63-92-C-0026 and NO0600-93-C-2481, the Digi-tal Equipment Corporation (the Systems Research Center andthe External Research Program), and the AT&T Foundation.Anderson was also supported by a National Science FoundationYoung Investigator Award. The content of the paper does notnecessarily reflect the position or the policy of the Governmentand no official endorsement should be inferred.Email: {rwahbe, lUCCO, tea, grahefn}@cs .berkeley. eduPermission to copy w!thout fee all or pa~t of th!s material ISH,ented prov,ded that theGVPIeSW%notmode or d,arr(buceu’ ford!rect commercial advantage, the ACM copyright notice and thetitle of the publ!catlon and Its date appear, and not[ce IS giventhat copying IS by permission of the Association for ComputingMachinery. To copy otherwtse, or to republish, requires a feeandlor specific permtsslon.SIGOPS ‘93/12 /93/N. C., USA0 1993 ACM 0-89791 -632 -S/93 /0012 . ..$l .501 IntroductionApplication programs often achieve extensibility byincorporating independently developed software mod-ules. However, faults in extension code can render asoftware system unreliable, or even dangerous, sincesuch faults could corrupt permanent data. To in-crease the reliability of these applications, an operat-ing system can provide services that prevent faults indistrusted modules from corrupting application data.Suchfault isolation services also facilitate software de-velopment by helping to identify sources of system fail-ure.For example, thePOSTGRES database manager in-cludes an extensible type system [Sto87]. Using thisfacility,POSTGRES queries can refer to general-purposecode thatdefines constructors, destructors, and pred-icates for user-defined data types such as geometricobjects. Without fault isolation, any query that usesextension code could interfere with an unrelated queryor corrupt the database.Similarly, recent operating system research has fo-cused on making it easier for third party vendorsto enhance parts of the operating system. An ex-ample is micro-kernel design; parts of the operat-ing system are implemented as user-level servers thatcan be easily modified or replaced.More gener-ally, several systems have added extension code intothe operating system, for example, the BSD networkpacket filter [M RA87, MJ93], application-specific vir-tual memory management [HC92], and Active Mes-sages [vCGS92]. Among industry systems, Microsoft’sObject Linking and Embedding system [Cla92] canlink together independently developed software mod-ules. Also, the Quark Xprem desktop publishing sys-tem [Dys92] is structured to support incorporation ofgeneral-purpose third party code. As withPO ST GRES,203faults in extension modules can render any of thesesystems unreliable.One way to provide fault isolation among cooperat-ing software modules is to place each in its own addressspace.Using Remote Procedure Call (RPC) [BN84],modules in separate address spaces can call into eachother through a normal procedure call interface. Hard-ware page tables prevent the code in one address spacefrom corrupting the contents of another.Unfortunately, there is a high performance costto providing fault isolation through separate addressspaces. Transferring control across protection bound-aries is expensive,and does not necessarily scalewith improvements in a processor’s integer perfor-mance [ALBL91]. A cross-address-space RPC requiresat least: a trap into the operating system kernel, copy-ing each argument from the caller to the callee, sav-ing and restoring registers, switching hardware ad-dress spaces (on many machines, flushing the transla-tion lookaside buffer), and a trap back to user level.These operations must be repeated upon RPC re-turn. The execution time overhead of an RPC, evenwith a highly optimized implementation, will oftenbe two to three orders of magnitude greater thanthe execution time overhead of a normal procedurecall [BALL90, ALBL91].The goal of our work is to make fault isolation cheapenough that system developers can ignore its perfor-mance effect in choosing which modules to place inseparate fault domains. In many cases where fault iso-lation would be useful, cross-domain procedure callsare frequent yet involve only a moderate amount ofcomputation per call. In this situation it is imprac-tical to isolate each logically separate module withinits own address space, because of the cost of crossinghardware protection boundaries.We propose a software approach to implementingfault isolation within a single address space. Our ap-proach has two parts. First, we load the code and datafor a distrusted module into its ownfault domain, alogically separate portion of the application’s addressspace. A fault domain, in addition to comprising a con-tiguous region of memory within an address space, hasa unique identifier which is used to control its access toprocess resources such as file descriptors. Second, wemodify the object code of a distrusted module to pre-vent it from writing or jumping to an address outsideits fault domain. Program modules isolated in
View Full Document
Unlocking...