Data processing apparatus and method for runtime integrity attestation

Abstract

A data processing apparatus (110) for executing an application with runtime integrity proof is provided. The data processing apparatus (110) comprises processing circuitry (111) for executing a modified version (143) of an application machine code (141) defining the application. The modified version (143) of the application machine code (141) includes one or more direct or indirect branch instructions, and one or more machine code instructions, the one or more machine code instructions being one or more target instructions for the one or more direct or indirect branch instructions. During the execution of the modified version (143) of the application machine code (141), the processing circuitry (111) is further configured to update a first register value in a first register and a second register value in a second register, and to update the modified version (143) of the application machine code (141) based on the first register value and the second register value. And / or triggering an exception if the one or more direct or indirect branch instructions are for instructions of the modified version (143) of the application machine code (141) instead of the one or more target instructions.

Description

Technical Field

[0001] This invention relates to security technology. More specifically, this invention relates to a data processing apparatus, a runtime verification system, and a method for runtime verification. Background Technology

[0002] Traditional computing systems are often implemented using potentially insecure programming languages ​​such as C and C++, making them inherently insecure. Memory corruption vulnerabilities are the biggest attack vector in such systems. These vulnerabilities can be exploited in various attack forms. The two main attack categories are (i) code injection attacks and (ii) code reuse attacks. The widespread deployment of data execution prevention (DEP) technologies as a defensive measure has raised the bar for attackers to successfully execute code injection attacks. Consequently, code reuse attacks have become the most popular software development technique over the past decade. These code reuse attacks can be categorized into control flow hijacking attacks and non-control flow hijacking attacks. Control flow hijacking techniques are widely used to launch attacks. Basically, there are two main techniques, known as return-oriented programming (ROP) and jump-oriented programming (JOP).

[0003] ROP (Recursive Open Programming) is a classic exploit technique. Using this technique, attackers exploit memory corruption vulnerabilities to gain control of the call stack, thereby hijacking program control flow and executing carefully chosen sequences of machine instructions called gadgets. These gadgets already exist in the target device's memory. Each gadget typically ends with a return instruction and resides within a subroutine in an existing program or shared library. By linking these gadgets together, attackers can perform malicious tasks.

[0004] Similar to ROP, JOP scans target software for code snippets that can be pieced together to execute an uncontrolled flow of tasks. ROP attacks look for sequences ending with a function return (RET). In contrast, JOP targets sequences that end with indirect jumps or calls and can be linked together by a special code snippet (called a dispatcher) that should also reside in the same memory location. It's important to note that JOP is considered a variant of ROP, allowing exploitation with or without stack control. For this, a dispatcher code snippet should exist to allow jumps to instruction lists ending with JUMP instructions.

[0005] Therefore, there is a need to improve devices and methods to detect and prevent control flow hijacking attacks such as JOP and ROP in an efficient manner with minimal performance overhead, and to provide credible evidence of the runtime integrity state of the target software in an efficient manner that supports scalability. Summary of the Invention

[0006] The aim is to provide improved devices and methods for secure and efficient runtime integrity verification to detect and prevent control flow hijacking attacks (such as JOP and ROP).

[0007] The foregoing and other objectives are achieved through the subject matter claimed in the independent claims. Other implementations are apparent from the dependent claims, the specification, and the drawings.

[0008] According to a first aspect, a data processing apparatus is provided for executing a software application defined by application machine code (e.g., a target binary image). The data processing apparatus includes processing circuitry for executing a modified (e.g., hardened) version of an original version of the application machine code defining the application. The modified version of the application machine code includes one or more direct or indirect branch instructions, and one or more hardware-assisted machine code instructions, which serve as one or more valid target instructions for the one or more direct or indirect branch instructions. In the context of processors based on, for example, ARM architectures, such hardware-assisted machine code instructions are referred to as landing pads or branch target identification (BTI) instructions (also referred to herein as LANDMARK instructions). During the execution of the modified version of the application machine code, the processing circuitry is further configured to update the value of the first register (i.e., status register) in the first register (i.e., status register) and the value of the second register (i.e., reference register) in the second register (i.e., reference register), and trigger a hardware exception based on the first register value and the second register value, and / or if the one or more direct or indirect branch instructions target instructions of the modified version of the application machine code instead of the one or more valid target instructions. Therefore, a data processing apparatus is provided that enables secure and efficient implicit device authentication and integrity verification throughout the entire lifecycle of the application's execution state.

[0009] In another possible implementation of the first aspect, the data processing apparatus further includes a communication interface for reporting proof data to a verifier server in the event of a hardware anomaly, the proof data including information about the first register value and / or the second register value. Therefore, the anomaly can be checked through a trusted source.

[0010] In another possible implementation of the first aspect, the information regarding the first register value and / or the second register value includes the first register value and the second register value and / or a digest value based on the first register value and / or the second register value, such as a hash value. Therefore, information regarding the first register value and / or the second register value can be provided in a compact and secure manner.

[0011] In another possible implementation of the first aspect, the one or more direct or indirect branch instructions of the modified version of the application machine code include one or more direct or indirect CALL instructions, one or more direct or indirect JUMP instructions, and / or one or more direct or indirect RETURN instructions. Therefore, the direct or indirect CALL instructions, direct or indirect JUMP instructions, and / or direct or indirect RETURN instructions can be protected in the modified version of the application machine code.

[0012] In another possible implementation of the first aspect, for each of the one or more direct or indirect branch instructions in the modified version of the application machine code, the processing circuitry is configured to: move the current first register value of the first register to the second register; update the current first register value of the first register by an XOR operation with a unique identifier, specifically the key Kx; execute the corresponding direct or indirect branch instruction; update the current first register value of the first register by another XOR operation with the unique identifier, specifically the key Kx; and compare the updated current first register value with the current second register value. Therefore, a chain of unique values ​​can be created using the XOR operation, where each value can belong to a specific location.

[0013] In another possible implementation of the first aspect, the processing circuitry is further configured to: trigger a hardware exception if the updated current first register value differs from the current second register value. Therefore, if the value is tampered with, it can be detected efficiently, and an exception can be triggered.

[0014] In another possible implementation of the first aspect, the processing circuitry is configured to generate or retrieve the unique identifier for each of the one or more direct or indirect branch instructions of the modified version of the applied machine code. Therefore, each of the one or more direct or indirect branch instructions of the modified version of the applied machine code can be uniquely identified.

[0015] In another possible implementation of the first aspect, the first register (i.e., the status register) and the second register (i.e., the reference register) are configured to be modified only by assignment (especially the MOV instruction), XOR instructions, and comparison (especially the CMP) instructions. Therefore, the first and second registers can only be used to inspect direct or indirect branch instructions.

[0016] In another possible implementation of the first aspect, the modified version of the application machine code includes one or more RETURN instructions relative to the original version of the application machine code, comprising a hard-coded jump table defining one or more jump destinations. Therefore, the RETURN instructions can be replaced in a safe manner.

[0017] In another possible implementation of the first aspect, the processing circuitry is further configured to associate the first register value of the first register with the memory address of the one or more jump destinations defined by the jump table, in order to minimize the lookup time in the hard-coded jump table. Therefore, the lookup time of the hard-coded jump table can be minimized.

[0018] According to a second aspect, a runtime verification system is provided. The runtime verification system includes: at least one data processing device according to the first aspect, configured to generate verification data; and a verifier server, configured to receive the verification data from the at least one data processing device and verify the integrity of the at least one data processing device based on the verification data. Therefore, an efficient runtime verification system is provided.

[0019] According to a third aspect, a method is provided for executing a software application defined by application machine code (e.g., a target binary image). The method includes:

[0020] Execute a modified version of the application machine code that defines the application, wherein the modified version of the application machine code includes one or more direct or indirect branch instructions and one or more machine code instructions, the one or more machine code instructions serving as one or more target instructions of the one or more direct or indirect branch instructions;

[0021] Update the value of the first register in the first register and the value of the second register in the second register;

[0022] An exception is triggered based on the first register value and the second register value, and / or if the one or more direct or indirect branch instructions target the modified version of the application machine code instead of the one or more target instructions. Therefore, a method is provided that enables secure and efficient implicit device proof and integrity verification throughout the entire lifecycle of the application's execution state.

[0023] The method according to the third aspect of the invention can be executed by the data processing apparatus according to the first aspect of the invention. Therefore, further features of the method according to the third aspect of the invention arise directly from the functionality of the data processing apparatus according to the first aspect of the invention and its different implementations described above and below.

[0024] According to a fourth aspect, a data processing apparatus is provided, wherein the data processing apparatus according to the fourth aspect is configured to: modify an original version of application machine code defining a software application to a modified (e.g., hardened) version of the application machine code. The original version of the application machine code includes one or more direct or indirect branch instructions. The data processing apparatus is configured to: for each of the one or more direct or indirect branch instructions of the original version of the application machine code, include one or more hardware-assisted machine code instructions, particularly landmark or landing point instructions, the one or more hardware-assisted machine code instructions indicating one or more valid target instructions of the one or more direct or indirect branch instructions for obtaining the modified (e.g., hardened) version of the application machine code. The data processing apparatus is further configured to compile the modified (e.g., hardened) version of the application machine code into an executable binary image. Therefore, a data processing apparatus is provided for providing a more secure, hardened version of application machine code.

[0025] In another possible implementation of the fourth aspect, the one or more direct or indirect branch instructions include one or more direct or indirect CALL instructions, and / or one or more direct or indirect JUMP instructions and / or one or more direct or indirect RETURN instructions. Therefore, the direct or indirect CALL instructions, direct or indirect JUMP instructions, and / or direct or indirect RETURN instructions can be protected in a hardened version of the application machine code.

[0026] In another possible implementation of the fourth aspect, the original version of the application machine code includes one or more RETURN instructions, and the data processing device is configured to include a hard-coded jump table defining one or more jump destinations for each of the one or more RETURN instructions. Therefore, the RETURN instructions can be replaced in a safe manner.

[0027] The accompanying drawings and the following description illustrate details of one or more embodiments. Other features, objects, and advantages will be apparent from the specification, drawings, and claims. Attached Figure Description

[0028] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0029] Figure 1 A schematic diagram of a runtime verification system provided in an embodiment is shown, the runtime verification system including at least one first data processing device and a verifier server provided in the embodiment;

[0030] Figure 2 A schematic diagram of the architecture of the first data processing apparatus and the second data processing apparatus provided in the embodiments is shown.

[0031] Figure 3 An exemplary flowchart of function-level control of the second data processing apparatus provided in the embodiment is shown;

[0032] Figures 4a to 4e The instrumentation effects of several functions that indicate call instructions are shown;

[0033] Figure 5 A schematic diagram of a function with ROP code snippets is shown;

[0034] Figure 6 The compilation process performed by the second data processing provided by the embodiment is shown in more detail;

[0035] Figure 7 This is a flowchart of the instrumentation sequence implemented by the second data processing device provided by the embodiment during compilation;

[0036] Figure 8 This is a schematic diagram of the architecture of the runtime verification system provided in the embodiment;

[0037] Figure 9 A flowchart is shown for a method of executing a software application defined by the application's machine code.

[0038] In the following text, the same reference numerals refer to the same or at least functionally equivalent features. Detailed Implementation

[0039] In the following description, reference is made to the accompanying drawings, which form part of this invention and illustrate specific aspects of embodiments of the invention or to the drawings in which specific aspects of embodiments of the invention may be used. It should be understood that embodiments of the invention may be used in other aspects and may include structural or logical variations not depicted in the drawings. Therefore, the following detailed description should not be construed in a limiting sense, and the scope of the invention is defined by the appended claims.

[0040] For example, it should be understood that the disclosure relating to the described method can also apply to the corresponding device or system for performing the method, and vice versa. For example, if one or more specific method steps are described, the corresponding device may include one or more units (e.g., functional units) to perform the described one or more method steps (e.g., one unit performs one or more steps, or multiple units perform one or more of a plurality of steps respectively), even if the one or more units are not explicitly described or illustrated in the drawings. On the other hand, for example, if a specific apparatus is described according to one or more units (e.g., functional units), the corresponding method may include a step to implement the function of one or more units (e.g., one step implements the function of one or more units, or multiple steps implement the function of one or more of a plurality of units respectively), even if the one or more steps are not explicitly described or illustrated in the drawings. Furthermore, it should be understood that, unless otherwise stated, features of the various exemplary embodiments and / or aspects described herein can be combined with each other.

[0041] Figure 1 A schematic diagram of a runtime verification system 100 provided in an embodiment is shown. The runtime verification system 100 includes at least one first data processing device 110 and a verifier server 120 provided in the embodiment. According to one embodiment, the runtime verification system 100 may further include a second data processing device 130. For example, the first data processing device 110 may be an IoT device, a smartphone, a network device, an electronic control unit, etc. For example, the second data processing device 130 may be a server, particularly a cloud server, a base station, a cloud machine, a router, etc. The verifier server 120 may be a cloud server.

[0042] like Figure 1As shown and described in more detail below, the first data processing device 110 includes processing circuitry 111, which may include, for example, one or more central processing units (CPUs). Processing circuitry 111 may be implemented in hardware and / or software and may include digital circuitry, or both analog and digital circuitry. Digital circuitry may include components such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or general-purpose processors. Furthermore, the first data processing device 110 may include electronic non-volatile memory 115 for storing data, such as flash memory 115. Non-volatile memory 115 may store executable program code that, when executed by processing circuitry 111, causes the first data processing device 110 to perform the functions and methods described herein. The first data processing device 110 may further include a communication interface 113, particularly a wireless and / or wired communication interface that enables the first data processing device 110 to communicate with the verifier server 120, the second data processing device 130 and / or other network devices.

[0043] Similarly, the second data processing device 130 may include processing circuitry 131, which may include one or more central processing units (CPUs) and / or one or more microcontrollers. Processing circuitry 131 may be implemented in hardware and / or software and may include digital circuitry, or both analog and digital circuitry. Digital circuitry may include components such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or general-purpose processors. Furthermore, the second data processing device 130 may include electronic non-volatile memory 135 for storing data, such as flash memory 135. Non-volatile memory 135 may store executable program code that, when executed by processing circuitry 131, causes the second data processing device 130 to perform the functions and methods described herein. The second data processing device 130 may further include a communication interface 133, specifically a wireless and / or wired communication interface that enables the second data processing device 130 to communicate with the verifier server 120, the first data processing device 110, and / or other network devices.

[0044] As will be described in more detail below, the second data processing device 130 is used to modify the original version of the application machine code 141 (also referred to as source code 141) that defines the software application to a modified (e.g., hardened) version 143 of the application machine code 141. The original version of the application machine code 141 includes one or more direct or indirect branch instructions.

[0045] The second data processing device 130 is configured to include one or more direct or indirect branch instructions for the original version of application machine code 141, each of which includes one or more hardware-assisted machine code instructions indicating one or more valid target instructions of the one or more direct or indirect branch instructions for obtaining a modified (e.g., hardened) version 143 of application machine code 141. In the context of a processor based on, for example, an ARM architecture, such hardware-assisted machine code instructions are referred to as landing point instructions (also referred to herein as landmark instructions). Further details regarding landing point instructions that can be used as hardware-assisted machine code instructions according to embodiments can be found, for example, in the document “Learn the architecture - Providing protection for complex software” https: / / developer.arm.com / documentation / 102433 / latest / , which is incorporated herein by reference in its entirety. The second data processing device 130 is also configured to compile the modified (e.g., hardened) version 143 of application machine code 141 into an executable binary image.

[0046] As a supplement, at least one first data processing device 110 is used to execute a software application defined by application machine code 141 (e.g., a target binary image). Processing circuitry 111 of the first data processing device 110 is used to execute a modified (e.g., hardened) version 143 of the original version of the application machine code 141 that defines the application. During the execution of the modified version 143 of the application machine code 141, the processing circuitry 111 of the first data processing device 110 is also used to update the value of the first register (i.e., the status register) in the first register (i.e., the status register) and the value of the second register (i.e., the reference register) in the second register (i.e., the reference register), and trigger a hardware exception based on the first register value and the second register value, and / or if one or more direct or indirect branch instructions target instructions of the modified version 143 of the application machine code 141 instead of one or more valid target instructions. The first data processing device 110 can also be used to generate proof data 145.

[0047] Verifier server 120 is used to receive verification data 145 from at least one first data processing device 110 and verify the integrity of at least one first data processing device 110 based on the verification data 145.

[0048] Figure 2 A schematic diagram of the architecture of the first data processing apparatus 110 and the second data processing apparatus 130 provided in the embodiments is shown.

[0049] like Figure 2 As shown, the application can be a user-space application running on an architecture that provides hardware support for landmark instructions, which can be inserted by any valid target for indirect jumps or calls, and triggers a hardware exception if the target is some other instruction. The processing circuit 111 of the first data processing device 110 can be a processing circuit 111 that provides the aforementioned hardware support, such as an ARM processor for high-end devices such as ARMv8.5-A or higher, or an ARM processor for low-end devices such as ARMv8.1-M or, for example, an 11th generation (or higher) Intel Skylake processor.

[0050] The validator server 120 may be a remote trusted entity, such as a management service, which obtains some metadata 201 from the deployment service (i.e., the second data processing device 130) after compiling a corresponding application that can be used to verify the proof data 145 (i.e., the proof report). At any time, the validator server 120 may contact the remote proof service or agent 203, i.e., the user-space process, to inquire about the runtime integrity status of the first data processing device 110. The remote proof service 203 may respond with a report, which will be verified by the validator server 120 against the received metadata 201.

[0051] The first data processing device 110 may be the entire untrusted device that runs during the runtime phase, i.e., the hardware of the managed software.

[0052] The hardware components of the first data processing device 110 may include processing circuitry 111 that supports landmark (LM) instructions, which can be inserted into specific locations in binary software to identify valid targets for indirect branch instructions.

[0053] The hardware components of the first data processing device 110 may further include a non-volatile memory 115, which provides storage space in which software modules and other files can be permanently stored when the first data processing device 110 is on or off.

[0054] The hardware components of the first data processing device 110 may also include volatile memory 116, for example, DRAM that holds all software modules when the first data processing device 110 is turned on.

[0055] The hardware components of the first data processing device 110 may further include a root of trust (RoT) hardware module 211, which is responsible for generating a chain of trust between various software layers, thereby detecting any forgerable reports.

[0056] It should be understood that the hardware components of the first data processing device 110 may also include other hardware components 119, such as the communication interface 113.

[0057] The software components of the first data processing device 110 may include an LM exception handler 207 in the kernel, which is high-privilege software that controls other software modules running on top of the kernel. The LM exception handler 207 may be a kernel module responsible for handling all violations triggered by indirect jumps or calls to non-LM instructions.

[0058] The software components of the first data processing device 110 may also include a RoT driver 209 in the kernel. The RoT driver 209 may be a kernel module responsible for handling all interactions with the RoT hardware module 211.

[0059] The software components of the first data processing device 110 may include a remote authentication agent 203 in user space. The remote authentication agent 203 may be a user space process (application) that is responsible for receiving commands from the verifier server 120 and responding accordingly after retrieving relevant data from other modules.

[0060] The software components of the first data processing device 110 may also include a hardened version 143 of the application machine code 141 in the user space, namely the corresponding user space application that is monitored and protected as described in the embodiments above and below.

[0061] It should be understood that the software components of the first data processing device 110 may include other modules 213 in the kernel and / or other applications 205 in user space.

[0062] The second data processing device 130 can operate during the build phase (i.e., during compilation), after which the resulting hardened version 143 of the machine code 141 is applied with the required instrumentation instructions.

[0063] As described in the embodiments above and below, the source code 141, including all dependent files of the target application, can be provided to the second data processing device 130.

[0064] The second data processing device 130 may include a compiler toolchain 131a, that is, a compiler infrastructure 131a used in compiling the target application. In particular, the processing circuit 131 of the second data processing device 130 may implement the compiler toolchain 131a.

[0065] The second data processing device 130 may further include a plug-in 131b, and in particular, the processing circuitry 131 of the second data processing device 130 may implement the plug-in 131b. The plug-in 131b may be a software library implemented and inserted into the compiler toolchain 131a. The plug-in 131b may execute when its corresponding flag is passed to the compiler infrastructure 131a, and may add the required instrumentation instructions to the target application.

[0066] As described in the embodiments above and below, the second data processing device 130 can generate a hardened version 143 of the application machine code 141, i.e., the compiled binary file. The hardened version 143 of the application machine code 141 can then be deployed to the first data processing device 110.

[0067] Runtime proof systems can be used for hardware / software co-design to mitigate control flow hijacking attacks.

[0068] On the hardware side, marking techniques, such as or similar to branch target identification (BTI) (in the ARM architecture), can be used because indirect transfer and jump instructions can only target landmark instructions. Two additional landmark instructions may be added: "lm c" for the indirect call instruction and "lm j" for the indirect jump instruction. The hardware may also include two additional registers reserved for use according to the embodiments described herein, called the state register (SR) and the reference register (RR). The hardware can enforce that these two registers can only be used for assign (MOV), XOR, and compare (CMP) instructions.

[0069] On the software side, compiler plugin 131b can be responsible for (i) inserting lm instructions into their correct positions, (ii) instrumenting all call points with specific XOR and CMP (compare) instructions using a uniquely generated key, (iii) replacing return instructions with hard-coded jump tables, and (iv) ensuring that the two additional registers SR and RR are not used outside their context.

[0070] On the software side, a custom LM exception handler 207 in the kernel can log all violations when triggered. The LM exception handler 207 may only need to log two values ​​from the two additional registers SR and RR, which are minimal but sufficient information for the trusted party (i.e., verifier server 120) to verify the logs later.

[0071] On the software side, a user-space secure process implemented in a secure language (such as Rust) can act as a remote authentication agent 203, reporting recorded logs to the validator server 120 in a trusted manner.

[0072] As described above, the runtime verification system 100 can operate in two phases: one phase involves the build (compilation) phase, and the other phase occurs during execution (runtime phase). Relevant components can instrument the target software (i.e., source code 141) and harden it as needed, while at runtime, the inserted instructions are responsible for preventing and detecting control flow hijacking attacks.

[0073] Figure 3 An exemplary flowchart of function-level control of the second data processing apparatus 130 provided in the embodiment is shown. Figure 3 As illustrated schematically, during the compilation phase, when compiling any application, plugin 131b can generate a control flow graph at the function level, for example... Figure 3 The exemplary diagram shown includes multiple nodes representing different functions 301 to 309. If not accurately parsed, all indirect branch instructions may be over-approximated.

[0074] Plugin 131b can also insert "lm c" at the beginning of each function to limit the effective target set of indirect branch instructions.

[0075] Plugin 131b can also generate a unique key for each direct / indirect call instruction and can add the following instructions: Before "(ind-)call Xd" for executing the (indirect) call instruction, after "XOR SR,Kx" for XORing the value of SR with the unique key Kx and storing it in SR, add "MOV RR,SR" to move the value of SR to RR. After "(ind-)call Xd" for executing the (indirect) call instruction, after "CMP RR,SR" for comparing the values ​​of RR and SR and triggering an LM exception if they are not equal, add "XOR SR,Kx" to XOR the value of SR with the same key Kx again.

[0076] Therefore, in addition to the instruction responsible for triggering the exception, each call instruction may be preceded by two instructions and followed by two more. This can be used to create a chain of unique values ​​using an XOR operation, where each value should belong to a specific position. If this value is tampered with, it will be detected, triggering an exception.

[0077] Plugin 131b can also replace RET (return) instructions with hard-coded jump tables based on the generated control flow graph and the expected SR value for a given path. The jump tables can embed "lm j" instructions, such as... Figures 4a to 4e Visualization within the text. More specifically, Figure 4a express Figure 4e The main function is 301. Figure 4b express Figure 4e Another first function 303, Figure 4c express Figure 4e Another second function, 305, Figure 4d express Figure 4e Another third function, 307. In Figures 4a to 4c In this context, the unique key Kx is an identifier designated as "ID1" through "ID5".

[0078] Consider as Figure 3 The control flow graph shown is as follows: Figures 4a to 4e The instrumentation effect on several functions 301 to 307 that indicate call instructions is shown. It should be understood that for functions containing ROP code snippets, the RET instruction can only be replaced by a hard-coded jump table. This means that all root and leaf functions are excluded from this RET instrumentation. Functions 303' to 307' with ROP code snippets are shown below. Figure 5 As shown.

[0079] Figure 6 The compilation process performed by the second data processing 130 provided by the embodiment is shown in more detail.

[0080] like Figure 6 As shown, after the source code 141 is provided to the compiler infrastructure 131a, the plugin 131b and / or the compiler infrastructure 131a can output an intermediate representation of code that is close to assembly language but is still human-readable.

[0081] Based on the intermediate representation 601, the graph analyzer module 603, implemented by the plug-in 131b, can identify the caller / callee of each function 301 to 309, identify functions 301 to 309 in the shared library, and mark leaf functions 301 to 309.

[0082] Based on the processing of the graph analyzer module 603, the encoder 605 implemented by the plug-in 131b can generate a unique function ID, i.e. a unique key Kx, and encode the status register SR.

[0083] Based on the encoding performed by encoder 605 and intermediate representation 601, instrumentation module 607 can add XOR instructions when needed (as described above), replace RET with jump table when needed (as described above), and compare RR with SR (as described above).

[0084] Based on the processing of instrumentation module 607, verifier module 609 can check the correct location of LM instructions and check the exclusive use of SR and RR. Verifier module 609 can connect to verifier server 120 and exchange data with verifier server 120, specifically for sending metadata 201 to verifier server 120.

[0085] Once verified by the verifier module 609, the second data processing device 130 can provide this hardened version 143 of the application machine code 141 to the first data processing device 110.

[0086] Any application can be compiled by a compiler that supports the associated custom compiler plugin 131b. Any violation detected due to (i) mismatches between register values ​​or (ii) indirect targeting of non-landmark instructions can trigger a custom LM exception handler 207 of the first data processing device 110. The primary task of the custom LM exception handler 207 may be to log the violation in a reliable manner and stop the compromised process. The remote authentication agent 203 of the first data processing device 110 can retrieve these logs upon request and send them to the verifier server 120 for verification.

[0087] Figure 7 This is a flowchart of the instrumentation sequence 700 implemented by the second data processing device 130 provided by the embodiment during compilation.

[0088] After the start of instrumentation sequence 700 701, source code 141 can be provided to the extended compiler toolchain 703, namely compiler infrastructure 131a and plugin 131b.

[0089] exist Figure 7 In step 705, a function-level control flow graph (CFG) can be generated.

[0090] exist Figure 7 In step 707, a unique ID, i.e. a unique key Kx, can be generated for the calling point.

[0091] exist Figure 7 In step 709, a jump table can be generated based on CFG.

[0092] exist Figure 7In step 711, the second data processing device 130 can iterate over the assembly instructions.

[0093] exist Figure 7 In step 713, the second data processing device 130 can check whether the current assembly instruction is a function entry point. If it is true, the instrumentation sequence 700 can proceed to... Figure 7 Step 715. If false, then instrumentation sequence 700 can proceed to... Figure 7 Step 719.

[0094] exist Figure 7 In step 715, the second data processing device 130 may insert the "lm c" instruction. After step 715, in order to end the current iteration loop 717, the instrumentation sequence 700 may proceed to step 711.

[0095] exist Figure 7 In step 719, the second data processing device 130 can check whether the current assembly instruction is a call instruction. If it is true, the instrumentation sequence 700 can proceed to... Figure 7 Step 721. If false, then instrumentation sequence 700 can proceed to... Figure 7 Step 749.

[0096] exist Figure 7 In step 721, the second data processing device 130 can check whether the current assembly instruction is a direct call. If it is true, then the instrumentation sequence 700 can proceed to... Figure 7 Step 723. If false, then instrumentation sequence 700 can proceed to... Figure 7 Step 739.

[0097] exist Figure 7 In step 723, the second data processing device 130 can check whether the current assembly instruction is a shared library function. If true, the instrumentation sequence 700 can proceed to... Figure 7 Step 725. If false, then instrumentation sequence 700 can proceed to... Figure 7 Step 727.

[0098] exist Figure 7 In step 725, the second data processing device 130 may insert MOV, XOR, and CMP instructions. After step 725, in order to end the current iteration loop 717, the instrumentation sequence 700 may proceed to step 711.

[0099] exist Figure 7 In step 727, the second data processing device 130 can check whether the current assembly instruction calls a leaf function. If true, then instrumentation sequence 700 can proceed to... Figure 7Step 729. If false, then instrumentation sequence 700 can proceed to... Figure 7 Step 731.

[0100] exist Figure 7 In step 729, the second data processing device 130 may choose not to perform instrumentation in the current iteration loop 717. After step 729, in order to end the current iteration loop 717, the instrumentation sequence 700 may proceed to step 711.

[0101] exist Figure 7 In step 731, the second data processing device 130 may insert an XOR instruction. After step 731, the instrumentation sequence 700 may proceed to step 733.

[0102] exist Figure 7 In step 733, the second data processing device 130 can check whether the callee is also a candidate for indirect calling with a leaf function. If true, then instrumentation sequence 700 can proceed to... Figure 7 Step 735. If false, then instrumentation sequence 700 can proceed to step 735. Figure 7 Step 737.

[0103] exist Figure 7 In step 735, the second data processing device 130 may insert the "lm j" instruction. After step 735, in order to end the current iteration loop 717, the instrumentation sequence 700 may proceed to step 711.

[0104] exist Figure 7 In step 737, the second data processing device 130 may replace the CALL instruction with a JUMP instruction. After step 737, in order to end the current iteration loop 717, the instrumentation sequence 700 may proceed to step 711.

[0105] exist Figure 7 In step 739, the second data processing device 130 can check whether any leaf function or shared library function exists as a candidate. If true, the instrumentation sequence 700 can proceed to... Figure 7 Step 741. If false, then instrumentation sequence 700 can proceed to... Figure 7 Step 745.

[0106] exist Figure 7 In step 741, the second data processing device 130 may insert an XOR instruction. After step 741, the instrumentation sequence 700 may proceed to step 743.

[0107] exist Figure 7In step 743, the second data processing device 130 may insert the "lm j" instruction. After step 743, in order to end the current iteration loop 717, the instrumentation sequence 700 may proceed to step 711.

[0108] exist Figure 7 In step 745, the second data processing device 130 may insert an XOR instruction. After step 745, the instrumentation sequence 700 may proceed to step 747.

[0109] exist Figure 7 In step 747, the second data processing device 130 can replace the indirect CALL instruction with an indirect JUMP instruction. After step 747, in order to end the current iteration loop 717, the instrumentation sequence 700 can proceed to step 711.

[0110] exist Figure 7 In step 749, the second data processing device 130 can check whether the current assembly instruction is a RET instruction. If it is true, then the instrumentation sequence 700 can proceed to... Figure 7 Step 751. If false, then instrumentation sequence 700 can proceed to... Figure 7 Step 757.

[0111] exist Figure 7 In step 751, the second data processing device 130 can check whether the current assembly instruction belongs to a leaf function or a shared library function. If true, the instrumentation sequence 700 can proceed to... Figure 7 Step 753. If false, then instrumentation sequence 700 can proceed to step 753. Figure 7 Step 755.

[0112] exist Figure 7 In step 753, the second data processing device 130 may choose not to perform instrumentation in the current iteration loop 717. After step 753, in order to end the current iteration loop 717, the instrumentation sequence 700 may proceed to step 711.

[0113] exist Figure 7 In step 755, the second data processing device 130 can replace RET with a jump table. After step 755, in order to end the current iteration loop 717, the instrumentation sequence 700 can proceed to step 711.

[0114] exist Figure 7 In step 757, the second data processing device 130 can check whether the current assembly instruction is the last instruction in the module. If true, the instrumentation sequence 700 can proceed to... Figure 7 Step 759. If false, then in order to end the current iteration loop 717, the instrumentation sequence 700 can proceed to step 711.

[0115] exist Figure 7 In step 759, the second data processing device 130 can proceed to the next compilation stage, namely the linker, in order to end the instrumentation sequence 700 (761).

[0116] Figure 8 This is a schematic diagram of the architecture of the runtime verification system 100 provided in the embodiment. When the target application, i.e., the hardened version 143 of the application machine code 141, is deployed, it can maintain normal operation without disclosing or logging any information. Inline instrumentation can calculate reference values ​​for anomalies during execution. If an error occurs, i.e., an error occurs as... Figure 8 If a violation is indicated by circle 1, the LM exception handler 207 is triggered. The LM exception handler 207 can also be triggered if the indirect branch instruction targets a non-LM instruction. In any case, when the LM exception handler 207 is triggered, such as... Figure 8 As shown in circle 2, it will only record the values ​​of the SR and RR registers in an append-only log file stored in non-volatile memory 115, and its integrity can be verified using a static remote proof scheme. Figure 8 As shown in circles 3 and 4, the LM exception handler 207 can also anchor the hash value of the added record to the RoT hardware component 211 via the RoT driver 209 to detect any potential future tampering. Finally, the LM exception handler 207 can stop the corresponding userspace process, as it is likely to be corrupted.

[0117] like Figure 8 As shown in circle 5, at any point in time, if the verifier server 120 is interested in verifying the runtime integrity status of the first data processing device 110, it can send a verification request to the remote verification agent 203 to inquire about the value of the special register in the RoT hardware module 211.

[0118] like Figure 8 As shown in circle 6, the remote proof agent 203 can query the value from the RoT hardware module 211 via the RoT driver 209 and send it back to the verifier server 120. If the value is as expected (e.g., zero), the proof process is terminated at this stage, and the conclusion is drawn that the first data processing device 110 is in a benign state. Otherwise, as... Figure 8 As shown in circle 7, verifier server 120 can continue to request the verification process of the entire signed log file.

[0119] like Figure 8As shown in circles 8 and 9, the remote verification agent 203 can retrieve the log file from the non-volatile memory 115 and send it back along with all the metadata required by the RoT hardware module 211 to verify its integrity and authenticity.

[0120] like Figure 8 As shown in circle 10, the verifier server 120 can then further investigate the execution status of the first data processing device 110 based on the received SR and RR register values. The verifier server 120 can output the function name and the path followed (possibly executed by an attacker) to trigger the LM exception handler 207.

[0121] Advantageously, the embodiments described herein can provide prevention and detection capabilities, namely, both control flow integrity (CFI) and control flow attestation (CFA). This can cover all control flow hijacking attacks. Furthermore, by providing prevention and detection capabilities to a trusted party (e.g., validator server 120) and trusted evidence regarding the runtime integrity state of the device (e.g., at least one first data processing device 110), the embodiments described herein can be highly beneficial in many scenarios such as cloud services.

[0122] The embodiments described herein are also completely transparent in a sense that they do not rely on secrets, and are therefore highly robust to many attacks. The embodiments described herein can also be extended to complex software stacks and can be very efficient in terms of performance overhead. By providing CFI capabilities and context awareness resulting from the use of XOR chains with unique IDs, the validator server 120 can reconstruct the latest execution path when needed. Unlike traditional CFA mechanisms, the embodiments described herein can report two register values ​​(SR and RR) as a report when needed, which is sufficient to reconstruct the latest execution trajectory when required. Given a small amount of proof data 145 (i.e., reports) and a deterministic method of verifying them, the validator functionality can be extended to handle a large number of first data processing devices 110. When the target application, i.e., a hardened version 143 of the application machine code 141, is deployed, it can remain operational without disclosing or logging any information.

[0123] The embodiments described herein can make launching a control flow hijacking attack (i) extremely difficult, (ii) detectable, and (iii) verifiable. The embodiments described herein can be based on a hardware-software co-design of fine-grained control flow integrity and proof schemes, which includes one or more of the following features:

[0124] - Hardware-aided landmark instructions can be inserted to restrict the valid targets of indirect branches (call and jump instructions). Therefore, if such instructions exist, indirect branches can only target them. Otherwise, an exception may be thrown.

[0125] - The Return (RET) instruction can be replaced with a hard-coded jump table to eliminate the ROP code snippet.

[0126] - These two registers can be dedicated to specific functions. When any control transfer instruction is executed, these two registers can be updated via an XOR operation.

[0127] To maintain awareness of the execution context.

[0128] The value of the register can be associated with the memory address of the correct jump destination to minimize lookup time in a hard-coded jump table.

[0129] - A unique ID can be assigned to each branch instruction, allowing for fine-grained assignment at the branch point level.

[0130] - A custom LM exception handler can be used to detect and report violations.

[0131] - Results can be verified easily and quickly, thus making it scalable.

[0132] If there is an interest in proving the runtime integrity of a target device (e.g., at least one first data processing device 110), the embodiments described herein can be applied to any product in any scenario. For example, if the required hardware support is found, it can be applied to implantable medical devices with safety-critical software that, if necessary, can be proven by a doctor or patient themselves. The invention can also be applied to various electronic control units (ECUs) in automobiles to achieve this implicit runtime proof without compromising the safety of many critical components. In short, the invention can also be applied to many technical fields as long as the required hardware is supported, such as in providing landmark instructions and reserving two registers.

[0133] The hardware portions of the embodiments described herein can be implemented in next-generation ARM and Intel architectures. Therefore, the embodiments described herein can be effectively applied to many products in the ICT field. Unlike traditional methods, the instrumentation portions in the embodiments described herein are not static but dynamic, specifically computational (via XOR operations) to maintain context awareness.

[0134] Figure 9 A flowchart is shown for a method 900 for executing a software application defined by application machine code 141 (e.g., a target binary image).

[0135] Method 900 includes the following steps: executing (901) a modified version 143 of application machine code 141 defining the application, wherein the modified version 143 of application machine code 141 includes one or more direct or indirect branch instructions and one or more machine code instructions, the one or more machine code instructions being one or more target instructions of one or more direct or indirect branch instructions.

[0136] Method 900 further includes the following steps: updating (903) the value of the first register in the first register and the value of the second register in the second register.

[0137] Method 900 further includes the following steps: triggering an exception (905) based on the first register value and the second register value, and / or if one or more direct or indirect branch instructions target instructions of a modified version 143 of the application machine code 141 instead of one or more target instructions.

[0138] Since method 900 can be implemented by the first data processing device 110, other features of method 900 come directly from the functionality of the first data processing device 110 and its various embodiments described above and below.

[0139] Those skilled in the art will understand that the “blocks” (“units”) in the various drawings (methods and apparatuses) represent or describe the functionality of embodiments of the invention (and are not necessarily separate “units” in hardware or software), and thus equally describe the functionality or features (units equivalent to steps) of apparatus embodiments and method embodiments.

[0140] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The embodiments of the apparatus described are merely exemplary. For example, unit partitioning is only a logical functional partitioning, and other partitioning methods may exist in actual implementation. For example, multiple units or components may be merged or integrated into another system, or some features may be ignored or not performed. Furthermore, the mutual coupling or direct coupling or communication connections shown or discussed may be implemented through some interfaces. Indirect coupling or communication connections between devices or units may be implemented electronically, mechanically, or otherwise.

[0141] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0142] In addition, the functional units in the embodiments described herein may be integrated into a processing circuit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

Claims

1. A data processing apparatus (110) for executing an application, characterized in that, The data processing device (110) includes: Processing circuit (111) is configured to execute a modified version (143) of application machine code (141) defining the application, wherein the modified version (143) of the application machine code (141) includes one or more direct or indirect branch instructions and one or more machine code instructions, the one or more machine code instructions serving as one or more target instructions of the one or more direct or indirect branch instructions. During the execution of the modified version (143) of the application machine code (141), the processing circuit (111) is also used to update the first register value in the first register and the second register value in the second register, and trigger an exception based on the first register value and the second register value, and / or if the one or more direct or indirect branch instructions are directed to instructions of the modified version (143) of the application machine code (141) rather than the one or more target instructions.

2. The data processing apparatus (110) according to claim 1, characterized in that, The data processing device (110) further includes a communication interface (113) for reporting proof data (145) to the verifier server (120) when an anomaly has been triggered. The proof data (145) includes information about the first register value and / or the second register value.

3. The data processing apparatus (110) according to claim 2, characterized in that, The information regarding the first register value and / or the second register value includes the first register value and the second register value and / or a summary value based on the first register value and / or the second register value.

4. The data processing apparatus (110) according to any one of the preceding claims, characterized in that, The one or more direct or indirect branch instructions of the modified version (143) of the application machine code (141) include one or more direct or indirect CALL instructions, one or more direct or indirect JUMP instructions and / or one or more direct or indirect RETURN instructions.

5. The data processing apparatus (110) according to any one of the preceding claims, characterized in that, For each of the one or more direct or indirect branch instructions in the modified version (143) of the application machine code (141), the processing circuit (111) is configured to: Move the current value of the first register in the first register to the second register; The current value of the first register is updated by XORing with the unique identifier; Execute the direct or indirect branch instruction; The current value of the first register is updated by another XOR operation with the unique identifier; Compare the updated current value of the first register with the value of the second register.

6. The data processing apparatus (110) according to claim 5, characterized in that, The processing circuit (111) is also used to: trigger an exception if the updated current first register value is different from the second register value.

7. The data processing apparatus (110) according to claim 5 or 6, characterized in that, The processing circuit (111) is used to generate or obtain the unique identifier for each of the one or more direct or indirect branch instructions of the modified version (143) of the application machine code (141).

8. The data processing apparatus (110) according to any one of the preceding claims, characterized in that, The first register and the second register are configured to be modified only by assignment instructions, XOR instructions, and comparison instructions.

9. The data processing apparatus (110) according to any one of the preceding claims, characterized in that, The modified version (143) of the application machine code (141) includes one or more RETURN instructions for the original version of the application machine code (141) that define one or more jump tables for jump destinations.

10. The data processing apparatus (110) according to claim 9, characterized in that, The processing circuit (111) is also configured to associate the first register value of the first register with the memory address of the one or more jump destinations defined by the jump table.

11. A runtime verification system (100), characterized in that, include: At least one data processing device (110) according to any one of the preceding claims is used to generate proof data (145); A verifier server (120) is configured to receive the verification data (145) from the at least one data processing device (110) and verify the integrity of the at least one data processing device (110) based on the verification data (145).

12. A method (900) for executing an application, characterized in that, The method (900) includes: Execute (901) a modified version (143) of the application machine code (141) defining the application, wherein the modified version (143) of the application machine code (141) includes one or more direct or indirect branch instructions and one or more machine code instructions, the one or more machine code instructions serving as one or more target instructions of the one or more direct or indirect branch instructions; Update (903) the value of the first register in the first register and the value of the second register in the second register; Based on the first register value and the second register value, and / or if the one or more direct or indirect branch instructions target the modified version (143) of the application machine code (141) instead of the one or more target instructions, an exception (905) is triggered.

13. A data processing apparatus (130), characterized in that, The data processing device (130) is used to modify an original version of the application machine code (141) defining the application to a modified version (143) of the application machine code (141), wherein the original version of the application machine code (141) includes one or more direct or indirect branch instructions, and the data processing device (130) is used to: Each instruction in the one or more direct or indirect branch instructions of the original version of the application machine code (141) includes one or more machine code instructions that indicate one or more target instructions of the one or more direct or indirect branch instructions for obtaining the modified version (143) of the application machine code (141). The modified version (143) of the application machine code (141) is compiled into an executable binary image.

14. The data processing apparatus (130) according to claim 13, characterized in that, The one or more direct or indirect branch instructions include one or more direct or indirect CALL instructions, and / or one or more direct or indirect JUMP instructions and / or one or more direct or indirect RETURN instructions.

15. The data processing apparatus (130) according to claim 13 or 14, characterized in that, The original version of the application machine code (141) includes one or more RETURN instructions, and the data processing device (130) is configured to include a jump table defining one or more jump destinations for each of the one or more RETURN instructions.

Images