Device and method for implementing control flow integrity

Abstract

Apparatus and methods related to control flow integrity enforcement. A computer device (110) includes a memory (116). The computer device also includes at least one processor (114) configured to execute a process and manage memory for the process. The processor is further configured to: execute one or more program instructions associated with an application; arrive at a control flow transfer for the one or more program instructions; in response to failure to satisfy a target control flow, expand a call stack associated with the one or more program instructions; identify an offending function call; and rewrite the offending function call. The rewritten function call includes a memory operation bounds check.

Description

Technical Field

[0001] The present disclosure relates to control flow integrity as it relates to software. Background Art

[0002] Most vulnerabilities are exploited by attackers to alter the normal control flow of an application in order to perform arbitrary malicious activities using the privileges of the exploited application. Control flow integrity (CFI) is a security mechanism that makes it significantly more difficult to perform such attacks by disallowing changes to the original control flow graph of compiled binary code. Summary of the Invention

[0003] According to one embodiment, a computer device includes a memory, the computer device also including at least one processor configured to execute a process and manage memory for the process. The processor is further configured to: execute one or more program instructions associated with an application; reach a control flow transfer for the one or more program instructions; in response to failure to satisfy a target control flow; unwind a call stack associated with the one or more program instructions; identify an offending function call; and rewrite the offending function call. The rewritten function call includes a memory operation boundary check.

[0004] According to a second embodiment, a method for managing memory for a process executing on a processor includes: executing one or more program instructions associated with an application; reaching a control flow transfer for the one or more program instructions; in response to a failure to satisfy a target control flow, expanding a call stack associated with the one or more program instructions; identifying an offending function call; and rewriting the offending function call, wherein the rewritten function call includes a memory operation boundary check.

[0005] According to a third embodiment, a computer device in a vehicle includes a memory and at least one processor configured to execute a process and manage memory for the process. The processor is configured to execute one or more program instructions associated with an application. The processor is further configured to: arrive at a control flow transfer for the one or more program instructions; in response to failure to satisfy a target control flow, expand a call stack associated with the one or more program instructions; identify an offending function call and a data size limit of a register in memory associated with the offending function call; and rewrite the offending function call, the rewritten function call including a memory operation bounds check. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Figure 1 is a diagram of an example computer system for detecting errors in a portion of memory allocated to a process according to an implementation of the present disclosure;

[0007] Figure 2 is a schematic block diagram of an example computer device according to an implementation of the present disclosure; and

[0008] Figure 3 is a flow chart 300 of an example method of control flow integrity (CFI) enforcement according to implementations of the present disclosure. DETAILED DESCRIPTION

[0009] Embodiments of the present disclosure are described herein. However, it should be understood that the disclosed embodiments are merely examples, and other embodiments may take various different and alternative forms. The drawings are not necessarily drawn to scale; some features may be enlarged or reduced to show details of particular components. Therefore, the specific structural and functional details disclosed herein should not be interpreted as limiting, but merely as a representative basis for teaching those skilled in the art to adopt the embodiments in various ways. As will be understood by those of ordinary skill in the art, the various features illustrated and described with reference to any one of the figures may be combined with features illustrated in one or more other figures to produce embodiments that are not explicitly illustrated or described. The combination of features illustrated provides representative embodiments for typical applications. However, various combinations and modifications of features consistent with the teachings of the present disclosure may be required for specific applications or implementations.

[0010] For example, memory corruption can occur in computing systems that utilize software written in low-level languages ​​such as C or C++. This is because such languages ​​are not compiled with data validation checks for reads or writes to memory by default. For example, compiled C code may not include validation to prevent data from being written outside the area of ​​memory allocated for data buffers. Such out-of-bounds accesses can be referred to as buffer overflows or buffer overruns.

[0011] When a process executes compiled code, a stack of data is allocated to the process as a block of memory. When a function is called by the code being executed, a new frame is pushed onto the stack. The new frame includes the parameters passed to the function, the local data variables used for the function, and the return address where execution will continue once the function completes. When the function completes, the frame is popped off the stack, and the return address is placed in the program counter to resume program flow. The return address is usually the instruction of the compiled code immediately following the location where the function was called.

[0012] A stack buffer overflow is a specific type of buffer overflow that can be used to alter program flow. For example, an attacker can engineer a buffer overflow of a local variable on the stack, causing the return address to be overwritten, leading to a jump to malicious code. This is an example of how an attacker can exploit gaps in data validation inherent in certain programming languages ​​to hijack the control flow of a program executing on a computing system.

[0013] Control flow integrity (CFI) technology can be used to detect certain types of memory corruption, but its response capabilities are still limited. CFI first works by tracing all possible execution paths in the code or program to build a control flow graph (CFG) and then enforcing program flow compliance with the control flow graph at runtime. CFI enforcement checks can be implemented in the code in a safe form that prevents the control flow of the code from deviating from the control flow graph, making it significantly more difficult to execute attacks that change the control flow and use the privileges generated by the exploited application to perform any malicious activities (e.g., malware, viruses, Trojans, spyware, etc.). Therefore, CFI technology can monitor and preserve control transfers and / or program flow within a computer environment. CFI technology can use reference monitors (e.g., embedded or external) and function transformations of the code that are passed through the reference monitor and compared with the ground truth CFI graph to determine abnormal or deviant behavior. CFI technology can identify faults caused by innocent or natural causes, including environmental radiation (e.g., electric and magnetic fields, etc.), random noise, signal errors, or component failures. More importantly, CFI technology can detect faults caused by intentional behavior, such as user-supplied manipulation of malicious program input. Typical CFI violation handling results in execution being halted and the program being re-executed in a fresh state. However, such handling mechanisms cannot eliminate adversarial access to the vulnerability and can reduce system availability by allowing continued exploitation.

[0014] In the improved CFI technology, the program can still be configured with the initial CFI implementation instructions. However, when a CFI violation is detected, instead of stopping or restarting execution, the program call stack can instead be expanded from the point of failure to identify the offending function that caused the violation. The offending function can then be modified (i.e., rewritten) to include instructions that perform a bounds check on the target buffer that overflowed in the offending function. By rewriting the offending function, the previous program call stack state can be used to resume execution from the point before the offending function was called. Significantly, since the rewritten function now includes a bounds check, the malformed data that caused the initial violation will be prevented from causing another violation. Therefore, memory corruption is prevented in the recovered execution, and the attacker cannot complete the overflow vulnerability. Therefore, instead of simply stopping execution and abruptly stopping the execution of the application, the application can be modified and restored to recover from the attack while also preventing future errors or problems at that point in the application.

[0015] Now refer to Figure 1 , the example computer system 100 includes a computer device 110. The computer device 110 may be, for example, any mobile or stationary computer device, including but not limited to a desktop or laptop computer or tablet computer, a cellular phone, a gaming device, a mixed reality device or virtual reality device, a music device, a television, a navigation system, a camera, a personal digital assistant (PDA), a handheld device, an electronic control unit, any other computer device having wired and / or wireless connection capabilities to one or more other devices, or any other type of computerized device capable of generating a video output signal.

[0016] Computer device 110 may include a central processing unit (CPU) 114 that executes instructions stored in memory 116. For example, CPU 114 may execute an operating system 140 and one or more applications 130. Operating system 140 and applications 130 may each be associated with one or more processes that may be assigned a process identifier and allocated a portion of memory 116.

[0017] Memory 116 may be configured to store data and / or computer-executable instructions. The computer-executable instructions may define and / or be associated with an operating system 140 and / or applications 130. CPU 114 may execute operating system 140 and / or applications 130. Memory 116 may represent one or more hardware memory devices accessible to computer device 110. Examples of memory 116 may include, but are not limited to, types of memory that may be used by a computer, such as random access memory (RAM), read-only memory (ROM), magnetic tape, magnetic disk, optical disk, volatile memory, non-volatile memory, and any combination thereof. Memory 116 may store local versions of applications being executed by CPU 114. In the example shown, memory 116 includes RAM 120, page cache 122, hard drive 124, and network interface 126. RAM 120 may be a hardware component such as one or more dual in-line memory modules (DIMMs). Page cache 122 may be a portion of RAM 120 that stores pages from a secondary storage device, such as hard drive 124. Hard drive 124 may represent any secondary storage device. Hard drive 124 may have a larger capacity but slower access time than RAM 120. Network interface 126 may also function as a secondary storage device, such as a network drive.

[0018] CPU 114 may include one or more processors for executing instructions. Examples of CPU 114 may include, but are not limited to, any processors specifically programmed as described herein, including controllers, microcontrollers, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), graphics processing units (GPUs), systems on chip (SoCs), or other programmable logic machines or state machines. CPU 114 may include other processing components, such as an arithmetic logic unit (ALU), registers, and a control unit. CPU 114 may include multiple cores and may be capable of using multiple cores to execute multiple threads to process different instruction groups and / or data groups simultaneously.

[0019] Operating system 140 may include instructions (e.g., applications 130) stored in memory 116 and executable by CPU 114. Operating system 140 may include a memory manager 142 for allocating memory to processes. For example, memory manager 142 may implement a virtual memory system. Memory 116 may include a limited amount of RAM 120. Processes executed by CPU 114 may request more memory than is available in RAM 120. However, much of the requested memory may remain unused for a significant amount of time. Memory manager 142 may use virtual memory to satisfy requests for memory by allocating virtual memory addresses 146 to processes. Virtual memory addresses 146 may then be associated with physical memory addresses in RAM 120 or pages, respectively, which may be stored in other logical and physical components, such as compressed memory 164 or hard drive 124. In implementations, virtual memory may include a page table 144 that stores the location of memory contents (e.g., pointers) for each virtual memory address 146. In implementations, page table 144 may also store metadata 148 for detecting and correcting memory errors or corruption. For example, a set of metadata 148 may be associated with each virtual memory address 146 in page table 144 .

[0020] A notification application programming interface (API) 154 or other type of software can allow a process to communicate with memory manager 142 to configure certain features of memory management for the process. In implementations, memory manager 142 can provide notifications about corrupted memory to a process or function. For example, memory manager 142 can generate a notification when corrupted memory is detected. For example, memory manager 142 can throw an exception indicating that corrupted memory has been detected or that a CFI violation has occurred. The process can indicate whether the process is handling the exception. If memory manager 142 does not receive an indication that the process is handling the exception, memory manager 142 can determine how to handle the exception (e.g., attempt recovery, terminate the process, crash the system, etc.). As another example of a notification, memory manager 142 can generate a notification when corrupted data is corrected. Similar to detecting corrupted memory, some processes may handle corrected memory in a specific manner. For example, a process may be able to regenerate data rather than trust that memory manager 142 has successfully corrected the corrupted memory. In other cases, a process may choose not to receive a notification when corrupted memory is corrected.

[0021] Error detector 158 may be software or hardware for evaluating whether a function call has become corrupted. For example, error detector 158 may identify a buffer error by checking whether a buffer access exceeds the buffer capacity in memory 116. When an error is detected, error detector 158 may provide an indication to notification API 154. Error detector 158 may be configured to evaluate a function call when a process requests a function call. Thus, error detector 158 can ensure that the process is receiving validated data. Additionally or alternatively, error detector 158 may periodically evaluate function calls to determine whether a function call has become corrupted. For example, error detector 158 may use an idle process to check for errors, or may select functions that have been in memory for a relatively long period of time. For example, for an application running in the background, error detector 158 may identify the application by its type and determine the application's uptime (e.g., a run time threshold). If the uptime exceeds the run time, error detector 158 may determine that an error may exist in the application. For example, if an application is expected to run for only one minute, and the application has been running for more than one minute, error detector 158 may determine that the function has become corrupted. In other examples, a watchdog may be utilized to determine if an application does not receive an expected response or "heartbeat" when being monitored.

[0022] When a corrupted function call is detected by the error detector 158, the error corrector 159 may attempt to correct the corrupted function call. The error corrector 159 may deterministically modify the code of the function call. For example, the error corrector 159 may sequentially modify the code to test for errors. For example, the error corrector 159 may analyze each line of code (or a group of lines of code) to modify and accordingly test each modified line of code for errors. The error corrector 159 may then use the error detector 158 to evaluate whether the modified function call matches the original function call.

[0023] Now refer to Figure 2 , shows an example computer device 110 according to an implementation, including Figure 1 In one example, computer device 110 may include a processor 48 for performing processing functions associated with one or more components and functions described herein. Processor 48 may include a single or multiple processors or a multi-core processor. Furthermore, processor 48 may be implemented as an integrated processing system and / or a distributed processing system. In one implementation, for example, processor 48 may include CPU 114.

[0024] In an example, the computer device 110 may include a memory 50 for storing instructions that may be executed by the processor 48 for performing the functions described herein. In an implementation, for example, the memory 50 may include a memory 116. The CPU 114 may also include dedicated instructions for performing the functions described (e.g., by calling these dedicated instructions to check function calls to check the validity / correctness of control flow transfers). These checks may also be performed by reference monitors included as part of the error detector 158 and instruments compiled into the operating system 140 or the application 130.

[0025] In addition, the computer device 110 may include a communication component 52 that provides for establishing and maintaining communications with one or more parties using hardware, software, and services as described herein. The communication component 52 may perform communications between components on the computer device 110, as well as communications between the computer device 110 and external devices (e.g., devices located across a communication network and / or devices serially or locally connected to the computer device 110). For example, the communication component 52 may include one or more buses and may also include a transmit chain component and a receive chain component associated with a transmitter and a receiver, respectively, that are operable to interact with the external devices.

[0026] In addition, computer device 110 may include data storage device 54, which may be any suitable combination of hardware and / or software that provides mass storage of information, databases, and programs employed in connection with the implementations described herein. For example, data storage device 54 may be a data repository for operating system 140 and / or applications 130. The data storage device may include memory 116.

[0027] The computer device 110 may also include a user interface component 56 that is operable to receive input from a user of the computer device 110 and to generate output for presentation to the user. The user interface component 56 may include one or more input devices, including but not limited to tactile input, a keyboard, a numeric keypad, a mouse, a touch-sensitive display, a digitizer, navigation keys, function keys, a microphone, a voice recognition component, any other mechanism capable of receiving input from a user, or any combination thereof. Additionally, the user interface component 56 may include one or more output devices, including but not limited to a display, a speaker, a tactile feedback mechanism, a printer, any other mechanism capable of presenting output to the user, or any combination thereof.

[0028] In an implementation, the user interface component 56 may send and / or receive messages corresponding to the operation of the operating system 140 and / or the applications 130. Furthermore, the processor 48 may execute the operating system 140 and / or the applications 130, and the memory 50 or the data storage device 54 may store the operating system 140 and / or the applications 130.

[0029] Computer device 110 may be located within a vehicle. For example, computer device 110 may be part of a vehicle computer system that includes a navigation system, an audio head unit, a vehicle safety system, and other vehicle components. In such an example, computer device 110 may interact with other vehicle components using a vehicle communication network, such as a vehicle bus (e.g., a controller area network (CAN) bus, etc.).

[0030] Figure 3 FIG3 is a flow chart 300 of an example method for CFI implementation according to an implementation of the present embodiment. In an example, the example method may be performed by computer device 110 loading application 130 or other computer code instructions into memory 116 for execution by CPU 114.

[0031] At operation 301, the computer device 110 executes program instructions. The program instructions can be any type of compiled code targeted for execution by the CPU 114 of the computer device 110. In an illustrative example, the program instructions include instructions compiled by a low-level language (e.g., C or C++) that lacks data validation checks for reading and writing to memory. The computer device 110 can execute any given program when the computer device 110 is started or when a new application is loaded. The computer device 110 can automatically execute the code based on the code or instruction. In another example, the code can be executed based on the user manually running the code. Such examples include double-clicking the program, typing an instruction to execute the code, touching an application icon on a touch interface, activating an icon based on any input device, activating a vehicle function, etc. Other input interfaces can also be used to execute the program.

[0032] At operation 303, the program flow of the code being executed reaches a control flow transfer. A control flow transfer can be a machine code instruction of a program instruction that transfers control of a program from one code location to another code location. Examples of such instructions include: a call instruction that transfers program flow to a subroutine location (and also saves the instruction address after the call on the stack for later use by a return instruction); a return instruction that allows execution to resume back to a storage location on the stack when the execution of the subroutine is completed; a conditional jump instruction that optionally transfers control to another instruction location based on satisfying one or more test conditions; and an unconditional jump instruction that unconditionally transfers control to a target location regardless of the conditions.

[0033] At operation 305, the system determines whether the destination instruction of the control flow transfer is a valid target code instruction. If the control flow transfer is attempting (or causing) a transfer of program flow consistent with the expectations of the program, the target code instruction can be considered valid. The fault can be caused by innocent or natural causes, including environmental radiation, random noise, signal errors, or by human factors. Alternatively, the fault can be caused by intentional behavior - for example, by user-provided manipulation of malicious program input. In one embodiment, in order to identify whether the target is valid, the system can include hooks in various function calls that are subject to CFI implementation. The system can also store a CFG model that represents the normal program flow obtained based on the code or program instructions running on the computer device 110. The error detector 158 can use the hook to intercept the function call and perform a comparison of the program flow caused by executing the pending control flow transfer with the normal program flow of the CFG model. However, if the target is invalid, control is passed to operation 307. In one example, if the target is consistent with the CFG model, the target is considered valid and control returns to operation 301 to continue execution of the control flow transfer instruction. For example, during program execution, whenever a machine code instruction transfers control, it targets a valid destination determined by the CFG created in advance. If the program flow does not match the CFG model, the error detector 158 or system can determine whether a fault has occurred based on the arrival of the control flow transfer.

[0034] At operation 307, the system expands the program call stack. In an example, the system can pop up the current stack frame from the program call stack based on the following assumption: the program execution is at a consistent stable point before the current illegal function is called, and the stack is not damaged at this point during execution. The illegal function of the program call stack can be disassembled in machine code, and the memory operators / operands in the illegal function can be identified. As discussed in more detail below, the illegal function code can be rewritten to eliminate memory corruption vulnerabilities (that is, buffer overflows), rather than making the illegal function code remain unchanged and risking the risk of repeated fault conditions. For example, an application or program can be disassembled from machine language into assembly language. Error corrector 159 can be utilized to disassemble machine language into assembly language. Then, error corrector 159 can analyze the code line (for example, individually or in groups thereof) to determine the memory operations and data size limits for the code line.

[0035] At operation 309, the system analyzes the illegal function code to determine the data size limit. For example, the system (for example, error detector 158) can perform code analysis to identify memory access operations and operands to the instruction. The system (for example, error detector 158) can also perform code analysis to identify the instantiation of variables to the instruction, because instantiation can indicate the boundaries of the variables being defined. As a possibility, the data size limit can be extracted by static, dynamic or symbolic analysis of program instructions. In an example, the system can simulate the program execution of the function to identify the buffer that causes memory damage. In another example, the system can search for buffer initialization code in the program instruction, and the buffer initialization code includes data size limit as parameter value, register value or immediate value. In some embodiments, in order to perform code analysis, the system can disassemble the machine instruction code of the illegal function into an assembly representation or other representation that is more suitable for high-level analysis.

[0036] In another example, machine code disassembly can be performed on the offending function and the identified memory operators / operands within the offending function. The operands are traced to their instantiations to determine their data size limits. Bounds checking consists of machine instructions that implement size comparisons based on those determined data size limits. Space for boundary checking is created by moving existing instructions or otherwise relocating existing instructions to add these machine instructions inline with existing instructions. The reason for rewriting the code is to eliminate memory corruption vulnerabilities (i.e., buffer overflows) rather than leaving the code unchanged and risking repeated failure conditions. Therefore, overall system reliability and availability can be improved in a hostile operating environment. In one example, the code can be rewritten using an error corrector 159 to eliminate memory corruption.

[0037] At operation 311, the system enables write access to the memory storing the code instructions to be modified. In many implementations, the memory segment containing the executable code is marked as read-only by the memory manager 142 to allow the code to be read but prevent the code from being modified. This is generally advantageous because once the program instructions are loaded into the memory, the write access restriction prevents accidental or intentional tampering or modification of the program instructions. However, such restrictions on write access to the code instructions may hinder the implementation of runtime program improvements identified by the CFI implementation method. In one example, the assigned permissions model can implement write access restrictions and not allow modification of permissions during operation of the computing device. The system can also instruct the memory manager 142 to temporarily mark the memory storing the code with both read and write permissions, thereby allowing the code to be rewritten in the event that an offending function is identified.

[0038] At operation 313, the system rewrites the function to include memory operation bounds checking based on the data size limit. The rewritten function includes bounds checking to ensure that write operations to the function's data buffer are limited to the size of the buffer. The system can track the failure to determine the size of the data buffer. The system can ensure that the data size limit is reduced for the rewritten function call by analyzing the data size limit of the memory associated with the rewritten function call. To assist in generating bounds-checking code instructions, the system (e.g., error corrector 159) can generate the rewritten code using a code template with data size limits and memory operand locations that can be inserted. The system can then inject the rewritten code into the existing machine code to prevent future CFI errors. For example, space for the new bounds-checking instructions can be created by moving or otherwise relocating existing code so that the new instructions can be added inline with the existing instructions. By rewriting the code, memory corruption vulnerabilities (i.e., buffer overflows) can be eliminated. This reduces the possibility of repeated failure conditions. As a result, overall system reliability and availability can be improved. Data size limits can be traced from the offending function call to initialization. For example, data size limits can be extracted through static, dynamic, or symbolic analysis of program instructions. The system (e.g., error detector 158) can identify offending function calls and disassemble program instructions or simulate program execution to identify buffers that cause memory corruption. The system can search for buffer initialization code in memory or program instructions that includes data size limits as parameter values, register values, or immediate values. The restored data size limits and memory operand locations are inserted into the code template to generate modified code. In another example, the system (e.g., error corrector 159) can test the modified code to verify the functional equivalence of the modified instructions compared to the original instructions. The system can apply various software tests (e.g., unit tests, regression tests, integration tests, formal verification tests, hardware-in-the-loop tests, coding rule tests, etc.) to the modified program, re-execute the modified program in a simulation environment with benign or malformed inputs, etc., to determine the presence of errors in the modified code. In response to any errors, the system can change the modification (e.g., using random mutation, genetic algorithms, etc.) and repeat the test until the passing criteria are met. The system can identify offending function calls and disassemble program instructions or simulate program execution to identify buffers that cause memory corruption. The system can search for buffer initialization code in memory or program instructions that includes data size restrictions as parameter values, register values, or immediate values. The restored data size restrictions and memory operand locations can be inserted into a code template to generate modified code. The system can rewrite function calls during runtime operation instead of stopping operation.

[0039] At operation 315, the system disables write permissions to the memory storing the code instructions. This restores the memory manager 142's blocking of write access to the code, thereby again preventing the code loaded into the memory from being written by accidental or malicious users. In this way, disabling write permissions can prevent the ability to modify the code by unauthorized users. When permissions are disabled, the ability to modify entries in the memory or storage device, including creating files, deleting files, renaming files, etc., is blocked.

[0040] At operation 317, the system restores the program call stack to a previous state. For example, the program stack, program counter, and other CPU registers, as well as other program states, can be reset to a state consistent with the execution of program instructions prior to executing the offending function. After operation 317, control is transferred to operation 301 to resume code execution. By rewriting the offending function, execution can be resumed from the point before calling the offending function using the previous program call stack state. Since the rewritten function now includes bounds checking, this will prevent a violation from causing another violation. Thus, memory corruption is prevented during the resumed execution. Therefore, the application can be modified and restored from the restored state, rather than simply stopping execution and abruptly halting the execution of the application, thereby recovering from the attack and preventing future errors or problems at that point in the application. In this way, the program can resume execution using the modified function, which is generated after rewriting the function call to include memory operation bounds checking based on data size restrictions. The program can then resume execution from the beginning, where bounds checking is enabled. Execution can occur in the restored state.

[0041] Although exemplary embodiments have been described above, it is not intended that these embodiments describe all possible forms encompassed by the claims. The terms used in the specification are descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of the present disclosure. As previously described, the features of the various embodiments may be combined to form additional embodiments of the present invention that may not be explicitly described or illustrated. Although various embodiments have been described as providing advantages or being preferred relative to other embodiments or prior art implementations in terms of one or more desired characteristics, those skilled in the art recognize that one or more features or characteristics may be compromised to achieve the desired overall system properties depending on the specific application and implementation. These properties may include, but are not limited to, cost, strength, durability, life cycle cost, marketability, appearance, packaging, size, applicability, weight, manufacturability, ease of assembly, etc. As such, to the extent that any embodiment is described as not being too desirable relative to other embodiments or prior art implementations in terms of one or more characteristics, these embodiments are not outside the scope of the present disclosure and may be desirable for specific applications.

Claims

1. A computer device comprising: Memory (50, 116); as well as At least one processor (48, 114) configured to execute a process and manage the memory for the process, wherein the at least one processor is configured to: executing one or more program instructions associated with the application; reaching a control flow transfer for the one or more program instructions; In response to a failure to satisfy the target control flow, unwinding a call stack associated with the one or more program instructions; Identify the offending function call; and The offending function call is rewritten, wherein the rewritten function call includes a memory operation bounds check configured to verify that write operations to a data buffer of the rewritten function are restricted to a size of the data buffer using at least a code template.

2. The computer device according to claim 1, wherein: The processor is further configured to, in response to the target control flow not being satisfied, enable write permission to the memory.

3. The computer device according to claim 2, wherein: The processor is further configured to, in response to a failure to satisfy the target control flow, disable write access to the memory.

4. The computer device according to claim 1, wherein: The process is configured to occur during operation at runtime.

5. The computer device according to claim 1, wherein: The processor is further configured to determine a data size limit for the offending function call.

6. The computer device according to claim 5, wherein: The memory operation boundary check is associated with the data size limit.

7. A method of managing memory for a process executing on a processor, comprising: executing one or more program instructions stored in the memory and associated with the application; reaching a control flow transfer for the one or more program instructions; In response to a failure to satisfy the target control flow, unwinding a call stack associated with the one or more program instructions; Identify illegal function calls; as well as The offending function call is rewritten, wherein the rewritten function call includes a memory operation bounds check configured to verify that write operations to a data buffer of the rewritten function are restricted to a size of the data buffer using at least a code template.

8. The method according to claim 7, wherein: The method further includes the step of restoring the program call stack to a previous state.

9. The method according to claim 7, wherein: The method further includes enabling write permission to the memory in response to failure to satisfy the target control flow.

10. The method according to claim 9, wherein: The method further includes disabling write access to the memory in response to failure to satisfy the target control flow.

11. The method according to claim 7, wherein: The method occurs during operation at run time.

12. The method according to claim 7, wherein: The processor is further configured to determine a data size limit for the offending function call.

13. The method according to claim 12, wherein: The memory operation boundary check is associated with the data size limit.

14. A computer device in a vehicle, comprising: Memory (50, 116); as well as At least one processor (48, 114) configured to execute a process and manage the memory for the process, wherein the at least one processor is configured to: executing one or more program instructions associated with the application; reaching a control flow transfer for the one or more program instructions; In response to a failure to satisfy the target control flow, unwinding a call stack associated with the one or more program instructions; identifying an offending function call and a data size limit of a register in memory associated with the offending function call; and The offending function call is rewritten, wherein the rewritten function call includes a memory operation bounds check configured to verify that write operations to a data buffer of the rewritten function are restricted to a size of the data buffer using at least a code template.

15. The computer device according to claim 14, wherein: The processor is configured to restore a program call stack to a previous state.

16. The computer device according to claim 14, wherein: The processor is further configured to, in response to the target control flow not being satisfied, enable write permission to the memory.

17. The computer device according to claim 16, wherein: The processor is further configured to, in response to a failure to satisfy the target control flow, disable write access to the memory.

18. The computer device according to claim 14, wherein: The process is configured to occur during operation at runtime.

19. The computer device according to claim 14, wherein: The processor is further configured to determine a data size limit for the offending function call.

20. The computer device according to claim 19, wherein: The memory operation boundary check is associated with the data size limit.

Images