Patent Description:
ROP is a computer security exploit technique which allows an attacker to execute malicious code even in the presence of security defenses such as executable space protection and code signing. With ROP, the attacker gains control of the call stack and hijacks the program control flow. The attacker can then execute carefully chosen machine instruction sequences which are already present in the device's memory. These sequences are called 'gadgets'. Each gadget typically ends in a return instruction and is located in a subroutine within the existing program and/or in a shared library code. Chained together, these gadgets allow an attacker to perform arbitrary operations even in a device employing defenses which can thwart simpler attacks.

One method of protecting against ROP attacks is address space layout randomization (ASLR). In ASLR, every time the program is run, component are randomly moved to different addresses in the virtual memory. In vehicle systems, there are cases in which the random access memory (RAM) size is limited and as a result there is not enough RAM to run a binary from the RAM. Therefore, in such cases, the binary is run in a flash memory. Flash memory has limitations to the number of times it can be rewritten. Thus, ASLR can be performed only a limited amount of times and thus is not a good solution. Additionally, it takes time to write to the flash memory and therefore rewriting the program into random memory locations at boot time will add an undesired latency.

<CIT>, and entitled " Dynamic execution prevention to inhibit return-oriented programming" is addressed to a method, apparatus, and/or system for execution prevention. A state indicator for a first subset of a plurality of memory pages of executable code in a memory device is set to a non-executable state. A state indicator for a second subset of the plurality of memory pages is set to an executable state, where the second subset of the plurality of memory pages includes indirection stubs to functions in the first subset of the plurality of memory pages. Upon execution of an application, a function call is directed to a corresponding indirection stub in the second subset of the plurality of memory pages which modifies the state indicator for a corresponding function in the first subset of the plurality of memory pages prior to directing execution of the called function from the first subset of the plurality of memory pages.

<CIT>, and entitled " Return oriented programming (rop) attack protection" is addressed to return oriented programing (ROP) attack prevention techniques. In one or more examples, a method is described of protecting against return oriented programming attacks. The method includes initiating a compute signature hardware instruction of a computing device to compute a signature for a return address and the associated location on the stack the return address is stored and causing storage of the computed signature along with the return address in the stack. The method also includes enforcing that before executing the return instruction using the return address on the stack, initiating a verify signature hardware instruction of the computing device to verify the signature matches the target return address on the stack and responding to successful verification of the signature through execution of the verify signature hardware instruction by the computing device, executing the return instruction to the return address.

A publication entitled "<NPL>, describes a method of defeating ROP attacks by using an on-the-fly ROP protection system by using the OS internal facilities, called OnDrop.

What is desired, and not provided by the prior art, is a way of protecting against ROP attacks without having to perform ASLR.

Accordingly, it is a principal object of the present invention to overcome at least some of the disadvantages of prior art ROP attack protection. This is provided in one embodiment by an ROP attack protection apparatus comprising: a first region of memory having stored therein a protection function, the first region of memory set as executable; and a second region of memory having stored thereon a plurality of operation functions, the second region of memory set as non-executable, wherein the protection function is arranged to: responsive to a call to one of the plurality of operation functions and further responsive to at least one predetermined rule, allow execution of the called operation function; and after receiving a return from the executed operation function, set the executed operation function as non-executable.

In one embodiment, the plurality of operation functions comprises the called function and a caller function, the call to the called function received from the caller function, and wherein the protection function is further arranged to: responsive to the call, set the caller function as non-executable; responsive to the received return, allow execution of the caller function. In another embodiment, responsive to the at least one predetermined rule, the protection function is further arranged to determine whether a return address of the call is valid, wherein the allowance of the execution of the called operation function is responsive to the return address of the call being determined to be valid, and wherein, responsive to the return address of the call being determined to not be valid, the protection function is further arranged to: not allow the execution of the called operation function; and output a notification regarding the non-valid return address. In one further embodiment, the determination that the return address is valid comprises a determination that the return address is not within an address range of the protection function, and wherein the determination that the return address is not valid comprises a determination that the return address is within an address range of the protection function.

In one embodiment, the call to one of the plurality of operation functions comprises: a call to the protection function; and information regarding an address of the called function. In another embodiment, the allowance of the execution comprises defining a section of the second region of memory as being executable, wherein the setting the executed operation function as non-executable comprises defining the section of the second region of memory as being non-executable. In one further embodiment, the definition of the section of the second region of memory as being executable comprises overwriting a value of a first register with a first boundary of an address range of the operation function which is allowed to be executed and overwriting a value of a second register with a second boundary of the address range of the operation function which is allowed to be executed, wherein the definition of the section of the second region of memory as being non-executable is performed by the overwriting.

In one embodiment, the allowance of the execution comprises copying the called operation function to the first region of memory, wherein the setting the executed operation function as non-executable comprises deleting the executed operation function from the first region of memory.

Independently, a return-oriented programming (ROP) attack protection method is provided, the method comprising: providing a region of memory having stored therein a plurality of operation functions, the region of memory set as non-executable; responsive to a call to one of the plurality of operation functions and further responsive 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 as non-executable.

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

In one further embodiment, the allowing execution of the called operation function and the setting the executed operation function as non-executable is performed by a protection function, wherein the determining that the return address is valid comprises determining that the return address is not within an address range of the protection function, and wherein the determining that the return address is not valid comprises determining that the return address is within an address range of the protection function. In one yet further embodiment, the call to one of the plurality of operation functions comprises: a call to the protection function; and information regarding an address of the called operation function.

In one embodiment, the allowance of the execution comprises defining a section of the region of memory as being executable, and wherein the setting the executed operation function as non-executable comprises defining the section of the region of memory as being non-executable. In one further embodiment, the definition of the section of the region of memory as being executable comprises overwriting a value of a first register with a first boundary of an address range of the operation function which is allowed to be executed and overwriting a value of a second register with a second boundary of the address range of the operation function which is allowed to be executed, wherein the definition of the section of the region of memory as being non-executable is performed by the overwriting.

In another embodiment, the allowance of the execution comprises copying the called operation function to an executable region of memory, and wherein the setting the executed operation function as non-executable comprises deleting the executed operation function from the executable region of memory.

Independently, a return-oriented programming (ROP) attack protection apparatus is provided, the ROP attack protection apparatus comprising: a processor; a first region of memory having stored therein instructions which when read by the processor causes the processor to implement a protection function, the first region of memory set as executable; and a second region of memory having stored therein instructions which when read by the processor causes the processor to implement a plurality of operation functions, the second region of memory set as non-executable, wherein, responsive to a call and further responsive to at least one predetermined rule, the processor is arranged to implement the protection function to: allow execution of one of the operation functions; and set the executed operation function as non-executable after completion of the executed operation function.

In one embodiment, the plurality of operation functions comprises the called function and a caller function, the call to the called function received from the caller function, wherein the processor is further arranged to implement the protection function to: responsive to the call, set the caller function as non-executable; responsive to the received return, allow execution of the caller function. In another embodiment, responsive to the at least one predetermined rule, the processor is further arranged to implement the protection function to determine whether a return address of the call is valid, wherein the allowance of the execution of the called operation function is responsive to the return address of the call being determined to be valid, and wherein, responsive to the return address of the call being determined to not be valid, the processor is further arranged to implement the protection function to: not allow the execution of the called operation function; and output a notification regarding the non-valid return address. In one further embodiment, the determination that the return address is valid comprises a determination that the return address is not within an address range of the protection function, and wherein the determination that the return address is not valid comprises a determination that the return address is within an address range of the protection function.

In another embodiment, the call to one of the plurality of operation functions comprises: a call to the protection function; and information regarding an address of the called function. In one embodiment, the allowance of the execution comprises defining a section of the second region of memory as being executable, wherein the setting the executed operation function as non-executable comprises defining the section of the second region of memory as being non-executable. In one embodiment, the allowance of the execution comprises copying the called operation function to the first region of memory, wherein the setting the executed operation function as non-executable comprises deleting the executed operation function from the first region of memory.

Additional features and advantages of the invention will become apparent from the following drawings and description.

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

With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how several forms of the invention may be embodied in practice. In the accompanying drawings:.

<FIG> illustrates a high level schematic diagram of an ROP attack protection apparatus <NUM>. ROP attack protection apparatus <NUM> comprises: a processor <NUM>; a memory protection unit (MPU) <NUM>; and a memory <NUM>. As known to those skilled in the art, MPU <NUM> is a hardware component which allows for setting predefined memory regions as non-executable. Particularly, code written in a non-executable memory region cannot be executed. Although for the sake of simplicity processor <NUM> and MPU <NUM> are illustrated as separate units, this is not meant to be limiting in any way and in one particular embodiment MPU <NUM> is implemented within processor <NUM>. In one embodiment, processor <NUM> is a microprocessor. Memory <NUM> comprises: at least one non-executable region <NUM> set such that code stored therein cannot be executed by processor <NUM>; and at least one executable region <NUM> set such that code stored therein can be executed by processor <NUM>. In one embodiment, one or more dedicated registers record which memory regions are executable, while the remaining regions are non-executable, and the below is described in relation to such an embodiment. In another embodiment, the dedicated one or more registers record which memory regions are non-executable, while the remaining regions are executable. In another embodiment, one or more first dedicated registers record which memory regions are executable and one or more second dedicated registers record which memory regions are non-executable. MPU <NUM> sets memory regions to be non-executable responsive to the values of the dedicated registers. In one embodiment, memory <NUM> is a flash memory, i.e. a computer storage medium which can be electrically erased and reprogrammed.

As will be further described below, a protection function <NUM> is stored in executable region <NUM> and a plurality of operation functions <NUM> are stored in non-executable region <NUM>. The term operation function, as used herein, is meant as any function which performs any type of operation, without limitation. For the sake of clarity, an operation function <NUM> which is calling another operation function <NUM> is termed herein as a caller operation function <NUM>. Similarly, an operation function <NUM> being called is termed herein as a callee operation function <NUM>. Additionally, interrupt functions and initializing commands are stored in executable region <NUM>. In another embodiment, the interrupt functions and initializing commands are stored on a separate executable region <NUM>, different than where operation functions <NUM> are stored. Each of protection function <NUM>, operation functions <NUM>, interrupt functions and initializing commands comprises computer readable instructions, which when read by processor <NUM> are arranged to cause processor <NUM> to perform the respective operations.

As will be described further below, any call to an operation function <NUM> goes to protection function <NUM>. In one embodiment, after enablement of protection function <NUM> by an initiation code, in the event that the caller function is an operation function <NUM> stored in non-executable region <NUM>, protection function <NUM> sets caller operation function <NUM> as non-executable. Particularly, in one embodiment, protection function <NUM> adjusts the value of a particular register such that MPU <NUM> sets the section of non-executable region <NUM> containing caller operation function <NUM> as being non-executable.

Protection function <NUM> is arranged to detect anomalies in the calls to operation functions <NUM>, in accordance with at least one predetermined rule of a protection model. Responsive to a call to a callee operation function <NUM>, such as by a main function, and responsive to the at least one predetermined rule, protection function <NUM> analyzes the return address stored on the call stack to determine whether it is a valid return command. Particularly, in an embodiment where all functions are stored in non-executable region <NUM> of memory <NUM>, protection function <NUM> checks whether the return address is the same address as that of protection function <NUM>. In the event that an attacker causes a stack overflow attack to hijack a return address, it can't jump to any operation function <NUM> because they are all set as being non-executable and any attempt to jump to any operation function <NUM> will cause an exception. However, the return address can be hijacked in order to jump to protection function <NUM>. Therefore, if the return address is to protection function <NUM>, an attack is identified. In an embodiment where one or more operation functions <NUM> are arranged to return to protection function <NUM>, instead of another operation function <NUM>, protection function <NUM> will allow the return.

In an embodiment where not all functions are stored in non-executable region <NUM>, and therefore return addresses can be hijacked to jump to other functions, protection function <NUM> compares the return command to predetermined parameters to determine whether the call is within legitimate parameters, e.g. whether the callee operation function <NUM> is allowed to return data to that address. In one further embodiment, protection function <NUM> determines that the return is valid only if the return address is within the address range of caller operation function <NUM>. Thus, the at least one predetermined rule comprises the above described parameters which determine whether the return address is valid.

In the event that the call is determined as being valid, protection function <NUM> allows callee operation function <NUM> to be executed. Particularly, in one embodiment, protection function <NUM> adjusts the value of a particular register such that MPU <NUM> sets the section of non-executable region <NUM> containing callee operation function <NUM> as being executable. In the event that the call is determined as not being valid, protection function <NUM> does not allow callee operation function <NUM> to be executed and an exception is generated. In one embodiment, protection function <NUM> generates a notification indicating the invalid call and outputs the notification to a predetermined output.

In another embodiment, even if all functions are set as non-executable, protection function <NUM> checks whether the return address is to the caller operation function <NUM>. In the event that the return address is invalid, protection function <NUM> generates a notification with the details of invalid return.

The return of callee operation function <NUM>, i.e. the data returned by callee operation function <NUM>, is received by protection function <NUM>. Responsive to receiving the return message, protection function <NUM> sets callee operation function <NUM> as non-executable. Particularly, in one embodiment, protection function <NUM> adjusts the value of a particular register to thereby define the section of non-executable region <NUM> containing callee operation function <NUM> as being non-executable. Additionally, protection function <NUM> allows execution of caller operation function <NUM>. As described above, in one embodiment, protection function <NUM> adjusts the value of a particular register to thereby define the section of non-executable region <NUM> containing caller operation function <NUM> as being executable.

In summary, only a single operation function <NUM> is allowed to be executed at any given time. After generating a call, a caller operation function <NUM> is set as non-executable and the called operation function <NUM> is allowed to be executed only if the return address on the call stack is valid. After completing execution and returning the requested data, the called operation function <NUM> is set as non-executable and the caller operation function <NUM> is allowed to be executed again. Therefore, no ROP attacks can be implemented. Such a method of protection can be useful, among other applications, in protection of automobile data systems, such as those described in: <CIT>; and <CIT>.

In one non-limiting embodiment, where ROP attack protection apparatus <NUM> is implemented in a TriCore microcontroller, commercially available from Infineon Technologies AG of Neubiberg, Germany, each executable range of addresses is stored in a dedicated pair of registers, a first register storing the address of the upper boundary of the executable range and a second register storing the address of the lower boundary of the executable range. A first register pair is used for defining the address range of protection function <NUM> and a second register pair is used for defining the address range of the operation function <NUM> which is currently allowed to be executed, as described above. The value of a control register is set such that both register pairs are set as defining executable ranges. Allowing an operation function <NUM> to be executed comprises overwriting the values of the second register pair with the address boundaries of the operation function <NUM> to be executed. In one embodiment, returning an executed operation function <NUM> to being non-executable is automatic when the register pair values are overwritten with the address range of the allowable operation function <NUM>. Thus, in the above embodiment, executable ranges <NUM> are determined by the first and second register pairs. Initializing code and interrupt functions are defined as executable by the first register pair or by other register pairs. Any memory which is not defined by the register pairs as being executable are defined as non-executable region <NUM>.

In another non-limiting embodiment, where ROP attack protection apparatus <NUM> is implemented in an MPC5777 microcontroller, commercially available from NXP Semiconductors N. of Eindhoven, Netherlands, there are <NUM> sets of adjustable memory ranges, <NUM> dedicated for code, <NUM> dedicated for memory and <NUM> which can be either for code or for memory. There are <NUM> registers: a first register for selecting which range is being 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. A first range is configured to include protection function <NUM> and a second range is configured to include the address range of an operation function <NUM> allowed to be executed, as described above. In one embodiment, allowing execution of an operation function <NUM> comprises: 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 <NUM>; and overwriting the value in the fourth register with the lower boundary of the address ranged of the operation function <NUM>. As described above, in such an embodiment, setting an operation function <NUM> as being non-executable occurs automatically when the register values are overwritten.

<FIG> illustrates a high level flow chart of a method of adding a predefined protection module, such as protection function <NUM>, to a binary program image when the source code is not available. The below is described in relation to an executable and linkable format (ELF) file. In stage <NUM>, the file is analyzed by a patching script to find available space which the protection functionality can fit into. In stage <NUM>, in the event that there is sufficient space within the existing segments, a portion of the PROGBITS, i.e. a portion of the program content, of the predefined protection module are copied into the binary program image within the space of stage <NUM> by the patching script. In one embodiment, only the PROGBITS sections necessary to run the predefined protection module are copied in order to save space. While copying the PROGBITS of the predefined protection module into the binary program image, preferably the relative distance between different sections within the protection functionality is maintained. Particularly, sections of the ELF file which contain various types of data and are loaded on runtime need to be mapped to addresses in the CPU memory. The mapping is performed by segments, as known to those skilled in the art at the time of the invention. Each segment contains a sequence of consecutive PROGBITS sections which are loaded together to the address specified by the segment. Thus, the added segments for the protection functionality will load the added PROGBITS sections to the process address space on runtime.

In stage <NUM>, in the event that there isn't sufficient space within the existing segments, two new segments are added to the ELF file by the patching script. The first segment is for read-only executable text and the second segment is for read-write access. Sections of the protection functionality are then added to the added segments. Specifically, the read-write access PROGBITS sections comprise data and the global offset table (GOT).

All of the segments of the ELF file are listed in a program header table. After adding the two new segments of stage <NUM>, the program header table no longer fits in its original offset. Therefore, in stage <NUM>, the program header table is moved by the patching script to the end of the ELF file. In stage <NUM>, a third segment is added to the program header table by the patching script, the third segment arranged to load the program header table from its new location to the process address space on runtime to allow the process to be loaded and executed. Code is position independent, therefore relocation within the address space does not require any modifications as long as the relative distance between different sections is maintained. However, sometimes there are global offsets in the code. These offsets are stored in the GOT and in stage <NUM> are modified by the patching script to reflect the relocation of the addresses. Thus, a new ELF file is generated, containing the original program and the predefined protection module.

<FIG> illustrates a high level flow chart of a method of patching a binary image, such as the generated ELF file of stages <NUM> - <NUM>, so that functions branch to a predefined protection module, such as protection function <NUM> described above. In stage <NUM>, a patching script replaces call opcodes in the binary image with a call to the predefined protection module. For example, in an ARM instruction set, 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 cases where there is a complex instruction set, where the return opcodes can have different sizes, e.g. <NUM> or <NUM> bits, the return opcode is replaced with an invocation of 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 which is being called. In one embodiment, all the call opcodes in the binary image are replaced. In another embodiment, a predetermined list of call opcodes are replaced.

In stage <NUM>, a training script scans the binary program image to determine, for each call, the start and end addresses of each caller and callee function, the addresses stored in the protection library. In stage <NUM>, the data section of the predefined protection module of stage <NUM> is updated with address data and predetermined validation parameters.

<FIG> illustrates a high level flow chart of an ROP attack protection method, in accordance with certain embodiments. In stage <NUM>, a region of memory having stored thereon a plurality of operation functions is provided, the region of memory set as non-executable. In optional stage <NUM>, in one embodiment a caller function is one of the plurality of operation functions. In such an embodiment, responsive to a call to one of the plurality of operation functions of stage <NUM> by the caller function, the caller function is set as non-executable. In optional stage <NUM>, responsive to the call of optional stage <NUM> and further responsive to the at least one predetermined rule of stage <NUM> described below, a determination is performed to determine whether a return address of the call of optional stage <NUM> is valid.

In stage <NUM>, responsive to a call to one of the plurality of operation functions of stage <NUM>, optionally the call of optional stages <NUM> and <NUM>, and further responsive to at least one predetermined rule, execution of the called operation function is allowed. In one embodiment, the allowance of execution of the called operation of stage <NUM>, is responsive to the return address of the call being determined as valid. In one embodiment, the allowance of execution is performed by a protection function. Particularly, in one embodiment, each call to an operation function comprises a call to the protection function and information regarding an address of the called operation function. In one embodiment, the determining that the return address is valid comprises determining that the return address is not within an address range of the protection function of stage <NUM>. In another embodiment, the allowance of execution comprises defining a section of the region of memory of stage <NUM> as being executable, the section comprising the address range of the allowed operation function. In one further embodiment, defining the section as being executable comprises overwriting a value of a first register with a first boundary of an address range of the operation function which is allowed to be executed and overwriting a value of a second register with a second boundary of the address range of the operation function which is allowed to be executed.

In stage <NUM>, after receiving a return from the executed operation function of stage <NUM>, the executed operation is set as non-executable. In one embodiment, setting the executed operation function as non-executable is performed by a protection function. In another embodiment, setting the executed operation as non-executable comprises defining the section of stage <NUM> as being non-executable, the section comprising the address range of the executed operation function. In one further embodiment, defining the section as being non-executable is performed automatically by the overwriting of stage <NUM>. In optional stage <NUM>, responsive to the received return of stage <NUM>, execution of the caller function of stage <NUM> is allowed.

In optional stage <NUM>, responsive to the return address of the call of stage <NUM> being determined as not valid, the execution of the called operation of stage <NUM> is not allowed and a notification regarding the non-valid return address is output. In one embodiment, the determining that the return address is not valid comprises determining that the return address is within an address range of the protection function of stage <NUM>.

<FIG> illustrates a high level schematic diagram of an ROP attack protection apparatus <NUM>, in accordance with certain embodiments. ROP attack protection apparatus <NUM> is used instead of ROP attack protection apparatus <NUM> when access to the MPU is not allowed during runtime, such as in safety related vehicle system components. ROP attack protection apparatus <NUM> comprises: a processor <NUM>; an MPU <NUM>; a memory <NUM>; and a memory <NUM>. Memory <NUM>, or a predetermined region thereof, is set by MPU <NUM> as non-executable, as described above. Memory <NUM>, or a predetermined region thereof, is executable. In one embodiment, memory <NUM> is a flash memory. In another embodiment, memory <NUM> is aRAM. In one embodiment, memory <NUM>, or the executable region thereof, has stored therein a protection function <NUM>. As described above, interrupt functions and initializing commands are stored in executable memory <NUM>. Memory <NUM>, or the non-executable region thereof, has stored therein a plurality of operation functions <NUM>. In another embodiment, memory <NUM> exhibits an executable region and a non-executable region. In such an embodiment, the executable region has stored therein protection function <NUM> and the non-executable region has stored therein the plurality of operation functions <NUM>. Each of protection function <NUM>, operation functions <NUM>, interrupt functions and initializing commands comprises computer readable instructions, which when read by processor <NUM> are arranged to cause processor <NUM> to perform the respective operations.

The operation of protection function <NUM> is in all respects similar to the operation of protection function <NUM>, with the exception that allowing execution of an operation function <NUM> comprises copying the operation function <NUM> to memory <NUM> and setting the operation function <NUM> as non-executable comprises deleting the operation function <NUM> from memory <NUM>. Particularly, an operation function <NUM>, such as a main function, is initiated on memory <NUM> and calls a callee operation function <NUM>. Responsive to the return address of the call being determined as valid, protection function <NUM> deletes caller operation function <NUM> from memory <NUM> and copies callee operation function <NUM> to memory <NUM> where it can be executed. Upon receiving the return message from callee operation function <NUM>, protection function <NUM> deletes callee operation function <NUM> from memory <NUM> and copies caller operation function <NUM> back to memory <NUM>. Protection function <NUM> additionally transmits the return message to the return address in caller operation function <NUM>.

In order to avoid security risks due to having a memory region which is both writable and executable, preferably protection function <NUM> is defined as the only process which can write to memory <NUM>. For example, in the MPC574XG, commercially available from NXP Semiconductors N. of Eindhoven, Netherlands, such a definition can be accomplished with the following code:.

Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination. In particular, the invention has been described with an identification of each powered device by a class, however this is not meant to be limiting in any way. In an alternative embodiment, all powered device are treated equally, and thus the identification of class with its associated power requirements is not required.

Unless otherwise defined, all technical and scientific terms used herein have the same meanings as are commonly understood by one of ordinary skill in the art to which this 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.

In case of conflict, the patent specification, including definitions, will prevail. In addition, the materials, methods, and examples are illustrative only and not intended to be limiting.

Claim 1:
A return-oriented programming (ROP) attack protection apparatus (<NUM>, <NUM>) comprising:
a first region of memory (<NUM>, <NUM>) having stored therein a protection function (<NUM>, <NUM>), said first region of memory set as executable; and
a second region of memory (<NUM>, <NUM>) having stored therein a plurality of operation functions (<NUM>, <NUM>), said second region of memory set as non-executable,
wherein said protection function is arranged to:
responsive to a call to one of said plurality of operation functions and further responsive to at least one predetermined rule, allow (<NUM>) execution of said called operation function; and
after receiving a return from said executed operation function, set (<NUM>) said executed operation function as non-executable,
wherein responsive to said at least one predetermined rule, said protection function is further arranged to determine (<NUM>) whether a return address of said call is valid,
wherein said allowance of said execution of said called operation function is responsive to said return address of said call being determined to be valid, and
wherein, responsive to said return address of said call being determined to not be valid, said protection function is further arranged to (<NUM>):
not allow said execution of said called operation function; and
output a notification regarding the non-valid return address,
wherein said plurality of operation functions comprises said called function and a caller function, said call to said called function received from said caller function, and
wherein said protection function is further arranged to (<NUM>):
responsive to said call, set said caller function as non-executable; and
responsive to said received return, allow execution of said caller function.