overhead35Weobservethatinordertorendercontrolowhijacksimpossibleitissufcienttoguaranteetheintegrityofcodepointersiethosethatareusedtodeterminethetargetsofindirectcontrolowtransfersindi ID: 141829
Download Pdf The PPT/PDF document "14811th USENIX Symposium on Operating Sy..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
14811th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)USENIX Association overhead[35].Weobservethat,inordertorendercontrol-owhijacksimpossible,itissufcienttoguaran-teetheintegrityofcodepointers,i.e.,thosethatareusedtodeterminethetargetsofindirectcontrol-owtransfers(indirectcalls,indirectjumps,orreturns).Thispaperintroducescode-pointerintegrity(CPI),awaytoenforceprecise,deterministicmemorysafetyforallcodepointersinaprogram.ThekeyideaistosplitprocessmemoryintoasaferegionandaregularregionCPIusesstaticanalysistoidentifythesetofmemoryob-jectsthatmustbeprotectedinordertoguaranteememorysafetyforcodepointers.Thissetincludesallmemoryobjectsthatcontaincodepointersandalldatapointersusedtoaccesscodepointersindirectly.Allobjectsinthesetarethenstoredinthesaferegion,andtheregionisisolatedfromtherestoftheaddressspace(e.g.,viahard-wareprotection).Thesaferegioncanonlybeaccessedviamemoryoperationsthatareprovenatcompiletimetobesafeorthataresafety-checkedatruntime.Thereg-ularregionisjustlikenormalprocessmemory:itcanbeaccessedwithoutruntimechecksand,thus,withnoover-head.Intypicalprograms,theaccessestothesaferegionrepresentonlyasmallfractionofallmemoryaccesses(6.5%ofallpointeroperationsinSPECCPU2006needprotection).Existingmemorysafetytechniquescannotefcientlyprotectonlyasubsetofmemoryobjectsinaprogram,rathertheyrequireinstrumentingdangerouspointeroperations.CPIfullyprotectstheprogramagainstallcontrol-owhijackattacksthatexploitprogrammemorybugs.CPIrequiresnochangestohowprogrammerswritecode,sinceitautomaticallyinstrumentspointeraccessesatcompiletime.CPIachieveslowoverheadbyselectivelyinstrumentingonlythosepointeraccessesthatareneces-saryandsufcienttoformallyguaranteetheintegrityofallcodepointers.TheCPIapproachcanalsobeusedfordata,e.g.,toselectivelyprotectsensitiveinformationliketheprocessUIDsinakernel.Wealsointroducecode-pointerseparation(CPS),are-laxedvariantofCPIthatisbettersuitedforcodewithabundantvirtualfunctionpointers.InCPS,allcodepointersareplacedinthesaferegion,butpointersusedtoaccesscodepointersindirectlyareleftintheregularre-gion(suchaspointerstoC++objectsthatcontainvirtualfunctions).UnlikeCPI,CPSmayallowcertaincontrol-owhijackattacks,butitstilloffersstrongerguaranteesthanCFIandincursnegligibleoverhead.Ourexperimentalevaluationshowsthatourproposedapproachimposessufcientlylowoverheadtobede-ployableinproduction.Forexample,CPSincursanaverageoverheadof1.2%ontheCprogramsinSPECCPU2006and1.9%forallC/C++programs.CPIincursonaverage2.9%overheadfortheCprogramsand8.4%acrossallC/C++SPECCPU2006programs.CPIandCPSareeffective:theyprevent100%oftheattacksintheRIPEbenchmarkandtherecentattacks[19,15,9]thatbypassCFI,ASLR,DEP,andallotherMicrosoftWin-dowsprotections.WecompileandrunwithCPI/CPSacompleteFreeBSDdistributionalongwith100widelyusedpackages,demonstratingthattheapproachisprac-tical.Thispapermakesthefollowingcontributions:Denitionoftwonewprogrampropertiesthatof-ferasecurity-benettoenforcement-costratiosu-periortothestateoftheart:code-pointerin-tegrity(CPI)guaranteescontrolowcannotbehi-jackedviamemorybugs,andcode-pointersepa-ration(CPS)providesstrongersecurityguaranteesthancontrol-owintegritybutatnegligiblecost.Anefcientcompiler-basedimplementationofCPIandCPSforunmodiedC/C++code.TherstpracticalandcompleteOSdistribution(basedonFreeBSD)withfullprotectionbuilt-inagainstcontrol-owhijackattacks.Intherestofthepaperweintroduceourthreatmodel(2),describeCPIandCPS(3),presentourim-plementation(4),evaluateourapproach(5),discussrelatedwork(6),andconclude(7).WeformalizetheCPIenforcementmechanismandprovideasketchofitscorrectnessproofinAppendixA.ThreatModelThispaperisconcernedsolelywithcontrol-owhijackattacks,namelyonesthatgivetheattackercontroloftheinstructionpointer.Thepurposeofthistypeofattackistodivertcontrolowtoalocationthatwouldnototh-erwisebereachableinthatsamecontext,hadthepro-gramnotbeencompromised.Examplesofsuchattacksincludeforcingaprogramtojump(i)toalocationwheretheattackerinjectedshellcode,(ii)tothestartofachainofreturn-orientedprogramfragments(gadgets),or(iii)toafunctionthatperformsanundesirableactioninthegivencontext,suchascallingwithattacker-suppliedarguments.Data-onlyattacks,i.e.,thatmodifyorleakunprotectednon-controldata,areoutofscope.Weassumepowerfulyetrealisticattackercapabilities:fullcontroloverprocessmemory,butnoabilitytomod-ifythecodesegment.Attackerscancarryoutarbitrarymemoryreadsandwritesbyexploitinginput-controlledmemorycorruptionerrorsintheprogram.Theycan-notmodifythecodesegment,becausethecorrespondingpagesaremarkedread-executableandnotwritable,andtheycannotcontroltheprogramloadingprocess.Theseassumptionsensuretheintegrityoftheoriginalprogramcodeinstrumentedatcompiletime,andenablethepro-gramloadertosafelysetuptheisolationbetweenthesafeandregularmemoryregions.Ourassumptionsareconsistentwithpriorworkinthisarea. 2 USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)149 Wenowpresenttheterminologyusedtodescribeourdesign,thendenethecode-pointerintegrityprop-erty(3.1),describethecorrespondingenforcementmechanism(3.2),anddenearelaxedversionthattradessomesecurityguaranteesforperformance(WefurtherformalizetheCPIenforcementmechanismandsketchitscorrectnessproofinAppendixA.Wesayapointerdereferenceisiffthememoryitaccesseslieswithinthetargetobjectonwhichthederef-erencedpointerisbased.Atargetobjectcaneitherbeamemoryobjectoracontrolowdestination.Bydereferencewemeanaccessingthememorytargetedbythepointer,eithertoread/writeit(fordatapointers)ortotransfercontrolowtoitslocation(forcodepointers).memoryobjectisalanguage-specicunitofmemoryallocation,suchasaglobalorlocalvariable,adynami-callyallocatedmemoryblock,orasub-objectofalargermemoryobject(e.g.,aeldina).Memoryobjectscanalsobeprogram-specic,e.g.,whenusingcustommemoryallocators.Acontrolowdestinationisaloca-tioninthecode,suchasthestartofafunctionorareturnlocation.Atargetobjectalwayshasawelldenedlife-time;forexample,freeinganarrayandallocatinganewonewiththesameaddresscreatesadifferentobject.Wesayapointerisbasedonatargetobjectiffthepointerisobtainedatruntimeby(i)allocatingontheheap,(ii)explicitlytakingtheaddressof,ifisallo-catedstatically,suchasalocalorglobalvariable,orisacontrolowtarget(includingreturnlocations,whosead-dressesareimplicitlytakenandstoredonthestackwhencallingafunction),(iii)takingtheaddressofasub-object(e.g.,aeldinthe),or(iv)computingapointerexpression(e.g.,pointerarithmetic,arrayin-dexing,orsimplycopyingapointer)involvingoperandsthatareeitherthemselvesbasedonobjectorarenotpointers.ThisisslightlystricterversionofC99sbasedondenition:weensurethateachpointerisbasedonatmostoneobject.Theexecutionofaprogramisiffallpointerdereferencesintheexecutionaresafe.Apro-gramismemory-safeiffallitspossibleexecutions(forallinputs)arememory-safe.Thisdenitionisconsis-tentwiththestateoftheartforC/C++,suchasSoft-Bounds+CETS[34,35].Precisememorysafetyenforce-ment[34,36,25]tracksthebased-oninformationforeachpointerinaprogram,tocheckthesafetyofeachpointerdereferenceaccordingtothedenitionabove;thedetectionofanunsafedereferenceabortstheprogram.TheCode-PointerIntegrity(CPI)PropertyAprogramexecutionsatisesthecode-pointerintegritypropertyiffallitsdereferencesthateitherdereferenceoraccesssensitivepointersaresafe.Sensitivepointers Figure1:CPIprotectscodepointers3and4andpointers1and2(whichmayaccesspointers3and4indirectly).Pointer2ofmaypointtodifferentobjectsatdifferenttimes.Thepointer5andnon-pointerdatalocationsarenotprotected.codepointersandpointersthatmaylaterbeusedtoac-cesssensitivepointers.Notethatthesensitivepointerdenitionisrecursive,asillustratedinFig.1.Accordingtocase(iv)ofthebased-ondenitionabove,dereferenc-ingapointertoapointerwillcorrespondinglypropagatethebased-oninformation;e.g.,anexpressioncopiestheresultof,whichisapointerbasedontoalocationpointedtoby,andassociatesthebased-onmetadatawiththatlocation.Hence,theintegrityofthebased-onmetadataassociatedwithsensitivepointersrequiresthatpointersusedtoupdatesensitivepointersbesensitiveaswell(wediscussimplicationsofrelaxingthisdenitionin3.3).Thenotionofasensitivepointerisdynamic.Forexample,apointer2inFig.1issensitivewhenitpointsatanothersensitivepointeratruntime,butitisnotsensitivewhenitpointstoaninteger.Amemory-safeprogramexecutiontriviallysatisestheCPIproperty,butmemory-safetyinstrumentationtypicallyhashighruntimeoverhead,e.g.,instate-of-the-artimplementations[35].Ourobservationisthatonlyasmallsubsetofallpointersareresponsibleformakingcontrol-owtransfers,andso,byenforc-ingmemorysafetyonlyforcontrol-sensitivedata(andthusincurringnooverheadforallotherdata),weob-tainimportantsecurityguaranteeswhilekeepingthecostofenforcementlow.Thisisanalogoustothecontrol-plane/data-planeseparationinnetworkroutersandmod-ernservers[5],withCPIensuringthesafetyofdatathatinuences,directlyorindirectly,thecontrolplane.Determiningpreciselythesetofpointersthataresensitivecanonlybedoneatruntime.However,theCPIpropertycanstillbeenforcedusinganyover-approximationofthisset,andsuchover-approximationscanbeobtainedatcompiletime,usingstaticanalysis.TheCPIEnforcementMechanismWenowdescribeawaytoretrottheCPIpropertyintoaprogramusingacombinationofstaticinstrumenta-tionandruntimesupport.Ourapproachconsistsofastaticanalysispassthatidentiesallsensitivepointersinandallinstructionsthatoperateonthem(3.2.1),anpassthatrewritestoprotectallsen-sitivepointers,i.e.,storetheminaseparate,safememoryregionandassociate,propagate,andchecktheirbased- 3 15011th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)USENIX Association onmetadata(3.2.2),andaninstruction-levelmechanismthatpreventsnon-protectedmemoryopera-tionsfromaccessingthesaferegion(3.2.3).Forperfor-mancereasons,wehandlereturnaddressesstoredonthestackseparatelyfromtherestofthecodepointersusingsafestackmechanism(CPIStaticAnalysisWedeterminethesetofsensitivepointersusingtype-basedstaticanalysis:apointerissensitiveifitstypeissensitive.Sensitivetypesare:pointerstofunctions,pointerstosensitivetypes,pointerstocompositetypes(suchasorarray)thatcontainsoneormoremem-bersofsensitivetypes,oruniversalpointers(i.e.,andopaquepointerstoforward-declaredes).Aprogrammercouldadditionallyindicate,ifdesired,othertypestobeconsideredsensitive,suchusedintheFreeBSDkerneltostorepro-cessUIDsandjailinformation.Allcodepointersthatacompilerorruntimecreatesimplicitly(suchasreturnad-dresses,C++virtualtablepointers,andbuffers)aresensitiveaswell.Oncethesetofsensitivepointersisdetermined,weusestaticanalysistondallprograminstructionsthatmanipulatethesepointers.Theseinstructionsincludepointerdereferences,pointerarithmetic,andmemory(de-)allocationoperationsthatcallstoeither(i)corre-spondingstandardlibraryfunctions,(ii)C++\roperators,or(iii)manuallyannotatedcustomallocators.Thederivedsetofsensitivepointersisover-approximate:itmayincludeuniversalpointersthatneverenduppointingtosensitivevaluesatruntime.Forin-stance,theC/C++standardallowspointerstopointtoobjectsofanytype,butsuchpointersarealsousedforCstrings.Asaheuristic,weassumethatthatarepassedtothestandard\fstringmanipulationfunctionsorthatareassignedtopointtostringconstantsarenotuniversal.Neithertheover-approximationnortheheuristicaffectthesecurityguaranteesprovidedbyCPI:over-approximationmerelyintroducesextraover-head,whileheuristicerrorsmayresultinfalseviolationreports(thoughweneverobservedanyinpractice).Memorymanipulationfunctionsfrom\f,suchas,couldintroducealotofoverheadinCPI:theytakearguments,soa\fcompiledwithCPIwouldinstrumentallaccessesinsidethefunctions,regardlessofwhethertheyareoperatingonsensitivedataornot.CPIsstaticanalysisinsteaddetectssuchcasesbyanalyzingtherealtypesoftheargumentspriortobeingcastto,andthesubsequentinstrumentationpasshandlesthemseparatelyusingtype-specicversionsofthecorrespondingmemorymanipulationfunctions.Weaugmentedtype-basedstaticanalysiswithadata-owanalysisthathandlesmostpracticalcasesofunsafepointercastsandcastsbetweenpointersandintegers.Ifavalueisevercasttoasensitivepointertypewithinthefunctionbeinganalyzed,orispassedasanargumentorreturnedtoanotherfunctionwhereitiscasttoasen-sitivepointer,theanalysisconsiderstobesensitiveaswell.Thisanalysismayfailwhenthedataowbetweenanditscasttoasensitivepointertypecannotbefullyre-coveredstatically,whichmightcausefalseviolationre-ports(wehavenotobservedanyduringourevaluation).Suchcastsareacommonproblemforallpointer-basedmemorysafetymechanismsforC/C++thatdonotre-quiresourcecodemodications[34].AkeybenetofCPIisitsselectivity:thenumberofpointeroperationsdeemedtobesensitiveisasmallfrac-tionofallpointeroperationsinaprogram.Asweshow5,forSPECCPU2006,theCPItype-basedanaly-sisidentiesforinstrumentation65%ofallpointerac-cesses;thistranslatesintoareductionofperformanceoverheadof1644relativetofullmemorysafety.Nevertheless,westillthinkCPIcanbenetfrommoresophisticatedanalyses.CPIcanleverageanykindofstaticanalysis,aslongasitprovidesanover-approximatesetofsensitivepointers.Forinstance,whenextendingCPItoalsoprotectselectnon-code-pointerdata,wethinkDSA[27,28]couldprovemoreeffective.CPIInstrumentationCPIinstrumentsaprograminorderto(i)ensurethatallsensitivepointersarestoredinasaferegion,(ii)createandpropagatemetadataforsuchpointersatruntime,and(iii)checkthemetadataondereferencesofsuchpointers.Intermsofmemorylayout,CPIintroducesasafere-gioninadditiontotheregularmemoryregion(Fig.2).Storagespaceforsensitivepointersisallocatedinboththesaferegion(thesafepointerstore)andtheregularregion(asusual);oneofthetwocopiesalwaysremainsunused.Thisisnecessaryforuniversalpointers(e.g.,),whichcouldbestoredineitherregiondepend-ingonwhethertheyaresensitiveatruntimeornot,andalsohelpstoavoidsomecompatibilityissuesthatarisefromthechangeinmemorylayout.Theaddressinregu-larmemoryisusedasanoffsettotolookupthevalueofasensitivepointerinthesafepointerstore.safepointerstoremapstheaddressofsensi-tivepointer,asallocatedintheregularregion,tothevalueofandassociatedmetadata.Themetadatafordescribesthetargetobjectonwhichisbased:lowerandupperaddressboundsoftheobject,andatemporalid(seeFig.2).ThelayoutofthesafepointerstoreissimilartometadatastorageinSoftBounds+CETS[35],exceptthatCPIstoresthevalueofinthesafepointerstore.Combinedwiththeisolationofthesafere-gion(3.2.3),thisallowsCPItoguaranteefullmemorysafetyofallsensitivepointerswithouthavingtoinstru- 4 USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)151 Figure2:CPImemorylayout:Thesaferegioncontainsthesafepointerstoreandthesafestacks.Thelocationofasensitivepointerontheleft(shaded)remainsunused,whilethevalueofthispointeranditsmetadataarestoredinthesafepointerstore.Thesafestackshavecorrespondingstacksinregularmemorytoallocateunsafestackobjects.mentallpointeroperations.Theinstrumentationstepchangesinstructionsthatop-erateonsensitivepointers,asfoundbyCPIsstaticanal-ysis,tocreateandpropagatethemetadatadirectlyfol-lowingthebased-ondenitionin3.1.Instructionsthatexplicitlytakeaddressesofastaticallyallocatedmemoryobjectorafunction,allocateanewobjectontheheap,ortakeanaddressofasub-objectareinstrumentedtocreatemetadatathatdescribethecorrespondingobject.Instruc-tionsthatcomputepointerexpressionsareinstrumentedtopropagatethemetadataaccordingly.InstructionsthatloadorstoresensitivepointerstomemoryarereplacedwithCPIintrinsicinstructions(3.2.3)thatloadorstoreboththepointervaluesandtheirmetadatafrom/tothesafepointerstore.Inprinciple,callandreturninstruc-tionsalsostoreandloadcodepointers,andsowouldneedtobeinstrumented,butweinsteadprotectreturnaddressesusingasafestack(Everydereferenceofasensitivepointerisinstru-mentedtocheckatruntimewhetheritissafe,usingthemetadataassociatedwiththepointerbeingdereferenced.Togetherwiththerestrictedaccesstothesaferegion,thisresultsinprecisememorysafetyforallsensitivepointers.Universalpointers()arestoredinei-therthesafepointerstoreortheregularregion,de-pendingonwhethertheyaresensitiveatruntimeornot.CPIinstrumentsinstructionsthatcastfromnon-sensitivetouniversalpointertypestoassignspecialinvalidmetadata(e.g.,withlowerboundgreaterthantheupperbound)fortheresultinguniversalpointers.Thesepoint-ers,asaresult,wouldneverbeallowedtoaccessthesaferegion.CPIintrinsicsforuniversalpointerswouldonlystoreapointerinthesafepointerstoreifithadvalidmetadata,andonlyloaditfromthesafepointerstoreifitcontainedvalidmetadataforthatpointer;otherwise,theywouldstore/loadfromtheregularregion.CPIcanbeconguredtosimultaneouslystorepro-tectedpointersinboththesafepointerstoreandregu-larregions,andcheckwhethertheymatchwhenloadingthem.Inthisdebugmode,CPIdetectsalltohi-jackcontrolowusingnon-protectedpointererrors;inthedefaultmode,suchattemptsaresilentlyprevented.Thisdebugmodealsoprovidesbettercompatibilitywithnon-instrumentedcodethatmayreadprotectedpointers(forexample,callbackaddresses)butnotwritethem.Moderncompilerscontainpowerfulstaticanalysispassesthatcanoftenprovestaticallythatcertainmemoryaccessesarealwayssafe.TheCPIinstrumentationpassprecedescompileroptimizations,thusallowingthemtopotentiallyoptimizeawaysomeoftheinsertedcheckswhilepreservingthesecurityguarantees.IsolatingtheSafeRegionThesaferegioncanonlybeaccessedviaCPIintrinsicinstructions,andtheyproperlyhandlepointermetadataandthesafestack(3.2.4).Themechanismforachievingthisisolationisarchitecture-dependent.Onx86-32,werelyonhardwaresegmentprotection.Wemakethesaferegionaccessiblethroughadedicatedsegmentregister,whichisotherwiseunused,andcon-gurelimitsforallothersegmentregisterstomaketheregioninaccessiblethroughthem.TheCPIintrinsicsarethenturnedintocodethatusesthededicatedregisterandensuresthatnootherinstructionsintheprogramusethatregister.Thesegmentregistersareconguredbythepro-gramloader,whoseintegrityweassumeinourthreatmodel;wealsopreventtheprogramfromreconguringthesegmentregistersviasystemcalls.Noneofthepro-gramsweevaluatedusethesegmentregisters.Onx86-64,CPIreliesonthefactthatnoaddressespointingintothesaferegionareeverstoredintheregularregion.Thisarchitecturenolongerenforcesthesegmentlimits,howeveritstillprovidestwosegmentregisterswithcongurablebaseaddresses.Similarlytox86-32,weuseoneoftheseregisterstopointtothesaferegion,however,wechoosethebaseaddressofthesaferegionatrandomandrelyonpreventingaccesstoitthroughinformationhiding.UnlikeclassicASLRthough,ourhidingisleak-proof:sincetheobjectsinthesaferegionareindexedbyaddressesallocatedforthemintheregu-larregion,noaddressespointingintothesaferegionareeverstoredinregularmemoryatanytimeduringexecu-tion.The48-bitaddressspaceofmodernx86-64CPUsmakesguessingthesaferegionaddressimpractical,be-causemostfailedguessingattemptswouldcrashthepro-gram,andsuchfrequentcrashescaneasilybedetectedbyothermeans.Otherarchitecturescoulduserandomization-basedprotectionaswell,orrelyonprecisesoftwarefaultisola-tion(SFI)[11].SFIrequiresthatallmemoryoperationsinaprogramareinstrumented,buttheinstrumentationislightweight:itcouldbeassmallasasingletionifthesaferegionoccupiestheentireupperhalfoftheaddressspaceofaprocess.Inourexperiments,theadditionaloverheadintroducedbySFIwaslessthan5%.Sincesensitivepointersformasmallfractionofalldatastoredinmemory,thesafepointerstoreishighlysparse.Tosavememory,itcanbeorganizedasahashta- 5 ①②③④⑤⑥ySa f④tB⑤⑥yua nd+CETt[④⑤34t,5T⑤⑥yua①②③④⑤⑥④ySaf3t[④⑤34t,5T⑤⑥yua 3t[④⑤]②LE4④2⑤34②2④⑤⑥yua 0tAN④⑤W⑤NBB④2⑤W⑤A② ④2⑤W⑤L③ ⑥④ytB②u⑤⑥④ySaf n:+ ns+ 15211th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)USENIX Association ble,amulti-levellookuptable,orasasimplearrayrely-ingonthesparseaddressspacesupportoftheunderlyingOS.Weimplementedandevaluatedallthreeversions,andwediscussthefastestchoiceinInthefuture,weplantoleverageIntelMPX[24]forimplementingthesaferegion,asdescribedinTheSafeStackCPItreatsthestackspecially,inordertoreduceperfor-manceoverheadandcomplexity.Thisisprimarilybe-causethestackhostsvaluesthatareaccessedfrequently,suchasreturnaddressesthatarecodepointersaccessedoneveryfunctioncall,aswellasspilledregisters(tempo-raryvaluesthatdonottinregistersandcompilersstoreonthestack).Furthermore,trackingwhichoftheseval-ueswillendupatruntimeinmemory(andthusneedtobeprotected)vs.inregistersisdifcult,asthecompilerdecideswhichregisterstospillonlyduringlatestagesofcodegeneration,longafterCPIsinstrumentationpass.Akeyobservationisthatthesafetyofmostaccessestostackobjectscanbecheckedstaticallyduringcom-pilation,hencesuchaccessesrequirenoruntimechecksormetadata.Moststackframescontainonlymemoryobjectsthatareaccessedexclusivelywithinthecorre-spondingfunctionandonlythroughthestackpointerregisterwithaconstantoffset.Wethereforeplaceallsuchproven-safeobjectsontoasafestacklocatedinthesaferegion.Thesafestackcanbeaccessedwithoutanychecks.Forfunctionsthathavememoryobjectsontheirstackthatdorequirechecks(e.g.,arraysorobjectswhoseaddressispassedtootherfunctions),weallocateseparatestackframesintheregularmemoryregion.Inourexpe-rience,lessthan25%offunctionsneedsuchadditionalstackframes(seeTable2).Furthermore,thisfractionismuchsmalleramongshortfunctions,forwhichtheover-headofsettinguptheextrastackframeisnon-negligible.Thesafestackmechanismconsistsofastaticanalysispass,aninstrumentationpass,andruntimesupport.Theanalysispassidenties,foreveryfunction,whichobjectsinitsstackframeareguaranteedtobeaccessedsafelyandcanthusbeplacedonthesafestack;returnaddressesandspilledregistersalwayssatisfythiscriterion.Fortheobjectsthatdonotsatisfythiscriterion,theinstrumen-tationpassinsertscodethatallocatesastackframefortheseobjectsontheregularstack.Theruntimesupportallocatesregularstacksforeachthreadandcanbeimple-mentedeitheraspartofthethreadinglibrary,aswedidonFreeBSD,orbyinterceptingthreadcreate/destroy,aswedidonLinux.CPIstorestheregularstackpointerin-sidethethreadcontrolblock,whichispointedtobyoneofthesegmentregistersandcanthusbeaccessedwithasinglememoryreadorwrite.Oursafestacklayoutissimilartodoublestackap-proachesinASR[6]andXFI[18],whichmaintainaseparatestackforarraysandvariableswhoseaddressesaretaken.However,weusethesafestacktoenforcetheCPIpropertyinsteadofimplementingsoftwarefaultisolation.Thesafestackisalsocomparabletolanguage-basedapproacheslikeCyclone[25]orCCured[36]thatsimplyallocatetheseobjectsontheheap,butourap-proachhassignicantlylowerperformanceoverhead.ComparedtoashadowstacklikeinCFI[1],whichduplicatesreturninstructionpointersoutsideoftheat-tackersaccess,theCPIsafestackpresentsseveralad-vantages:(i)allreturninstructionpointersandmostlocalvariablesareprotected,whereasashadowstackonlypro-tectsreturninstructionpointers;(ii)thesafestackiscom-patiblewithuninstrumentedcodethatusesjusttheregu-larstack,anditdirectlysupportsexceptions,tailcalls,andsignalhandlers;(iii)thesafestackhasnear-zeroperformanceoverhead(5.2),becauseonlyahandfuloffunctionsrequireextrastackframes,whileashadowstackallocatesashadowframeforeveryfunctioncall.ThesafestackcanbeemployedindependentlyfromCPI,andwebelieveitcanreplacestackcookies[14]inmoderncompilers.Byprovidingpreciseprotectionofallreturnaddresses(whicharethetargetofROPat-tackstoday),spilledregisters,andsomelocalvariables,thesafestackprovidessubstantiallystrongersecuritythanstackcookies,whileincurringequalorlowerper-formanceoverheadanddeploymentcomplexity.Code-PointerSeparation(CPS)Thecode-pointerseparationpropertytradessomeofCPIssecurityguaranteesforreducedruntimeoverhead.ThisisparticularlyrelevanttoC++programswithmanyvirtualfunctions,wherethefractionofsensitivepoint-ersinstrumentedbyCPIcanbecomehigh,sinceeverypointertoanobjectthatcontainsvirtualfunctionsissen-sitive.Wefoundthat,onaverage,CPSreducesoverheadby4(from8.4%forCPIdownto1.9%forCPS),andinsomecasesbyasmuchasanorderofmagnitude.CPSfurtherrestrictsthesetofprotectedpointerstocodepointersonly,leavingpointersthatpointtocodepointersuninstrumented.Weadditionallyrestrictthedenitionofbased-onbyrequiringthatacodepointerbebasedonlyonacontrolowdestination.Thisrestrictionpreventsattackersfromforgingacodepointerfromavalueofanothertype,butstillallowsthemtotricktheprogramintoreadingorupdatingwrongcodepointers.CPSisenforcedsimilarlytoCPI,except(i)forthecriteriausedtoidentifysensitivepointersduringstaticanalysis,and(ii)thatCPSdoesnotneedanymetadata.Control-owdestinations(pointedtobycodepointers)donothavebounds,becausethepointervaluemustal-waysmatchthedestinationexactly,hencenoneedforboundsmetadata.Furthermore,theyaretypicallystatic,hencedonotneedtemporalmetadataeither(thereare 6 USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)153 afewrareexceptions,likeunloadingasharedlibrary,whicharehandledseparately).Thisreducesthesizeofthesaferegionandthenumberofmemoryaccesseswhenloadingorstoringcodepointers.Ifthesaferegionisorganizedasasimplearray,aCPS-instrumentedpro-gramperformsessentiallythesamenumberofmemoryaccesseswhenloadingorstoringcodepointersasanon-instrumentedone;theonlydifferenceisthatthepointersarebeingloadedorstoredfromthesafepointerstorein-steadoftheiroriginallocation(universalpointerloadorstoreinstructionsstillintroduceoneextramemoryaccesspersuchinstruction).Asaresult,CPScanbeenforcedwithlowperformanceoverhead.CPSguaranteesthat(i)codepointerscanonlybestoredtoormodiedinmemorybycodepointerstoreinstructions,and(ii)codepointerscanonlybeloadedbycodepointerloadinstructionsfrommemorylocationstowhichpreviouslyacodepointerstoreinstructionstoredavalue.Combinedwiththesafestack,CPSpreciselyprotectsreturnaddresses.CPSisstrongerthanmostCFIimplementations[1,54,53],whichallowanyvulnerableinstructioninaprogramtomodifyanycodepointer;theyonlycheckthatthevalueofacodepointer(whenusedinanindirectcontroltransfer)pointstoafunctiondenedinaprogram(forfunctionpointers)ordirectlyfollowsacallinstruction(forreturnaddresses).CPSguarantee(i)aboverestrictstheattacksurface,whileguarantee(ii)restrictstheattackersexibilitybylimitingthesetoflo-cationstowhichthecontrolcanberedirectedthesetincludesonlyentrypointsoffunctionswhoseaddresseswereexplicitlytakenbytheprogram.Toillustratethisdifference,considerthecaseofthePerlinterpreter,whichimplementsitsopcodedispatchbyrepresentinginternallyaPerlprogramasasequenceoffunctionpointerstoopcodehandlersandthencallinginitsmainexecutionloopthesefunctionpointersonebyone.CFIstaticallyapproximatesthesetoflegitimatecontrol-owtargets,whichinthiscasewouldincludeallpossiblePerlopcodes.CPShoweverpermitsonlycallsthroughfunctionpointersthatareactuallyassigned.ThismeansthatamemorybuginaCFI-protectedPerlin-terpretermaypermitanattackertodivertcontrolowandexecuteanyPerlopcode,whereasinaCPS-protectedPerlinterpretertheattackercouldatmostexecuteanop-codethatexistsintherunningPerlprogram.CPSprovidesstrongcontrol-owintegrityguaranteesandincurslowoverhead(5).WefoundthatitpreventsallrecentattacksdesignedtobypassCFI[19,15,9].WeconsiderCPStobeasolidalternativetoCPIinthosecaseswhenCPIs(alreadylow)overheadseemstoohigh.WeimplementedaCPI/CPSenforcementtoolforC/C++,calledLevee,ontopoftheLLVM3.3com-pilerinfrastructure[30],withmodicationstoLLVMli-braries,thecompiler,andtheTouseLevee,onejustneedstopassadditionalagstothecompilertoenableCPI(),CPS(),orsafe-stackprotection().LeveeworksonunmodiedprogramsandsupportsLinux,FreeBSD,andMacOSXinboth32-bitand64-bitmodes.Leveecanbedownloadedfromtheprojecthome-,andweplantopushourchangestotheupstreamLLVM.Analysisandinstrumentationpasses:Weimple-mentedthestaticanalysisandinstrumentationforCPIastwoLLVMpasses,directlyfollowingthedesign3.2.1and3.2.2.TheLLVMpassesoperateontheLLVMintermediaterepresentation(IR),whichisalow-levelstrongly-typedlanguage-independentprogramrep-resentationtailoredforstaticanalysesandoptimizationpurposes.TheLLVMIRisgeneratedfromtheC/C++sourcecodeby,whichpreservesmostofthetypeinformationthatisrequiredbyouranalysis,withafewcornercases.Forexample,incertaincases,notpreservetheoriginaltypesofpointersthatarecast\rwhenpassingthemasanargumenttoorsimilarfunctions,whichisrequiredfortherelatedoptimizationsdiscussedin3.2.2.TheIRalsodoesnotdistinguishbetween\r\f\rbothas\r),butthisinformationisrequiredforourstringpointersdetectionheuristic.Weaugmentedtoal-wayspreservesuchtypeinformationasLLVMmetadata.Safestackinstrumentationpass:Thesafestackinstru-mentationtargetsfunctionsthatcontainon-stackmem-oryobjectsthatcannotbeputonthesafestack.Forsuchfunctions,itallocatesastackframeontheunsafestackandrelocatescorrespondingvariablestothatframe.Giventhatmostofthefunctionsdonotneedanun-safestack,Leveeusestheusualstackpointer(reg-isteronx86-64)asthesafestackpointer,andstorestheunsafestackpointerinthethreadcontrolblock,whichisaccessibledirectlythroughoneofthesegmentregisters.Whenneeded,theunsafestackpointerisloadedintoanIRlocalvalue,andLeveereliesontheLLVMregisterallocatortopicktheregisterfortheunsafestackpointer.LeveeexplicitlyencodesunsafestackoperationsasIRinstructionsthatmanipulateanunsafestackpointer;itleavesalloperationsthatuseasafestackintact,lettingtheLLVMcodegeneratormanagethem.Leveeperformsthesechangesasalaststepbeforecodegeneration(di-rectlyreplacingLLVMsstack-cookieprotectionpass),thusensuringthatitoperatesonthenalstacklayout.Certainlow-levelfunctionsmodifythestackpointerdirectly.Thesefunctionsinclude\n\nexceptionhandlingfunctions(whichstore/loadthestackpointer),andthreadcreate/destroyfunctions,whichal-locate/freestacksforthreads.OnFreeBSDweprovide 7 15411th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)USENIX Association full-systemCPI,sowedirectlymodiedthesefunctionstosupportthedualstacks.OnLinux,ourinstrumentationpassndsandexceptionhandlingfunc-tionsintheprogramandinsertsrequiredinstrumentationattheircallsites,whilethreadcreate/destroyfunctionsareinterceptedandhandledbytheLeveeruntime.Runtimesupportlibrary:Mostoftheinstrumentationbytheabovepassesareaddedasintrinsicfunctioncalls,suchas ,whichareim-plementedbyLeveesruntimesupportlibrary(apart).Thisdesigncleanlyseparatesthesafepointerstoreimplementationfromtheinstrumentationpass.Inordertoavoidtheoverheadassociatedwithex-trafunctioncalls,weensurethatsomeoftheruntimesupportfunctionsarealwaysinlined.WecompilethesefunctionsintoLLVMbitcodeandinstructtolinkthisbitcodeintoeveryobjectleitcompiles.Functionsthatarecalledrarely(e.g., \r,calledwhenaCPIviolationisdetected)areneverinlined,inordertoreducetheinstructioncachefootprintoftheinstrumentation.Weimplementedandbenchmarkedseveralversionsofthesafepointerstoremapinourruntimesupportlibrary:asimplearray,atwo-levellookuptable,andahashtable.ThearrayimplementationreliesonthesparseaddressspacesupportoftheunderlyingOS.InitiallywefoundittoperformpoorlyonLinux,duetomanypagefaults(es-peciallyatstartup)andadditionalTLBpressure.Switch-ingtosuperpages(2MBonLinux)madethissimpleta-blethefastestimplementationofthethree.Binarylevelfunctionality:Somecodepointersinbina-riesaregeneratedbythecompilerand/orlinker,andcan-notbeprotectedontheIRlevel.Suchpointersincludetheonesinjumptables,exceptionhandlertables,andtheglobaloffsettable.BoundschecksforthejumptablesandtheexceptionhandlertablesarealreadygeneratedbyLLVManyway,andthetablesthemselvesareplacedinread-onlymemory,hencecannotbeoverwritten.Werelyonthestandardloaderssupportforread-onlyglobaloffsettables,usingtheexisting \bTheCPIdesigndescribedin3includesbothspatialandtemporalmemorysafetyenforcementforsensitivepointers,howeverourcurrentprototypeim-plementsspatialmemorysafetyonly.Itcanbeeasilyextendedtoenforcetemporalsafetybydirectlyapplyingthetechniquedescribedin[35]forsensitivepointers.LeveecurrentlysupportsLinux,FreeBSDandMacOSuser-spaceapplications.WebelieveLeveecanbeportedtoprotectOSkernelsaswell.Relatedtechnicalchallengesincludeintegrationwiththekernelmemorymanagementsubsystemandhandlingofinlineassembly.CPIandCPSrequireinstrumentingallcodethatma-nipulatessensitivepointers;non-instrumentedcodecancauseunnecessaryaborts.Non-instrumentedcodecouldcomefromexternallibrariescompiledwithoutLevee,in-lineassembly,ordynamicallygeneratedcode.Leveecanbeconguredtosimultaneouslystoresensitivepointersinboththesafeandtheregularregions,inwhichcasenon-instrumentedcodeworksneaslongasitonlyreadssensitivepointersbutdoesntwritethem.Inlineassemblyanddynamicallygeneratedcodecanstillupdatesensitivepointersifinstrumentedwithappro-priatecallstotheLeveeruntime,eithermanuallybyaprogrammerordirectlybythecodegenerator.Dynamicallygeneratedcode(e.g.,forJITcompila-tion)posesanadditionalproblem:runningthegeneratedcoderequiresmakingwritablepagesexecutable,whichviolatesourthreatmodel(thisisacommonproblemformostcontrol-owintegritymechanisms).Onesolutionistousehardwareorsoftwareisolationmechanismstoisolatethecodegeneratorfromthecodeitgenerates.Sensitivedataprotection:EventhoughthemainfocusofCPIiscontrol-owhijackprotection,thesametech-niquecanbeappliedtoprotectothertypesofsensitivedata.Leveecantreatprogrammer-annotateddatatypesassensitiveandprotectthemjustlikecodepointers.CPIcouldalsoselectivelyprotectindividualprogramvari-ables(asopposedtotypes),howeveritwouldrequirere-placingthetype-basedstaticanalysisdescribedinwithdata-basedpoints-toanalysissuchasDSA[27,28].FutureMPX-basedimplementation:Intelannouncedahardwareextension,IntelMPX,tobeusedforhardware-enforcedmemorysafety[23].Itisproposedasatestingtool,probablyduetotheassociatedoverhead;nooverheadnumbersareavailableatthetimeofwriting.WebelieveMPX(orsimilar)hardwarecanbere-purposedtoenforceCPIwithlowerperformanceover-headthanourexistingsoftware-onlyimplementation.MPXprovidesspecialregisterstostoreboundsalongwithinstructionstocheckthem,andahardware-basedimplementationofapointermetadatastore(analogoustothesafepointerstoreinourdesign),organizedasatwo-levellookuptable.OurimplementationcanbeadaptedtousethesefacilitiesonceMPX-enabledhardwarebe-comesavailable.Webelievethatahardware-basedCPIimplementationcanreducetheoverheadofasoftware-onlyCPIinmuchthesamewayasHardBound[16]orWatchdog[33]reducedtheoverheadofSoftBound.AdoptingMPXforCPImightrequireimplementingmetadataloadinglogicinsoftware.LikeCPI,MPXalsostoresthepointervaluetogetherwiththemetadata.How-ever,beingatestingtool,MPXchoosescompatibilitywithnon-instrumentedcodeoversecurityguarantees:itusesthestoredpointervaluetocheckwhethertheorigi-nalpointerwasmodiedbynon-instrumentedcodeand,ifyes,resetstheboundsto.Incontrast,CPIsguar-anteesdependonpreventinganynon-instrumentedcodefromevermodifyingsensitivepointervalues. 8 USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)155 EvaluationInthissectionweevaluateLeveeseffectiveness,ef-ciency,andpracticality.WeexperimentallyshowthatbothCPIandCPSare100%effectiveonRIPE,themostrecentattackbenchmarkweareawareof(5.1).Weeval-uatetheefciencyofCPI,CPS,andthesafestackonSPECCPU2006,andndaverageoverheadsof8.4%,1.9%,and0%respectively(5.2).Todemonstrateprac-ticality,werecompilewithCPI/CPS/safestackthebaseFreeBSDplusover100packagesandreportresultsonseveralbenchmarks(WeranourexperimentsonanIntelXeonE5-2697with24cores@2.7GHzin64-bitmodewith512GBRAM.TheSPECbenchmarksranonanUbuntuPrecisePangolin(12.04LTS),andtheFreeBSDbenchmarksinaKVM-basedVMonthissamesystem.EffectivenessontheRIPEBenchmarkWedescribedin3thesecurityguaranteesprovidedbyCPI,CPS,andthesafestackbasedontheirdesign;toexperimentallyevaluatetheireffectiveness,weusetheRIPE[49]benchmark.Thisisaprogramwithmanydif-ferentsecurityvulnerabilitiesandasetof850exploitsthatattempttoperformcontrol-owhijackattacksontheprogramusingvarioustechniques.Leveedeterministicallypreventsallattacks,bothinCPSandCPImode;whenusingonlythesafestack,itpreventsallstack-basedattacks.OnvanillaUbuntu6.06,whichhasnobuilt-indefensemechanisms,833848ex-ploitssucceedwhenLeveeisnotused(somesucceedprobabilistically,hencetherange).Onnewersystems,fewerexploitssucceed,duetobuilt-inprotectionmech-anisms,changesintherun-timelayout,andcompatibil-ityissueswiththeRIPEbenchmark.OnvanillaUbuntu13.10,withallprotections(DEP,ASLR,stackcookies)disabled,197205exploitssucceed.Withallprotectionsenabled,4349succeed.WithCPSorCPI,nonedo.TheRIPEbenchmarkonlyevaluatestheeffectivenessofpreventingexistingattacks;aswearguedin3andaccordingtotheproofoutlinedinAppendixA,CPIren-dersall(knownandunknown)memorycorruption-basedcontrol-owhijackattacksimpossible.EfciencyonSPECCPU2006BenchmarksInthissectionweevaluatetheruntimeoverheadofCPI,CPS,andthesafestack.WereportnumbersonallSPECCPU2006benchmarkswritteninCandC++(ourpro-totypedoesnothandleFortran).Theresultsaresum-marizedinTable1andpresentedindetailinFig.3.WealsocompareLeveetotworelatedapproaches,Soft-Bound[34]andcontrol-owintegrity[1,54,53].performswellformostCbenchmarks,howeveritcanincurhigheroverheadforprogramswritteninC++.Thisoverheadiscausedbyabundantuseofpointersto Figure3:LeveeperformanceforSPECCPU2006,underthreecongurations:fullCPI,CPSonly,andsafestackonly. SafeStackCPSCPI Average(C/C++) 0.0%1.9%8.4%Median(C/C++) 0.0%0.4%0.4%Maximum(C/C++) 4.1%17.2%44.2% Average(Conly) -0.4%1.2%2.9%Median(Conly) -0.3%0.5%0.7%Maximum(Conly) 4.1%13.3%16.3%Table1:SummaryofSPECCPU2006performanceoverheads.C++objectsthatcontainvirtualfunctiontablessuchpointersaresensitiveforCPI,andsoalloperationsonthemareinstrumented.Samereasonholdsfor:itembedsfunctionpointersinsomeofitsdatastructuresandthenusespointerstothesestructuresfrequently.Thenext-mostimportantsourceofoverheadarememorymanipulationfunctions,like.Whenourstaticanalysiscannotprovethatacalltosuchafunctionusesasargumentsonlypointerstonon-sensitivedata,Leveereplacesthecallwithonetoacustomversionofanequivalentfunctionthatchecksthesafepointerstoreforeachupdated/copiedword,whichintroducesoverhead.Weexpecttoremovesomeofthisoverheadusingimprovedstaticanalysisandheuristics.averages1.21.8%overhead,andexceeds5%ononlytwobenchmarks,.Thefor-merisduetothelargenumberofvirtualfunctioncallsoccurringatruntime,whilethelatteriscausedbyaspecicwayinwhichimplementsitsopcodedis-patch:itinternallyrepresentsaprogramasasequenceoffunctionpointerstoopcodehandlers,anditsmainexecu-tionloopcallsthesefunctionpointersoneaftertheother.Mostotherinterpretersuseaforopcodedispatch.Safestackprovidedasurprise:in9cases(outof 9 15611th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)USENIX Association 19),itimprovesperformanceinsteadofhurtingit;inonecase(),theimprovementisashighas4.2%,morethantheoverheadincurredbyCPIandCPS.Thisisbecauseobjectsthatendupbeingmovedtotheregular(unsafe)stackareusuallylargearraysorvariablesthatareusedthroughmultiplestackframes.Movingsuchobjectsawayfromthesafestackincreasesthelocalityoffrequentlyaccessedvaluesonthestack,suchasCPUregistervaluestemporarilystoredonthestack,returnad-dresses,andsmalllocalvariables.Thesafestackoverheadexceeds1%inonlythree,and.Westudiedthedisassemblyofthemostfrequentlyexecutedfunc-tionsthatuseunsafestackframesintheseprogramsandfoundthatsomeoftheoverheadiscausedbyinefcienthandlingoftheunsafestackpointerbyLLVMsregisterallocator.Insteadofkeepingthispointerinasingleregis-terandusingitasabaseforallunsafestackaccesses,theprogramkeepsmovingtheunsafestackpointerbetweendifferentregistersandoftenspillsittothe(safe)stack.Webelievethiscanberesolvedbymakingtheregisterallocatoralgorithmawareoftheunsafestackpointer.Incontrasttothesafestack,stackcookiesdeployedtodayhaveanoverheadofupto5%,andofferstrictlyweakerprotectionthanoursafestackimplementation.Thedatastructuresusedforthesafestackandthesafememoryregionresultinmemoryoverheadcomparedtoaprogramwithoutprotection.Wemeasurethememoryoverheadwhenusingeitherasimplearrayorahashta-ble.ForSPECCPU2006themedianmemoryoverheadforthesafestackis0.1%;forCPStheoverheadis2.1%forthehashtableand5.6%forthearray;andforCPItheoverheadis13.9%forthehashtableand105%forthearray.Wedidnotoptimizethememoryoverheadyetandbelieveitcanbeimprovedinfutureprototypes.InTable2weshowcompilationstatisticsforLevee.Therstcolumnshowsthatonlyasmallfractionofallfunctionsrequireanunsafestackframe,conrmingourhypothesisfrom3.2.4.Theothertwocolumnscon-rmthekeypremisesbehindourapproach,namelythatCPIrequiresmuchlessinstrumentationthanfullmemorysafety,andCPSneedsmuchlessinstrumentationthanCPI.ThenumbersalsocorrelatewithFig.3.ComparisontoSoftBound:WecomparewithSoft-Bound[34]ontheSPECbenchmarks.Wecannotfairlyreusethenumbersfrom[34],becausetheyarebasedonanolderversionofSPEC.InTable3wereportnumbersforthefourC/C++SPECbenchmarksthatcancompilewiththecurrentversionofSoftBound.ThiscomparisonconrmsourhypothesisthatCPIrequiressignicantlyloweroverheadcomparedtofullmemorysafety.Theoretically,CPIsuffersfromthesamecompatibil-ityissues(e.g.,handlingunsafepointercasts)aspointer-basedmemorysafety.Inpractice,suchissuesarise UStackCPSCPI 400 perlbench 15.0%1.0%13.8% bzip2 27.2%1.3%1.9% gcc 19.9%0.3%6.0% mcf 50.0%0.5%0.7% milc 50.9%0.1%0.7% namd 75.8%0.6%1.1% gobmk 10.3%0.1%0.4% dealII 12.3%6.6%13.3% soplex 9.5%4.0%2.5% povray 26.8%0.8%4.7% hmmer 13.6%0.2%2.0% sjeng 50.0%0.1%0.1% libquantum 28.5%0.4%2.3% h264ref 20.5%1.5%2.8% lbm 16.6%0.6%1.5% omnetpp 6.9%10.5%36.6% astar 9.0%0.1%3.2% sphinx3 19.7%0.1%4.6% xalancbmk 17.5%17.5%27.1%Table2:CompilationstatisticsforLevee:FNUStacklistswhatfractionoffunctionsneedanunsafestackframe;MOCPSCPIshowthefractionofmemoryoperationsinstrumentedforCPSandCPI,respectively. SafeStackCPSCPISoftBound 401 bzip2 0.3%1.2%2.8%90.2% dealII 0.8%-0.2%3.7%60.2% sjeng 0.3%1.8%2.6%79.0% h264ref 0.9%5.5%5.8%249.4%Table3:OverheadofLeveeandSoftBoundonSPECprogramsthatcompileandrunerrors-freewithSoftBound.muchlessfrequentlyforCPI,becauseCPIinstrumentsmuchfewerpointers.ManyoftheSPECbenchmarkseitherdontcompileorterminatewithanerrorwhenin-strumetedbySoftBound,whichillustratesthepracticalimpactofthisdifference.Comparisontocontrol-owintegrity(CFI):Theav-erageoverheadforcompiler-enforcedCFIis21%forasubsetoftheSPECCPU2000benchmarks[1]and5-6%forMCFI[39](withoutstackpointerintegrity).CC-FIR[53]reportsanoverheadof3.6%,andbinCFI[54]reports8.54%forSPECCPU2006toenforceaweakCFIpropertywithgloballymergedtargetsets.WIT[3],asource-basedmechanismthatenforcesbothCFIandwriteintegrityprotection,has10%overheadAtlessthan2%,CPShasthelowestoverheadamongallexistingCFIsolutions,whileprovidingstrongerpro-tectionguarantees.Also,CPIsoverheadisbestedonlybyCCFIR.However,unlikeanyCFImechanism,CPIguaranteestheimpossibilityofanycontrol-owhijackattackbasedonmemorycorruptions.Incontrast,there Wewereunabletondopen-sourceimplementationsofcompiler-basedCFI,sowecanonlycomparetopublishedoverheadnumbers. 10 USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)157 Figure4:PerformanceoverheadsonFreeBSD(Phoronix).existsuccessfulattacksagainstCFI[19,15,9].WhileneitheroftheseattacksarepossibleagainstCPIbycon-struction,wefoundthat,inpractice,neitherofthemwouldworkagainstCPSeither.Wefurtherdiscusscon-ceptualdifferencesbetweenCFIandCPIinCaseStudy:ASafeFreeBSDDistributionHavingshownthatLeveeisbotheffectiveandefcient,wenowevaluatethefeasibilityofusingLeveetoprotectanentireoperatingsystemdistribution,namelyFreeBSD10.Werebuiltthebasesystembaselibraries,devel-opmenttools,andserviceslikemorethan100packages(including)infourcongurations:CPI,CPS,SafeStack,andvanilla.FreeBSD10usesLLVM/asitsdefaultcompiler,whilesomecorecomponentsofLinux)cannotbebuiltwithyet.WeintegratedtheCPIruntimedirectlyintotheClibraryandthethread-inglibrary.Wehavenotyetportedtheruntimetokernelspace,sotheOSkernelremaineduninstrumented.WeevaluatedtheperformanceofthesystemusingthePhoronixtestsuite[41],awidelyusedcomprehensivebenchmarkingplatformforoperatingsystems.WechosetheserversettingandexcludedbenchmarksmarkedasunsupportedorthatdonotcompileorrunonrecentFreeBSDversions.AllbenchmarksthatcompiledandworkedonvanillaFreeBSDalsocompiledandworkedintheCPI,CPSandSafeStackversions.Fig.4showstheoverheadofCPI,CPSandthesafe-stackversionscomparedtothevanillaversion.TheresultsareconsistentwiththeSPECresultspresented5.2.ThePhoronixbenchmarksexerciselargepartsofthesystemandsomeofthemaremulti-threaded,whichintroducessignicantvarianceintheresults,especiallywhenrunonmodernhardware.AsFig.4shows,formanybenchmarkstheoverheadsofCPSandthesafestackarewithinthemeasurementerror. SafeStackCPSCPI Staticpage 1.7%8.9%16.9%Wsgitestpage 1.0%4.0%15.3%Dynamicpage 1.4%15.9%138.8%Table4:Throughputbenchmarkforwebserverstack(FreeBSD+Apache+SQLite+mod wsgi+Python+Django).WealsoevaluatedarealisticusagemodeloftheFreeBSDsystemasawebserver.WeinstalledMezza-nine,acontentmanagementsystembasedonDjango,whichusesPython,SQLite,Apache,andmod wsgi.WeusedtheApachetooltobenchmarkthethroughputofthewebserver.TheresultsaresummarizedinTable4.TheCPIoverheadforadynamicpagegeneratedbyPythoncodeismuchlargerthenweexpected,butcon-sistentwithsuspiciouslyhighoverheadofthebenchmarkinFig.4.WethinkitmightbecausedbytheuseofsomeCconstructsinthePythoninterpreterthatarenotyethandledwellbyouroptimizationheuristics,e.g.,emulatingC++inheritanceinC.Webelievetheper-formancemightbeimprovedinthiscasebyextendingtheheuristicstorecognizesuchCconstructs.RelatedWorkAvarietyofdefensemechanismshavebeenproposedto-datetoanswertheincreasingchallengeofcontrol-owhijackattacks.Fig.5comparesthedesignofthedifferentprotectionapproachestoourapproach.Enforcingmemorysafetyensuresthatnodanglingorout-of-boundspointerscanbereadorwrittenbytheap-plication,thuspreventingtheattackinitsrststep.Cy-clone[25]andCCured[36]extendCwithasafetypesystemtoenforcememorysafetyfeatures.Theseap-proachesfacetheproblemthatthereisalarge(unported)legacycodebase.Incontrast,CPIandCPSbothworkforunmodiedC/C++code.SoftBound[34]withitsCETS[35]extensionenforcesmemorysafetyatthecostof2slowdown.Toolswithlessover-head,likeBBC[4],onlyapproximatememorysafety.LBC[20]andAddressSanitizer[43]detectcontinu-ousbufferoverowsand(probabilistically)indexinger-rors,butcanbebypassedbyanattackerwhoavoidstheredzonesplacedaroundobjects.Writeintegritytesting(WIT)[3]providesspatialmemorysafetybyrestrictingpointerwritesaccordingtopoints-tosetsobtainedbyanover-approximatestaticanalysis(andisthereforelimitedbythestaticanalysis).Othertechniques[17,2]enforcetype-safememoryreusetomitigateattacksthatexploittemporalerrors(useafterfrees).CPIbydesignenforcesspatialandtemporalmemorysafetyforasubsetofdata(codepointers)inStep2ofFig.5.OurLeveeprototypecurrentlyenforcesspatialmemorysafetyandmaybeextendedtoenforcetemporalmemorysafetyaswell(e.g.,howCETSextendsSoft- 11 15811th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)USENIX Association ①②②③④⑤⑥y②SaftBaSt②unS④d③+CyET②Bay⑥③[[⑥④B+②tB[34[B,⑥dC5③④⑤y]②③④⑤⑥y①Saf③tyS⑤ftB⑤und+CETS①[34,①35]BBC①[4],①LBC①[20],①ASAN①[43],①W T①[3]LSyN⑤:①sub-⑤bj③cts,①⑥③ads①n⑤t①p⑥⑤t③ct③dN⑤:①p⑥⑤t③cts①⑥③d①z⑤n③s①⑤nlyN⑤:①⑤v③⑥-app⑥⑤xi④at③①valid①s③ts116%110%23%2B0S3fBC+②St⑥A+②SNtC②uW②dCy⑥,Bt⑤ CP ①CPSSaf③①StackLSyN⑤:①valid①c⑤d③①pt⑥s.①int③⑥chang③abl③N⑤:①p⑥③cis③①⑥③tu⑥n①p⑥⑤t③cti⑤n①⑤nly8.4%1.9%~0%Rand⑤④izati⑤nASLR①[40],①ASLP①[26]P⑤intGua⑥d①[13]DSR①[6]NOP①ins③⑥ti⑤n①[21]N⑤:①vuln③⑥abl③①t⑤①inf⑤⑥④ati⑤n①l③aksN⑤:①vuln③⑥abl③①t⑤①inf⑤⑥④ati⑤n①l③aksN⑤:①vuln③⑥abl③①t⑤①inf⑤⑥④ati⑤n①l③aksN⑤:①vuln③⑥abl③①t⑤①inf⑤⑥④ati⑤n①l③aks~10%10%20%C⑤nt⑥⑤l-Fl⑤w① nt③g⑥ityStack①c⑤⑤ki③sCF ①[1]W T①(CF ①pa⑥t)①[3]DF ①[10]N⑤:①p⑥⑤babilistic①⑥③tu⑥n①p⑥⑤t③cti⑤n①⑤nlyN⑤:①⑤v③⑥-app⑥⑤xi④at③①valid①s③tsN⑤:①⑤v③⑥-app⑥⑤xi④at③①valid①s③tsN⑤:①⑤v③⑥-app⑥⑤xi④at③①valid①s③ts~2%20%104%N⑤n-Ex③cutabl③①DataHW①(NX①bit)SW①(Ex③c①Shi③ld,①PaX)N⑤:①c⑤d③①⑥③us③①attacksN⑤:①c⑤d③①⑥③us③①attacksf③w①%High-l③v③l①p⑤lici③sSandb⑤xing①(SF )ACLsCapabiliti③s s⑤lati⑤n①⑤nly s⑤lati⑤n①⑤nly s⑤lati⑤n①⑤nlyva⑥i③sva⑥i③sva⑥i③s C⑤⑥⑥upt①data①p⑤int③⑥ nB0C4u⑥③⑥④B0S⑥aBC+②St⑥: t⑤①add⑥③ss①⑤f①gadg③t/sh③llc⑤d③ Ex③cut③①inj③ct③d①sh③llc⑤d③ Ex③c.①availabl③①gadg③ts/func.-s C⑤nt⑥⑤l-fl⑤whijack Us③①p⑤int③⑥①by①indi⑥③ct①call/ju④p Us③①p⑤int③⑥①by①⑥③tu⑥n①inst⑥ucti⑤n①sNb⑥BsStdS③0 Figure5:Summaryofcontrol-owhijackdefensemechanismsalignedwithindividualstepsthatarenecessaryforasuccessfulattack.Thegureontheleftisasimpliedversionofthecompletememorycorruptiondiagramin[46].Bound).WebelieveCPIisthersttostopallcontrol-owhijackattacksatthisstep.Randomizationtechniques,likeASLR[40]andASLP[26],mitigateattacksbyrestrictingtheattackersknowledgeofthememorylayoutoftheapplicationinStep3.PointGuard[13]andDSR[7](whichissimilartoprobabilisticWIT)randomizethedatarepresentationbyencryptingpointervalues,butfacecompatibilityprob-lems.Softwarediversity[21]allowsne-grained,per-instancecoderandomization.Randomizationtechniquesaredefeatedbyinformationleaksthrough,e.g.,memorycorruptionbugs[45]orsidechannelattacks[22].Control-owintegrity[1]ensuresthatthetargetsofallindirectcontrol-owtransferspointtovalidcodelo-cationsinStep4.AllCFIsolutionsrelyonstaticallypre-computedcontext-insensitivesetsofvalidcontrol-owtargetlocations.ManypracticalCFIsolutionssim-plyincludeeveryfunctioninaprograminthesetofvalidtargets[53,54,29,47].Evenifprecisestaticanalysiswasbefeasible,CFIcouldnotguaranteepro-tectionagainstallcontrol-owhijackattacks,butrathermerelyrestrictthesetsofpotentialhijacktargets.In-deed,recentresults[19,15,9]showthatmanyexist-ingCFIsolutionscanbebypassedinaprincipledway.CFI+SFI[52],Strato[51]andMIPS[38]enforceanevenmorerelaxed,staticallydenedCFIpropertyinordertoenforcesoftware-basedfaultisolation(SFI).CCFI[31]encryptscodepointersinmemoryandprovidessecu-rityguaranteesclosetoCPS.Data-owbasedtechniqueslikedata-owintegrity(DFI)[10]ordynamictaintanal-ysis(DTA)[42]canenforcethattheusedcodepointerwasnotsetbyanunrelatedinstructionortountrusteddata,respectively.Thesetechniquesmaymisssomeat-tacksorcausefalsepositives,andhavehigherperfor-mancecoststhanCPIandCPS.Stackcookies,CFI,DFI,andDTAprotectcontrol-transferinstructionsbydetect-ingillegalmodicationofthecodepointerwheneveritisused,whileCPIprotectstheloadandstoreofacodepointer,thuspreventingthecorruptionintherstplace.CPIprovidespreciseandprovablesecurityguarantees.InStep5,theexecutionofinjectedcodeispreventedbyenforcingthenon-executable(NX)datapolicy,butcode-reuseattacksremainpossible.Highlevelpolicies,e.g.,restrictingtheallowedsys-temcallsofanapplication,limitthepoweroftheat-tackereveninthepresenceofasuccessfulcontrol-owhijackattackinStep6.Softwarefaultisolation(SFI)techniques[32,18,11,50,52]restrictindirectcontrol-owtransfersandmemoryaccessestopartofthead-dressspace,enforcingasandboxthatcontainstheattack.SFIpreventsanattackfromescapingthesandboxandal-lowstheenforcementofahigh-levelpolicy,whileCPIenforcesthecontrol-owinsidetheapplication.Thispaperdescribescode-pointerintegrity(CPI),awaytoprotectsystemsagainstallcontrol-owhijacksthatexploitmemorybugs,andcode-pointerseparation,are-laxedformofCPIthatstillprovidesstrongguarantees.Thekeyideaistoselectivelyprovidefullmemorysafetyforjustasubsetofaprogramspointers,namelycodepointers.Weimplementedourapproachandshowedthatitiseffective,efcient,andpractical.Givenitsadvan-tageoussecurity-to-overheadratio,webelieveourap-proachmarksasteptowarddeterministicallysecuresys-temsthatarefullyimmunetocontrol-owhijackattacks.AcknowledgmentsWethanktheanonymousreviewersandourshepherdJunfengYangfortheirvaluableinput.Wearegrate-fultoMartinAbadi,HerbertBos,MiguelCastro,VijayDSilva,UlfarErlingsson,JohannesKinder,PerLarsen,JimLarus,SantoshNagarakatte,andJonasWagnerfor USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)159 AtomicTypesPointerTypesStructTypesLHSExpressionsRHSExpressionsFigure6:ThesubsetofCusedinAppendixA;denoteslocalstaticallytypedvariables,structureelds,integers,andfunctionsfromapre-denedset.theirvaluablefeedbackanddiscussionsonearlierver-sionsofthepaper.ThisworkwassupportedbyERCStartingGrantNo.278656,aMicrosoftResearchPhDfellowship,agiftfromGoogle,DARPAawardHR0011-12-2-005,NSFgrantsCNS-0831298andCNS-1319137,andAFOSRFA9550-09-1-0539.FormalModelofCPIThissectionpresentsaformalmodelandoperationalse-manticsoftheCPIpropertyandasketchofitscorrect-nessproof.DuetothesizeandcomplexityofC/C++specications,wefocusonasmallsubsetofCthatillus-tratesthemostimportantfeaturesofCPI.Duetospacelimitationswefocusonspatialmemorysafety.WebuildupontheformalizationofspatialmemorysafetyinSoft-Bound[34],reusethesamenotation,andextendittosupportapplyingspatialmemorysafetytoasubsetofmemorylocations.Theformalismcanbeeasilyextendedtoprovidetemporalmemorysafety,directlyapplyingtheCETS[35]mechanismtothesafememoryregionofthemodel.Fig.6givesthesyntaxrulesoftheCsubsetweconsiderinthissection.AllvalidprogramsmustalsopasstypecheckingasspeciedbytheCstandard.Wedenetheruntimeenvironmentofaprogramasatriple,wheremapsvariableidentierstotheirrespectiveatomictypesandaddresses,aregu-larmemorymapsaddressestovalues(denotedasandcalledregularvalues),andasafememoryaddressestovalueswithboundsinformation(denotedasandcalledsafevalues)oraspecialmarkerTheboundsinformationspeciesthelowest()andthehighest()addressofthecorrespondingmemoryobject.usethesameaddressing,butmightcontaindistinctvaluesforthesameaddress.Somelocations(e.g.,oftype)canstoreeithersafeorregularvalueandareresolvedtoeitheratruntime.Theruntimeprovidestheusualsetofmemoryoper-ationsfor,assummarizedinTable5.modelsstandardmemory,whereasstoresvalueswithboundsandhasaspecialmarkerforabsentlocations,similarlytothememoryinSoftBounds[34]formaliza-tion.Weassumethememoryoperationsfollowthestan-dardbehaviorofread/write/mallocoperationsinallother Semantics uMul returnMuluMulv setMulvsMsl ,ifisallocated;return ,ifisallocated; donothingotherwise ,ifisallocated; donothingotherwise Ei allocateamemoryobjectofsizeinboth (atthesameaddress);failwhenoutofmemoryTable5:MemoryOperationsinCPIeldsofsFigure7:ThedecisioncriterionforprotectingtypesinCPIrespects,e.g.,readreturnsthevaluepreviouslywrittentothesamelocation,mallocallocatesaregionofmemorythatisdisjointwithanyotherallocatedregion,etc..EnforcingtheCPIpropertywithlowperformanceoverheadrequiresplacingmostvariablesin,whilestillensuringthatallpointersthatrequireprotectionatruntimeaccordingtotheCPIpropertyareplacedin.Inthisformalization,werelyontype-basedstaticanalysisasdenedbythecriterion,shownonFig.7.Wesayatypeissensitiveiff.SettingtotrueforalltypeswouldmaketheCPIoperationalsemanticsequivalenttotheonepro-videdbySoftBoundandwouldensurefullspatialmem-orysafetyofallmemoryoperationsinaprogram.Theclassicationprovidedbytherionisstaticandonlydetermineswhichoperationsinaprogramtoinstrument.Expressionsofsensitivetypescouldevaluatetobothsafeorregularvaluesatruntime,whereasexpressionsofregulartypesalwaysevaluatetoregularvalues.Inparticular,accordingtoFig.7,issensitiveand,hence,inagreementwiththeCspeci-cation,valuesofthattypecanholdanypointervalueatruntime,eithersafeorregular.WeextendtheSoftBounddenitionoftheresultofanoperationtodifferentiatebetweensafeandregularvaluesandleft-hand-sidelocations:arethesafe(withboundsinforma-tion)and,respectively,regularvaluesthatresultfromarighthandsideexpression,arelocationsthatre-sultfromasafeandregularleft-hand-sideexpression,isaresultofasuccessfulcommand,andareerrorcodes.Weassumethatalloperationalse-manticsrulesofthelanguagepropagatetheseerrorcodesuptotheendoftheprogramunchanged.Usingtheabovedenitions,wenowformalizetheop- 13 16011th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)USENIX Association erationalsemanticsofCPIthroughthreeclassesofrules.rulesspec-ifyhowlefthandsideexpressionsareevaluatedtoasafeorregularlocations,respectively.Therulesspecifyhowrighthandsideexpressionsareevaluatedtosafevalueswithboundsorregularvalues,respectively,possiblymodify-ingtheenvironmentthroughmemoryallocation(turningitfrom).Finally,therulesspec-ifyhowcommandsareexecuted,possiblymodifyingtheenvironment,wherecanbeeitheroranerrorcode.WeonlypresenttherulesthataremostimportantfortheCPIsemantics,omittingrulesthatsimplyrepresentthestandardsemanticsoftheClanguage.Boundsinformationisinitiallyassignedwhenallocat-ingamemoryobjectorwhentakingafunctionsaddress(bothoperationsalwaysreturnsafevalues): E&frlllErhsiEilE Takingtheaddressofavariablefromifitstypeissensitiveisanalogous.Structureeldaccessoperationseithernarrowboundsinformationaccordingly,orstripitifthetypeoftheaccessedeldisregular.Typecastingresultsinasafevalueiffasafevalueiscasttoasensitivetype: EarhsrvbeEaErhslvbe:a EarhsrvEErhslv:a Thenextsetofrulesdescribesmemoryoperations(pointerdereferenceandassignment)onsensitivetypesandsafevalues: Elhslls:aaElhslls:asEMslslbelbea ElhslaElhslls:aErhsrvbe:aEMsEMslsvbe TheserulesareidenticaltothecorrespondingrulesofSoftBound[34]andensurefullspatialmemorysafetyofallmemoryobjectsinthesafememory.Onlyoperationsmatchingthoserulesareallowedtoaccesssafememory.Inparticular,anyattemptstoaccessvaluesofsensi-tivetypesthroughregularlvaluescauseaborts: ElhslaElhsllu:a Notethattheserulescanonlybeinvokedifthevalueofthesensitivetypewasobtainedbycastingfromaregu-lartypeusingacorrespondingtypecastingrule.Leveerelaxesthecastingrulestoallowpropagationofboundsinformationthroughcertainright-hand-sideexpressionsofregulartypes.Thisrelaxationhandlesmostcommoncasesofunsafetypecasting;itaffectsperformance(in-ducingmoreinstrumentation)butnotcorrectness.Somesensitivetypes(onlyinoursimpliedversionofC),canholdregularvaluesatruntime.Forex-ample,avariableoftypecanrstbeusedtostoreafunctionpointerandsubsequentlyre-usedtostoreanvalue.Thefollowingruleshandlesuchcases: Elhsllu:aaElhslls:aErhsrv:aEMuEMulvEMsEMsl Memoryoperationsonregulartypesalwaysaccessregularmemory,withoutanyadditionalruntimechecks,followingtheunsafememorysemanticsofC. Elhsllu:aaElhsll:aErhsrv:aEMuEMulv Theseaccessestoregularmemorycangooutofboundsbut,giventhatoperationscanonlymodifyregularmemory,itdoesnotviolatememorysafetyofthesafememory.Finally,indirectcallsabortifthefunctionpointerbe-ingcalledisnotsafe: Elhsc\r\fEElhsrlu:f NotethattheoperationalrulesforvaluesthataresafeatruntimearefullyequivalenttothecorrespondingSoft-Boundrules[34]and,therefore,satisfytheSoftBoundsafetyinvariantwhich,asprovenin[34],ensuresmem-orysafetyforthesevalues.Accordingtothecriterionandthesafelocationdereferenceandindirectfunctioncallrulesabove,alldereferencesofpointersthatrequireprotectionaccordingtotheCPIpropertyareal-wayssafeatruntime,ortheprogramaborts.Therefore,theoperationalsemanticsdenedaboveindeedensuretheCPIpropertyasdenedin 14 USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)161 ReferencesencesM.Abadi,M.Budiu,U.Erlingsson,andJ.Ligatti.Control-owintegrity.InACMConf.onComputerandCommunicationSecurity,2005.2005.P.Akritidis.Cling:Amemoryallocatortomitigatedanglingpointers.InUSENIXSecuritySymposiumSymposiumP.Akritidis,C.Cadar,C.Raiciu,M.Costa,andM.Castro.PreventingmemoryerrorexploitswithWIT.InIEEESymp.onSecurityandPrivacy,MayMayP.Akritidis,M.Costa,M.Castro,andS.Hand.BaggyBoundsChecking:AnEfcientandBackwards-compatibleDefenseAgainstOut-of-boundsErrors.InUSENIXSecuritySymposiumSymposiumG.AltekarandI.Stoica.Focusreplaydebuggingeffortonthecontrolplane.USENIXWorkshoponHotTopicsinDependability,2010.2010.S.Bhatkar,E.Bhatkar,R.Sekar,andD.C.Duvar-ney.Efcienttechniquesforcomprehensivepro-tectionfrommemoryerrorexploits.InSecuritySymposium,2005.2005.S.BhatkarandR.Sekar.DataSpaceRandomiza-tion.InIntl.Conf.onDetectionofIntrusionsandMalware,andVulnerabilityAssessment,2008.2008.T.Bletsch,X.Jiang,V.W.Freeh,andZ.Liang.Jump-orientedprogramming:anewclassofcode-reuseattack.InACMSymp.onInformation,Com-puterandCommunicationsSecurity,2011.2011.N.CarliniandD.Wagner.Ropisstilldangerous:Breakingmoderndefenses.InUSENIXSecurity,2014.2014.M.Castro,M.Costa,andT.Harris.Securingsoft-warebyenforcingdata-owintegrity.InonOperatingSystemsDesignandImplementationementationM.Castro,M.Costa,J.-P.Martin,M.Peinado,P.Akritidis,A.Donnelly,P.Barham,andR.Black.Fastbyte-granularitysoftwarefaultisolation.InACMSymp.onOperatingSystemsPrinciplesnciplesS.Checkoway,L.Davi,A.Dmitrienko,A.-R.Sadeghi,H.Shacham,andM.Winandy.Return-orientedprogrammingwithoutreturns.InACMConf.onComputerandCommunicationSecuritySecurityC.Cowan,S.Beattie,J.Johansen,andP.Wa-gle.PointguardTM:protectingpointersfrombufferoverowvulnerabilities.InUSENIXSecuritySym-,2003.2003.C.Cowan,C.Pu,D.Maier,H.Hintony,J.Walpole,P.Bakke,S.Beattie,A.Grier,P.Wagle,andQ.Zhang.StackGuard:Automaticadaptivedetec-tionandpreventionofbuffer-overowattacks.InUSENIXSecuritySymposium,1998.1998.L.Davi,A.-R.Sadeghi,D.Lehmann,andF.Mon-rose.Stitchingthegadgets:Ontheineffectivenessofcoarse-grainedcontrol-owintegrityprotection.USENIXSecuritySymposium,2014.2014.J.Devietti,C.Blundell,M.M.K.Martin,andS.Zdancewic.Hardbound:Architecturalsupportforspatialsafetyofthecprogramminglanguage.InIntl.Conf.onArchitecturalSupportforProgram-mingLanguagesandOperatingSystems,2008.2008.D.Dhurjati,S.Kowshik,andV.Adve.SAFE-Code:enforcingaliasanalysisforweaklytypedSIGPLANNotices,41(6):144157,JuneJune´U.Erlingsson,M.Abadi,M.Vrable,M.Budiu,andG.C.Necula.XFI:Softwareguardsforsystemad-dressspaces.InSymp.onOperatingSystemsDe-signandImplementation,2006.2006.E.Goktas¸,E.Athanasopoulosy,H.Bos,andG.Por-tokalidis.Outofcontrol:Overcomingcontrol-owintegrity.InIEEESymp.onSecurityandPrivacyPrivacyN.Hasabnis,A.Misra,andR.Sekar.Light-weightboundschecking.InIEEE/ACMSymp.onCodeGenerationandOptimization,2012.2012.A.Homescu,S.Neisius,P.Larsen,S.Brunthaler,andM.Franz.Prole-guidedautomatedsoftwarediversity.InIEEE/ACMSymp.onCodeGenerationandOptimization,2013.2013.R.Hund,C.Willems,andT.Holz.Practicaltimingsidechannelattacksagainstkernelspaceaslr.InIEEESymp.onSecurityandPrivacy,2013.2013.IntelArchitectureInstructionSetExten-sionsProgrammingReference.\r\f\n\t\b\n\n\t,2013.2013.Intel.IntroductiontoIntelmemoryprotec-tionextensions.https://software.intel.com/en-protection-extensions,July2013. 15 16211th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)USENIX Association T.Jim,J.G.Morrisett,D.Grossman,M.W.Hicks,J.Cheney,andY.Wang.Cyclone:AsafedialectofC.InUSENIXAnnualTechnicalConf.,2002.2002.C.Kil,J.Jun,C.Bookholt,J.Xu,andP.Ning.Ad-dressspacelayoutpermutation(ASLP):Towardsne-grainedrandomizationofcommoditysoftwar.AnnualComputerSecurityApplicationsConf..C.LattnerandV.Adve.AutomaticPoolAlloca-tion:ImprovingPerformancebyControllingDataStructureLayoutintheHeap.InACMConf.onProgrammingLanguageDesignandImplementa-,2005.2005.C.Lattner,A.Lenharth,andV.Adve.Mak-ingContext-SensitivePoints-toAnalysiswithHeapCloningPracticalForTheRealWorld.InACMConf.onProgrammingLanguageDesignandIm-,2007.2007.J.Li,Z.Wang,T.K.Bletsch,D.Srinivasan,M.C.Grace,andX.Jiang.Comprehensiveandef-cientprotectionofkernelcontroldata.TransactionsonInformationForensicsandSecu-,6(4):14041417,Dec.2011.2011.TheLLVMcompilerinfrastructure.infrastructure.A.J.Mashtizadeh,A.Bittau,D.Mazieres,andD.Boneh.Cryptographicallyenforcedcontrolowintegrity.http://arxiv.org/abs/1408.1451,Aug.Aug.S.McCamantandG.Morrisett.Evaluatingsforaciscarchitecture.InUSENIXSecuritySymposiumSymposiumS.Nagarakatte,M.M.K.Martin,andS.Zdancewic.Watchdog:Hardwareforsafeandsecuremanualmemorymanagementandfullmemorysafety.InIntl.Symp.onComputerArchitecture,2012.2012.S.Nagarakatte,J.Zhao,M.M.Martin,andS.Zdancewic.SoftBound:HighlyCompatibleandCompleteSpatialSafetyforC.InACMConf.onProgrammingLanguageDesignandImplementa-,2009.2009.S.Nagarakatte,J.Zhao,M.M.Martin,andS.Zdancewic.CETS:CompilerEnforcedTempo-ralSafetyforC.InIntl.Symp.onMemoryMan-agement,2010.2010.G.Necula,J.Condit,M.Harren,S.McPeak,andW.Weimer.CCured:Type-saferetrottingoflegacysoftware.ACMTrans.onProgrammingLanguagesandSystems,27(3):477526,2005.2005.Nergal.Theadvancedreturn-into-lib(c)ex-Phrack,11(58):,Nov.2007.2007.B.NiuandG.Tan.Monitorintegrityprotectionwithspaceefciencyandseparatecompilation.InACMConf.onComputerandCommunicationSe-,2013.2013.B.NiuandG.Tan.Modularcontrol-owintegrity.ACMConf.onProgrammingLanguageDesignandImplementation,2014.2014.PaX-Team.PaXASLR(AddressSpaceLay-outRandomization).,2003.2003.Phoronix.Phoronixtestsuite.\r\r\rE.J.Schwartz,T.Avgerinos,andD.Brumley.Allyoueverwantedtoknowaboutdynamictaintanal-ysisandforwardsymbolicexecution(butmighthavebeenafraidtoask).InIEEESymp.onSecurityandPrivacy,2010.2010.K.Serebryany,D.Bruening,A.Potapenko,andD.Vyukov.AddressSanitizer:AFastAddressSan-ityChecker.InUSENIXAnnualTechnicalConf..H.Shacham.Thegeometryofinnocenteshonthebone:Return-into-libcwithoutfunctioncalls(onthex86).InACMConf.onComputerandCommu-nicationSecurity,2007.2007.K.Z.Snow,F.Monrose,L.Davi,A.Dmitrienko,C.Liebchen,andA.-R.Sadeghi.Just-in-timecodereuse:Ontheeffectivenessofne-grainedaddressspacelayoutrandomization.InIEEESymp.onSe-curityandPrivacy,pages574588,2013.2013.L.Szekeres,M.Payer,T.Wei,andD.Song.SoK:Eternalwarinmemory.IEEESymp.onSecurityandPrivacy,2013.2013.C.Tice,T.Roeder,P.Collingbourne,S.Check-oway,U.Erlingsson,L.Lozano,andG.Pike.En-forcingforward-edgecontrol-owintegrityingcc&llvm.InUSENIXSecuritySymposium,2014.2014.A.vandeVenandI.Molnar.ExecShield.,2004. 16 USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)163 J.Wilander,N.Nikiforakis,Y.Younan,M.Kamkar,andW.Joosen.RIPE:Runtimeintrusionpreventionevaluator.InAnnualComputerSecurityApplica-tionsConf.,2011.2011.B.Yee,D.Sehr,G.Dardyk,J.B.Chen,R.Muth,T.Ormandy,S.Okasaka,N.Narula,andN.Ful-lagar.Nativeclient:Asandboxforportable,un-trustedx86nativecode.InIEEESymp.onSecurityandPrivacy,2009.2009.B.Zeng,G.Tan,andU.Erlingsson.Strato:Aretar-getableframeworkforlow-levelinlined-referencemonitors.InUSENIXSecuritySymposium,2013.2013.B.Zeng,G.Tan,andG.Morrisett.Combiningcontrol-owintegrityandstaticanalysisforef-cientandvalidateddatasandboxing.InACMConf.onComputerandCommunicationSecurity,2011.2011.C.Zhang,T.Wei,Z.Chen,L.Duan,L.Szekeres,S.McCamant,D.Song,andW.Zou.PracticalCon-trolFlowIntegrity&RandomizationforBinaryEx-ecutables.InIEEESymp.onSecurityandPrivacyPrivacyM.ZhangandR.Sekar.ControlowintegrityforCOTSbinaries.InUSENIXSecuritySymposium 17 USENIX Association 11th USENIX Symposium on Operating Systems Design and Implementation (OSDI 14)147 Code-PointerIntegrityVolodymyrKuznetsovoSzekeres,MathiasPayerGeorgeCandea 1 Code-Pointer IntegrityVolodymyr Kuznetsov, École Polytechnique Fédérale de Lausanne (EPFL);László Szekeres, Stony Brook University; Mathias Payer, Purdue University; George Candea, École Polytechnique Fédérale de Lausanne (EPFL); R. Sekar, Stony Brook University; Dawn Song, University of California, Berkeleyhttps://www.usenix.org/conference/osdi14/technical-sessions/presentation/kuznetsov This paper is included in the Proceedings of the 11th USENIX Symposium on Operating Systems Design and Implementation.October 68, 2014 Broomfield, CO978-1-931971-16-4Open access to the Proceedings of the 11th USENIX Symposium on Operating Systems Design and Implementation is sponsored by USENIX.