A compiler-based program branch data integrity protection method, system, device and medium

Abstract

A compiler-based program branch data integrity protection method, system, device and medium, the method: when the program is data flow integrity protection, input program intermediate code in the program, and control dependence analysis is carried out on the input program intermediate code, the program to be protected is obtained Control flow related branch data, and the source point of the branch data is located by inputting into the static value flow analysis algorithm, then according to the source point of the branch data, generate program data flow graph, at the same time, save the source point of the branch data to the runtime definition table, when the program runs, according to the data address index, the corresponding source point in the runtime definition table is saved, and the safety of the runtime definition table is protected through Intel MPK hardware, finally, judge whether the source point is in the range of program data flow graph, if yes, continue to execute the program, otherwise, throw an exception; The system, device and medium are used for realizing the compiler-based program branch data integrity protection method; The present application has the advantages of high safety, low system overhead and wide compatibility.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of data flow integrity (DFI), and particularly relates to a compiler-based program branch data integrity protection method, system, device and medium. BACKGROUND

[0002] Non-control data attacks make attackers no longer need to inject and execute their own code, as long as the exploitable part (such as a function that allows running with administrator privileges) existing in the target program is identified, and then by changing the value in the program data structure, the unauthorized access function can be accessed. Some existing methods that are effective against control data attacks cannot detect non-control data attacks. Dynamic taint analysis marks foreign input data as taint and tracks the propagation path, and performs security checks according to the security policy at the designated security-sensitive instruction, but since it needs to track foreign input, the overhead is often high. Data randomization (DSR) is a randomization process for memory data, and then different masks are assigned to different equivalence classes, and are XORed with the actual numerical value. However, in the calculation of equivalence classes, the analysis algorithm is not accurate, resulting in too large equivalence classes, and attackers can bypass the defense measures. Dynamic information flow tracking (DIFT) is similar to dynamic taint analysis, and the basic idea is to mark (pollute) untrusted external data or sensitive internal data, and track their propagation in the system. Unlike dynamic taint analysis, when the processor detects an instruction operation on untrusted data, a trap is generated and is processed by the trap processor. Data flow integrity protection (DFI) is currently the mainstream solution for defending against non-control data attacks. Initially, DFI adopts a method of maintaining a runtime definition table (RDT) to protect the integrity of data flow. Specifically, the actual definition reachability analysis is performed on each variable at runtime, and the identifier of the last write instruction of the variable is stored in the runtime definition table (RDT). When a variable is read, the identifier in the RDT table is indexed by the variable address, and then it is checked whether the identifier exists in the static data flow graph (DFG). If it does not exist, the data flow integrity is broken, and an exception is thrown. However, its security depends on the accuracy of the DFG generated by the static definition reachability analysis, and since all non-control data is protected, there is a problem of excessive system overhead. Selecting part of the sensitive non-control data in the program for protection is an effective means to solve the problem of excessive system overhead, and has been extensively studied by many scholars.

[0003] SCHLESINGER C et al. disclose Modular protections against non-control data attacks (SCHLESINGER C, PATTABIRAMAN K, SWAMY N, et al. Modular protections against noncontrol data attacks [J]. Journal of Computer Security, 2014, 22(5): 699-742.), hereinafter referred to as YARRA, YARRA protects the key data types by declaring the key data types and dividing the key data types into important data to be protected, the data can only be written by the pointer with the given static type characteristics, and any invalid write (including the possible coverage due to buffer overflow) is detected at the dynamic runtime, but when the key data is too large or the application program is computationally intensive, YARRA has the disadvantage of excessive performance overhead, the overhead exceeds 400%.

[0004] SONG C et al. disclose HDFI: Hardware-assisted data-flow isolation (SONG C, MOON H, ALAM M, et al. HDFI: Hardware-assisted data-flow isolation [C] / / 2016 IEEE Symposium on Security and Privacy (SP). 2016: 1-17.), HDFI has low performance overhead because it protects part of the non-control data, but HDFI introduces a new instruction set, resulting in the disadvantage of being unable to be widely applied, and is limited by the hardware characteristics and the newly introduced instruction set, and has the disadvantage of poor compatibility.

[0005] SONG C et al. disclose Enforcing Kernel Security Invariants with Data Flow Integrity (SONG C, LEE B, LU K, et al. Enforcing Kernel Security Invariants with Data Flow Integrity. [C / OL] / / Network and Distributed System Security Symposium. 2016. https: / / api.semanticscholar.org / CorpusID: 63019167.), KENALI mainly protects part of data in the kernel, and the performance overhead is relatively low, but KENALI needs much hardware support, and therefore does not have universality.

[0006] LIU T et al. disclose TMDFI: Tagged memory assisted for fine-grained data-flow integrity towards embedded systems against software exploitation (LIU T, SHI G, CHEN L, et al. TMDFI: Tagged memory assisted for fine-grained data-flow integrity towards embedded systems against software exploitation [C] / / 2018 17th IEEE International Conference On Trust, Security And Privacy In Computing And Communications / 12th IEEE International Conference On Big Data Science And Engineering (TrustCom / BigDataSE). 2018: 545-550.), TMDFI adopts an integrity protection scheme based on a tag technology, but TMDFI has only 256 tags, and is only applicable to small programs, and cannot be applied to large programs. SUMMARY

[0007] In order to overcome the above-mentioned shortcomings of the prior art, the purpose of the present application is to provide a compiler-based program branch data integrity protection method, system, device and medium, by performing control dependence analysis on the program to obtain the branch data to be protected, then using a static value flow analysis algorithm to obtain the branch data source point, and forming a program data flow graph; when the program is running, verifying whether the data source point is destroyed, achieving the purpose of program data flow integrity protection, having the characteristics of safety, high efficiency and high universality, and being applicable to large programs.

[0008] In order to achieve the above-mentioned purpose, the technical solution adopted by the present application is:

[0009] A compiler-based program branch data integrity protection method, comprising static analysis and program runtime verification;

[0010] When performing data flow integrity protection on the program, the static analysis is performed, comprising the following steps:

[0011] Step 1: inputting program intermediate code (LLVM-IR), and performing control dependence analysis on the input program intermediate code (LLVM-IR) to obtain the branch data to be protected related to the control flow in the program;

[0012] Step 2: transmitting the branch data obtained in step 1 into a static value flow analysis algorithm to locate the source point of the branch data;

[0013] Step 3: generating a program data flow graph (DFG) according to the branch data source point obtained in step 2;

[0014] When the program is running, the program runtime verification is performed, comprising the following steps:

[0015] Step S1: saving the branch data source point obtained in step 2 into a runtime definition table (English name RuntimeDefinitions Table, RDT), then searching the corresponding source point in the runtime definition table (RDT) according to the data address index, and protecting the safety of the runtime definition table (RDT) through Intel MPK hardware;

[0016] Step S2: judging whether the source point searched in step S1 is within the range of the program data flow graph (DFG) generated in step 3, if yes, continuing to execute the program, and if no, throwing an exception.

[0017] The step 1 specifically comprises:

[0018] Firstly, the program intermediate code (LLVM-IR) is passed as input to the Pass framework of the LLVM compiler, and the Pass framework controls the control dependence analysis algorithm to analyze the control dependence of the program, including the completeness analysis and the last analysis, wherein the completeness analysis is to analyze all branch data related to the control flow in the program, and the last analysis is to analyze the last branch data related to the control flow in the program;

[0019] The control dependence analysis algorithm has the following specific steps:

[0020] Step 1.1: Initialize the set of branch data (Condition_DataSet) to be protected, and provide two analysis methods, namely the last analysis and the completeness analysis;

[0021] Step 1.2: Loop through all program instructions in the program, and determine whether the current instruction is a control flow instruction. If the current instruction is a control flow instruction, go to step 1.3. If the current instruction is not a control flow instruction, continue to step 1.2;

[0022] Step 1.3: Analyze all the aforementioned basic blocks (BasicBlock) of the control flow instruction in step 1.2;

[0023] Step 1.3.1: If step 1.1 selects the last analysis, then according to the distance from the control flow from near to far, analyze whether the termination instruction of the aforementioned basic block obtained in step 1.3 is a conditional branch instruction, find the last conditional branch instruction with the control flow, and add the branch data to the set of branch data to be protected, and continue to step 1.2;

[0024] Step 1.3.2: If step 1.1 selects the completeness analysis, then analyze whether the termination instruction of all the aforementioned basic blocks obtained in step 1.3 is a conditional branch instruction, and add all the branch data obtained by the analysis to the set of branch data to be protected, and continue to step 1.2;

[0025] Step 1.4: All program instructions in step 1.2 are traversed, and the analysis is completed.

[0026] The step 2 specifically includes:

[0027] The Pass framework of the LLVM compiler passes the branch data as input to the source point auxiliary context-sensitive static value flow analysis algorithm to obtain the source point of the branch data, wherein the source point instruction is defined as the instruction in the program that last assigns the data, and the operand of the instruction is not a function parameter. When the operand of the source point instruction is a function parameter, it is necessary to further backtrack the source point of the branch data in the program;

[0028] The static value flow analysis algorithm specifically includes the following steps:

[0029] Step 2.1: Initialize worklists, add sensitive data instructions to the worklists, and assign the to-be-analyzed sensitive data to a temporary variable (temp_val);

[0030] Step 2.2: Loop through the worklists in step 2.1 until the definition instruction (Alloca) of the sensitive data is found to end the loop:

[0031] Step 2.2.1: Determine whether the temporary variable (temp_val) after assignment in step 2.1 is a function parameter. If it is a function parameter, obtain its callee and continue the value flow analysis in the callee until the source point is found and the loop is terminated.

[0032] Step 2.2.2: Determine whether the temporary variable (temp_val) after assignment in step 2.1 is a phi instruction, and backtrack the source points of the two branches of the phi instruction respectively, and terminate the program.

[0033] Step 2.2.3: Determine whether the temporary variable (temp_val) after assignment in step 2.1 is a select instruction. Unlike the analysis of the phi instruction, the select instruction only needs to backtrack the analysis of one operand, and the program is terminated.

[0034] Step 2.2.4: When the temporary variable (temp_val) after assignment in step 2.1 is not in the cases of steps 2.2.1-2.2.3, reassign the operand of the temporary variable (temp_val) instruction after assignment in step 2.1 to the temporary variable (temp_val) instruction itself, and add the instruction to the worklists, end the judgment, and re-enter the step 2.2.1 loop.

[0035] Step 2.3: Based on the definition instruction (Alloca) of the sensitive data found in step 2.2, traverse the instructions of the entire function, find all the write instructions based on the def-use relationship, and write the found write instructions into the source instruction set (write_insts).

[0036] Step 2.4: Further judge the write instruction obtained in step 2.3. Determine whether the operand (valueOpearnd) of the write instruction is a function parameter. If it is a function parameter, obtain its callee and continue the value flow analysis in the callee until the source point is found and the loop is terminated.

[0037] The tuple of the program data flow graph (DFG) generated in step 3 is defined as [I i ,I o ,Origin], wherein I i represents the branch instruction itself, I o represents the origin point instruction itself, and Origin is the origin point value.

[0038] The step S1 comprises:

[0039] The Pass framework of the LLVM compiler saves the origin point located by the static value flow analysis in the form of key-value pairs (key, value), wherein the key is the origin point address, and the value is the origin point value, and the safety of the runtime definition table (RDT) is protected by the Intel MPK hardware, and the step specifically comprises the following steps:

[0040] Step S1.1: The runtime definition table (RDT) is a piece of memory area protected by the Intel MPK for the context information, and the access permission of the memory area is set to be inaccessible;

[0041] Step S1.2: When there is context information to be saved, the access permission of the memory area applied in step S1.1 is set to be readable, and the entry to be stored is retrieved;

[0042] Step S1.3: After the relevant entry is retrieved in step 1.2, the access permission of the memory area applied in step S1.1 is set to be writable, and the context information is written;

[0043] Step S1.4: After the writing in step 1.3 is completed, the access permission of the memory area applied in step S1.1 is immediately set to be inaccessible;

[0044] Step S1.5: When the program executes to the module to be verified, the access permission of the memory area applied in step S1.1 is set to be readable, and the relevant information is found for verification;

[0045] Step S1.6: After the verification in step S1.5 is completed, the access permission of the memory area applied in step S1.1 is set to be inaccessible.

[0046] The step S2 comprises:

[0047] The Pass framework of the LLVM compiler generates an executable program after program instrumentation of a program is completed, and when execution reaches a sensitive branch instruction, the program looks up a source point value in a runtime definition table (RDT) according to an address of the branch data, and forms a program data flow tuple, and further judges whether the program data flow tuple is in a program data flow graph (DFG), if the program data flow tuple is in the program data flow graph (DFG), the program continues to execute, if the program data flow tuple is not in the program data flow graph (DFG), an exception is thrown.

[0048] A system based on a compiler-based program branch data integrity protection method, comprising:

[0049] A static analysis module: input program intermediate code (LLVM-IR), and perform control dependence analysis on the input program intermediate code (LLVM-IR), obtain branch data to be protected in the program related to the control flow, then pass the branch data into a static value flow analysis algorithm, locate the source point of the branch data, and generate a program data flow graph (DFG);

[0050] A program runtime verification module: save the source point of the branch data to a runtime definition table (RDT), then look up the corresponding source point in the runtime definition table (RDT) according to the data address index, and protect the safety of the runtime definition table (RDT) through Intel MPK hardware, judge whether the source point is within the range of the program data flow graph (DFG), if yes, continue to execute the program, if no, throw an exception.

[0051] A compiler-based program branch data integrity protection device, comprising:

[0052] A memory: used for storing a computer program for implementing a compiler-based program branch data integrity protection method;

[0053] A processor: used for implementing the compiler-based program branch data integrity protection method when the computer program is executed.

[0054] A computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the compiler-based program branch data integrity protection method.

[0055] Compared with the prior art, the present application has the following advantages:

[0056] 1. The present application is based on program intermediate code (LLVM-IR) for static analysis, and the Pass framework is used for static instrumentation and rewriting of the program, which has the advantages of high universality and can be applied to large-scale application programs.

[0057] 2. The application selects and controls the part of non-control data related to the control flow for integrity protection, and innovatively proposes two control dependence analysis algorithms, namely completeness analysis and last analysis, which respectively focus on all conditional branch data and the last conditional branch data related to the control flow, and eliminate some non-sensitive data, so that the system has the characteristics of low overhead.

[0058] 3. The application introduces the source point as a context concept for realizing data flow integrity protection, acquires the source point of sensitive data through a static value flow analysis algorithm, and introduces the source point into the tuple definition of a program data flow graph, so that the system has the characteristics of high security.

[0059] 4. The application adopts Intel MPK hardware to protect the runtime definition table, and through the conversion between the readable, writable and inaccessible permissions of the memory region, the memory has the characteristics of high security.

[0060] In summary, the application has the advantages of low overhead, high security and high universality, and can be applied to large-scale application programs. BRIEF DESCRIPTION OF DRAWINGS

[0061] Figure 1 It is a program structure diagram of the application.

[0062] Figure 2 It is a control dependence analysis algorithm diagram adopted by the embodiment of the application.

[0063] Figure 3 It is a static value flow analysis algorithm diagram adopted by the embodiment of the application.

[0064] Figure 4 It is an Intel MPK hardware protection runtime definition table (RDT) principle diagram of the application.

[0065] Figure 5 It is a comparison diagram of the number of layers required for the last analysis of the embodiment of the application.

[0066] Figure 6 It is a comparison of the data protection amount of the completeness analysis and the last analysis of the embodiment of the application.

[0067] Figure 7 It is a system overhead comparison diagram of the embodiment of the application. DETAILED DESCRIPTION

[0068] The application will be described in detail below with reference to the drawings.

[0069] As shown in the figure, a compiler-based program branch data integrity protection method comprises static analysis and program runtime verification. Figure 1

[0070] ​When the data flow integrity protection is performed on the program, the static analysis is performed, including the following steps:

[0071] Step 1: first, the source program is converted into program intermediate code (LLVM-IR) by the LLVM compiler, then the input program intermediate code (LLVM-IR) is input, and control dependence analysis is performed on the input program intermediate code (LLVM-IR) to obtain branch data related to control flow in the program to be protected, and according to different security requirements of the user on the system, complete analysis or the last analysis can be selected;

[0072] Step 2: the branch data obtained in step 1 is transmitted into a static value flow analysis algorithm, and the source point of the branch data is located, and in the present application, only the last assignment instruction for the sensitive data needs to be found, and the assignment of the instruction is not a function parameter, so that the purpose of avoiding unnecessary analysis and reducing the complexity of analysis is achieved, and at the same time, it is assumed that the attacker has attack authority for the function stack space, so when the value of the assignment is a function parameter, it is still not trusted;

[0073] Step 3: according to the branch data source point obtained in step 2, a program data flow graph (DFG) is generated, and the purpose is to verify whether the data flow integrity is destroyed during the program running;

[0074] When the program runs, the program runtime verification is performed, including the following steps:

[0075] Step S1: the branch data source point obtained in step 2 is saved to a runtime definition table (English name RuntimeDefinitions Table, RDT), and then the corresponding source point in the runtime definition table (RDT) is found according to the data address index, and the safety of the runtime definition table (RDT) is protected by the Intel MPK hardware;

[0076] Step S2: it is judged whether the source point found in step S1 is within the range of the program data flow graph (DFG) generated in step 3, if yes, the program continues to be executed, and if no, an exception is thrown.

[0077] The step 1 specifically includes:

[0078] First, the program intermediate code (LLVM-IR) is transmitted as input to the Pass framework of the LLVM compiler, and the Pass framework performs control dependence analysis on the program by a control dependence analysis algorithm, and the control dependence analysis includes complete analysis and last analysis, the complete analysis is to analyze all branch data related to control flow in the program, and the last analysis is to analyze the last branch data related to control flow in the program;

[0079] The control dependence analysis algorithm aims to obtain branch data related to control flow, which is based on IR to identify sensitive branch data in the instruction set of the program for further analysis and processing. According to the selection judgment condition, the branch data is not empty (Condition_DataSet is not empty) or the current basic block is the initial basic block (isEntryBB(curbb)), respectively, the latest analysis and completeness analysis are performed. The control dependence analysis algorithm input is the program IR file, and the output is the branch data related to the control flow. The specific steps are as follows:

[0080] Step 1.1: Initialize the protected branch data (Condition_DataSet) set, and provide two analysis methods, namely the latest analysis and the completeness analysis.

[0081] Step 1.2: Loop through all program instructions in the program, and judge whether the current instruction is a control flow instruction. If the current instruction is a control flow instruction, go to step 1.3. If the current instruction is not a control flow instruction, continue to step 1.2.

[0082] Step 1.3: Analyze all the aforementioned basic blocks (BasicBlock) of the control flow instruction in step 1.2.

[0083] Step 1.3.1: If step 1.1 selects the latest analysis, then according to the distance from the control flow from near to far, analyze whether the termination instruction of the aforementioned basic block obtained in step 1.3 is a conditional branch instruction, find the last conditional branch instruction closest to the control flow, and add the branch data to the protected branch data set, and continue to step 1.2.

[0084] Step 1.3.2: If step 1.1 selects the completeness analysis, then analyze whether the termination instruction of all the aforementioned basic blocks obtained in step 1.3 is a conditional branch instruction, and add all the branch data obtained by analysis to the protected branch data set, and continue to step 1.2.

[0085] Step 1.4: All program instructions in step 1.2 are traversed, and the analysis is completed.

[0086] The control dependence analysis algorithm is implemented as shown in Figure 2 :

[0087] (1) The first line initializes the Condition_DataSet set, and the 16th line returns the conditional dependence data set obtained by analysis;

[0088] (2) The loop in lines 2-16 traverses all instructions in the program until the entire program IR is traversed; line 4 judges whether the instruction is an indirect call, and lines 5-12 are conditional dependence data analysis for the indirect call, specifically, line 6 obtains all previous basic blocks of the current basic block;

[0089] (3) Lines 7-10 traverse all basic blocks until the current basic block is the function entry basic block, and the loop ends, note that if the Condition_DataSet set is not empty, the loop is exited, and this analysis method is suitable for the last analysis method. Line 8 judges whether the end instruction of the basic block is a conditional branch instruction, and if it is, the branch data is added to the Condition_DataSet set.

[0090] The step 2 specifically comprises:

[0091] The Pass framework of the LLVM compiler passes the branch data as input to the source point auxiliary context-sensitive static value flow analysis algorithm to obtain the source point of the branch data, wherein the source point instruction is defined as the instruction in the program that last assigns the data, and the operand of the instruction is a non-function parameter, and when the operand of the source point instruction is a function parameter, the branch data needs to be further traced back to the source point in the program;

[0092] The static value flow analysis algorithm inputs the sensitive data to be analyzed, and outputs the inter-process instruction based on the def-use chain and the write instruction where the source point is located, and specifically comprises the following steps:

[0093] Step 2.1: Initialize the worklist (worklists), add the sensitive data instruction to the worklist (worklists), and assign the sensitive data to be analyzed to a temporary variable (temp_val);

[0094] Step 2.2: Loop iteration is performed on the worklist (worklists) in step 2.1 until the definition instruction (Alloca) of the sensitive data is found, and the loop ends:

[0095] Step 2.2.1: Judge whether the temporary variable (temp_val) after assignment in step 2.1 is a function parameter, if it is a function parameter, obtain its callee, and continue to perform value flow analysis in the callee until the source point is found, and the loop is terminated;

[0096] Step 2.2.2: Judge whether the temporary variable (temp_val) after assignment in step 2.1 is a phi instruction, and backtrack the source point according to the two branches of the phi instruction, and terminate the program;

[0097] Step 2.2.3: If the temporary variable (temp_val) after the assignment in step 2.1 is a select instruction, unlike the analysis of phi instructions, the select instruction only needs to be backtracking analyzed on one of its operands, and the program is terminated;

[0098] Step 2.2.4: When the temporary variable (temp_val) after the assignment in step 2.1 is not in the cases of steps 2.2.1-2.2.3, the operand of the temporary variable (temp_val) instruction after the assignment in step 2.1 is re-assigned to the temporary variable (temp_val) instruction itself, and the instruction is added to the work list (worklists), the judgment is ended, and the step 2.2.1 loop is re-entered;

[0099] Step 2.3: Based on the definition instruction (Alloca) of the sensitive data found in step 2.2, the instructions of the entire function are traversed, all write instructions are found based on the def-use relationship, and the found write instructions are written into the source point instruction set (write_insts);

[0100] Step 2.4: Further judgment is made on the write instruction obtained in step 2.3, to judge whether the operand (valueOpearnd) of the write instruction is a function parameter, if it is a function parameter, the callee is obtained, and the value flow analysis is continued in the callee until the source point is found, and the loop is terminated.

[0101] The tuple of the program data flow graph (DFG) generated in the step 3 is defined as [I i ,I o ,Origin], wherein, I i represents the branch instruction itself, I o represents the source point instruction itself, and Origin is the source point value.

[0102] The specific implementation of the static value flow analysis algorithm is shown in Figure 3 :

[0103] (1) First, the algorithm initializes a work list worklists in lines 1-3, adds the sensitive data instruction to the list, and assigns the sensitive data to be analyzed to temp_val;

[0104] (2) Lines 4-19 loop iterate on the work list until the definition (Alloca) instruction of the sensitive data is found, and the loop is terminated:

[0105] a) Among them, lines 5-8 judge whether temp_val is a function parameter, if it is a function parameter, the callee is obtained, and the value flow analysis is continued in the callee until the source point is found, and the loop is terminated;

[0106] b) Lines 9-11 determine whether temp_val is a phi instruction, and backtrack to its source point according to the two branches of phi, and terminate the program;

[0107] c) Lines 12-14 determine whether temp_val is a select instruction. Unlike the analysis of phi instructions, select only needs to perform backtracking analysis on one of its operands and then terminate the program.

[0108] d) Lines 15-18, except for the cases mentioned above, reassign the operand of the temp_val instruction to itself, add the instruction to worklists, end the if conditional statement, and re-enter the loop;

[0109] (3) Line 20 is based on the Allca instruction obtained from the above analysis. It iterates through the instructions of the entire function, finds all the write instructions based on the def-use relationship, and writes them into the write_insts set.

[0110] (4) Lines 21-26 further judge the write instruction obtained from the above analysis, and determine whether its valueOpearnd is a function parameter. If it is a function parameter, obtain its callee and enter the callee to continue value flow analysis until its source point is found and the loop terminates.

[0111] Step S1 includes:

[0112] like Figure 4 As shown, the LLVM compiler's Pass framework saves the source points located by static value stream analysis into the Runtime Definition Table (RDT) in the form of key-value pairs (key, value), where the key is the source point address and the value is the source point value. The security of the Runtime Definition Table (RDT) is protected by Intel MPK hardware, specifically including the following steps:

[0113] Step S1.1: The Runtime Definition Table (RDT) is a memory region protected by IntelMPK that the program requests for context information at runtime. Set the access permissions of the memory region to inaccessible.

[0114] Step S1.2: When context information needs to be saved, set the memory area access permissions requested in step S1.1 to readable, and retrieve the entries that need to be stored;

[0115] Step S1.3: After the relevant entry is retrieved in step 1.2, the memory region access permissions requested in step S1.1 are set to writable, and the context information is written.

[0116] Step S1.4: When the writing of step 1.3 is completed, immediately set the memory region access permission of the step S1.1 application to be inaccessible;

[0117] Step S1.5: When the program execution reaches the module that needs to be verified, set the memory region access permission of the step S1.1 application to be readable, and find the relevant information for verification;

[0118] Step S1.6: When the verification of step S1.5 is completed, set the memory region access permission of the step S1.1 application to be inaccessible.

[0119] The step S2 comprises:

[0120] The Pass framework of the LLVM compiler generates an executable program after the program is instrumented, and when the program is running, the program looks up the source point value in the runtime definition table (RDT) according to the address of the branch data, and forms a program data flow tuple, and further judges whether the program data flow tuple is in the program data flow graph (DFG), if the program data flow tuple is in the program data flow graph (DFG), the program continues to execute, if the program data flow tuple is not in the program data flow graph (DFG), an exception is thrown, so as to judge whether the branch data integrity is damaged.

[0121] The system based on the compiler-based program branch data integrity protection method comprises:

[0122] The static analysis module: input program intermediate code (LLVM-IR), and perform control dependence analysis on the input program intermediate code (LLVM-IR), obtain the branch data to be protected in the program related to the control flow, then pass the branch data into the static value flow analysis algorithm, locate the source point of the branch data, and generate a program data flow graph (DFG), which is used to realize steps 1-3 of the compiler-based program branch data integrity protection method;

[0123] The program runtime verification module: saves the branch data source point to the runtime definition table (RDT), then indexes and looks up the corresponding source point in the runtime definition table (RDT) according to the data address, and protects the safety of the runtime definition table (RDT) through the Intel MPK hardware, judges whether the source point is within the range of the program data flow graph (DFG), if yes, the program continues to execute, if no, an exception is thrown, which is used to realize steps S1-S2 of the compiler-based program branch data integrity protection method.

[0124] A compiler-based program branch data integrity protection device comprises:

[0125] Memory: for storing a computer program for implementing a compiler-based program branch data integrity protection method;

[0126] Processor: for implementing the compiler-based program branch data integrity protection method when executing the computer program.

[0127] A computer readable storage medium, which stores a computer program, the computer program is executed by a processor to implement the steps of the compiler-based program branch data integrity protection method.

[0128] Figure 5 The table shows the number of layers of backtracking required for the last analysis of the SPEC CPU2006 test cases, wherein the first column indicates the test case, the second column ICTs indicates the number of control flow transfer instructions (excluding return instructions, only including indirect call and virtual call) of the test case, the third column L1 indicates the number of control dependence analysis algorithm backtracking layers required to find the last conditional branch data related to the control flow, and the fourth column L2 and the fifth column L3 are sequentially similar. Therefore, the two-layer backtracking method finally adopted by the present application for the last analysis greatly reduces the analysis time and cost.

[0129] Figure 6 For the comparison of the two analysis methods of the present application, namely the completeness analysis and the last analysis, the figure shows that the last analysis greatly reduces the amount of protected data. Since the farther the distance from the control flow in the program, the higher the cost of the attacker's tampering, the last analysis reduces the system overhead as much as possible without sacrificing security, and meets the customized security according to different user's different security requirements.

[0130] Figure 7 For the system overhead of the present application for the SPEC CPU2006 test suite, the average system overhead of the last analysis is 10.10%, and the average system overhead of the completeness analysis is 50.12%.

[0131] Compared with the prior art, the performance overhead of the present application is reduced by 98% compared with YARRA; compared with HDFI, no new instruction set is introduced, so it can be more widely applied to large programs; compared with KENALI, it only needs Intel MPK support, and the mainstream processor has already supported Intel MPK by default, so it can be more conveniently applied to the system; compared with TMDFI, the present application does not use the traditional label technology, but adopts the source point assisted context sensitive technology, and can solve the disadvantage that the number of labels is not enough to protect large programs. After testing all C programs and C++ programs of SPEC CPU 2006, when the last analysis is adopted and two layers are traced back, the number of branch data related to indirect call that can be protected is 84.2%, and the proportion of branch data that can be protected for C type programs is 97.5%, which can greatly make up for the defect that the CFI technology cannot guarantee the integrity of non-control data.

Claims

1. A compiler-based program branch data integrity protection method, characterized by, comprising static analysis and program runtime verification; the static analysis is performed when data flow integrity protection is performed on a program, comprising the following steps: Step 1: input program intermediate code (LLVM-IR), and perform control dependence analysis on the input program intermediate code (LLVM-IR) to obtain branch data related to control flow in the program to be protected; Step 2: pass the branch data obtained in Step 1 into a static value flow analysis algorithm to locate the source point of the branch data; Step 3: generate a program data flow graph (DFG) according to the source point of the branch data obtained in Step 2; the program runtime verification is performed when the program is running, comprising the following steps: Step S1: save the source point obtained in Step 2 to a runtime definition table (RDT), then find the corresponding source point in the runtime definition table (RDT) according to the data address index, and protect the safety of the runtime definition table (RDT) through Intel MPK hardware; Step S2: determine whether the source point found in Step S1 is within the range of the program data flow graph (DFG) generated in Step 3, if yes, continue to execute the program, if no, throw an exception.

2. The compiler-based program branch data integrity protection method of claim 1, wherein, The Step 1 specifically comprises: First, pass the program intermediate code (LLVM-IR) as input to the Pass framework of the LLVM compiler, and the Pass framework performs control dependence analysis on the program through a control dependence analysis algorithm, which includes completeness analysis and last-time analysis, wherein the completeness analysis is to analyze all branch data related to control flow in the program, and the last-time analysis is to analyze the last branch data related to control flow in the program; The algorithm of the control dependence analysis specifically comprises the following steps: Step 1.1: initialize a set of branch data (Condition_DataSet) to be protected, and provide two analysis methods, namely last-time analysis and completeness analysis; Step 1.2: loop through all program instructions in the program, and determine whether the current instruction is a control flow instruction, if the current instruction is a control flow instruction, go to Step 1.3, if the current instruction is not a control flow instruction, continue to Step 1.2; Step 1.3: analyze all basic blocks (BasicBlock) of the control flow instruction in Step 1.2; Step 1.3.1: if Step 1.1 selects the last-time analysis, then analyze whether the termination instruction of each of the aforementioned basic blocks obtained in Step 1.3 is a conditional branch instruction from near to far according to the distance from the control flow, find the last conditional branch instruction closest to the control flow, add the branch data to the set of branch data to be protected, and continue to Step 1.2; Step 1.3.2: if Step 1.1 selects the completeness analysis, then analyze whether the termination instruction of each of the aforementioned basic blocks obtained in Step 1.3 is a conditional branch instruction, add all the branch data obtained by the analysis to the set of branch data to be protected, and continue to Step 1.2; Step 1.4: All the procedures in step 1.2 are completed, and the analysis is completed.

3. The compiler-based program branch data integrity protection method of claim 1, wherein, The step 2 specifically comprises: The Pass framework of the LLVM compiler passes the branch data as input to the source point auxiliary context-sensitive static value flow analysis algorithm to obtain the source point of the branch data, wherein the source point instruction is defined as the instruction in the program that last assigns the data, and the operand of the instruction is a non-function parameter, and when the operand of the source point instruction is a function parameter, the branch data needs to be further traced back to the source point in the program; The static value flow analysis algorithm specifically comprises the following steps: Step 2.1: Initialize the work list (worklists) and add the sensitive data instruction to the work list (worklists), and assign the to-be-analyzed sensitive data to a temporary variable (temp_val); Step 2.2: Loop iteration is performed on the work list (worklists) in step 2.1 until the definition instruction (Alloca) of the sensitive data is found, and the loop is ended: Step 2.2.1: It is judged whether the temporary variable (temp_val) after the assignment in step 2.1 is a function parameter, if it is a function parameter, the callee thereof is obtained, and the value flow analysis is continuously performed in the callee until the source point is found, and the loop is terminated; Step 2.2.2: It is judged whether the temporary variable (temp_val) after the assignment in step 2.1 is a phi instruction, and the source points thereof are traced back according to the two branches of the phi instruction, and the program is terminated; Step 2.2.3: It is judged whether the temporary variable (temp_val) after the assignment in step 2.1 is a select instruction, which is different from the analysis of the phi instruction, and the select instruction only needs to trace back the analysis of one operand, and the program is terminated; Step 2.2.4: When the temporary variable (temp_val) after the assignment in step 2.1 is not the case of steps 2.2.1-2.2.3, the operand of the temporary variable (temp_val) instruction after the assignment in step 2.1 is re-assigned to the temporary variable (temp_val) instruction itself, and the instruction is added to the work list (worklists), the judgment is ended, and the step 2.2.1 loop is re-entered; Step 2.3: Based on the definition instruction (Alloca) of the sensitive data found in step 2.2, the instructions of the entire function are traversed, all the write instructions are found based on the def-use relationship, and the write instructions are written into the source point instruction set (write_insts); Step 2.4: The write instruction obtained in step 2.3 is further judged, and it is judged whether the operand (valueOpearnd) of the write instruction is a function parameter, if it is a function parameter, the callee thereof is obtained, and the value flow analysis is continuously performed in the callee until the source point is found, and the loop is terminated.

4. The compiler-based program branch data integrity protection method of claim 1, wherein, The tuple of the program data flow graph (DFG) generated in the step 3 is defined as [I i , o , Origin], wherein I i represents the branch instruction itself, I o represents the source point instruction itself, and Origin is the source point value.

5. The compiler-based program branch data integrity protection method of claim 1, wherein, The step S1 comprises: The Pass framework of the LLVM compiler saves the source point located by the static value flow analysis in the form of a key-value pair (key, value), where the key is the source point address and the value is the source point value, and protects the safety of the runtime definition table (RDT) through the Intel MPK hardware, and the steps include the following steps: Step S1.1: The runtime definition table (RDT) is a piece of memory area protected by the Intel MPK for context information application, and the access permission of the memory area is set to be inaccessible; Step S1.2: When there is context information to be saved, the access permission of the memory area applied in step S1.1 is set to be readable, and the entries to be stored are retrieved; Step S1.3: After the relevant entries are retrieved in step 1.2, the access permission of the memory area applied in step S1.1 is set to be writable, and the context information is written; Step S1.4: After the writing in step 1.3 is completed, the access permission of the memory area applied in step S1.1 is immediately set to be inaccessible; Step S1.5: When the program executes to the module to be verified, the access permission of the memory area applied in step S1.1 is set to be readable, and the relevant information is found for verification; Step S1.6: After the verification in step S1.5 is completed, the access permission of the memory area applied in step S1.1 is set to be inaccessible.

6. The compiler-based program branch data integrity protection method of claim 1, wherein, The step S2 includes: The Pass framework of the LLVM compiler generates an executable program after the program is instrumented, and when the program runs to a sensitive branch instruction, the program finds the source point value in the runtime definition table (RDT) according to the address of the branch data, and forms a program data flow tuple, and further judges whether the program data flow tuple is in the program data flow graph (DFG), if the program data flow tuple is in the program data flow graph (DFG), the program continues to execute, if the program data flow tuple is not in the program data flow graph (DFG), an exception is thrown.

7. A system for compiler-based program branch data integrity protection according to any of claims 1 to 6, characterized in that It includes: A static analysis module: input program intermediate code (LLVM-IR), and control dependence analysis is performed on the input program intermediate code (LLVM-IR), the branch data to be protected in the program related to the control flow is obtained, and then the branch data is transmitted to the static value flow analysis algorithm, the source point of the branch data is located, and a program data flow graph (DFG) is generated; A program runtime verification module: saves the source point of the branch data to the runtime definition table (RDT), and then indexes the corresponding source point in the runtime definition table (RDT) according to the data address, and protects the safety of the runtime definition table (RDT) through the Intel MPK hardware, judges whether the source point is within the range of the program data flow graph (DFG), if yes, the program continues to execute, if no, an exception is thrown.

8. A compiler-based program branch data integrity protection device, characterized by, It includes: A memory: for storing a computer program for implementing the program branch data integrity protection method based on the compiler according to any one of claims 1-6. Processor: for executing the computer program to implement a compiler-based program branch data integrity protection method according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program is executed by the processor to implement the steps of the compiler-based program branch data integrity protection method according to any one of claims 1-6.

Images