Programming guards for returns

Abstract

A ROP attack protection device is composed of the following parts: a first memory area in which a protection function is stored, the first memory area is set to be executable; and a second memory area in which a plurality of operation functions are stored, the second memory area is set to be non-executable, wherein the protection function is set to: in response to a call to one of the plurality of operation functions and further in response to at least one predetermined rule, allow the execution of the called operation function; and after receiving a return from the executed operation function, set the executed operation function to be non-executable.

Description

Technical Field

[0001] The present invention relates generally to the field of security devices, and more particularly to a system and method for defending against return-oriented programming (ROP) attacks. Background Art

[0002] ROP is a computer security exploitation technique that allows an attacker to execute malicious code even in the presence of security defenses such as executable space guards and code signing. With ROP, an attacker can take control of the call stack and hijack program control flow. The attacker is then able to execute carefully chosen sequences of machine instructions that are already present in the device's memory. These sequences are called "instruction snippets." Each instruction snippet typically ends with a return instruction and is located in a subroutine of an existing program and / or in shared library code. These instruction snippets are chained together, allowing an attacker to execute arbitrary operations even in devices that employ defenses that would block simpler attacks.

[0003] One method of defending against ROP attacks is Address Space Layout Randomization (ASLR). In ASLR, components are randomly moved to different addresses in virtual memory each time a program is run. In vehicle systems, there are situations where the size of the Random Access Memory (RAM) is limited, and as a result, there is not enough RAM to run the binary from RAM. Therefore, in this case, the binary will be run from flash memory. Flash memory has a limit on the number of times it can be rewritten. Therefore, ASLR can only be performed a limited number of times and is therefore not a good solution. In addition, writing to flash memory takes time, so rewriting the program to the random memory cells at boot time will add undesirable delays.

[0004] What is desired is a method of defending against ROP attacks without having to perform ASLR, and the prior art does not provide such a method. Summary of the invention

[0005] Therefore, the main object of the present invention is to overcome at least some of the shortcomings of the prior art ROP attack protection. In one embodiment, this is provided by a ROP attack protection device, the device comprising: a first memory area in which a protection function is stored, the first memory area is set to be executable; and a second memory area in which a plurality of operation functions are stored, the second memory area is set to be non-executable, wherein the protection function is set to: in response to a call to one of the plurality of operation functions, and further in response to at least one predetermined rule, allow the execution of the called operation function; and after receiving a return from the executed operation function, set the executed operation function to be non-executable.

[0006] In one embodiment, the plurality of operation functions include a called function and a caller function, a call to the called function is received from the caller function, and wherein the protection function is further configured to: in response to the call, set the caller function to be non-executable; in response to the received return, allow the execution of the caller function. In another embodiment, in response to at least one predetermined rule, the protection function is further configured to determine whether the return address of the call is valid, wherein the execution of the called operation function is allowed in response to the return address of the call being determined to be valid, and wherein, in response to the return address of the call being determined to be invalid, the protection function is further configured to: not allow the execution of the called operation function; and output a notification about the invalid return address. In another embodiment, determining that the return address is valid includes determining that the return address is not within the address range of the protection function, and wherein determining that the return address is invalid includes determining that the return address is within the address range of the protection function.

[0007] In one embodiment, the call to one of the plurality of operation functions includes: a call to a protection function; and information about the address of the called function. In another embodiment, the permission of execution includes defining a portion of the second memory area as executable, wherein setting the executed operation function to be non-executable includes defining the portion of the second memory area as non-executable. In another embodiment, defining the portion of the second memory area as executable includes: rewriting the value of the first register at a first boundary of the address range of the operation function that is allowed to be executed, and rewriting the value of the second register at a second boundary of the address range of the operation function that is allowed to be executed, wherein defining the portion of the second memory area as non-executable is executed by rewriting.

[0008] In one embodiment, the allowing of execution includes copying the called operation function to the first memory area, wherein setting the executed operation function to be non-executable includes deleting the executed operation function from the first memory area.

[0009] Independently, a method for return oriented programming (ROP) attack protection is provided, the method comprising: providing a memory area in which a plurality of operation functions are stored, the memory area being set to be non-executable; in response to a call to one of the plurality of operation functions, and further in response to at least one predetermined rule, allowing execution of the called operation function; after receiving a return from the executed operation function, setting the executed operation function to be non-executable.

[0010] In one embodiment, the plurality of operation functions include a called function and a caller function, and a call to the called function is received from the caller function, wherein the method further comprises: in response to the call, setting the caller function to be non-executable; and in response to the received return, allowing the execution of the caller function. In another embodiment, in response to at least one predetermined rule, the method further comprises: determining whether the return address of the call is valid, allowing the execution of the called operation function in response to the return address of the call being determined to be valid; in response to the return address of the call being determined to be invalid, not allowing the execution of the called operation function and outputting a notification about the invalid return address.

[0011] In another embodiment, allowing execution of the called operation function and setting the executed operation function to be non-executable are performed by a protection function, wherein determining that the return address is valid includes determining that the return address is not within the address range of the protection function, and wherein determining that the return address is invalid includes determining that the return address is within the address range of the protection function. In yet another embodiment, calling one of the plurality of operation functions includes: a call to the protection function; and information about the address of the called operation function.

[0012] In one embodiment, the enabling of execution includes defining a portion of the memory area as executable, and wherein setting the executed operation function to be non-executable includes defining the portion of the memory area as non-executable. In another embodiment, defining the portion of the memory area as executable includes: rewriting the value of a first register at a first boundary of an address range of the operation function that is enabled to be executed, and rewriting the value of a second register at a second boundary of the address range of the operation function that is enabled to be executed, wherein defining the portion of the memory area as non-executable is performed by rewriting.

[0013] In another embodiment, the enabling of execution includes copying the called operation function to an executable area of ​​the memory, and wherein setting the executed operation function to be non-executable includes deleting the executed operation function from the executable area of ​​the memory.

[0014] Independently, a return-oriented programming (ROP) attack protection device is provided, which includes: a processor; a first memory area in which instructions are stored that cause the processor to implement a protection function when read by the processor, and the first memory area is set to be executable; a second memory area in which instructions are stored that cause the processor to implement multiple operation functions when read by the processor, and the second memory area is set to be non-executable, wherein, in response to a call and further in response to at least one predetermined rule, the processor is set to implement the protection function to: allow execution of one of the operation functions; and after completing the executed operation function, set the executed operation function to be non-executable.

[0015] In one embodiment, a plurality of operation functions include a called function and a caller function, a call to the called function is received from the caller function, wherein the processor is further configured to implement a protection function to: in response to the call, set the caller function to be non-executable; in response to the received return, allow the execution of the caller function. In another embodiment, in response to at least one predetermined rule, the processor is further configured to implement a protection function to determine whether the return address of the call is valid, wherein the execution of the called operation function is allowed in response to the return address of the call being determined to be valid, and wherein, in response to the return address of the call being determined to be invalid, the processor is further configured to implement a protection function to: not allow the execution of the called operation function; and output a notification about the invalid return address. In another embodiment, determining that the return address is valid includes determining that the return address is not within the address range of the protection function, and wherein determining that the return address is invalid includes determining that the return address is within the address range of the protection function.

[0016] In another embodiment, the call to one of the plurality of operation functions includes: a call to a protection function; and information about an address of the called function. In one embodiment, the permission of execution includes defining a portion of the second memory area as executable, wherein setting the executed operation function as non-executable includes defining the portion of the second memory area as non-executable. In one embodiment, the permission of execution includes copying the called operation function to the first memory area, wherein setting the executed operation function as non-executable includes deleting the executed operation function from the first memory area.

[0017] Additional features and advantages of the invention will become apparent from the following drawings and description. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] For a better understanding of the invention and to show how it may be carried into effect, reference will now be made, purely by way of example, to the accompanying drawings in which like reference numerals refer to corresponding parts or elements throughout.

[0019] With specific reference now to the drawings in detail, it is emphasized that the details shown are exemplary only and are presented only for the purpose of illustrative discussion of the preferred embodiments of the invention and in order to provide what is believed to be the most useful and most easily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show the structural details of the invention in more detail than is necessary for a basic understanding of the invention, and it will be apparent to those skilled in the art from the description in conjunction with the drawings how the several forms of the invention may be carried out. In the drawings:

[0020] Figure 1is a high-level schematic diagram of a first embodiment of a program attack protection device.

[0021] Figure 2 A high-level flow chart illustrating a method of adding a predefined protection module to a binary program image according to certain embodiments;

[0022] Figure 3 shows patching a binary image to make the function branch to Figure 2 A high-level flowchart of the method for implementing predefined protection modules.

[0023] Figure 4 A high-level flow chart illustrating a method for program attack protection according to certain embodiments; and

[0024] Figure 5 A high level schematic diagram of a second embodiment of a program attack protection device is shown. DETAILED DESCRIPTION

[0025] Before explaining at least one embodiment of the present invention in detail, it should be understood that the application of the present invention is not limited to the details of the construction and arrangement of the components set forth in the following description or shown in the accompanying drawings. The present invention may be applied to other embodiments or practiced or executed in various ways. Furthermore, it should be understood that the words and terms used herein are for descriptive purposes and should not be considered restrictive.

[0026] Figure 1A high-level schematic diagram of a ROP attack protection device 10 is shown. The ROP attack protection device 10 includes: a processor 20; a memory protection unit (MPU) 25; and a memory 30. As known to those skilled in the art, the MPU 25 is a hardware component that allows a predefined memory area to be set to be non-executable. In particular, the code written in the non-executable memory area cannot be executed. Although the processor 20 and the MPU 25 are shown as separate units for simplicity, this is not meant to be limiting in any way, and in a specific embodiment, the MPU 25 is implemented within the processor 20. In one embodiment, the processor 20 is a microprocessor. The memory 30 includes: at least one non-executable area 40, which is set so that the code stored therein cannot be executed by the processor 20; and at least one executable area 50, which is set so that the code stored therein can be executed by the processor 20. In one embodiment, one or more dedicated registers record which memory areas are executable and the remaining areas are non-executable, and the following description is about such an embodiment. In another embodiment, a dedicated one or more registers record which memory areas are non-executable and the remaining areas are executable. In another embodiment, one or more first special registers record which memory regions are executable, and one or more second special registers record which memory regions are non-executable. The MPU 25 sets the memory regions to be non-executable in response to the values ​​of the special registers. In one embodiment, the memory 30 is a flash memory, i.e., a computer storage medium that can be electrically erased and reprogrammed.

[0027] As will be further described below, the protection function 60 is stored in the executable area 50, and a plurality of operation functions 70 are stored in the non-executable area 40. As used herein, the term operation function refers to any function that performs any type of operation, without limitation. For the sake of clarity, an operation function 70 that calls another operation function 70 is referred to herein as a caller operation function 70. Similarly, the called operation function 70 is referred to herein as a callee operation function 70. In addition, an interrupt function and an initialization command are stored in the executable area 50. In another embodiment, the interrupt function and the initialization command are stored in a separate executable area 50, which is different from the location where the operation function 70 is stored. Each of the protection function 60, the operation function 70, the interrupt function and the initialization command includes a computer-readable instruction that is configured to cause the processor 20 to perform a corresponding operation when read by the processor 20.

[0028] As will be further described below, any call to the operation function 70 enters the protection function 60. In one embodiment, after the protection function 60 is enabled by the startup code, in the case where the caller function is the operation function 70 stored in the non-executable area 40, the protection function 60 sets the caller operation function 70 to be non-executable. In particular, in one embodiment, the protection function 60 adjusts the value of a specific register so that the MPU 25 sets the portion of the non-executable area 40 containing the caller operation function 70 to be non-executable.

[0029] The protection function 60 is set to detect an exception in a call to an operation function 70 according to at least one predetermined rule of the protection model. In response to a call to the callee operation function 70, for example, by a main function, and in response to at least one predetermined rule, the protection function 60 analyzes the return address stored on the call stack to determine whether it is a valid return command. In particular, in an embodiment where all functions are stored in the non-executable area 40 of the memory 30, the protection function 60 checks whether the return address is the same as the address of the protection function 60. In the case where an attacker causes a stack overflow attack to hijack the return address, it cannot jump to any operation function 70 because they are all set to be non-executable, and any attempt to jump to any operation function 70 will result in an exception. However, the return address can be hijacked in order to jump to the protection function 60. Therefore, if the return address is a protection function 60, it is identified as an attack. In an embodiment where one or more operation functions 70 are set to return to the protection function 60 instead of another operation function 70, the protection function 60 will allow the return.

[0030] In one embodiment where not all functions are stored in the non-executable area 40, and thus the return address can be hijacked to jump to other functions, the protection function 60 compares the return command with predetermined parameters to determine whether the call is within a legal parameter range, such as whether the callee operation function 70 is allowed to return data to the address. In another embodiment, the protection function 60 determines that the return is valid only if the return address is within the address range of the caller operation function 70. Therefore, at least one predetermined rule includes the above-mentioned parameters for determining whether the return address is valid.

[0031] In the case where the call is determined to be valid, the protection function 60 allows the execution of the callee operation function 70. In particular, in one embodiment, the protection function 60 adjusts the value of a specific register so that the MPU 25 sets the portion of the non-executable area 40 containing the callee operation function 70 to be executable. In the case where the call is determined to be invalid, the protection function 60 does not allow the execution of the callee operation function 70 and generates an exception. In one embodiment, the protection function 60 generates a notification indicating an invalid call and outputs the notification to a predetermined output.

[0032] In another embodiment, even if all functions are set to be non-executable, the protection function 60 checks whether the return address is to the caller operation function 70. In the case that the return address is invalid, the protection function 60 generates a notification with invalid return details.

[0033] The return of the callee operation function 70, that is, the data returned by the callee operation function 70, is received by the protection function 60. In response to receiving the return message, the protection function 60 sets the callee operation function 70 to be non-executable. In particular, in one embodiment, the protection function 60 adjusts the value of a specific register, thereby defining the portion of the non-executable area 40 containing the callee operation function 70 as non-executable. In addition, the protection function 60 allows the caller operation function 70 to be executed. As described above, in one embodiment, the protection function 60 adjusts the value of a specific register, thereby defining the portion of the non-executable area 40 containing the caller operation function 70 as executable.

[0034] In summary, only a single operation function 70 is allowed to be executed at any given time. After the call is made, the caller operation function 70 is set to be non-executable, and the called operation function 70 is allowed to be executed only when the return address on the call stack is valid. After the execution is completed and the requested data is returned, the called operation function 70 is set to be non-executable, and the caller operation function 70 is allowed to be executed again. Therefore, ROP attacks cannot be implemented. In other applications, such protection methods can be useful in the protection of automotive data systems, such as those described in the following: International Application Publication WO 2018 / 037397 (published on March 1, 2018); and U.S. Provisional Patent Application 62 / 617,668 (filed on January 16, 2018), the entire contents of each of which are incorporated herein by reference.

[0035] In one non-limiting embodiment, where the ROP attack protection device 10 is implemented in a TriCore microcontroller, which is commercially available from Infineon Technologies AG of Neubiberg, Germany, each executable address range is stored in a dedicated pair of registers, the first register storing the address of the upper boundary of the executable range, and the second register storing the address of the lower boundary of the executable range. As described above, the first register pair is used to define the address range of the protection function 60, and the second register pair is used to define the address range of the operation function 70 currently allowed to be executed. The value of the control register is set so that both register pairs are set to define the executable range. Allowing the operation function 70 to be executed includes: rewriting the value of the second register pair with the address boundary of the operation function 70 to be executed. In one embodiment, when the register pair value is rewritten with the address range of the allowed operation function 70, the operation function 70 to be executed is automatically restored to non-executable. Therefore, in the above embodiment, the executable range 50 is determined by the first and second register pairs. Initialization code and interrupt functions are defined as executable by the first register pair or other register pairs. Any memory not defined as executable by the register is defined as a non-executable area 40 .

[0036] In another non-limiting embodiment, where the ROP attack protection device 10 is implemented in an MPC5777 microcontroller, which is commercially available from NXP Semiconductors NV of Eindhoven, the Netherlands, there are 24 sets of adjustable memory ranges, of which 6 sets are dedicated to code, 12 sets are dedicated to memory, and 6 sets can be used for both code and memory. There are 5 registers: a first register for selecting the range to be configured; a second register for configuring the process ID; a third register for defining the upper boundary of the range; a fourth register for defining the lower boundary of the range; and a fifth register for determining whether the range is executable or non-executable. As described above, the first range is configured to include the protection function 60, and the second range is configured to include the address range of the operation function 70 that is allowed to be executed. In one embodiment, allowing the operation function 70 to be executed includes: selecting the second range with the first register; overwriting the value in the third register with the upper boundary of the address range of the operation function 70; and overwriting the value in the fourth register with the lower boundary of the address range of the operation function 70. As described above, in such an embodiment, when the register value is overwritten, the operation function 70 is automatically set to be non-executable.

[0037] Figure 2A high-level flow chart of a method for adding a predefined protection module (e.g., protection function 60) to a binary program image when source code is not available is shown. The following is a description of an executable and linkable format (ELF) file. In stage 1000, the file is analyzed by a patch script to find available space where the protection functionality can be placed. In stage 1010, if there is enough space in the existing segment, a portion of the PROGBITS of the predefined protection module (i.e., a portion of the program content) is copied by the patch script to the binary program image in the space of stage 1000. In one embodiment, only the PROGBITS portion necessary for running the predefined protection module is copied to save space. When the PROGBITS of the predefined protection module is copied to the binary program image, preferably, the relative distance between different portions within the protection functionality is maintained. In particular, the portion of the ELF file that contains various types of data and is loaded at runtime needs to be mapped to an address in the CPU memory. As known to those skilled in the art at the time of the present invention, mapping is performed in segments. Each segment contains a series of continuous PROGBITS portions that are loaded together to the address specified by the segment. Therefore, the segment added for the protection functionality will load the added PROGBITS section into the process address space at runtime.

[0038] In stage 1020, if there is not enough space in the existing segments, two new segments are added to the ELF file by the patch script. The first section is for read-only executable text and the second section is for read-write access. Then, the various sections of the protection functionality are added to the added segments. Specifically, the read-write access PROGBITS section includes data and the global offset table (GOT).

[0039] All segments of the ELF file are listed in the program header table. After the two new segments are added in stage 1020, the program header table no longer fits in its original offsets. Therefore, in stage 1030, the program header table is moved to the end of the ELF file by the patch script. In stage 1040, a third segment is added to the program header table by the patch script, and the third segment is set to load the program header table into the process address space from its new location at runtime to allow the process to be loaded and executed. The code is position-independent, so as long as the relative distances between different sections are maintained, there is no need to make any modifications to the relocations within the address space. However, sometimes there are global offsets in the code. These offsets are stored in the GOT and modified by the patch script in stage 1050 to reflect the relocation of the addresses. Therefore, a new ELF file is generated, containing the original program and the predefined protection modules.

[0040] Figure 3A high-level flow chart of a method for patching a binary image is shown, the binary image being, for example, the generated ELF file of stages 1000-1050, so that the function branches to a predetermined protection module, such as the protection function 60 described above. In stage 2000, the patch script replaces the call opcode in the binary image with a call to a predefined protection module. For example, in the ARM instruction set, the opcode POP is replaced with BL xxxxx, where xxxxx is the relative offset from the current frame pointer to the address of the predefined protection module. For situations where there is a complex instruction set, the returned opcode can have different sizes, such as 16 bits or 32 bits, and the returned opcode is replaced by a call to a dedicated software interrupt, which jumps to the predefined protection module. The new call to the predefined protection module contains the address of the original operation function being called. In one embodiment, all call opcodes in the binary image are replaced. In another embodiment, a predetermined list of call opcodes is replaced.

[0041] In stage 2020, the training script scans the binary program image to determine the start and end addresses of each caller and callee function for each call, as well as the addresses stored in the protection library. In stage 2030, the data portion of the predefined protection module of stage 2000 is updated with the address data and predetermined verification parameters.

[0042] Figure 4 A high-level flow chart of a ROP attack protection method according to certain embodiments is shown. In stage 3000, a memory area having a plurality of operation functions stored thereon is provided, the memory area being set to be non-executable. In optional stage 3005, in one embodiment, the caller function is one of the plurality of operation functions. In such an embodiment, in response to a call of the caller function of stage 3000 to one of the plurality of operation functions, the caller function is set to be non-executable. In optional stage 3007, in response to the call of optional stage 3005 and further in response to at least one predetermined rule of stage 3010 described below, a determination is performed to determine whether the return address of the call of optional stage 3005 is valid.

[0043] In stage 3010, in response to a call to one of the plurality of operation functions of stage 3000, optionally the calls of stages 3005 and 3007, and further in response to at least one predetermined rule, execution of the called operation function is allowed. In one embodiment, allowing execution of the called operation of stage 3010 is in response to the return address of the call being determined to be valid. In one embodiment, the allowing of execution is performed by a protection function. In particular, in one embodiment, each call to the operation function includes a call to the protection function and information about the address of the called operation function. In one embodiment, determining that the return address is valid includes determining that the return address is not within the address range of the protection function of stage 3010. In another embodiment, the allowing of execution includes defining a portion of the memory area of ​​stage 3000 as executable, the portion including the address range of the allowed operation function. In another embodiment, defining the portion as executable includes: rewriting the value of a first register with a first boundary of the address range of the operation function allowed to be executed, and rewriting the value of a second register with a second boundary of the address range of the operation function allowed to be executed.

[0044] In stage 3020, after receiving a return from the executed operation function of stage 3010, the executed operation is set to be non-executable. In one embodiment, the executed operation function is set to be non-executable by a protection function. In another embodiment, the executed operation is set to be non-executable including defining a portion of stage 3010 as non-executable, the portion including the address range of the executed operation function. In yet another embodiment, the portion is automatically defined as non-executable by rewriting stage 3010. In optional stage 3030, in response to the received return of stage 3020, the caller function of stage 3005 is allowed to execute.

[0045] In optional stage 3040, in response to the return address of the call of stage 3010 being determined to be invalid, the called operation of stage 3010 is not allowed to be executed, and a notification about the invalid return address is output. In one embodiment, determining that the return address is invalid includes determining that the return address is within the address range of the protection function of stage 3010.

[0046] Figure 5A high-level schematic diagram of a ROP attack protection device 100 according to certain embodiments is shown. When access to the MPU is not allowed during runtime (e.g., in a safety-related vehicle system component), the ROP attack protection device 100 is used instead of the ROP attack protection device 10. The ROP attack protection device 100 includes: a processor 110; an MPU 115; a memory 120; and a memory 130. As described above, the memory 120 or a predetermined area thereof is set to be non-executable by the MPU 115. The memory 130 or a predetermined area thereof is executable. In one embodiment, the memory 120 is a flash memory. In another embodiment, the memory 130 is a RAM. In one embodiment, the memory 130 or an executable area thereof has stored therein a protection function 140. As described above, interrupt functions and initialization commands are stored in the executable memory 130. The memory 120 or its non-executable area has stored therein a plurality of operation functions 150. In another embodiment, the memory 120 has an executable area and a non-executable area. In such an embodiment, a protection function 140 is stored in the executable area, and a plurality of operation functions 150 are stored in the non-executable area. Each of the protection function 140, the operation function 150, the interrupt function and the initialization command includes computer-readable instructions that, when read by the processor 110, are configured to cause the processor 110 to perform a corresponding operation.

[0047] The operation of the protection function 140 is similar in all respects to the operation of the protection function 60, except that allowing the operation function 150 to be executed includes copying the operation function 150 to the memory 130 and setting the operation function 150 to be non-executable includes deleting the operation function 150 from the memory 130. In particular, an operation function 150 such as a main function is started on the memory 130 and calls the called operation function 150. In response to the return address of the call being determined to be valid, the protection function 140 deletes the caller operation function 150 from the memory 130 and copies the callee operation function 150 to the memory 130 where the function can be executed. Upon receiving a return message from the callee operation function 150, the protection function 140 deletes the callee operation function 150 from the memory 130 and copies the caller operation function 150 back to the memory 130. The protection function 140 also sends the return message to the return address in the caller operation function 150.

[0048] To avoid security risks caused by having a memory area that is both writable and executable, preferably the protection function 140 is defined as the only process that can write to the memory 130. For example, in the MPC574XG, commercially available from NXP Semiconductors NV of Eindhoven, The Netherlands, such a definition can be accomplished using the following code:

[0049] SMPU_1.RGD[1].WORD4.B.PID=0x1;

[0050] SMPU_1.RGD[1].WORD4.B.PIDEN=0x1; / / enablePID

[0051] SMPU_1.RGD[1].WORD5.B.VLD=0x1; / / enable descriptor[0]

[0052] This allows only process ID 1 to write to a predefined area of ​​memory 130 .

[0053] In the protection functionality 140, the code defines the protection functionality as process ID 1, thereby defining an area of ​​the memory 130 that only the protection functionality 140 can write to:

[0054] _MTSPR(SPR_PID, 1);

[0055] It should be understood that certain features of the invention that are described in the context of separate embodiments for the sake of clarity may also be provided in combination in a single embodiment. Conversely, various features of the invention that are described in the context of a single embodiment for the sake of brevity may also be provided separately or in any suitable sub-combination. In particular, the present invention has been described by identifying each powered device by classification, but this is not meant to be limiting in any way. In alternative embodiments, all powered devices are treated equally and therefore there is no need to identify the class by its relative power requirements.

[0056] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the invention belongs. Although methods similar or equivalent to those described herein can be used in the practice or testing of the present invention, suitable methods are described herein.

[0057] All publications, patent applications, patents and other references mentioned herein are incorporated herein by reference in their entirety. In the event of a conflict, the patent specification and its definitions shall prevail. In addition, the materials, methods and embodiments are illustrative only and are not intended to be limiting.

[0058] Those skilled in the art will recognize that the present invention is not limited to what has been specifically shown and described above. On the contrary, the scope of the present invention is defined by the claims, and includes combinations and sub-combinations of the various features described above, as well as variations and modifications thereof that will occur to those skilled in the art after reading the foregoing description.

Claims

1. A return-oriented programming attack protection device, comprising: a first memory area having a protection function stored therein, the first memory area being set to be executable; as well as a second memory area in which a plurality of operation functions are stored, the second memory area being set to be non-executable, The protection function is set as: In response to a call to one of the plurality of operation functions, and further in response to at least one predetermined rule, allowing execution of the called operation function; and After receiving a return from the executed operation function, setting the executed operation function to be non-executable, Wherein, in response to the at least one predetermined rule, the protection function is further configured to determine whether the return address of the call is valid, wherein the execution of the called operation function is allowed in response to the return address of the call being determined to be valid, and Wherein, in response to the return address of the call being determined to be invalid, the protection function is further set to: not allowing said execution of said called operation function; and Outputs a notice about an invalid return address.

2. The return-oriented programming attack protection device according to claim 1, wherein: Determining that the return address is valid includes determining that the return address is not within an address range of the protection function; and Wherein, determining that the return address is invalid includes determining that the return address is within the address range of the protection function.

3. The return-oriented programming attack protection device according to any one of claims 1-2, wherein: said enabling of said execution comprises defining a portion of said second memory area as executable; and The step of setting the executed operation function as non-executable includes defining the portion of the second memory area as non-executable.

4. The return-oriented programming attack protection device according to claim 3, wherein: Defining the portion of the second memory area as executable comprises: rewriting the value of the first register at a first boundary of the address range of the operation function that is allowed to be executed, and rewriting the value of the second register at a second boundary of the address range of the operation function that is allowed to be executed, and The defining of the portion of the second memory area as non-executable is performed by the rewriting.

5. The return-oriented programming attack protection device according to any one of claims 1-2, wherein: The enabling of the execution includes copying the called operation function to the first memory area, and The setting of the executed operation function as non-executable includes deleting the executed operation function from the first memory area.

6. A return-oriented programming attack protection method, the method comprising: providing a memory area in which a plurality of operation functions are stored, the memory area being set to be non-executable; In response to a call to one of the plurality of operation functions, and further in response to at least one predetermined rule, allowing execution of the called operation function; and After receiving the return from the executed operation function, the executed operation function is set to be non-executable, Wherein, in response to the at least one predetermined rule, the method further comprises: determining whether the return address of the call is valid, the allowing execution of the called operation function in response to the return address of the call being determined to be valid; In response to the return address of the call being determined to be invalid, the execution of the called operation function is not permitted and a notification regarding an invalid return address is output.

7. The return-oriented programming attack protection method according to claim 6, wherein: The allowing the execution of the called operation function and the setting of the executed operation function to be non-executable are performed by the protection function, Wherein, determining that the return address is valid includes determining that the return address is not within the address range of the protection function, and Wherein, determining that the return address is invalid includes determining that the return address is within the address range of the protection function.

8. The return-oriented programming attack protection method according to claim 7, wherein: The call to one of the plurality of operation functions comprises: a call to the guard function; and Information about the address of the called operation function.

9. The return-oriented programming attack protection method according to any one of claims 6 to 8, wherein: said enabling of said execution comprises defining a portion of a memory region as executable; and The step of setting the executed operation function as non-executable includes defining the portion of the memory area as non-executable.

10. The return-oriented programming attack protection method according to claim 9, wherein: Defining the portion of the memory area as executable includes: rewriting the value of the first register at a first boundary of the address range of the operation function that is allowed to be executed, and rewriting the value of the second register at a second boundary of the address range of the operation function that is allowed to be executed, and wherein defining the portion of the memory area as non-executable is performed by rewriting.

11. The return-oriented programming attack protection method according to any one of claims 6 to 8, wherein: The enabling of the execution includes copying the called operation function to an executable area of ​​a memory, and The step of setting the executed operation function to be non-executable includes deleting the executed operation function from an executable area of ​​the memory.

12. A return-oriented programming attack protection device, comprising: processor; a first memory area having stored therein instructions which, when read by the processor, cause the processor to implement a protection function, the first memory area being set to be executable; as well as a second memory area in which instructions are stored which, when read by the processor, cause the processor to implement a plurality of operation functions, the second memory area being set to be non-executable, Wherein, in response to the call and further in response to at least one predetermined rule, the processor is configured to implement the protection function to: allowing execution of one of the plurality of operating functions; and After the executed operation function is completed, the executed operation function is set to be non-executable, Wherein, in response to the at least one predetermined rule, the processor is further configured to implement the protection function to determine whether the return address of the call is valid, wherein the execution of the called operation function is allowed in response to the return address of the call being determined to be valid, and Wherein, in response to the return address of the call being determined to be invalid, the processor is further configured to implement the protection function to: not allowing said execution of said called operation function; and Outputs a notice about an invalid return address.

13. The return-oriented programming attack protection device according to claim 12, wherein: Determining that the return address is valid includes determining that the return address is not within an address range of the protection function; and Wherein, determining that the return address is invalid includes determining that the return address is within the address range of the protection function.

14. The return-oriented programming attack protection device according to any one of claims 12 to 13, wherein: said enabling of said execution comprises defining a portion of said second memory area as executable; and The step of setting the executed operation function as non-executable includes defining the portion of the second memory area as non-executable.

15. The return-oriented programming attack protection device according to any one of claims 12 to 13, wherein: The enabling of the execution includes copying the called operation function to the first memory area, and The setting of the executed operation function as non-executable includes deleting the executed operation function from the first memory area.

Images