RISC-V ISA Extension for Control Flow Integrity

49 Pages·2019·0.356 MB·German

by  Leander Seidlitz

DEPARTMENT OF INFORMATICS
TECHNICAL UNIVERSITY OF MUNICH
Bachelor’sThesisinInformatics
RISC-V ISA Extension for Control Flow
Integrity
LeanderSeidlitz
DEPARTMENT OF INFORMATICS
TECHNICAL UNIVERSITY OF MUNICH
Bachelor’sThesisinInformatics
Adaption von Control Flow Integrity in der
RISC-V ISA
RISC-V ISA Extension for Control Flow
Integrity
Author: LeanderSeidlitz
Supervisor: Prof.Dr.ClaudiaEckert
Advisor: LukasAuer,M.Sc.
SubmissionDate: 12.April2019
IconfirmthatthisBachelor’sThesisismyownworkandIhavedocumentedallsources
andmaterialused.
Ichversichere,dassichdieseBachelorarbeitselbsta¨ndigverfasstundnurdieangegebenen
QuellenundHilfsmittelverwendethabe.
Ort,Datum LeanderSeidlitz
Abstract
Low-levelprogramminglanguagessuchasCandC++delegatememory
managementtotheprogrammer.Incorrectmemoryhandlingmaycause
memoryerrors,whichpresentaprimetargetforattackers.
Currentlywidedeployeddefensemechanismsprovidegoodprotection
againstcertainclassesofattacks.Manymechanismsaredefeatedbypow-
erfulattackerswitharbitrarymemoryaccess,astheyrelyonsecretsstored
in memory. We recognize the need for defense measures that can cope
withsuchattackers.
WithARMv8.3-AARMhasintroducedARMPAC,hardwaresupportfor
pointerauthentication.APACisaMessageAuthenticationCodebound
tothepointervalue,acontext,andasecretkey.ThePACisstoredinthe
unusedbitsofthepointer.Itallowsreliabletamperdetection.Itcanbe
usedtoenforceControlFlowIntegrity,providingstronghardware-based
protectionagainstcode-reuseattacks.
InthisworkwepresentanadaptionofARMPAContheRISC-Varchi-
tecture.WedevelopanextensiontotheInstructionSetArchitecturefor
hardware-basedpointerauthentication.WemodifyGCCtosupportre-
turn address protection using pointer authentication instructions. Our
approach allows for protection against strong attackers with arbitrary
memoryaccess.
Contents
1 Introduction 1
1.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Background 3
2.1 RISC-V . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 CodeReuseAttacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 ControlFlowIntegrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 CurrentDefenseMechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 ARMPointerAuthentication 8
3.1 PointerAuthentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 AuthenticatingandVerifyingPointers . . . . . . . . . . . . . . . . . 9
3.1.2 KeyManagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.3 QARMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3 SecurityProperties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 Design 14
4.1 PointerAuthenticationonRISC-V . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.1 AttackerModel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2 AuthenticationandVerificationofPointers . . . . . . . . . . . . . . 15
4.1.3 KeyManagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.4 CryptographicPrimitives . . . . . . . . . . . . . . . . . . . . . . . . 17
4.2 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 UseCasesofPointerAuthentication . . . . . . . . . . . . . . . . . . . . . . 19
4.3.1 ReturnAddressProtection . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.2 ControlFlowIntegrity . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.3 ProtectionofGenericDataStructures . . . . . . . . . . . . . . . . . 20
5 Implementation 21
5.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1.1 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1.2 ControlandStatusRegisters . . . . . . . . . . . . . . . . . . . . . . 23
5.1.3 CryptographicPrimitives . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.1 GCC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.2.2 LinuxBinutilsandGDB . . . . . . . . . . . . . . . . . . . . . . . . . 26
6 Evaluation 28
6.1 SecurityPropertiesandAttackResistance . . . . . . . . . . . . . . . . . . . 28
6.1.1 CodeReuseAttacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.1.2 SigningKeys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.3 PACEntropy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.1.4 SigningGadgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
6.1.5 LeakingKeys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.1.6 RIPETestsuite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2 Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2.1 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2.2 Returnaddresssigning . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.3 Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7 DiscussionandConclusion 34
7.1 RelatedWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7.3 FutureWork . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3.1 CombinedInstructions . . . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3.2 CreatingPACsforotherPrivilegeLevels . . . . . . . . . . . . . . . 36
7.3.3 MultipleKeys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.3.4 ExtendingSoftwareSupport . . . . . . . . . . . . . . . . . . . . . . 37
Acronyms 40
Appendix 41
authInstructionImplementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
vrfyInstructionImplementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
authgInstructionImplementation . . . . . . . . . . . . . . . . . . . . . . . . . . 43
strpInstructionImplementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1 Introduction
Low-levelprogramminglanguagessuchasCandC++delegatememorymanagementto
theprogrammer.Compilersforsuchlanguagesareunabletocheckforinvalidmemory
accessesorundefinedbehavior.Wecalltheselanguagesmemory-unsafe.Theprogrammer
isleftwithaccesstotherawmemoryandisexpectedtomanageit—andtheprogrammer
ispronetohumanerror.Alotofsystemsoftwarethatrunswithhighprivilegesiswritten
in such memory-unsafe languages, e.g. the Linux kernel or device drivers. This makes
memoryerrorsaprimetargetforattackers,whichleveragememoryerrorstogaincontrol
overasystembystrategicallycorruptingcontroldatastoredinwritablememory.
The arms race between attackers and countermeasures has gone on for some time.
PriortoDataExecutionPrevention(DEP)[4],attackerscouldinjectexecutablecodeinto
processmemory.Theattackerwouldthentriggerexecutionofthiscode.Directexecution
of injected code is prevented by the hardware-assisted DEP present in modern CPUs.
Itforceswritablememorytobenon-executableandthereforepreventstheexecutionof
injectedcode.AsDEPpreventstheformerexploit,attackershavemovedontoattacks
basedonothervectors.CodeReuseAttacksdonotrelyonattackercraftedcodebutrather
corruptcontroldataandutilizeexistingprogramcode.Theseattacksleverageexisting
instructionsequencesintheexecutableinordertobypassnon-executablememory.Asthe
writablememorycontainscontroldataandpointers,attackersstrategicallycorruptthese
inordertohijacktheprogramcontrolflow.Chainingtogetherprogrampartsinawaynot
intendedbytheprogrammerallowsforattackerdefinedbehavior.
Many currently widely deployed protection mechanisms are defeated by attackers
with arbitrary memory access. Therefore we need approaches for better protection. A
classofsuchapproachesisbasedonControlFlowIntegrity(CFI).CFImonitorsprogram
executionandisabletodetectwhenaprogramdivertsfromnormalbehavior.Attacks
causeunexpectedbehavior,whichCFIdetects.
CFI approaches often trade off precision for performance. Solutions offering very
preciseCFIareabletoreliablydetectattacksbutcomewithalargeruntimeoverheador
requiresourcecodemodification,propertiesunacceptableforprotectionmechanismsthat
needtobewidelycompatible.Inthecaseoflegacysystems,sourcecodemodificationis
notanoption.Attackmitigationmechanismsneedtohavealowoverheadandrequire
littletonoeffortfromtheprogrammerinordertobeaccepted.
Manyprotectionmechanismsareimplementedinsoftware,yettheunderlyinghard-
wareposeslimits.Addingnewmechanismstothehardwareitselfallowsforapproaches
1
1 Introduction
notlimitedbyexistingstructures.Furthermore,hardware-basedimplementationshave
theadvantageofbeinguninfluenceablebyanattacker.Softwareisinfluenceablebyan
attackerashecanaccessthememorybuttheunderlyinghardwareisoutofhisreach.
With Pointer Authentication Codes (PACs) [16, 17, 5] ARM has implemented an
addition to its Instruction Set Architecture (ISA) allowing for integrity protection and
authenticationofpointers.Theseadditionscanalsobeusedtoenforcehardware-assisted
CFI.ARMPACremainseffectiveagainststrongattackerswitharbitrarymemoryaccess.
ARM’s hardware-based approach offers a lower overhead in contrast to software
solutions.ProtectionschemesmakinguseofARM’sadditions,suchasPARTS[14]offer
verygoodruntimeprotection.PARTSoffersprotectionofalldataandinstructionpointers
ataruntimeoverheadof19.5%.Protectionofthereturnaddresscomeswithalowoverhead
of0.5%.AsPARTSiscompilerbased,itdoesnotrequiresourcecodemodification.
1.1 Contributions
InthispaperwepresentanapproachtopointerauthenticationfortheRISC-VISA,based
on ARM’s approach to pointer authentication [16, 17, 5]. We present a design and an
extension of the RISC-V ISA for pointer integrity protection and authentication. We
reportthehardwaremodificationsandinstructionsadded.Ourapproachallowsreliable
detectionofpointertampering.Itcanwithstandstrongattackerswitharbitrarymemory
access.Wepresentause-caseofourapproach,addingcompilersupportforprotectionof
thereturnaddressstoredonthestack.WeshowthatoursolutioniseffectiveagainstCode
ReuseAttacks.Ourhardwareadditionsallowforstrongprotectionmechanismsutilizing
theaddedinstructions.
Theremainderofthisthesisisorganizedasfollows:InChapter2wegiveanoverview
overtheRISC-VISA,theconceptofCFIaswellasrelevantattacksandcountermeasures.
Chapter3givesanoverviewoverARMPAC,ARM’sapproachtopointerauthentication.In
Chapter4wepresentourdesignforpointerauthenticationfortheRISC-VISA.Chapter5
presentstheimplementationdetailsofourdesignaswellasaproof-of-concept:protection
of the return address stored on the stack. In Chapter 6 we evaluate our approach. In
Chapter7wegiveanoverviewoverrelatedwork,aconclusion,andfutureextensions.
2
2 Background
OurapproachtopointerauthenticationextendstheRISC-VISA.Relevantbackground
is given in the following. We introduce to the RISC-V ISA, code reuse attacks, CFI and
commonprotectionmechanisms.
2.1 RISC-V
The RISC-V architecture [23, 22] is a free and open load/store Reduced Instruction Set
Computer (RISC) ISA, providing support for 32 and 64-bit address space variants. In
contrasttootherarchitectures,theRISC-VISAtakesamodularapproach.Themodular
approachsplittinguptheISAallowsforcustom,non-standardextensionsthatextendthe
ISAforspecialpurposes.
Instruction Set Architecture. There are four base integer instruction sets: the two pri-
marybaseISAsRV32IandRV64I,the128-bitvariantRV128I,andRV32E,whichistargeted
at small microcontrollers. Each base ISA provides a minimal target for toolchains and
computation.Inthefollowingwefocusonthe64-bitvariantRV64I.Thebaseintegerin-
structionsetiscomplementedbyextensions(suchasfloatingpointoratomics)toprovide
atargetforgeneral-purposesoftware.
The64-bitbaseintegerinstructionsetusedinthefollowingisRV64I(RV64denoting
the64-bitvariantandIdenotingtheintegerbaseinstructionset).TheRISC-VISAstring
consistsofthebasearchitecture(RV64I)followedbytheextensionspresent.Thegeneral-
purposeinstructionsetincludesthebaseintegerISAandextensions,beingdenotedas
RV64GwhichisequaltoRV64IMAFD.Thegeneral-purposeinstructionsetincludes
• theintegerbaseinstructionsetI
• thestandardextensionMforIntegerMultiplicationandDivision
• thestandardextensionAforAtomicInstructions
• thestandardextensionFforSingle-PrecisionFloating-Point
• thestandardextensionDforDouble-PrecisionFloating-Point.
By splitting the ISA into a base and extensions, RISC-V avoids bloating the standard
instructionset.RISC-Vaimstoonlyhavetheminimalnecessarysetofinstructionspresent.
3
2 Background
31 25 24 20 19 15 14 12 11 7 6 0
funct7 rs2 rs1 funct3 rd opcode R-type
imm[11:0] rs1 funct3 rd opcode I-type
imm[11:5] rs2 rs1 funct3 imm[4:0] opcode S-type
imm[31:12] rd opcode U-type
Table1:RISC-Vinstructionformats.imm[11:0]denotesimmediatebitpositions11to0.Takenfromthe
RISC-VISAmanual[23].
Registers. TheRV64IbaseRISC-VISAspecifies31general-purposeregisters(x1-x31),a
dedicatedzeroregister(x0)andaprogramcounter(pc).Theregisterwidthisdenotedby
XLEN.Forthe64-bitvariantRV64XLENisequal64.
Instruction Formats. Instructions of the general-purpose ISA are 32-bit wide with ex-
ceptionofthecompressedinstructionsoftheCextension,whichare16-bitwide.TheC
extensionofferscompressed16-bitinstructionsforcommonoperations.
Instructionsmustbefour-bytealignedinmemory,exceptiftheCextensionispresent.
Inthiscasealignmentmustbeonatwo-byteboundary.
The base instruction set specifies four core instruction formats: R, I, S and U. The
instruction formats are listed in Table 1. There are two additional immediate encoding
variants(B,J)encodingbranchandjumpinstructions.Thers1andrs2fieldsencodethe
sourceregisters.Theresultoftheinstructioniswrittentotheregisterrd.Immediatevalues
are encoded by the imm fields and may be split into multiple fields. If present, funct7,
funct3andopcodeencodetheinstruction.opcodespecifiestheinstruction’smajoropcode.
Bykeepingthesourceanddestinationregisteratthesamepositiondecodingissimplified.
PrivilegeLevels. TheISAspecifiesthreeprivilegelevels:Usermode(U-mode),Supervi-
sormode(S-mode)andMachinemode(M-mode).ThelowestprivilegelevelisU-mode.
The levels and encoding are listed in Table 2. The minimum an implementation has to
supportisM-mode.
InaLinuxenvironmentthebootloaderandfirmwareruninM-mode,thekernelin
S-modeandusersoftwareinU-mode.
ControlandStatusRegisters. ControlandStatusRegisters(CSRs)arespecialregisters
that contain state information of a processor, such as timers and counters. The RISC-V
ISAspecifies12-bitwideCSRaddresses.ACSR’saddressimplicitlyencodestheaccess
permissions. The highest two bits (bits [11:10]) encode whether the CSR is read/write
accessible(values00,01,10)orread-only(11).Thenexttwobits(bits[9:8])encodethe
lowest privilege level that can access the CSR. Privilege level encodings are listed in
Table2.
TheCSRsareaccesseddirectlybytheCSRinstructionswhichatomicallyread-modify-
writeasingleCSR.AccessingaCSRwithouthavingtheappropriateprivilegelevelraises
anillegalinstructionexception.
VirtualMemory. RV64IU-modeandS-modesupportamodefordirectaddressingas
wellas39-bit(Sv39)and48-bit(Sv48)wideVirtualAddresses(VAs).M-modedoesnot
supportaddresstranslation.TheMODEfieldinthesatp(SupervisorAddressTranslation
4