IEEE XXX, VOL. XX, NO. X, 2018. 1

HCIC: Hardware-assisted Control-flow IntegrityChecking

Jiliang Zhang, Member, IEEE, Binhang Qi, Gang Qu, Senior Member, IEEE

Abstract—Recently, code reuse attacks (CRAs), such as return-oriented programming (ROP) and jump-oriented programming(JOP), have emerged as a new class of ingenious securitythreatens. Attackers can utilize CRAs to hijack the control flowof programs to perform malicious actions without injecting anycodes. Many defenses, classed into software-based and hardware-based, have been proposed. However, software-based methodsare difficult to be deployed in practical systems due to highperformance overhead. Hardware-based methods can reduceperformance overhead but may require extending instructionset architectures (ISAs) and modifying compiler or suffer thevulnerability of key leakage. To tackle these issues, this paperproposes a new hardware-based control flow checking methodto resist CRAs with negligible performance overhead withoutextending ISAs, modifying compiler and leaking the encryp-tion/decryption key. The key technique involves two control flowchecking mechanisms. The first one is the encrypted Hammingdistances (EHDs) matching between the physical unclonablefunction (PUF) response and the return addresses, which preventsattackers from returning between gadgets so long as the PUFresponse is secret, thus resisting ROP attacks. The second one isthe liner encryption/decryption operation (XOR) between PUFresponse and the instructions at target addresses of call andjmp instructions to defeat JOP attacks. Advanced return-basedfull-function reuse attacks will be prevented with the dynamickey-updating method. Experimental evaluations on benchmarksdemonstrate that the proposed method introduces negligible0.95% run-time overhead and 0.78% binary size overhead onaverage.

Index Terms—control flow integrity, code reuse attacks, phys-ically unclonable function, hardware-assisted security.

I. INTRODUCTION

A. Motivation

CODE reuse attacks (CRAs) emerged as a powerful attack,can hijack the control flow of programs without injecting

any malicious codes. CRAs can use the original code in theprogram to construct small fragments of existing codes. Thesecode fragments are called gadgets. A gadget is composedof several assembly instructions, and each instruction canimplement a different function (e.g., write a specified valueto a fixed register). By chaining the gadgets ingenious, anattacker can construct a sequence of gadgets to implementthe same function as the malicious code. After constructing

This work is supported by the National Natural Science Foundation ofChina under Grant No. 61602107, and the Central Universities FundamentalResearch funding of China.

J. Zhang and B. Qi are with the College of Computer Science andElectronic Engineering, Hunan University, Changsha 410082, China (e-mail:zhangjiliang@hnu.edu.cn).

G. Qu is with the Department of Electrical and Computer Engi-neering, University of Maryland, College Park, MD 20742 USA (e-mail:gangqu@umd.edu).

gadgets, attackers utilize the buffer overflow vulnerabilityto overwrite the return address on the stack with the startaddress of gadget chaining to hijack the control flow of theprogram, and ultimately obtain the system privilege. CRAsmainly include return-oriented programming (ROP) attacks[1], [2] and jump-oriented programming (JOP) attacks [3],[4]. ROP was shown to be Turing-complete on a variety ofplatforms. It allows attackers to execute arbitrary code byperforming a chain of gadgets which come from exist binariesand all end with a ret instruction, while JOP makes use of jmpinstructions instead of ret instructions in gadgets to changethe control flow. Some tools [5] have been developed to finduseful gadgets in given binaries to facilitate CRAs whichhave been demonstrated on a broad range of architectures,such as x86, Atmel AVR, SPARC, ARM, Z80 and PowerPC,and successfully cracked some well-known software suchas Adobe Reader, Adobe Flashplayer and Quicktime Player.To thwart the CRAs, many defenses have been proposed inindustry and academia. However, they suffer from severalissues. Below we will summarize these techniques and analyzethe limitations of them.

B. Limitations of Prior Art

Buffer overflow is one of the most prevalent softwareattacks. Stack smashing [6] is a typical buffer overflow at-tack. Attackers inject the malicious code in the stack andoverwrite the return address of normal instruction to executethe malicious code. Several approaches have been proposedto defeat buffer overflow attacks. For example, data executionprevention (DEP) [7] prohibits a memory page to be writableand executable at the same time. Hence, attackers are unableto execute their injected malicious codes. DEP has beensupported by both AMD and Intel processors and widelyadopted by modern operating systems. However, CRAs canredirect the control flow of programs by reusing gadgets, thuseliminating the need of code injection and bypassing hardwarememory protection mechanisms such as DEP.

Recently, many defenses have been proposed to thwartCRAs. The most general solution is control-flow integrity(CFI) checking, where the control flow graph (CFG) of theprogram is generated during compilation and enforced at run-time [8]. CFI can be roughly classed into two categories,software-based and hardware-based. Current software-basedsolutions incur significant performance overhead [8]–[10],[12], which limits adoption in practical systems. Hardware-based CFIs can reduce performance overhead and have at-tracted much attention in recent years. But hardware-based

arX

iv:1

801.

0739

7v1

[cs

.CR

] 2

3 Ja

n 20

18

IEEE XXX, VOL. XX, NO. X, 2018. 2

CFIs require extending the existing processors’ instruction setarchitectures (ISAs) and modifying compiler [11], [13]–[17]or suffer the vulnerability of leaking encryption/decryption key[18].

C. Our Contributions

This paper proposes a Hardware-assisted Control-flow In-tegrity Checking technique, named HCIC, to thwart CRAs byencrypted Hamming distance (EHD)-matching and linear en-cryption/decryption without modifying compiler and extendingISAs and leaking encryption/decryption key. HCIC providesthe following capabilities to defend against ROP/JOP stylecontrol-flow subversion attacks.

EHD matching method: the EHDs between return ad-dresses of call-function and the physical unclonable function(PUF) [19] response are computed before the return addressesare stored in the memory structure. Then, the EHDs will becomputed at run-time when the corresponding ret instructionsare executed. Finally, the pre-computed EHDs are comparedwith the EHDs computed at runtime to verify whether theEHDs are matched. If attackers modify the address in thestack, the EHDs will not be matched. In this case, our proposedmechanism can prevent attackers from returning betweengadgets to thwart ROP attacks. With the PUF response (key)updating, return-based full-function reuse can be prevented.

Linear encryption/decryption method: the PUF-basedliner encryption operations (XOR) on the instructions at targetaddresses of jmp and call are performed once the executablebinary is loaded into memory. Then, the run-time liner decryp-tion operation can be done while jmp or call instructions areexecuted. If attackers modify the target address of a jmp or callinstruction, the default decryption operation for the instructionat the address will be forced to perform, which will make thecontrol flow abnormal and finally may raise a system error,thus defeating JOP attacks.

Compared with previous solutions, our solution incurs ex-tremely low performance and binary size (memory) overheads.This approach has the following contributions and features:

1) EHD matching method is proposed to protect programsfrom ROP attacks. This new method solves the securityvulnerability suffered in the previous work [18] that thesecret PUF key can be deduced through memory leakageor debugging.

2) Liner encryption/decryption mechanism is proposed toresist JOP attacks. In this mechanism, the PUF key usedin the JOP-defense mechanism is different from the PUFkey used in the ROP-defense mechanism, which bringsa big advantage that the key leakage in JOP-defensemechanism cannot be used to compromise the ROP-defense mechanism. Therefore, the security is improved.

3) Dynamic key-updating method is proposed to resist ad-vanced CRAs and hence improves the security. Moreover,HCIC doesn’t require the PUF generating the reliableresponse and hence avoiding the intractable reliabilityissue suffered in previous PUF applications [20]–[22].

4) HCIC does not modify compiler and add any new in-structions to the existing processor’s ISA.

5) Simulation results demonstrate that our architecture’saverage run-time and binary size overheads are only0.95% and 0.78%, respectively, which are much lowerthan traditional CFI approaches (up to 21% [8]).

6) Exception analysis shows that our proposed defensedoesn’t produce anomalies when some exceptional casesoccurred, and security analysis show that the proposedmethod is sound and secure against CRAs with zero falsepositive and negative rates.

The rest of this paper is organized as follows. Related workis elaborated in Section II. Code reuse attacks are describedin Section III. Preliminaries are given in Section IV. Theproposed hardware-assisted CFI and its working mechanismare elaborated in Section V. Exception analysis is given inSection VI. Security is analyzed in Section VII. The detailedexperimental results and analysis are reported in Section VIII.Finally, we conclude in Section IX.

II. RELATED WORK

CRAs are to use existing codes to launch an attack withoutinjecting any codes. A kind of early code reuse attack, namedreturn-to-libc attack [23], can call the libc functions elaboratelychosen by the attackers to change the normal control flow.In this way, an attacker might eventually execute maliciouscomputing. Recently, ROP [1], [2] and JOP [3], [4] as morepowerful types of code reuse attacks are proposed. Lots ofworks have been proposed to thwart CRAs, such as addressspace layout randomization (ASLR) [24]–[26], shadow stack[27]–[29], gadgets checking [30] and CFI [13]–[16], [31].

ASLR [24]–[26] randomizes the address of code and dataregions when the program is loaded into memory to preventattackers from guessing the entry address of gadgets. However,the code and data region is not fully randomized whenASLR is applied on modern operating systems, and with theknowledge of some randomized codes, it is still possible tofind enough gadgets in memory to perform CRAs [2]. Shadowstack was proposed to protect the stack of ret from beingchanged by adding a second stack for the program that is usedexclusively for control transfer operations. However, shadowstack needs dedicated maintenance and requires protectionfrom the main program incurring additional overhead [28] andrequire modifying the ISA [29] and cannot defend againstJOP attacks [27], [28]. Recently, Intel proposed a control-flow enforcement technology that also uses shadow stack todefend against ROP, and proposed indirect branch tracking byadding a new instruction ENDBRANCH that is used to markvalid indirect call/jmp targets in the program to defend againstJOP [29]. Gadgets checking [30] was proposed to monitor thefrequency of executing gadgets to judge whether the programis under attack. This method can resist the JOP attack but itmay incur a high false positive rate when a program consists ofmany small functions having little amount of instructions. CFIis the most general solution among current defenses. The keyidea is to generate the CFG for a program during compilationand enforce the control flow to follow the CFG at run-time.CFI includes software-based CFI and hardware-based CFI aswe will introduce in details next.

IEEE XXX, VOL. XX, NO. X, 2018. 3

A. Software-based CFI

CFI checking makes the control flow change be consistentwith the CFG of original program. Abadi et al. proposedto check the CFI [8] by inserting the checking ID beforeeach indirect branch instruction to prevent the unintendedchange of control flow. Any illegal changes of control flowwill be theoretically checked and refused in run-time dueto an ID-checking violation. Theoretically, a unique ID canbe inserted for each control flow transition. However, theseCFI incurs high performance overhead due to the ID creating,querying, comparing and storing. The performance overheadof CFI is up to 21% [8]. In order to reduce the performanceoverhead, several techniques [9], [12] proposed to loosen thecontrol transitions and use least IDs. Compact control flowintegrity and randomization (CCFIR) [9] redirects indirect jmpbranches to a new springboard. By assigning aligned entry todirect and indirect branch targets, indirect jmp instructionswill be checked and only allowed to transit control flowto the springboard entries. CCFIR uses three IDs to restrictcontrol flow. Two IDs are used to return to sensitive or non-sensitive functions, and one ID is used for call or indirect jmpinstructions. This looser CFI allows control flow to jump tothe address that does not present in program’s CFG, whichmakes it be possible for attackers to launch an advanced ROPattack. Besides, CCFIR requires program allocating alignedspringboard to ensure control flow integrity, which largelyincreases the space requirements. However, CCFIR still incurshigh performance overhead and space overhead.

As discussed above, software-based CFIs incur high perfor-mance and binary size overheads, and need to insert checkinginstructions or create accompanying data structures (e.g. stack)in executing programs, which may overwrite registers or flagsat run time and cause the programs behaving abnormally [8].

B. Hardware-Based CFI

Hardware-based CFIs can reduce performance overheadand hence have attracted much attention recently. Severalhardware-based CFIs were also proposed, such as BranchRegulation (BR) [10], hardware-assisted CFI [13]–[16].

BR [10] uses hardware support to monitor the control flow,in which indirect jmp instructions are restricted to jump to itsown function or the first instruction of other functions. BRalso adds a shadow stack to record legal return addresses andcheck before each ret instruction. To improve efficiency, BRemploys cache for accessing the shadow stack. BR adds BR-annotation to indicate a function and restrict indirect branch.However, BR allows jmp instruction to transfer the controlflow inside the function, which can be used by an attackerto perform malicious attacks. Kanuparthi et al. [32] proposedto use the DTPM to support run-time integrity checking ofa program. The key idea is to verify the hash value of eachtrace in CFG to check the integrity of control flow. However,DTPM cannot detect control flow anomalies between trace andtrace in CFG and brings high performance overhead. Daviet al. [13], [14] proposed a hardware-assisted fine-grainedCFI which adds new CPU instructions to ISAs. By assigningdifferent labels to each function, it ensures an indirect call

instruction must fit new CPU instructions. Ret instructionscan only return to the most recent callsite since the labelfor call function can be activated at call time and inspectedat return time. But labels are needed to insert into binarywhich needs to change the compiler and ISAs to support therecognition of labels. Besides, run-time checking requires alabel state memory to store function labels, which increasesthe space overhead. In 2016, Sullivan et al. [15] enhancedthe hardware-assisted fine-grained CFI to ensure the forward-edge and backward-edge control flow follow the CFG. Suchdefense can prevent ROP, JOP, and full-function reuse. Butit also requires extending ISAs and modifying compiler andcode size overhead is up to 13.5%. In our previous hardware-assisted CFI architecture [18], the return addresses of function-call are encrypted and will be decrypted with the simple XORoperation when the corresponding instructions are executed,which is vulnerable to the attack that attackers may getthe linearly encrypted addresses through memory leakage ordebugging and then deduce the secret PUF response. Later, theauthors [17] proposed to replace XOR with the AES integratedin Intel processors to improve security, but this techniquealso needs to expand ISA (added new AES encryption anddecryption instructions) [33]. Cryptographic CFI (CCFI) [34]also protects control flow elements with AES. However, CCFIis built on source codes and has limitations in performanceoverhead and defending against JOP attacks. Clercq et al.[35] use cryptographic mechanisms to encrypt and decryptthe instructions with control flow dependent information toenforce CFI, which doesn’t need to extend ISAs. However, itincurs unacceptable performance overhead (up to 110%), andwhen the same function is called multiple times, the instructiondecryption will be wrong which would incur high false positiverate.

To address these issues, this paper proposes a hardware-assisted CFI checking with the encrypted Hamming distance(EHD)-matching and linear encryption/decryption withoutmodifying compiler and extending ISAs and the vulnerabilityof leaking encryption/decryption key. Our proposed methodincurs low performance overhead and doesn’t produce anoma-lies when some exceptional cases occurred. Security analysisshow that the proposed method is sound and secure againstROP and JOP and even some advanced CRAs such as return-based full-function reuse.

III. CODE REUSE ATTACKS

When executing a CALL function, CPU pushes the returnaddress into stack and then performs the instruction at the firstaddress of the destination function. When the RET instructionis executed, the CPU pops the return address from the stackand execute the instruction at the return address. ROP attacksfirst construct a sequence of gadgets from the existing code,then link these gadgets’ entry address together to form a chain.Finally, an attacker exploits the buffer overflow vulnerability tooverwrite the return address on the stack with the entry addressof the gadgets chain. Once CPU executes the ret instruction,the program would execute the gadgets chain and completesthe ROP attack. The principle of JOP is similar to ROP. The

IEEE XXX, VOL. XX, NO. X, 2018. 4

pop ecx

ret

mov eax, ecx

ret

mov ebx, ecx

int 0x80

ret

memory

Parameter 1

Address of

gadget 2

Address of

gadget 1

Parameter 2

Address of

gadget 3

Address of

int 0x80

stack

23

4

5

gadget 1

gadget 2

gadget 3

System call

1

Overwrite

Fig. 1. An example of ROP attack.

difference is that JOP uses indirect jmp instructions to hijackthe program’s control flow and execute malicious actions. Inwhat follows, we will discuss ROP and JOP in detail.

A. ROP attacks

Stack is used to store temporary variables, the return addressof the function call, parameters of CALL function and soon, which will be pushed into the stack successively whenCPU executes the call instruction. When the ret instruction isexecuted, the return address will be popped into the programcounter to perform the instruction at the return address. If anattacker overwrites the return address, the instruction at theoverwritten address would be executed, and the control flowwill be hijacked by the attacker. ROP utilizes the characteris-tics of the stack for CALL function to hijack the control flowof program by overwriting the return address in the stack.Gadgets are object program’s small code fragments, so theROP attack is covert and difficult to be found. Such attackcan bypass existing defense mechanisms such as DEP [7].

We illustrate a ROP attack in Fig. 1, where an attacker’s goalis to make a system call “int 0x80” with parameter “data” inboth eax and ebx. To achieve this goal, the attacker needs tocomplete the following steps.

Step 1: The attacker exploits an overflow vulnerability tostore the addresses of the system call “int 0x80”, gadget 1,gadget 2, gadget 3 and the data that the system call needs inthe stack.

Step 2: The program executes the gadget 1. The “pop ecx”instruction stores the parameter 1 which is designated by theattacker in ecx register. Then, the program gets the addressof gadget 2 from the stack and jumps to the gadget 2 afterexecuting the ret instruction.

Step 3: The program executes the gadget 2. The “mov eax,ecx” instruction moves the parameter 1 in the ecx to the eax.Then, the program gets the address of gadget 1 from the stackand jumps to the gadget 1 after executing the ret instruction.

Step 4: The program executes the gadget 1 again. The “popecx” instruction stores the parameter 2 which is designated by

the attacker in the ecx register. Then, the program gets theaddress of gadget 3 from the stack and jumps to the gadget 3after executing the ret instruction.

Step 5: The program executes the gadget 3. The “movebx, ecx” instruction moves the parameter 2 in the ecx tothe ebx. Then, the program gets the address of “int 0x80”from the stack and jumps to “int 0x80” after executing the retinstruction.

When constructing the entry address chain of gadgets, weadd the same number of data as the number of pop instructionsafter adding the entry address of gadgets. This ensures thatwhen the ret instruction is executed, the program pops thereturn address which is the entry address of the next gadgetand continues to execute the rest of gadgets to complete theattack.

B. JOP attacks

JOP attack is similar to ROP attack. It also utilizes theexisting code in the program to hijack the program controlflow. The difference is that JOP attacks use indirect jmpinstructions to change the control flow of the program whilethe ROP attacks use ret instructions. During program exe-cution, an attacker can change the values in registers withspecified parameters. When program executes the indirect jmpinstruction or indirect call instruction, the target address takenfrom the register is the address that the attacker constructed.The attacker forces the program to execute these gadgets tocomplete the JOP attack. JOP attacks reduce the difficulty ofconstructing reuse code greatly. And because JOP uses indirectjmp/call instructions instead of ret instructions, which makescurrent ROP defenses cannot prevent JOP attacks. Therefore,ROP and JOP should be prevented simultaneously for anyeffective defenses.

IV. PRELIMINARIES

In this section, we will introduce the general terms andconcepts used throughout the paper. More specific definitionswould be described as necessary.

A. Silicon Physical Unclonable Functions

Silicon Physical Unclonable Function (PUF) has emergedas a promising hardware security primitive that is used forauthentication and key generation without the requirement ofexpensive hardware such as secure EEPROMs and battery-backed SRAM, and hence gained a lot of attention over thepast few years [19] [36].

There are several reasons that we use PUF instead oftraditional secret key storing in digital memory to assist CFIverification. First, PUFs derive a secret from the physicalcharacteristics of the IC. This approach is advantageous overstandard secure digital storage such as more easy to fabricate,consuming less power and area, and naturally anti-tamper [36].Second, the PUF key is chip-unique, unclonable and can beupdated each time when the program is loaded. Even if aPUF key is cracked in a system, it cannot be used to breakanother system, and hence improves the security largely. Third,

IEEE XXX, VOL. XX, NO. X, 2018. 5

.

.

.

call func_2

ID11:

.

.

.

call func_3

ID12:

.

.

.

check ID41

call *(fptr)

ID21:...

check ID11ret

check ID41

call *(fptr)

ID31:...

check ID12ret

ID41:...

check ID21||ID31

ret

func_1 () :

func_3 () :

bool func_1 ( int a ){

return a < 0;

}

func_2 ( int x) {

func_1 ( x );

}

func_3 ( int y) {

func_1 ( y );

}

cal ( int a, int b) {

func_2 (a);

func_3 (b);

}

Fig. 2. An example of program fragment and fine-grained CFI.

it is well known that current PUF applications such as keygeneration [37], anti-overbuilding [20], FPGA IP protection[21] and resisting FPGA replay attacks [22] cannot tolerant biterrors (e.g., key generation has an extremely high requirementon reliability). They all require extra reliability-enhancingtechniques [38] [39] and error-correction schemes [40] toincrease the quality of responses, which incurs significanthardware overhead and hence limits adoption. Our proposedHCIC exhibits a big advantage that it doesn’t require thePUF generating the reliable response and hence avoiding suchintractable issue suffered in previous applications. Last, manyintrinsic PUFs [41] [42] have been proposed. They require noany additional circuitry (zero hardware overhead), and is costeffective. Random number generator also can be used, but itincus higher hardware overhead and lower security than PUF.

B. Control Flow Integrity

Before running the program, the control flow integrity(CFI) mechanism calculates the normal execution paths of theprogram. CFI employs the debug information to generate thecomplete CFG before the program is compiled, and forcesthe program to execute in accordance with the normal controlflow. To ensure CFI, the CFG needs to be extracted from theprogram first. A basic block (BB) is an instruction sequencethat only has a single entry point and a single exit point.A function consists of multiple BBs. A CFG represents thecorrect run direction of program between BBs.

As shown in Fig. 2, the fine-grained CFI [43] assigns aunique ID at the target address of control flow instructionsand inserts the ID checking instructions before the controlflow instructions in order to ensure that the target addressesof the control flow instructions are valid. There are two typesof control flow jump instructions, direct jump and indirectjump. The target address of the direct jump is fixed and cannotbe tampered, so the ID does not need to be inserted andchecked when the program is running. While for indirect jumpinstructions, their target addresses are calculated and loadedinto the memory when the program is running and hence canbe tampered. The CFI is for indirect jump instructions. Beforethe program executes the indirect jump instruction, it is first tocheck that whether the ID at the target address is equal to theknown and valid ID of the jump instruction. With this way, thelegitimacy of indirect jump is verified. However, fine-grainedCFI inserts a unique ID at the target address of indirect jump.

.

.

.

call func_2

ID2:

.

.

.

call func_3

ID2:

.

.

.

check ID1

call *(fptr)

ID2:...

check ID2ret

check ID1

call *(fptr)

ID2:...

check ID2ret

ID1:...

check ID2

ret

cal() : func_2 () :

func_1 () :

func_3 () :

bool func_1 ( int a ){

return a < 0?;

}

func_2 ( int x) {

func_1 ( x );

}

func_3 ( int y) {

func_1 ( y );

}

cal ( int a, int b) {

func_2 (a);

func_3 (b);

}

Fig. 3. An example of program fragment and coarse-grained CFI.

If the instruction can jump to multiple target addresses, allthese IDs will be compared to determine whether the jump islegal. This incurs high performance overhead.

Fig. 3 shows an example of coarse-grained CFI with fewerIDs to reduce the performance overhead, much like CCFIR[9] and Bin-CFI [12]. There are two kinds of control flowtransitions in this example. The first one is the function pointerfptr pointing to function func 1() (in function func 2() andfunc 3()), and the other is the function return of func 2(),func 3(), cal(), or func 1(). In order to avoid any maliciousmodification on the target address of fptr due to ROP or JOPattacks, CFI adds the ID1 checking (check ID1) for verifyinglegal jumps from the source (function func 2() and func 3())to the destinations of fptr (functions func 1()). Any illegaljumps to other destinations will not pass the check ID1 becausethere are no ID1 inserted at those target addresses. Meanwhile,CFI also adds the ID2 checking (check ID2) for verifyinglegal returns from the call functions to the callsite to avoidmalicious modifications on the return addresses in the stack.Any changes to other return addresses will not pass the checkID2 because there are no ID2 inserted at illegal addresses.This CFI introduces fewer IDs (for instance, the Bin-CFImechanism introduces two IDs), the verification overhead islower than the ideal CFI. However, with the increasing ofgadgets of the same ID, the attack would be success withhigher probability. For example, the jump from func 1 tofunc 3 (red) shown in Fig. 3 is illegal but cannot be detectedwith this CFI.

As described above, fine-grained CFI and coarse-grainedCFI have their own strengths and weaknesses. Fine-grainedCFI has higher security, while coarse-grained CFI incurs lowerperformance overhead. Therefore, the security and practicalityshould be balanced. Our proposed method in this paper showsa good balance between security and practicality comparedwith previous CFI methods because HCIC incurs low perfor-mance and is able to resist mainstream CRAs.

V. THE PROPOSED HARDWARE-ASSISTED CFI

In this study, we assume that the program code is trust-worthy and the attacker cannot modify the source code of theprogram that has been loaded into memory. In addition, weassume that the attacked system has deployed DEP that forcesthe attacker to reuse existing code. We further assume that

IEEE XXX, VOL. XX, NO. X, 2018. 6

Program

PUFE

Memory

Instruction Cache High Performance

CPU Pipeline

profile

load

Judger

EHDME EHDMD PUFD

call ret jmp

Hardware-assisted CFI Module

Non-Control Flow

Instruction

Conventional

Processor

Fig. 4. Basic framework of HCIC

the attacker can access the stack to perform overflow attacksand CRAs. The details of the proposed hardware-assisted CFIchecking are depicted in figures 4, 5 and 6 and described asfollows.

A. Encrypted Hamming Distance

Hamming distance (HD) is a number used to denote thedifference between two binary strings. Let x and y be twobinary sequences of the same length. The HD d(x,y) betweenx and y is the number of positions at which the correspondingsymbols are different:

d(x, y) =

n−1∑i=0

x[i]⊕

y[i] (1)

where i = 0, 1, ..., n-1; x, y denotes n-bit binary sequence; ⊕denotes exclusive OR.

One of key contributions in this paper is that the encryptedHamming distance (EHD) matching method is proposed toresist ROP, where the EHD is generated by appending randoml bits at the end of d(x,y) and then rotating right m bits. In thispaper, l can be the first 2-bit in the PUF key; m can be thelast 3-bit in the key (ranges from 0 to 7). Since the addressis 32 bits, the HD ranges from 0 to 32, and requires 6 bitsto encode. If the HD is rotated right m bits, the result wouldrepeat when m = 6 & m = 0, likewise, when m = 1 & m = 7and so on. This would increase the possibility that attackersguess the correct HD. To address this issue, we insert 2-bit lat the end of the HD and then rotate the new HD right m bits.In this way, there are 8 possible shifted results for the HD,and there are no repeated results for rotating right.

B. Framework of HCIC

The framework of hardware-assisted CFI checking is shownin Fig. 4. Judger is to determine whether the instructionis the control flow instruction. If the fetched instruction isthe control flow instruction, the next instruction would beprocessed by the hardware-assisted CFI Module, while non-control flow instruction is fed to the conventional processor.There are four key operations, EHD matching-based encoding(EHDME), EHD matching-based decoding (EHDMD), PUF-based encoding (PUFE) and PUF-based decoding (PUFD),

Program

PUF Generates

keys

Encrypt the

instructions

Program is

loaded into

memory

Program

executes

Call instruction?

Ret instruction?

jmp instruction?

Compute the EHD

and push it in the

stack

Compute the EHD

and compare with

pre-stored EHD

Same?

Decrypt the

instruction

The instruction

execute normally?

Program exits

abnormally

Y

N

Y

N

YN

Y NN Y

Fig. 5. The flow of HCIC

involving in our proposed HCIC. EHDME and EHDMD areused to encode and verify the EHDs to resist ROP attacks.PUFE and PUFD are used to resist JOP attacks. The wholeflow of HCIC is shown in Fig. 5.

A ret instruction will bring the program execution to anaddress which is pushed into the stack by a call instruction.But an attacker is able to modify the address by overflowattacks. We should guarantee the ret instruction targeting thenext instruction of the corresponding call instruction. The jmpinstructions and call instructions also should be limited topoint to the encrypted instructions which belong to the firstinstructions of basic blocks (BBs). We elaborate it as follows.

CALL and RET: To prevent attackers from changing thereturn address of a ret instruction via the memory overflowand then hijacking program control flow, EHDME would firstcompute the encrypted Hamming distance EHD1 between thekey 2 generated by PUF and the return address when the callinstruction is executed. Then, the return address and EHD1 arepushed into the stack. When the ret instruction is executed,EHDMD would compute the encrypted Hamming distanceEHD2 between key 2 and the current popped return addressagain. Only the EHD2 is equal to the pre-stored encryptedHamming distance EHD1, can the program jump normally.Once the return address was overflowed at run-time or there isno paired call for ret instructions, the EHD2 would be unequalto EHD1 because the PUF key is unknown to the attacker.Hence, the execution cannot point to the code that attackersintend to perform.

CALL and JMP: We use XOR operation to linearlyencrypt/decrypt the first instruction at target address of jmp

IEEE XXX, VOL. XX, NO. X, 2018. 7

CPU

Cache

Memory

Fetch

Insturction

Commit

Decode

Execute

IR

Access

Memory

XOR

KEY_LEN_1

KEY_1

KEY_2

PUF

EHDCC

DC

liner_enc. Inst.

liner_dec.inst

ret.addr. or

liner_enc. inst.

key_1

key_2

key_2

key_1

key_length_1

Calculate EHD

store as parameter

campare

KEY_LEN_2

key_length_2

Fig. 6. Micro-architecture and data flow of HCIC. 1© key 1 is used tolinearly encrypt the first instruction at target address of jmp and call via XORoperation. 2© Perform XOR operation on return address of call instructionwith key 2 or the first instruction at target address of jmp instruction andcall instruction with key 1. 3© key 1 is used to linearly decrypt the firstinstruction at target address of jmp and call instruction via XOR operation. 4©Calculate the encrypted Hamming distance EHD1 between the return addressand key 2. 5© When call instruction is executed, EHD1 is pushed into thestack as a parameter. 6© When ret instruction is executed, the encryptedHamming distance EHD2 between key 2 and the current popped returnaddress is calculated and transmitted into the decision circuit (DC) whichjudges whether EHD2 is equal to the pre-stored EHD1.

and call in order to prevent attackers from hijacking programcontrol flow. Before program is loaded into memory, the key 1generated by PUF is used to encrypt all first instructions attarget addresses (PUFE). When a program is running, as longas the jmp or call instruction is executed, the first instructionwill be decrypted dynamically with key 1 (PUFD). Thus, ifattackers hijack program control flow via illegally changingthe target address of jmp and call, the program may jumpto an address with an unencrypted instruction which wouldbe decrypted forcedly. If an incorrect decrypted instructionis executed, a system error may occur. Thus, JOP attackswould be defeated if an attacker wants to use indirect branchinstructions to perform code reuse attacks.

Fig. 6 depicts the hardware structure of our proposedmechanism, as shown in the purple area, and how it in-teracts with CPU. The hardware structure is appended toCPU architecture with a XOR operation unit, 4 regis-ters (KEY 1,KEY 2,KEY LEN1,KEY LEN2), a PUFmodule, an encrypted Hamming distance calculation circuit(EHDCC) and a decision circuit (DC). CPU communicateswith XOR unit; the registers and PUF communicate withEHDCC and XOR; DC communicates with EHDCC. KEY 1and KEY 2 used in XOR operation are generated by the PUFmodule and stored in KEY 1 and KEY 2 registers. The rea-son we use two keys is to solve the security vulnerability thatthe work [18] suffered. It is well-known that if the program hasbeen loaded into memory, the code can’t be tampered anymore.Hence, JOP attacks are unable to break the defense. However,through JOP attack, the attacker can deduce the secret keyused for linear encryption by memory leakage or debugging.

If the defense mechanism exploits a single secret key in allXOR operations, attackers can calculate correct EHDs of everyaddress for ROP attacks. To eliminate the vulnerability, weexploit two different secret keys for the encryption/decryptionoperation. The key length of key1 and key2 is determined bythe KEY LEN 1 and KEY LEN 2 registers. Here thelength of key 1 is x which is less than the length of shortestfirst instruction, and the length of key 2 is 32 bits. The valueof KEY LEN 1 and KEY LEN 2 registers are x and 32,respectively. After receiving the XOR result, the encryptedHamming distance of current return address is calculated inEHDCC and then is sent to DC. The DC will judge whetherthe calculated encrypted Hamming distance is equal to thepreviously stored one.

In our proposed HCIC, the first step is to perform XORoperation on all first instructions at target addresses of calland jmp instructions for linear encryption before the programis loaded into memory. Next, when jmp is executed, the firstinstruction at target address will be decrypted dynamically.When the call instruction is executed, XOR and EHDCC willbe used to calculate the encrypted Hamming distance betweenreturn address and key 2 and store it in stack, and then thefirst instruction at target address is decrypted and executed.When ret instruction is executed, XOR and EHDCC will beused to calculate the encrypted Hamming distance betweenreturn address and key 2, and then the DC judges whether theprogram control flow is normal by comparing the calculatedEHD and the previously stored one.

The concrete process of HCIC is as follows:1) When the program is started up, CPU calls silicon-PUF

module to generate key 1 and key 2 and stores them inKEY 1 and KEY 2 registers, respectively. Accordingto the rule proposed above, the length of key 1 andkey 2 are generated and stored in KEY LEN 1 andKEY LEN 2, respectively.

2) Before loading program into memory, CPU searchestarget addresses of all call and jmp instructions andtransmits every first instruction to XOR.

3) XOR unit performs XOR operation on every first instruc-tion for linear encryption unit according to key length 1and key 1 and returns the result to CPU.

4) After all the first instructions being encrypted, programis loaded into memory and starts up.

5) In the executing process, memory transmits the programinstruction to Cache in real time. CPU will fetch theinstruction from Cache and then decrypt it. When callinstruction is fetched, jump to the step 6) to perform;when ret instruction is fetched, jump to the step 9) toperform; when jmp instruction is fetched, jump to thestep 13) to perform; if the program is done, exit normally.

6) Transmit the return address of call instruction to XOR.7) XOR unit performs XOR operation on return address

with key length 2 and key 2, and sends the result toEHDCC.

8) EHDCC calculates the encrypted hamming distance be-tween current return address and key 2 according to thereceived result. Then the encrypted Hamming distanceis pushed into stack as a parameter of call instruction,

IEEE XXX, VOL. XX, NO. X, 2018. 8

-PUF em in

respectively. According to key_2 are

generated and stored in KEY_LEN_1 and KEY_LEN_2,

CPU searches target jmp instructions and transmits

XOR operation on every first

0x08048546: call 80484f3 <func>

0x0804854b: add $0x10, %esp

.

.

0x080484f3: push %ebp

0x080484f4: mov %esp, %ebp

0x080484f6: sub $0x78, %esp

.

.

.

0x0804851f: ret

main():

func():

0x080486f1: int 0x80

0x084753e popa

0x084753f jmp [eax+0xe3]

.

.

0x084753e add %edx, %eax

0x0847541 jmp %ecx

.

.

0x08476e3 int 0x80

gadget1:

gadget2:

gadget3:

a) An example to resist ROP attacks. b) An example to resist JOP attacks. Fig. 7. Examples to resist CRAs. a) An example to resist ROP attacks. b)An example to resist JOP attacks.

following the return address. Jump to the step 13) toperform.

9) Transmit the return address of ret instruction to XOR.10) XOR unit performs XOR operation on return address with

key length 2 and key 2, and sent the result to EHDCC.11) EHDCC calculates the EHD between current return ad-

dress and key 2 according to the received result and sendsthe encrypted Hamming distance to DC.

12) DC unit receives the EHD from EHDCC and compares itwith pre-stored EHD. If the comparing result is the same,program continues to perform, and jump to the step 5);if not, jump to the step 16).

13) Program jumps to target address of call or jmp instruction.When the instruction at target address is loaded in CPU,the content of IR register is transmitted to XOR.

14) XOR unit performs XOR operation toward the instructionwith key length 1 and key 1 for linear encryption andreturns the result to IR register of CPU.

15) CPU executes the instruction which has been decryptedwithin IR register. If the decrypted instruction is executednormally, jumps to 5); if not, program exits abnormally.

16) The attack is detected; system produces warning andwaits to be processed.

In what follows, we use a 32-bit CISC instruction architec-ture to illustrate the key idea of our approach. In this case,a n-bit PUF is used to encode n-bit instruction at the targetaddress of call and jmp instruction and compute the EHD.We give two examples to demonstrate how code-reuse attackswould fail in attacking programs protected by the HCIC. Asan example, as shown in Fig. 7a), a CALL instruction divertsexecution to the entry point of a function func(). Assume thereturn address A1 is 0x0804854b and key 2 is 0xa2156cf7.The HD between A1 and key 2 is 16 (010000). ‘01000010’ isgenerated by padding the first 2-bit ‘10’ of key 2 to ‘010000’.Then ‘01000010’ is rotated right 7 bits to get the encryptedHamming distance EHD1 132 (10000100) which is pushedinto the stack. If an attacker has overflowed the return addressin order to perform the instruction “int 0x80” at the addressA2 (0x080486f1), the overflowed address A2 will be fetchedwhen RET is executed. However, the encrypted Hammingdistance EHD2 between A2 and key 2 is computed withXOR and EHDCC. DC determines whether EHD1 is equal

to EHD2. Because the attacker doesn’t know the PUF key,EHD1 (132) is not equal to EHD2 (108). In this case, theprogram would throw an exception and generate a warning.Hence, the program will not perform the intended instruction“int 0x80”.

As another example, as shown in Fig. 7b), we assume anattacker overflows the program successfully to perform JOPattacks. When the jmp in gadget1 is executed, the programwould be deviated to the gadget2. However, the XOR wouldbe used to decrypt the target instruction “add %edx, %eax”.The decryption would be wrong for the target instructionbecause this unintended instruction didn’t be encoded by XORoperation. Hence, our proposed HCIC can efficiently thwartthe code reuse attacks.

VI. EXCEPTION ANALYSIS AND HANDLING

In complex binaries, there are some exceptions to the normalbehavior of call, ret, and jmp. For example, most of thepreviously proposed CFI methods that strictly follow call-retpairing would result in false positives even for the normalcontrol flow of the program when call-ret pair is replaced bycall-jmp pair. In this section, we will discuss exceptional casesin detail, and prove that our proposed defense doesn’t producethese anomalies.

Case 1: the jmp instruction replaces the ret instruction totarget the return address.

There are two cases that the jmp instruction will replace theret instruction to target the return address: 1) the longjmp()function in the C language. After longjmp() function is ex-ecuted, indirect jmp instruction targets the return address in-stead of ret; 2) the compiler sometimes replaces ret instructionswith the pop and jmp instructions. In these cases, a CFI policywhich strictly follows call-ret pairing would result in falsepositives.

HCIC doesn’t result in false positives in these cases. Whenthe call instruction is executed, the return address of thefunction is pushed into stack with the EHD. When the functionis done, the jmp instruction instead of the ret instruction willbe executed to target the return address. In addition, the firstinstruction at the target address of the jmp has been encryptedbefore the program is loaded into memory. Therefore, whenthe jmp instruction instead of the ret instruction is executed,the program will decrypt and execute the first instruction atthe target address successfully. The stack space of the functionwill be reclaimed after the function is done.

Case 2: call-ret instructions appear in different orderFor the shadow stack technique, all threads share the same

shadow stack. In a multithreaded program, thread A executesthe call instruction, the return address R1 is pushed into theshadow stack. Then thread B executes the call instruction, thereturn address R2 is pushed into the shadow stack successively.In this case, if thread A executes the ret instruction beforeB, R1 will be popped to compare with the R2 at the top ofthe shadow stack, which would throw an exception due tothe mismatch. In order to handle this exception, the returnaddress is allowed to match all addresses in the shadow stack,which increases the performance overhead greatly. In our

IEEE XXX, VOL. XX, NO. X, 2018. 9

proposed method, the exception doesn’t be produced in themulti-threaded program because all call functions have theirown stack and the EHDs between the PUF key and their returnaddresses are stored in the stack without affecting each other.

Case 3: ret instruction returns to a non-return addressIn the C++ exception handling mechanism, an exception

is thrown when the program executes the throw() function.After the throw() is done, the program will jump directly withthe ret instruction to the end of the try block instead of thenext instruction after the throw(). In this case, some defenses[44] will produce an exception since the return address is notthe return address stored in the shadow stack when the callinstruction is executed. In order to handle the exceptional case,[44] extended rules by adding the exception handler landingpad addresses in the .eh frame and .gcc except table to theshadow stack so that the return address of the ret instructionin throw() can be matched in the shadow stack. However, inour experiments, we found that the throw() function eventuallyjumps to the end of the try block by the jmp instruction insteadof the ret instruction.

HCIC doesn’t produce the exception. Similar to the case 1,when throw() function is executed, the return address of thefunction is pushed into stack with the EHD. When the throw()function is done, the jmp instruction is executed to target theend of the try block. In HCIC, the first instruction at the targetaddress of the jmp has been encrypted before the program isloaded into memory. When the jmp instruction is executed,the program will decrypt and execute the first instruction atthe target address successfully. Therefore, the throw() functioncan be executed normally with the jmp instruction. The stackspace of the function will be reclaimed after the function isdone.

VII. SECURITY ANALYSIS

For code reuse attacks, attackers first make use of thestack overflow to overwrite the return address to execute thefirst gadget, and then the ret/jmp/call instructions of gadgetsare used to change the control flow between gadgets, whichfinally enables the attackers to execute malicious actions. Theproposed HCIC can prevent the buffer overflow and codereuse attacks. Stack smashing and ROP attacks are basedon overwriting of the return address. Our technique securesthe target address of the ret instruction by the EHDMEand EHDMD operations. Therefore, these attacks can beprevented. JOP attack uses the target address of indirect jmpand call instruction which is limited to point to the firstinstructions of BBs. Because a part of first instructions ofBBs have been encoded by the PUFE operation before theexecutable binary is loaded into memory, if any call and jmpinstructions illegally change the control flow to the instructionwhich is not the first instruction of the BBs, the instructionwould be wrongly decoded by the PUFD operation. With thePUF key updating, even the illegal control flow between BBswill be prevented. Thus, all the common attacks to the controlflow can be prevented by our method. In what follows, thefive important security threats or metrics are analyzed.

A. The key leakage issue

In [18], the simple XOR operation is used to encrypt thereturn address in the stack and the instructions at the targetaddresses of the indirect jmp instructions. This scheme suffersthe following key leakage issues:

1) Attackers can get the original and encrypted returnaddress by debugging and then deduce the secret keythrough the XOR operation.

2) Attackers can get the original and encrypted instructionby debugging and then deduce the secret key through theXOR operation.

HCIC is to calculate and compare the EHD between thereturn address and the secret key to resist the ROP attack,and decrypt the instruction at the target address of jmp andcall instructions to resist the JOP attack. Although the returnaddress and the EHD between the return address and the secretPUF key are pushed into the stack, the attacker cannot deducethe key with the EHD and the address. Therefore, HCICresolves the above key leakage issue and hence exhibits thehigher security.

In addition, HCIC uses two registers KEY 1 and KEY 2to store different PUF keys against JOP and ROP, respectively,which further improves the security. If the EHD calculationand the instruction encryption use the same key, attackers canget the key key 1 used for JOP defense by debugging, andthen use key 1 to crack the ROP defense. With different PUFkeys for EHD calculation and instruction encryption, evenif the attacker can obtain the key 1 in the JOP defense bydebugging, key 1 cannot be used for ROP attacks. Moreover,the key 1 cannot be used to launch JOP attack anymorebecause HCIC will encrypt the instructions before the programloaded into memory and decrypt the instructions dynamicallywhen the program is running (It is well-known that if theprogram has been loaded into memory, the code can’t betampered anymore). Therefore, HCIC does not suffer the keyleakage issues.

B. EHD guessing attacks

In our proposed ROP defense, if attackers guess the correctEHD between the return address and key 2, the defense wouldbe compromised. Take an extreme case for example, there isa call instruction in front of a gadget, and there is just a bitdifference between the return address R1 and the address ofthe gadget R2. In this case, the probability that attackers guessthe correct m is 1/8 (m ranges from 0 to 7). Assuming the HDbetween R1 and key 2 is HD1, and the HD between R2 andkey 2 is HD2. Since there is just 1-bit difference between R1and R2, the difference between HD1 and HD2 would be 1 or -1. Under the premise of guessing the correct m, the probabilitythat attackers guess the correct HD2 between R2 and key 2is 1/2. Hence, the probability that attackers guess the correctEHD between R2 and key 2 would be 1/8*1/2=1/16. Inaddition, the ROP gadgets chain is composed of at leastthree gadgets. Therefore, in the worst and extreme case, theprobability that an attacker could successfully perform a ROPattack is 1/4096.

IEEE XXX, VOL. XX, NO. X, 2018. 10

C. Advanced CRAs

Full-function reuse attacks are advanced CRAs that fullfunctions are used as gadgets. There are many indirect call/jmpinstructions existing in a program, attackers may use them toconduct full-function CRAs. For example, RIPE [47] contains80 attacks that use indirect call instructions. If an attackeruses indirect call/jmp instructions to conduct thus advancedCRAs, most current defenses such as ASLR [24]–[26], shadowstack [27]–[29], gadgets checking [30] and CFI [17], [18], [44]would be bypassed. For example, shadow stack techniquesallow the return address to be any address in the shadow stackto avoid an exception thrown in the case of multithread andlongjmp(), so it is vulnerable to full-function CRAs.

It is possible for attackers to bypass our ROP defensewith the return-based full-function reuse. First, in the attackpreparation phase, attackers traverse the program to find outall the available full-functions as gadgets. Then, they recordthese full-functions’ return addresses and the correspondingEHDs when the program is running. Finally, attackers replacethe return address and EHD in the stack with one of recordedavailable full-functions’ return addresses and the correspond-ing EHD to hijack the control flow. This advanced CRAs canbe prevented with our proposed key-updating method whichcan invalidate previous recorded addresses and EHDs.

The key-updating algorithm is shown below. The inputs tothe algorithm are 32-bit PUF key key 2, return address andthe count of counter. Count is initialized to 0 when the keyis generated. The outputs of the algorithm are the EncryptedHamming distance (See Section V.A) and the updated key.At the beginning of the algorithm, l is initialized to the first2 bits of key 2, and m is initialized to the last 3 bits ofkey 2. A counter is used to record the number of times ofthe key 2 used. When the call instruction is executed, thecounter is increased by 1; when the ret instruction is executed,the counter is decreased by 1. When the counter is reduced to0, the key will be updated immediately.

However, our defense mechanism is vulnerable to a moreadvanced CRA, COOP [45]. As a new emerged full-functionreuse attack in C ++ Applications, COOP uses virtual func-tions as gadgets and doesn’t need to modify the function’sreturn address so that CFIC is unable to detect such attack.We therefore assume auxiliary protections for virtual calls. Forexample, we assume that VTrust is deployed with about addi-tional 0.72% performance overhead [53]. In other words, weassume virtual function calls are well-protected. In addition,non-control-data attacks [54] [46] that may lead to control-flow hijacking are out of the scope of this paper.

D. False positive/negative rate

The profiling of the program needs to be done at the compiletime to obtain the CFG information. To increase the coverage,the program has to run several times with different set ofvalid inputs. Because it is difficult to get complete CFG, falsepositive may occur in all CFI checking schemes. For example,if the legal target addresses of some call or jmp instructions arenot covered by the profiled CFG, the program would producean error resulting in false positives when the program decrypts

Algorithm: key-updating

1 Input: 32-bit key_2, return address and count

2 Output: EHD and the updated key_2

3 Initialize: l and m

4 if the instruction is a indirect call then

5 count=count+1

6 for n=0, 1, …, 31 do

7 hd [n] = key_2 [n] address[n]

8 end for

9 insert l at the end of the hd

10 EHD=rotate hd right m bits

11 else if the instruction is a return then

12 count=count-1

13 for n=0, 1, …, 31 do

14 hd [n] = key_2 [n] address[n]

15 end for

16 insert l at the end of the hd

17 EHD=rotate hd right m bits

18 if count == 0 then

19 Update the key_2

20 end if

21 end if

unencrypted instructions at that addresses. The false-positivecan be reduced with a CFG as precise as possible. On the otherhand, if attackers can use full-functions as gadgets to launchadvanced CRAs, the false-negative will occur. However, mostof advanced CRAs can be detected with CFIC. Therefore, intheory, the false negative rate would be extremely low.

VIII. EXPERIMENTAL RESULTS AND ANALYSIS

The SPEC CPU2006 [48], BioBench [49], MiBench [50]and Stream benchmarks [51] are used in our experiment. Thesebenchmarks are compiled using the GNU GCC version 4.9.2at O3 optimization level on Ubuntu-15.04. Pin [52] is usedto get the target addresses of jmp and call instructions andthe instructions at the target addresses for pre-processing ofbenchmarks. We use RIPE [47], which contains 850 bufferoverflow attacks, to evaluate the defense capability of ourproposed mechanism.

A. Evaluation on RIPE Benchmark Attacks

RIPE consists of 850 buffer-overflow attacks which canbypass ASLR and perform code injection, return-into-libc, andROP on the stack, heap, BSS, and data segment. Our testresults show that in the case of disabling DEP, 419 attacksout of 850 attacks in RIPE can be successful. However, allof them were detected by our defense mechanism. In thecase of enabling DEP, 60 attacks out of 850 attacks in RIPEwere successful, and all of them were detected by our defensemechanism. Among the 850 attacks, most of them tamper thereturn addresses of ret instructions, such as code injection,

IEEE XXX, VOL. XX, NO. X, 2018. 11

return-into-libc, and ROP. Since our defense mechanism limitsthe return address to be the address of the next instruction ofthe corresponding call instruction by computing and matchingEHD, these attacks get detected. Some attacks tamper thetarget addresses of indirect jmp instructions and indirect callinstructions to redirect the control flow to the gadgets. Sinceour proposed method encrypts the instructions at the targetaddresses of all jmp instructions and call instructions beforethe program loaded into memory and decrypts the instructionsdynamically when the program is running, if the target addressof an indirect jmp or call instruction is tampered, the programwould decrypt an unencrypted instruction and eventually exe-cutes an unintended instruction that causes the attack to fail.Therefore, these attacks get detected.

TABLE IGADGETS ELIMINATION TESTED BY ROPGADGET-V5.4

Benchmark TotalGadgets

AllowedGadgets

GadgetsElimination rate

mcf 11927 0 100%hmmer 15802 0 100%

libquantum 12531 0 100%h264ref 17820 0 100%

lbm 12304 0 100%blowfish 12140 0 100%phylip 13466 0 100%

specrand 11591 0 100%stream 11549 0 100%

basicmath 14664 0 100%patricia 13188 0 100%

sha 13304 0 100%Average 100%

B. Gadgets Elimination

We use the gadgets reduction as a metric to evaluate ourdefense mechanism. In general, attackers use the gadgets toperform CRAs, so the allowed gadgets reduction is one ofthe important metrics to evaluate a defense mechanism. Forexample, the average gadgets reduction for a previous work[44] is 99.381%. The reason of the allowed gadgets stillexisting in this defense mechanism is that there are someBBs can be exploited to perform a ROP. HCIC limits thereturn address to be the address of the next instruction ofthe corresponding call instruction, so the attacker is difficultto use BBs to perform ROP attacks. We use ROPGadget-v5.4[5] to scan the binary to get all the gadgets in the programand get the number of allowed gadgets which are used tobypass the defense mechanism and perform CRAs. Table 1gives the number of gadgets, allowed gadgets and the gadgetsreduction rate for different benchmarks with HCIC. The testresults show that HCIC can effectively reduce the allowedgadgets (the allowed gadgets are 0 and the gadgets reductionrate achieves 100%).

C. False positive/negative

The same with all other CFIs, HCIC would produce falsepositive if the legal target addresses of some call or jmpinstructions are not covered by the profiled CFG. Therefore,

ld decrypt an unencrypted instruction and eventually executes an unintended

attacks

to evaluate our general, attackers use the gadgets to

perform CRAs, so the allowed gadgets reduction is one of the important metrics to evaluate a defense mechanism. For

previous work [42] xisting in

there are some BBs can be . As discussed in Section VI.C,

limits the return address to be the address of the next

Benchmark Total Allowed Reduction

11927 0 100%

hmmer 15802 0 100%

libquantum 12531 0 100%

h264ref 17820 0 100%

12304 0 100%

blowfish 12140 0 100%

phylip 13466 0 100%

specrand 11591 0 100%

stream 11549 0 100%

basicmath 14664 0 100%

patricia 13188 0 100%

Fig. 8. Average Indirect Target Reduction (AIR)

96%

97%

98%

99%

100%

Fig. 8. Average Indirect Target Reduction (AIR).

during profiling, to increase the coverage, we run each bench-mark thousands of times with different set of valid inputsto get the possible target addresses of all the jmp and callinstructions. Our experimental results show that the falsepositive is 0% with HCIC. Besides, we evaluated the falsenegative with RIPE and analyzing gadgets reduction. Ourexperimental results show that HCIC can detect all attacksin the RIPE and reduce the gadgets by 100%, which meansthe false negative rate of our defense mechanism is 0%.

TABLE IIRUNTIME OVERHEAD

Benchmark Originalruntime(s)

Resultruntime(s)

Runtimeoverhead

mcf 2.652508 2.684364 1.2%hmmer 0.003413 0.003450 1.08%

libquantum 0.004010 0.004041 0.77%h264ref 29.620388 30.010754 1.31%

lbm 2.753622 2.763091 0.34%blowfish 0.000741 0.000752 1.5%phylip 0.002136 0.002159 1.1%

specrand 0.023326 0.023489 0.7%stream 1.105379 1.111355 0.54%

basicmath 0.284601 0.284694 0.03%patricia 0.076869 0.077837 1.25%

sha 0.037029 0.037612 1.57%Average 0.95%

TABLE IIIBINARY SIZE OVERHEAD

Benchmark OriginalSize(B)

ResultSize(B)

Binary Sizeoverhead

mcf 761244 767145 0.7753%hmmer 1119396 1130997 1.0364%

libquantum 853244 859221 0.7005%h264ref 780604 781334 0.0935%

lbm 781872 786030 0.5318%blowfish 764524 767004 0.3244%phylip 858452 864139 0.6625%

specrand 743580 748150 0.6147%stream 752128 758546 0.8534%

basicmath 803960 812411 1.0512%patricia 748032 756532 1.1363%

sha 747808 759476 1.5603%Average 0.7783%

IEEE XXX, VOL. XX, NO. X, 2018. 12

TABLE IVCOMPARISON OF SECURITY AND PRACTICALITY

Security Practicality

Level Keyleakage

ISAExtensions

Compilermodification

Binary Sizeincreasement

PerformanceOverhead

CFI(CCS’05 [31]) I \ N N High(8%) High(21%)

CCFI(CCS’15 [34]) I N Y Y Y1 High(52%)

SOFIA(DATE’16 [15]) II N N N Y1 High(110%)

LEA(DAC16’ [18]) II Y N N Low(0.78%) Low(0.9%)

HECFI(DAC’16 [15]) III \ Y Y High(13.5%) Low(1.75%)

LEA-AES(TCAD17 [17]) II N Y Y Low(0.78%) Low(3.2%)

Our proposedHCIC II N N N Low(0.78%) Low(0.95%)

1 The authors did not give the data of binary size overhead.

D. Average Indirect Target Reduction (AIR)

In general, attackers hijack the normal control flow of theprogram and perform CRAs by tampering the target addressesof indirect jmp instructions. Therefore, reducing the numberof indirect targets can reduce the successful probability thatattackers conduct CRAs. So, the reduction of indirect targets isone of the important metrics to evaluate a defense mechanism.The average indirect target reduction (AIR) metric [12] is usedto evaluate the reduction of indirect targets, as Eq. (2) shows.

AIR = 1/n

n∑j=1

(1− |Tj |/S) (2)

where, n is the number of indirect jmp instructions, Tj is thenumber of indirect target addresses, S is the size of binarycode.

In HCIC, all call instructions target the beginning of func-tions, all jmp instructions target the starting address of BBs,and all ret instructions target the next instructions of thecorresponding call instructions. Hence, the number of targetaddresses for call instructions is given by the number of func-tions, and the number of target addresses for jmp instructionsis given by the number of BBs. For the ret instructions, thenumber of target addresses is always 1. Then Eq. (2) can besimplified to Eq. (3).

AIR = 1− (|Tcall|+ |Tjmp|+ 1)/3S (3)

where, Tcall is the number of functions and the Tjmp isthe number of BBs. Fig. 8 shows the estimation of AIR onbenchmarks with HCIC. The reduction of indirect targets isgreater than 99.8%, which means that HCIC can eliminatealmost all indirect targets.

E. Performance and Binary Size Overhead

HCIC computes and matches the EHD, and decrypts theinstructions at the target addresses of the call and jmp in-structions when the program is running, which would generatethe run-time overhead. In our experiments, we insert an “andl%eax, %eax” instruction in the beginning and ending of each

function, and insert an “andl %eax, %eax” instruction beforeeach call and jmp instruction. The reason for inserting the“andl %eax, %eax” instruction is that this instruction willnot modify the value of the register and the program can beexecuted normally. As shown in Table 2, the average run-timeoverhead is 0.95%, which is far less than the performanceoverhead of traditional CFIs.

Because the sequential execution of encrypted instructionswill produce the false positive (i.e., the first loop of thedo-while statement), we insert a jmp instruction before theinstruction at the target address of jmp instruction to ensurethat the program can run normally. The target address of theinserted jmp instruction is the next encrypted instruction’saddress. We just insert one instruction before the instructionat the target address of the jmp instruction. Therefore, HCICproduces very low binary size overhead. As shown in Table3, the average binary size overhead is just 0.78%.

F. Comparison of Security and PracticalityWe compare HCIC with recent methods [31] [34] [35] [18]

[15] [17] [53]. Security and practicality are two most importantmetrics to evaluate current CRA defenses. Practicality is eval-uated by ISA extensions, compiler modification, binary sizeincreasement and performance overhead. Security is evaluatedby the key leakage and security level. We divide the securitylevel of defense machinises into the following four levels:

• Level-I: Only defend against ROP;• Level-II: defend against ROP and JOP;• Level-III: defend against ROP, JOP and some advanced

CRAs such as COOP;• Level-IV: defend against all potential CRAs.As shown in Table 4, our proposed HCIC doesn’t need to

extent ISA, modify compiler, and incurs low binary size andperformance overheads. Besides, HCIC can achieve the level-II without leaking the key. It is worth noting that HCIC can beenriched with VTrust [53] (VTrust protects virtual call onlyand cannot prevent against ROP and JOP) to defend againstCOOP with additional 0.72% performance overhead. Obvi-ously, our proposed HCIC shows the best balance betweensecurity and practicality.

IEEE XXX, VOL. XX, NO. X, 2018. 13

IX. CONCLUSION

This paper proposes a hardware-assisted CFI checking tech-nique to resolve the vulnerabilities that current software-basedCFI incurs high performance and hardware-based may requireextending the existing processors’ ISAs or suffer some securityvulnerabilities. The key technique involves two control flowverification mechanisms. The first one is to compute EHDs be-tween the PUF response and the return addresses, then verifieswhether the EHDs are matched to make attackers impossible toreturn between gadgets, thus resisting ROP attacks. The secondone is to perform the liner XOR operation between PUF keyand the instructions at target addresses of call and jmp instruc-tions once the executable binary is loaded into memory, thenthe run-time liner decryption operation can be done when jmpand call instructions are executed, thus defeating JOP attacks.The experiment results show that the proposed new techniqueincurs extremely low performance overhead (average 0.95%)and binary size overhead (average 0.78%), which are muchlower than traditional CFI approaches. Exception analysisshows that our proposed defense doesn’t produce anomalieswhen some exceptional cases occurred. Security analysis alsoshows that the proposed method is sound and secure againstcode reuse attacks with zero false positive and negative rates.

Coarse-grained CFI is more vulnerable to function reuseattacks than fine-grained CFI which validates call sites beyondjust the target address considering elements such as expectedVTable type, validating number of arguments, or even argu-ment types, for a given indirect call. A key tradeoff betweenthe two approaches is performance, as introducing too muchcomplexity into a CFI policy can add significant overhead.Considering this, current deployed CFI schemes in industryare almost coarse-grained CFI such as Microsoft’s ControlFlow Guard and Intel’s Control-flow Enforcement Technology.HCIC is able to prevent ROP, JOP and return-based full-function reuse attacks, and can be enriched with auxiliaryprotections to prevent virtual function reuse with additionalsmall performance penalty. Our proposed method shows agood balance between security and practicality.

REFERENCES

[1] S. Checkoway, L. Davi, A. Dmitrienko, A.-R. Sadeghi, H. Shacham, andM. Winandy, “Return-oriented programming without returns,” in Proc.ACM CCS, 2010, pp. 559-572.

[2] K. Z. Snow, F. Monrose, L. Davi, A. Dmitrienko, C. Liebchen, andA. R. Sadeghi, “Just-in-time code reuse: On the effectiveness of fine-grained address space layout randomization,” in Proc. IEEE Symposiumon Security and Privacy, 2013, pp. 574-588.

[3] T. Bletsch, X. Jiang, V. W. Freeh, and Z. Liang, “Jump-oriented program-ming: a new class of code-reuse attack,” in Proc. ACM Symposium onInformation, Computer and Communications Security, 2011, pp. 30-40.

[4] P. Chen, X. Xing, B. Mao, L. Xie, X. Shen, and X. Yin, “Automaticconstruction of jump-oriented programming shellcode (on the x86),” inProc. ACM Symposium on Information, Computer and CommunicationsSecurity, 2011, pp. 20-29.

[5] Jonathan Salwan, “ROPgadget - Gadgets finder and auto-roper,” 2011.[6] A. S. Jonathan Afek, “Smashing the pointer for fun and profit,” Blackhat

07, 2007.[7] P. Team,“Pax non-executable pages design & implementation” .[8] M. Abadi, M. Budiu, . Erlingsson, and J. Ligatti, “Control-flow integrity

principles, implementations, and applications,” ACM Trans. Inf. Syst.Secur., vol. 13, no. 1, pp. 1-40, 2009.

[9] C. Zhang et al., “Practical Control Flow Integrity and Randomization forBinary Executables,”in IEEE Symposium on Security and Privacy, 2013,pp. 559-573.

[10] M. Kayaalp, M. Ozsoy, N. Abu-Ghazaleh, and D. Ponomarev, “Effi-ciently Securing Systems from Code Reuse Attacks,” IEEE Transactionson Computers, vol. 63, no. 5, pp. 1144-1156, 2014.

[11] M. Budiu, U. Erlingsson, and M. Abadi, “Architectural support forsoftware-based protection,” in Proc. workshop on Architectural andsystem support for improving software dependability, 2006, pp. 42-51.

[12] M. Zhang and R. Sekar, “Control Flow and Code Integrity for COTS bi-naries,”in Proceedings of the 31st Annual Computer Security ApplicationsConference, 2015, pp. 91-100.

[13] L. Davi, P. Koeberl, and A.-R. Sadeghi, “Hardware-assisted fine-grainedcontrol-flow integrity: Towards efficient protection of embedded systemsagainst software exploitation,”in DAC, 2014, pp. 1-6.

[14] L. Davi et al., “HAFIX: Hardware-Assisted Flow Integrity Extension,”in Proc. Annual Design Automation Conference, 2015, pp. 1-6.

[15] D. Sullivan, O. Arias, L. Davi, P. Larsen, A.-R. Sadeghi, and Y. Jin,“Strategy without tactics: Policy-agnostic hardware-enhanced control-flow integrity,” in Proceedings of the 53rd Annual Design AutomationConference, 2016, pp. 1-6.

[16] N. Christoulakis, G. Christou, E. Athanasopoulos, and S. Ioannidis,“HCFI: Hardware-enforced Control-Flow Integrity,” in Proceedings of theSixth ACM on Conference on Data and Application Security and Privacy,2016, pp. 38-49

[17] P. Qiu, Y. Lyu, J. Zhang, D. Wang, and G. Qu, “Control Flow Integritybased on Lightweight Encryption Architecture,” IEEE Trans. Comput.Des. Integr. Circuits Syst., pp. 1-1, 2017.

[18] P. Qiu, Y. Lyu, J. Zhang, X. Wang, D. Wang, and G. Qu,, “Physicalunclonable functions-based linear encryption against code reuse attacks,”in Proceedings of the 53rd Annual Design Automation Conference, 2016,pp. 1-6.

[19] J. Zhang, G. Qu, Y. Lv, and Q. Zhou, “A Survey on Silicon PUFs andRecent Advances in Ring Oscillator PUFs,” J. Comput. Sci. Technol., vol.29, no. 4, pp. 664-678, Jul. 2014.

[20] F. Koushanfar, “Provably Secure Active IC Metering Techniques forPiracy Avoidance and Digital Rights Management,” IEEE Trans. Inf.Forensics Secur., vol. 7, no. 1, pp. 51-63, 2012.

[21] J. Zhang, Y. Lin, Y. Lyu, and G. Qu, “A PUF-FSM Binding Schemefor FPGA IP Protection and Pay-Per-Device Licensing,” IEEE Trans. Inf.Forensics Secur., vol. 10, no. 6, pp. 1137-1150, Jun. 2015.

[22] J. Zhang, Y. Lin, and G. Qu, “Reconfigurable Binding against FPGAReplay Attacks,” ACM Trans. Des. Autom. Electron. Syst., vol. 20, no. 2,pp. 1-20, Mar. 2015.

[23] S. Designer, “‘return-to-libc’ attack,” Bugtraq.2007.[24] S. Bhatkar, R. Sekar, and D. C. DuVarney, “Efficient techniques for

comprehensive protection from memory error exploits,” in Proc. Conf.USENIX Security Symposium, 2005, pp. 17-17.

[25] V. Pappas, M. Polychronakis, and A. D. Keromytis,“Smashing theGadgets: Hindering Return-OrientedProgramming Using In-place CodeRandomization,” in IEEE S&P, 2012, pp. 601-615.

[26] R. Wartell, V. Mohan, K. W. Hamlen, and Z. Lin,“Binary stirring: self-randomizing instruction addresses of legacy x86 binary code,” in Proc.ACM CCS, 2012, p. 157.

[27] M. Frantzen and M. Shuey, “StackGhost: Hardware facilitated stackprotection,” in USENIX Security Symposium, 2001, pp. 55-66.

[28] T. H. Y. Dang, P. Maniatis, and D. Wagner, “The Performance Cost ofShadow Stacks and Stack Canaries,” in Proc. ACM Symp. Information,Computer and Communications Security, 2015, pp. 555-566.

[29] Intel corporation, “Intel Control-flow Enforce-ment Technology,” 2017. [Online]. Available:https://software.intel.com/sites/default/files/managed/4d/2a /control-flow-enforcement-technology-preview.pdf.

[30] P. Chen, H. Xiao, X. Shen, X. Yin, B. Mao, and L. Xie, “DROP:Detecting Return-Oriented Programming Malicious Code,” in Proc. Int.Inf. Sys. Sec., pp. 163-177, 2009.

[31] M. Abadi, M. Budiu, U. Erlingsson, and J. Ligatti,“Control-flow in-tegrity,” in Proc. ACM Conf. Comput. Commun. Secur., pp. 340-353, 2005.

[32] A. K. Kanuparthi, M. Zahran, and R. Karri, “Feasibility study of dy-namic Trusted Platform Module,” in Proc. IEEE International Conferenceon Computer Design, 2010, pp. 350-355.

[33] S. Gueron, “Intel advanced encryption standard (aes) new instructionsset,” Intel Corpor, 2010. .

[34] A. J. Mashtizadeh, A. Bittau, D. Boneh, and D. Mazires, “Cryptograph-ically Enforced Control Flow Integrity,” in Proc. ACM CCS, 2015, pp.941-951.

IEEE XXX, VOL. XX, NO. X, 2018. 14

[35] R. de Clercq, et al, “SOFIA: Software and control flow integrityarchitecture,” Proceedings of the 2016 Conference on Design, Automation& Test in Europe, pp.1172-1177, 2016.

[36] C. Herder, M.-D. Yu, F. Koushanfar, and S. Devadas, “Physical Un-clonable Functions and Applications: A Tutorial,” Proc. IEEE, pp. 1-16,2014.

[37] G. E. Suh and S. Devadas, “Physical Unclonable Functions for DeviceAuthentication and Secret Key Generation,” in 44th ACM/IEEE DesignAutomation Conference, 2007.

[38] M. Gao, K. Lai, and G. Qu, “A Highly Flexible Ring Oscillator PUF,”in Proceedings of the The 51st Annual Design Automation Conference onDesign Automation Conference, 2014, pp. 1-6.

[39] Z. Pang, J. Zhang, Q. Zhou, S. Gong, X. Qian, and B. Tang, “CrossoverRing Oscillator PUF,” in 18th International Symposium on QualityElectronic Design (ISQED), 2017, pp. 237-243.

[40] M. Majzoobi, M. Rostami, F. Koushanfar, D. S. Wallach, and S.Devadas, “Slender PUF Protocol: A Lightweight, Robust, and SecureAuthentication by Substring Matching,” in IEEE Symposium on Securityand Privacy Workshops, 2012, pp. 33-44.

[41] F. Tehranipoor, N. Karimina, K. Xiao, and J. Chandy, “DRAM basedIntrinsic Physical Unclonable Functions for System Level Security,” inProceedings of the 25th edition on Great Lakes Symposium on VLSI,2015, pp. 15-20.

[42] A. Maiti and P. Schaumont, “A novel microprocessor-intrinsic PhysicalUnclonable Function,” in Int. Conf. Field Programmable Logic andApplications (FPL), 2012, pp. 380-387.

[43] E. Goktas, E. Athanasopoulos, H. Bos, and G. Portokalidis, “Out ofControl: Overcoming Control-Flow Integrity,” in IEEE S&P, 2014, pp.575-589.

[44] S. Das, W. Zhang, and Y. Liu, “A Fine-Grained Control Flow IntegrityApproach Against Runtime Memory Attacks for Embedded Systems,”IEEE Trans. Very Large Scale Integr. Syst., vol. 24, no. 11, pp. 3193-3207, Nov. 2016.

[45] F. Schuster et al., “Counterfeit Object-oriented Programming On theDifficulty of Preventing Code Reuse Attacks in C ++ Applications,” inProc. IEEE S&P, pp. 745-762, 2015.

[46] N. Carlini, A. Barresi, M. Payer, D. Wagner, and T. R. Gross,“Control-Flow Bending: On the Effectiveness of Control-Flow Integrity,” inUSENIX Security Symposium, 2015, pp. 161-176.

[47] J. Wilander, N. Nikiforakis, Y. Younan, M. Kamkar, and W. Joosen,“RIPE: runtime intrusion prevention evaluator,” in Proc. 27th Annu.Comput. Secur. Appl. Conf., pp. 41-50, 2011.

[48] J. L. Henning, “SPEC CPU2006 benchmark descriptions,” ACMSIGARCH Comput. Archit. News, vol. 34, no. 4, pp. 1-17, Sep. 2006.

[49] K. Albayraktaroglu et al., “BioBench: A Benchmark Suite of Bioinfor-matics Applications,” in IEEE International Symposium on PerformanceAnalysis of Systems and Software, 2005, pp. 2-9.

[50] M. R. Guthaus, J. S. Ringenberg, D. Ernst, T. M. Austin, T. Mudge, andR. B. Brown, “MiBench: A free, commercially representative embeddedbenchmark suite,” in Proceedings of the Fourth Annual IEEE Interna-tional Workshop on Workload Characterization. 2001, pp. 3-14.

[51] J. McCalpin, “Stream Benchmark.” [Online]. Available:https://www.cs.virginia.edu/stream/.

[52] Naftaly S., “Pin - A Dynamic Binary Instrumentation Tool,” 2012. [On-line]. Available: https://software.intel.com/en-us/articles/pin-a-dynamic-binary-instrumentation-tool.

[53] C. Zhang et al., “VTrust: Regaining Trust on Virtual Calls,” in Proceed-ings of Network and Distributed System Security Symposium, 2016.

[54] S. Chen, J. Xu, E. C. Sezer, P. Gauriar, and R. K. Iyer, “Non-controldataattacks are realistic threats,” in Usenix Security Symposium, 2005.

Jiliang Zhang received the Ph.D. degree in Com-puter Science and Technology from Hunan Uni-versity, Changsha, China in 2015. From 2013 to2014, he worked as a Research Scholar at theMaryland Embedded Systems and Hardware Se-curity Lab, University of Maryland, College Park.From 2015 to 2017, he was an Associate Professorwith Northeastern University, China. Since 2017,he has joined Hunan University. He has authoredover 30 papers in refereed international conferencesand journals such as the IEEE TRANSACTIONS

ON INFORMATION FORENSICS AND SECURITY, IEEE TRANSAC-TIONS ON COMPUTER-AIDED DESIGN of Integrated Circuits and Sys-tems, IEEE TRANSACTIONS ON VERY LARGE SCALE INTEGRA-TION, ACM Transactions on Design Automation of Electronic Systems, andACM/IEEE Design Automation Conference. His current research interestsinclude hardware/hardware-assisted security, artificial intelligence security andemerging technologies.

2017

Binhang Qi is a visiting student at Hunan Univer-sity, China. His current research interests includehardware-assisted security.

Gang Qu received the B.S. and M.S. degrees inmathematics from the University of Science andTechnology of China, in 1992 and 1994, respec-tively, and the Ph.D. degree in computer sciencefrom the University of California, Los Angeles, in2000. Upon graduation, he joined the University ofMaryland at College Park, where he is currentlya professor in the Department of Electrical andComputer Engineering and Institute for SystemsResearch. He is also a member of the MarylandCybersecurity Center and the Maryland Energy Re-

search Center. Dr. Qu is the director of Maryland Embedded Systems andHardware Security Lab and the Wireless Sensors Laboratory.

His primary research interests are in the area of embedded systemsand VLSI (Very Large Scale Integration) CAD (Computer Aided Design)with focus on low power system design and hardware related security andtrust. He studies optimization and combinatorial problems and applies histheoretical discovery to applications in VLSI CAD, wireless sensor network,bioinformatics, and cybersecurity. Dr. Qu has received many awards for hisacademic achievements, teaching, and service to the research community. Heis a senior member of IEEE and serving as associate editor for the IEEETransactions on Computers, IEEE Embedded Systems Letters and Integration,the VLSI Journal.