Pointer authentication failure detection

Abstract

Memory faults are handled based on detecting whether a memory pointer was invalidated due to a pointer authentication (PA) failure. After an access to a memory pointer results in a memory fault, detecting whether the memory pointer was invalidated due to a PA failure includes creating a new memory pointer by replacing a reserved bit of the memory pointer with a default value, and determining that the new memory pointer corresponds to a memory address that falls within executable memory. The determination includes determining that the memory address is within an executable memory page, determining that a call instruction is stored at a previous memory address immediately preceding the memory address, and / or determining that the memory address corresponds to a code segment of an executable file. The PA failure is handled based on recording the PA failure, terminating an application, and / or resuming execution at an instruction stored at the memory address.

Description

Background Technology

[0001] Because of executable space protection techniques such as non-executable (NX) bits and Data Execution Protection (DEP), it is difficult for attackers to directly insert new malicious code into a program's memory space and execute it (e.g., by inserting new code onto the program's data stack using a buffer overflow). Therefore, many modern attacks are executed using Return-Oriented Programming (ROP). With ROP, an attacker manipulates the program's data stack (e.g., by exploiting vulnerabilities such as buffer overflows) to overwrite the return address with an attacker-chosen replacement return address, thereby redirecting the program's control flow. When a subroutine that depends on that return address exits, the replacement return address causes the execution of attacker-chosen executable code that already exists in executable memory. This attacker-chosen executable code is typically located within the program code itself or within a linked library. Libraries often contain subroutines and other functions that could potentially give an attacker greater access to the computer system.

[0002] Some processors, such as those designed by ARM Ltd. in Cambridge, England, include support for Pointer Authentication (PA), which can be used to mitigate ROP attacks on the program data stack. Specifically, PA technology adds at least one instruction to the processor's instruction set architecture (ISA) to create an authenticated pointer (e.g., instructions prefixed with "pac" in the ARM ISA). For example, on an ARM processor, the pac instruction cryptographically generates a Pointer Authentication Code (PAC) based on the pointer address (along with other data) and stores the PAC in a reserved space within the pointer (this, in turn, prevents the authenticated pointer from being used directly). PA technology also adds at least one instruction to the processor's ISA to authenticate a subject pointer (e.g., instructions prefixed with "aut" in the ARM ISA). For example, on an ARM processor, the aut instruction generates a new PAC from the subject pointer and compares the new PAC to the value in the reserved space within the pointer (if the pointer is authenticated, the existing PAC is stored). On ARM processors, if the new PAC matches an existing PAC, the `aut` instruction removes the existing PAC from the pointer (e.g., by restoring the reserved bits to their default values); otherwise, the `aut` instruction invalidates the pointer (e.g., by scrambling the reserved bits), causing dereferencing or calling the pointer with the invalid pointer to result in a memory-related fault (e.g., a memory translation fault). For example, if the pointer corresponds to the return address used by a subroutine's return instruction (e.g., the `ret` instruction in the ARM ISA), the execution of that return instruction would result in a memory translation fault if the pointer has been invalidated by the PAC. Summary of the Invention

[0003] However, the inventors have recognized that PA technology does not provide a deterministic mechanism for detecting whether a pointer is invalidated due to a PA failure or because the PA prevents a ROP attack on the program's data stack. In particular, a memory translation failure caused by PA appears to be any other pointer dereference problem, and therefore it does not carry information about the nature of the pointer corruption that caused the failure—that is, it appears as if the memory translation failure was caused by an invalid pointer. This invalid pointer could be the result of PA pointer invalidation that mitigates a ROP attack on the program's data stack; or it could be the result of a programming error that writes an invalid pointer value, or otherwise corrupts pointer values ​​on the program's data stack.

[0004] At least some of the embodiments described herein determine whether a memory pointer might have been invalidated due to a PA failure. For example, in one embodiment, a memory fault handler is configured to analyze the memory pointer that triggered the memory fault (e.g., a memory translation fault) to determine whether the pointer would correspond to a memory address falling within the executable memory location if the PA invalidation of the pointer were reversed. To achieve this, in one embodiment, the memory fault handler identifies the memory pointer that triggered the memory fault and then attempts to “repair” the memory pointer by setting reserved bits (which are used by the PA to store the PAC) to default values ​​for those reserved bits (e.g., all 1s, all 0s, etc., as defined by the processor ISA). The memory fault handler then determines whether the “repaired” memory pointer corresponds to a memory address falling within the executable memory location. In an embodiment, the determination is based on determining that the memory address is within an executable memory page (e.g., a memory page without a corresponding NX bit), determining that the calling instruction is stored at a previous memory address immediately preceding that memory address (i.e., it makes sense for the code to return to that location when exiting a subroutine), and / or determining that the memory address corresponds to a memory region mapped to a code segment (e.g., .text) of the executable file.

[0005] When a memory pointer is determined to be likely invalidated due to a PA failure (and therefore the memory fault is caused by a failed PAC authentication), at least some embodiments handle the memory fault in light of the PA failure that has already occurred. In embodiments, this handling includes logging the PA failure, terminating the program that caused the PA failure, and / or resuming program execution at the machine code instruction corresponding to the repaired memory pointer. Conversely, when a memory pointer is determined to be unlikely to be invalidated due to a PA failure (and therefore the memory fault is caused by an invalid pointer, possibly due to a programming error), at least some implementations handle the memory fault as is normal for a typical invalid pointer (e.g., by terminating a program with a segmentation fault).

[0006] By distinguishing between memory failures caused by failed PAC authentication and those caused by invalid pointers, embodiments of this paper provide the technical effects and improvements of generating valuable logging information that can be used to identify and repair PA incompatibilities in a program (thus resolving errors and failures in the program) or to detect ROP-type attacks (thus improving security). Furthermore, embodiments of this paper provide the technical effects and improvements of implementing rich memory failure handling modes. In embodiments, these memory failure handling modes include a “strict mode” that terminates the program when any PA failure occurs during program execution, while potentially logging the PA failure. In embodiments, these memory failure handling modes also include a “compatibility mode” that terminates the program in view of some PA failures and allows the program to continue execution in view of other PA failures, while potentially logging each PA failure. In embodiments, the compatibility mode terminates the program when the PA failure is caused by the program's code or by a “compatible” module loaded by the program, and allows the program to continue execution when the PA failure is caused by a “non-compatible” module loaded by the program or by dynamic code generated by the program. In embodiments, these memory failure handling modes also include an “audit mode” that logs each PA failure on a program-by-program basis without actually terminating the program.

[0007] In embodiments, methods, systems, and computer program products handle memory failures based on detecting whether a memory pointer is invalidated due to a PA failure. These embodiments identify memory pointers whose access during application execution results in a memory failure at the processor. These embodiments also detect that the memory pointer is invalidated due to a PA failure. This detection includes creating a new memory pointer by replacing a plurality of reserved bits with default values ​​and determining that the new memory pointer corresponds to a memory address falling within the executable memory location. This determination is based on at least one of the following: determining that the memory address is within an executable memory page, determining that a call instruction is stored at a previous memory address immediately preceding the memory address, or determining that the memory address corresponds to a memory region mapped to a code segment of the executable file. At least based on the detection that the memory pointer is invalidated due to a PA failure, these embodiments also handle PA failures by performing at least one of the following: logging the PA failure, terminating the application, or resuming execution at the machine code instruction stored at the memory address.

[0008] This summary is provided to present a simplified description of the selected concepts, which will be further described in the detailed embodiments below. This summary is not intended to identify key or essential features of the claimed subject matter, nor is it intended to serve as an aid in determining the scope of the claimed subject matter. Attached Figure Description

[0009] To describe in detail the ways in which the above-described advantages and features, as well as other advantages and features, of the invention can be obtained, the invention, which has been briefly described above, will be described in more detail with reference to specific embodiments of the invention shown in the accompanying drawings. It should be understood that these drawings depict only exemplary embodiments of the invention and should therefore not be considered as limiting its scope. The invention will be described and explained with additional specificity and detail using the drawings, in which:

[0010] Figure 1A An example computer architecture is shown that facilitates the detection of whether a memory pointer has been invalidated due to a PA failure;

[0011] Figure 1B An example memory fault handling procedure is shown;

[0012] Figure 2 An example of PAC calculation is shown;

[0013] Figure 3 An example of using the PA directive to wrap functionality is shown; and

[0014] Figure 4 A flowchart is shown for an example method of handling memory faults based on detecting whether a memory pointer has been invalidated due to a PA failure. Detailed Implementation

[0015] Figure 1A An example computer architecture 100 is shown that facilitates the detection of whether a memory pointer has been invalidated due to a PA failure (i.e., failure to make a PAC stored in an authenticated pointer effective). Computer architecture 100 includes a computer system 101 that includes or utilizes dedicated or general-purpose computer hardware, such as, for example, a processor 102 (or multiple processors), system memory 103, and persistent storage device 104, which are communicatively coupled using a bus 105 (or multiple buses).

[0016] Embodiments within the scope of this invention include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available medium accessible to general-purpose or special-purpose computer systems. Computer-readable media storing computer-executable instructions and / or data structures are computer storage media. Computer-readable media carrying computer-executable instructions and / or data structures are transmission media. Therefore, by way of example and not limitation, embodiments of the invention may include at least two distinct types of computer-readable media: computer storage media and transmission media.

[0017] Computer storage media are physical storage media (e.g., system memory 103 and / or persistent storage device 104) that store computer-executable instructions and / or data structures. Physical storage media include computer hardware such as RAM, ROM, EEPROM, solid-state drives (“SSDs”), flash memory, phase-change memory (“PCM”), optical disc storage devices, magnetic disk storage devices, or other magnetic storage devices, or any other hardware storage devices that can be used to store program code(s) in the form of computer-executable instructions or data structures that can be accessed and executed by general-purpose or special-purpose computer systems to achieve the functions disclosed in this invention.

[0018] Transmission media may include networks and / or data links, which may be used to carry program code in the form of computer-executable instructions or data structures, and may be accessed by general-purpose or special-purpose computer systems. A “network” is defined as one or more data links that enable the transmission of electronic data between computer systems and / or modules and / or other electronic devices. When information is transmitted or provided to a computer system via a network or another communication connection (hardwired, wireless, or a combination of hardwired and wireless), the computer system may consider that connection as a transmission medium. Combinations of the above should also be included within the scope of computer-readable media.

[0019] Furthermore, upon arrival at various computer system components, program code in the form of computer-executable instructions or data structures can be automatically transferred from the transmission medium to the computer storage medium (and vice versa). For example, computer-executable instructions or data structures received via a network or data link can be buffered in RAM within a network interface module and then ultimately transferred to the computer system RAM (e.g., system memory 103) and / or a less volatile computer storage medium (e.g., persistent storage device 104) at the computer system. Therefore, it should be understood that computer storage media can be included in computer system components that also (or even primarily) utilize the transmission medium. Computer-executable instructions include, for example, instructions and data that, when executed at one or more processors, cause a general-purpose computer system, a special-purpose computer system, or a special-purpose processing device to perform a specific function or group of functions. Computer-executable instructions can be, for example, machine code instructions (e.g., binary), intermediate format instructions (such as assembly language), or even source code.

[0020] Those skilled in the art will understand that this invention can be practiced in networked computing environments with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile phones, PDAs, tablet computers, pagers, routers, switches, etc. This invention can also be practiced in distributed system environments, where both local and remote computer systems, linked via a network (e.g., via a hardwired data link, a wireless data link, or a combination of hardwired and wireless data links), perform tasks. Therefore, in a distributed system environment, a computer system can include multiple constituent computer systems. In a distributed system environment, program modules can reside on both local and remote memory storage devices.

[0021] Those skilled in the art will also understand that the present invention can be practiced in a cloud computing environment. A cloud computing environment can be distributed, although this is not required. When distributed, a cloud computing environment can be internationally distributed within an organization and / or have components owned across multiple organizations. In this specification and the appended claims, “cloud computing” is defined as a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage devices, applications, and services). The definition of “cloud computing” is not limited to any of the many other advantages that can be obtained from such a model when properly deployed.

[0022] Cloud computing models can be composed of various characteristics, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, and measurable services. Cloud computing models can also take the form of various service models, such as, for example, Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”). Cloud computing models can also be deployed using different deployment models, such as private cloud, community cloud, public cloud, and hybrid cloud.

[0023] Some embodiments, such as cloud computing environments, may include a system comprising one or more hosts, each capable of running one or more virtual machines. During operation, the virtual machines emulate the operating computing system, supporting an operating system and possibly one or more other applications. In some embodiments, each host includes a hypervisor that uses physical resources abstracted from the view of the virtual machines to simulate virtual resources for the virtual machines. The hypervisor also provides appropriate isolation between virtual machines. Thus, from the perspective of any given virtual machine, the hypervisor provides the illusion that the virtual machine is engaging with physical resources, even if the virtual machine only engages with the appearance of physical resources (e.g., virtual resources). Examples of physical resources include processing power, memory, disk space, network bandwidth, media drives, etc.

[0024] like Figure 1A As shown, (among others) processor 102 includes processing unit 106 (or more processing units) that loads and executes machine code instructions (typically via one or more processor caches, not shown) from system memory 103. In some embodiments, processor 102 includes gate logic and / or microcode that provides pointer authentication support 107 (PA support 107) by processor 102. Specific functionality of PA support 107 may vary depending on design choices, but example functionality includes one or more instructions (e.g., instructions with the pac prefix in ARM ISA) for creating an authenticated pointer by inserting a PAC into a pointer, and one or more instructions (e.g., instructions with the aut prefix in ARM ISA) for authenticating the PAC stored in the pointer. However, it should be understood that embodiments herein can be implemented without PA support 107 in processor 102. For example, PA functionality can instead be implemented in software, such as through an operating system and / or as instructions in the preamble and end of a process compiled into the application binary.

[0025] As shown, persistent storage device 104 stores computer-executable instructions and / or data structures representing executable software components; correspondingly, during the execution of the software at processor 102, one or more portions of these computer-executable instructions and / or data structures are loaded into system memory 103. For example, persistent storage device 104 is shown storing computer-executable instructions and / or data structures corresponding to operating system 108 and executable files 111 (or multiple executable files). In embodiments, each executable file 111 corresponds to an application or a module or library that can be loaded by an application. Persistent storage device 104 may also store data such as logs 112. Operating system 108 is shown including a memory fault handler 109 and potentially includes a logger 110 (i.e., for logging data to logs 112, such as a kernel log).

[0026] System memory 103 is capable of storing a wide variety of data; however, for the purposes of illustrating embodiments herein, system memory 103 is shown to store at least memory data corresponding to application 113 executed from executable file 111 (as indicated). For example, the memory data of application 113 is shown to include a data stack 114 (sometimes referred to as a call stack). System memory 103 is also shown to potentially store at least memory data corresponding to module 115 executed from another executable file 111 (as indicated). As indicated, module 115 is utilized by application 113 when present, and in embodiments, this module is loaded into the memory space of application 113.

[0027] In an embodiment, the memory fault handling procedure 109 is executed based on the occurrence of a memory-related fault (such as a memory translation fault) that occurs in relation to the execution of instructions by the processing unit 106. Therefore, in an embodiment, the memory fault handling procedure 109 includes at least the function of handling memory faults based on detecting whether the memory pointer is invalidated due to a PA failure. To explain how the memory fault handling procedure 109 is able to detect whether the memory pointer is invalidated due to a PA failure, it is now combined with... Figure 2 And combined Figure 3 Briefly describe the operation PA. Figure 2 Example 200 of PAC calculation is shown. Figure 3 Example 300 shows a function wrapped with the PA instruction.

[0028] In many processor architectures, the processor defines a pointer as consisting of multiple reserved bits (e.g., the higher 16 bits in an ARM ISA) plus the actual memory address it points to. In embodiments, PA technology stores a signature (e.g., PAC) within these reserved bits to transform the pointer into an authenticated pointer. Therefore, refer to... Figure 2 Example 200 illustrates that, in an embodiment, the authenticated pointer 206 includes a PAC 205 stored in reserved bits of the authenticated pointer 206, and an address 201 including the address it points to. As shown, in an embodiment, the PAC 205 is computed using a function 204(P) that takes the address 201, modifier 202, and key 203 as input. In an embodiment, the ARM ISA uses one or more registers (e.g., SP, X16, Xn) and / or the value for modifier 202 (e.g., zero).

[0029] Now go to Figure 3 Example 300 illustrates a table including columns 301 and 302. Column 301 shows an example ARM-based subroutine structure lacking return address protection, and column 302 shows an example ARM-based subroutine structure using PAC-based return address protection. As shown in column 301, the subroutine structure includes a prologue (lines 2 and 3) that saves the return address stored in the link register (lr) to the stack (e.g., data stack 114) and advances the stack pointer to create a new stack frame. The subroutine structure also includes a body, indicated by an ellipsis at line 4, comprising one or more instructions. The subroutine structure also includes a closing statement (lines 5 and 6) that deletes the stack frame and loads the saved return address into the link register. The subroutine structure also includes a return statement to the address stored in the link register (line 8).

[0030] As shown in line 302, in this embodiment, PAC-based return address protection adds the `paciasp` instruction (line 1) to the preamble and the `autiasp` instruction (line 7) to the end. The `paciasp` instruction transforms the link register into an authenticated pointer 206 by calculating PAC 205 (using the stack pointer as modifier 202) and inserting PAC 205 into a reserved bit in the link register. Therefore, the return address stored at line 2 is an authenticated pointer 206 based on the actual return address. Then, after the stored return address has been loaded from the data stack (e.g., data stack 114) into the link register, the `autiasp` instruction authenticates the link register. As long as the return address stored at line 2 has not been modified by the subroutine body, the `autiasp` instruction calculates the value stored in the reserved bit in the link register and restores the reserved bit to its default value (e.g., all 1s or all 0s); therefore, the subsequent return instruction (line 8) succeeds. However, if the return address stored at line 2 is modified by the subroutine body (e.g., due to ROP), the autiasp instruction calculates a value different from the value stored in the reserved bit of the link register and scrambles the reserved bit; therefore, the subsequent return instruction (line 8) causes a memory fault.

[0031] When handling memory failures, whether the failure is caused by a general programming error—such as an instruction attempting to access an invalid pointer—or by a PA authentication instruction (e.g., autoasp), the failure appears the same to memory failure handler 109. This PA authentication instruction scrambles reserved bits in the pointer because it failed to verify the PAC of a previously valid pointer. According to embodiments herein, memory failure handler 109 determines whether a memory pointer might have been invalidated due to a PA failure by "repairing" the pointer by setting the reserved bits in the pointer to default values ​​(e.g., all 1s or all 0s as defined by the processor ISA), and then determining whether the "repaired" memory pointer corresponds to a memory address falling within the executable memory location. If so, the pointer that caused the memory failure was likely invalidated after the PA failure. Otherwise, the pointer that caused the memory failure may never have actually corresponded to a valid memory address.

[0032] Figure 1BDetails of a memory fault handling procedure 109 according to some embodiments are shown. This procedure 109 includes example components that facilitate memory fault handling based on detecting whether a memory pointer has been invalidated due to a PA failure. It should be understood that the depicted components—including their identifiers, subcomponents, and arrangements—are presented merely as aids in describing various embodiments of the memory fault handling procedure 109 as described herein, and these components are not limited to how the various embodiments described herein or their specific functions can be implemented in software and / or hardware.

[0033] Now combine Figure 4 To describe the components of memory fault handling procedure 109, Figure 4 A flowchart is shown for an example method 400 for handling memory faults based on detecting whether a memory pointer has been invalidated due to a PA failure. In an embodiment, instructions for implementing method 400 are encoded as computer-executable instructions stored on a hardware storage device (e.g., persistent storage device 104), executable by a processor (e.g., processor 102) to cause a computer system (e.g., computer system 101) to perform method 400. In an embodiment, these computer-executable instructions correspond to a memory fault handling procedure 109, such that method 400 is implemented by a memory fault handling procedure of the operating system kernel. The following discussion now relates to multiple methods and method actions. Although method actions may be discussed in a certain order, or may be illustrated in the flowchart as occurring in a specific order, no specific ordering is required unless specifically stated, or because a specific ordering is required because an action depends on another action completed before that action is performed.

[0034] refer to Figure 1B The memory fault handler 109 is shown to include a pointer identification component 116. In an embodiment, when the memory fault handler 109 is invoked by the processor 102 due to a memory fault, the pointer identification component 116 identifies which memory pointer caused the memory fault. In an embodiment, this pointer is provided to the memory fault handler 109 by the processor 102 as part of triggering the memory fault handler 109, or is otherwise accessible at the processor 102 (e.g., by reading a processor register). Reference Figure 4 Method 400 includes an action 401 of identifying a memory pointer that caused a memory failure. In some embodiments, action 401 includes identifying a memory pointer whose access caused a memory failure at the processor during execution of the application. While various types of memory failures may exist, in some embodiments, the memory failure identified in action 401 is a memory translation failure.

[0035] refer to Figure 3In one example of action 401, as shown in line 302, if during the execution of application 113, the `autiasp` instruction at line 7 invalidates a pointer in the link register due to a PA failure (e.g., by scrambling the pointer's reserved bits), then the `ret` instruction at line 8 attempts to dereference the invalid pointer, thus causing a memory fault at processor 102, which triggers memory fault handler 109; in this case, pointer identification component 116 will identify the invalid pointer. In another example of action 401, if during the execution of application 113, a load or store instruction in the subroutine body (ellipsis at line 4) attempts to access an invalid pointer (e.g., it is invalid due to an error), then the load or store instruction attempts to dereference the invalid pointer, thus causing a memory fault at processor 102, which triggers memory fault handler 109; in this case, pointer identification component 116 will identify the invalid pointer. In either case, there is no indication to memory fault handler 109 whether the memory fault was caused by a PA failure that invalidated the pointer.

[0036] return Figure 1B The memory fault handling procedure 109 is also shown to include a PA failure detection component 117. In an embodiment, the PA failure detection component 117 determines whether the memory pointer identified by the pointer identification component 116 may have been invalidated due to a PA failure by attempting to reverse the effects of the PA. (See reference...) Figure 4 Method 400 further includes action 402 to detect whether a memory pointer has been invalidated due to a PA failure. The technical effect of action 402 includes distinguishing between memory failures caused by a failed PAC authentication and memory failures caused by an invalid pointer. In one example, if during the execution of application 113, the memory failure handler 109 is triggered by a ret instruction attempting to dereference a pointer invalidated by an autoasp instruction, then the PA failure detection component 117 determines that the pointer has been invalidated due to a PA failure. In another example, if during the execution of application 113, the memory failure handler 109 is triggered by a load or store instruction attempting to dereference an invalid pointer, then the PA failure detection component 117 determines that the pointer has not been invalidated due to a PA failure.

[0037] In some embodiments, the PA failure detection component 117 operates only when the processor 102 is determined to include PA support 107 and / or when the application 113 executing in the event of a memory failure is compiled to support PA (e.g., by including PAC-based return address protection, as shown in column 302). Therefore, in some embodiments, method 400 detects whether a memory pointer is invalidated due to a PA failure only when the processor is determined to have PA capability. In additional or alternative embodiments, method 400 detects whether a memory pointer is invalidated due to a PA failure only when it is determined that the PA feature is enabled for the application.

[0038] As explained above, the embodiment determines whether a memory pointer might have been invalidated due to a PA failure by: "repairing" the pointer by setting its reserved bits to default values ​​(e.g., all 1s, all 0s, etc., as defined by the processor ISA), and then determining whether the "repaired" memory pointer corresponds to a memory address falling within the executable memory location. Therefore, returning to the reference... Figure 1B PA failure detection component 117 is shown as including pointer repair component 118 and memory location analysis component 119.

[0039] In one embodiment, the pointer repair component 118 attempts to reverse the PA invalidation of the memory pointer by setting the pointer's reserved bits to the ISA's default values ​​(e.g., all 1s, all 0s, etc.). Reference Figure 4 As shown in the figure, action 402 includes action 403 of repairing reserved bits of the memory pointer. In some embodiments, action 403 includes creating a new memory pointer by replacing the multiple reserved bits with default values ​​of the multiple reserved bits of the memory pointer. In the example, and referring to Figure 2 In the ARM ISA, pointer repair component 118 replaces the higher sixteen bits of the pointer with default values ​​for those reserved bits. If the pointer is invalidated due to a PAC authentication failure, the operation of pointer repair component 118 has the technical effect of restoring the pointer to its state before it was inserted into the PAC 205 (e.g., before the execution of the aut instruction). If the pointer is invalidated in other ways, it may remain invalid after the operation of pointer repair component 118 (e.g., not pointing to a valid memory address, not pointing to an executable memory page, etc.).

[0040] In an embodiment, the memory location analysis component 119 determines whether the "repaired" memory pointer generated by the pointer repair component 118 corresponds to a memory address falling within the executable memory location. (See reference...) Figure 4As shown in the figure, action 402 further includes action 404 of determining whether the repaired memory pointer corresponds to an executable memory location. Therefore, in some embodiments, action 404 includes determining that the new memory pointer corresponds to a memory address falling within the executable memory location. In the example, if the memory pointer used by the ret instruction is invalidated due to a PA failure, then "repairing" the memory pointer by setting the reserved bits in the pointer to default values ​​will produce a memory pointer corresponding to a memory address falling within the executable memory location. In this case, action 402 detects that the memory pointer is invalidated due to a PA failure, and method 400 proceeds to action 405.

[0041] In some other embodiments, action 404 includes determining that the new memory pointer does not correspond to a memory address falling within the executable memory location. In an example, if a memory pointer used by a load or store instruction is invalid due to an error, "fixing" the memory pointer by setting a reserved bit in the pointer to a default value may not produce a memory pointer corresponding to a memory address falling within the executable memory location. In this case, action 402 detects that the memory pointer was not invalidated due to a PA failure, and method 400 proceeds to action 406.

[0042] There are various ways in which the memory location analysis component 119 can determine whether the "repaired" memory pointer corresponds to a memory address that falls within the executable memory location, and the memory location analysis component 119 can use these methods individually or in combination.

[0043] In one embodiment, memory location analysis component 119 determines whether a memory address is within an executable memory page. For example, in a system implementing an NX bit and DEP, memory location analysis component 119 may determine (e.g., using a memory page table) whether the memory page pointed to by the repaired memory pointer has a corresponding NX bit, and determine that the memory address is within an executable memory page when the NX bit is set to indicate the state of the executable memory. Therefore, in this embodiment, determining in action 404 that a new memory pointer corresponds to a memory address falling within the executable memory location is at least based on determining that the memory address is within an executable memory page.

[0044] In another embodiment, memory location analysis component 119 determines whether the call instruction was stored at a previous memory address immediately preceding the memory address. For example, a return address typically falls immediately after the call instruction. Therefore, it makes sense that when exiting a subroutine, the code would return to the memory location after the call instruction. Thus, in this embodiment, determining in action 404 that the new memory pointer corresponds to a memory address falling within the executable memory location is based at least on determining that the call instruction was stored at a previous memory address immediately preceding the memory address.

[0045] In another embodiment, memory location analysis component 119 determines that a memory address corresponds to a memory region mapped to a code segment. For example, applications and libraries execute based on loading an executable file, such as a Portable Executable (PE) or an Executable and Linkable Format (ELF) file, and if an executable memory location is mapped to a code (e.g., a .text) segment of the executable file, then the memory address corresponds to that memory location. Therefore, in this embodiment, determining in action 404 that a new memory pointer corresponds to a memory address falling within the executable memory location is based at least on determining that the memory address corresponds to a memory region mapped to a code segment of an executable file (e.g., executable 111 corresponding to application 113, or module 115 loaded by application 113).

[0046] return Figure 1B The memory fault handling procedure 109 is also shown to include a PA failure handling procedure 120. In an embodiment, the PA failure handling procedure 120 handles memory faults in light of a PA failure that has occurred. Figure 4 When action 402 detects that the memory pointer has been invalidated due to a PA failure, method 400 may include action 405: handling the PA failure when the memory pointer has been invalidated due to a PA failure. In some embodiments, action 405 includes handling the PA failure at least based on the detection that the memory pointer has been invalidated due to a PA failure.

[0047] PA failure handling procedure 120 can take various actions to handle PA failure, and the PA failure handling procedure 120 can take these actions individually or in combination.

[0048] In one embodiment, PA failure handling procedure 120 records PA failures. For example, PA failure handling procedure 120 uses logger 110 to record PA failures to log 112. Therefore, in this embodiment, handling PA failures in action 405 includes at least recording the PA failure. In this embodiment, the technical effect of action 405 includes generating log information that can be used to identify and fix PA incompatibilities in the program (thereby resolving errors and malfunctions in the program) or to detect ROP-type attacks (thereby improving security).

[0049] In another embodiment, PA failure handling procedure 120 terminates the program that caused the PA failure. For example, PA failure handling procedure 120 causes application 113 to terminate. Therefore, in this embodiment, handling PA failure in action 405 includes at least terminating the application. In this embodiment, the technical effect of action 405 includes preventing the program from executing after a possible ROP attack, thereby maintaining system security by preventing malicious actors from executing code of their choice.

[0050] In another embodiment, the PA failure handler 120 resumes program execution at the machine code instruction corresponding to the repaired memory pointer. For example, the PA failure handler 120 enables the resumption of application 113 execution by executing the instruction stored at the memory address pointed to by the repaired memory pointer. Therefore, in this embodiment, handling a PA failure in action 405 includes at least resuming execution at the machine code instruction stored at the memory address. In this embodiment, the technical effect of action 405 includes avoiding interruption of application execution even in the event of a possible ROP attack.

[0051] In this embodiment, the PA failure handling procedure 120 supports various enforcement modes. In this embodiment, when a PA failure is detected by the PA failure detection component 117, each enforcement mode takes multiple different remedial measures.

[0052] In embodiments, the enforcement mode includes "strict mode" as the most restrictive mode, wherein when any PA failure occurs during program execution, PA failure handler 120 terminates the program (e.g., application 113). Therefore, based on the application executing in strict mode, in some embodiments of action 405, handling PA failure includes terminating the application.

[0053] In an embodiment, when operating in strict mode, PA failure handler 120 also logs PA failures in log 112 (e.g., using logger 110). Therefore, based on the application executing in strict mode, in some embodiments of action 405, handling PA failures includes logging PA failures.

[0054] In embodiments, the enforcement mode also includes a "compatibility mode" as a moderately restrictive mode, in which PA failure handler 120 terminates the program in view of some PA failures (e.g., application 113), but allows the program to continue execution in view of other PA failures. In embodiments, when operating in compatibility mode, PA failure handler 120 terminates the program when a PA failure is caused by the program's own code, or when a PA failure is caused by a module classified as PA-compatible and loaded by the program (e.g., module 115). Therefore, in some embodiments, action 404 includes determining a memory address corresponding to a memory region mapped to a code segment of the executable file. Then, when the executable file corresponds to an application, and based on the application executing in compatibility mode, in some embodiments of action 405, handling PA failure includes terminating the application when the executable file corresponds to that application. Alternatively, when the executable file corresponds to a PA-compatible module loaded by an application, and based on the application executing in compatibility mode, in some embodiments of action 405, handling PA failure includes terminating the application when the executable file corresponds to a PA-compatible module.

[0055] In embodiments, when operating in compatibility mode, if a PA failure is caused by a module (e.g., module 115) classified as incompatible with the PA (in some embodiments, this includes unknown compatibility with the PA) and loaded by the program, or if the PA failure is caused by dynamic code generated by the program, the PA failure handler 120 allows the program to continue execution. Therefore, in some embodiments, action 404 includes determining a memory address and a memory region mapped to a code segment of the executable file. Then, when the executable file corresponds to a PA-incompatible module loaded by the application, and based on the application executing in compatibility mode, in some embodiments of action 405, handling the PA failure includes: when the executable file is a binary file loaded by the application, resuming execution at the machine code instructions stored at the memory address. In other embodiments, based on the application executing in compatibility mode, in some embodiments of action 405, handling the PA failure includes: when the memory address stores dynamic code instructions, resuming execution at the machine code instructions stored at the memory address.

[0056] In any case, in embodiments, when operating in compatibility mode, PA failure handler 120 also logs PA failures in log 112 (e.g., using logger 110). Therefore, based on the application executing in compatibility mode, in some embodiments of action 405, handling PA failures also includes logging PA failures.

[0057] In embodiments, the enforcement mode also includes an "audit mode" as the least restrictive enforcement mode, in which the PA failure handling procedure 120 logs each PA failure per program (e.g., application 113) without actually terminating the program. In embodiments, the audit mode can be used to run a program with active PA support to identify behaviors that cause PA failures (e.g., as part of testing compatibility, to identify errors, etc.) without actually terminating the program when a PA failure occurs. Therefore, based on the application executing in audit mode, in some embodiments of action 405, handling a PA failure includes (i) logging the PA failure and (ii) resuming execution at the machine code instruction stored at a memory address.

[0058] Therefore, in the embodiments, the technical effects of action 405 include enabling a rich set of memory failure handling modes, such as a strict mode that terminates the program when any PA fails during program execution (while potentially logging the PA failure), a compatible mode that terminates the program in case of some PA failures and allows the program to continue execution in case of other PA failures (while potentially logging each PA failure), and an audit mode that logs each PA failure per program without actually terminating the program.

[0059] return Figure 1B The memory fault handling procedure 109 is also shown to include an invalid pointer handling procedure 121. In an embodiment, the invalid pointer handling procedure 121 handles memory faults as conventionally would, such as by terminating an application with a segmentation fault or other error state. Figure 4 When action 402 detects that the memory pointer was not invalidated due to PA failure, method 400 includes action 406, that is, when the memory pointer was not invalidated due to PA failure, disposing of the invalid pointer.

[0060] In embodiments, the principles described herein operate in an "offline" post-analysis mode, either at computer system 101 or at some other computer system. In these embodiments, the computer system performing the post-analysis analyzes telemetry data received from computer system 101, and potentially analyzes telemetry data received from one or more other computer systems. This telemetry data includes pointers that could lead to memory failures, and the post-analysis performs the analysis described in conjunction with PA failure detection component 117 to determine whether these memory failures were caused by pointer invalidation following a PA failure. In embodiments, PA failure detection performed via this post-analysis is used to identify malicious ROP behavior and / or program errors (including PA incompatibility). As should be understood, post-analysis of telemetry data received from multiple computer systems can be used to improve the accuracy of identifying malicious ROP behavior and / or program errors (including PA incompatibility).

[0061] Therefore, the embodiments described herein determine whether a memory pointer may have been invalidated due to a PA failure. This is based on identifying the memory pointer that triggered the memory failure, "repairing" the memory pointer by setting a reserved bit to a default value, and determining whether the "repaired" memory pointer corresponds to a memory address falling within the executable memory location. When a memory pointer is determined to be likely invalidated due to a PA failure (and therefore the memory failure was caused by a failed PAC authentication), the embodiments described herein handle the memory failure by logging the PA failure, terminating the program that caused the PA failure, and / or resuming program execution at the machine code instruction corresponding to the repaired memory pointer.

[0062] By distinguishing between memory failures caused by failed PAC authentication and memory failures caused by invalid pointers, the embodiments described herein provide log information that can be used to identify and repair PA incompatibilities in a program (thus resolving errors and failures in the program) or to detect ROP-type attacks (thus improving security). Furthermore, the embodiments described herein provide the technical effect of enabling rich memory failure handling modes. Although the subject matter has been described in language specific to structural features and / or method actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the features or actions described above, or the order of the actions described above. Rather, the described features and actions are disclosed as exemplary forms for implementing the claims.

[0063] The invention may be embodied in other specific forms without departing from its essential characteristics. Such embodiments may include: a data processing apparatus including means for performing one or more of the methods described herein; a computer program including instructions that, when executed by a computer, cause the computer to perform one or more of the methods described herein; and / or a hardware storage device including instructions that, when executed by a computer, cause the computer to perform one or more of the methods described herein. The described embodiments are to be considered illustrative rather than restrictive in all respects. Therefore, the scope of the invention is indicated by the appended claims rather than by the foregoing description. All variations within the meaning and equivalence of the claims should be included within their scope. When elements are introduced in the appended claims, the articles “a,” “an,” “the,” and “the” are intended to mean the presence of one or more of these elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that additional elements besides those listed may be present. Unless otherwise specified, the terms "set," "superset," and "subset" are intended to exclude the empty set, and thus a "set" is defined as a non-empty set, a "superset" as a non-empty superset, and a "subset" as a non-empty subset. Unless otherwise specified, the term "subset" excludes its entire superset (i.e., a superset contains at least one item not included in the subset). Unless otherwise specified, a "superset" may include at least one additional element, and a "subset" may exclude at least one element.

Claims

1. A method implemented in a computer system including a processor for memory fault handling based on detecting whether a memory pointer has been invalidated due to a pointer authentication PA failure, the method comprising: Identify a memory pointer; access to this memory pointer during application execution results in a memory failure at the processor. Detecting that the memory pointer was invalidated due to a PA failure includes: A new memory pointer is created by replacing the multiple reserved bits with their default values. as well as The new memory pointer is determined to correspond to the memory address falling within the executable memory location based on at least one of the following: It is determined that the call instruction was stored at a previous memory address immediately preceding the memory address; or Determine the correspondence between the memory address and the memory region mapped to the code segment of the executable file; and Based at least on the detection that the memory pointer was invalidated due to a PA failure, the PA failure is handled by performing at least one of the following: The PA was recorded as failing; Terminate the application; or Execution resumes at the machine code instruction stored at the memory address.

2. The method according to claim 1, wherein the memory fault is a memory switching fault.

3. The method according to claim 1, wherein the method is implemented by a memory fault handling program in the operating system kernel.

4. The method of claim 1, wherein the method detects whether the memory pointer is invalidated due to a PA failure only when the processor is determined to have PA capability.

5. The method of claim 1, wherein the method detects whether the memory pointer is invalidated due to a PA failure only when the application is compiled to have support for PA.

6. The method of claim 1, wherein handling PA failure based on the application being executed in audit mode comprises: (i) record the PA failure, and (ii) resume execution at the machine code instruction stored at the memory address.

7. The method of claim 1, wherein handling the PA failure based on the application being executed in strict mode comprises: (i) record the PA failure, and (ii) terminate the application.

8. The method according to claim 1, wherein The method includes determining that the memory address corresponds to a memory region mapped to a code segment of the executable file; and Based on the application being executed in compatibility mode, handling the PA failure includes: The application is terminated when the executable file corresponds to the application.

9. The method according to claim 1, wherein The method includes determining that the memory address corresponds to a memory region mapped to a code segment of the executable file; and Based on the application being executed in compatibility mode, handling the PA failure includes: When the executable file is a binary file loaded by the application, execution resumes at the machine code instructions stored at the memory address.

10. The method of claim 1, wherein determining the correspondence between the new memory pointer and the memory address falling within the executable memory location comprises: The memory address is determined to be within an executable memory page.

11. The method of claim 1, wherein determining the correspondence between the new memory pointer and the memory address falling within the executable memory location comprises: It is determined that the call instruction is stored at the previous memory address immediately preceding the memory address.

12. The method of claim 1, wherein determining the correspondence between the new memory pointer and the memory address falling within the executable memory location comprises: The memory address is determined to correspond to the memory region of the code segment mapped to the executable file.

13. A computer system for memory fault handling based on detecting whether a memory pointer has been invalidated due to a pointer authentication PA failure, comprising: processor; as well as A hardware storage device for storing computer-executable instructions, which are executable by the processor to enable the computer system to at least: Identify a memory pointer; access to this memory pointer during application execution results in a memory failure at the processor. Detecting that the memory pointer was invalidated due to a PA failure includes: A new memory pointer is created by replacing the multiple reserved bits with their default values. as well as The new memory pointer is determined to correspond to the memory address falling within the executable memory location based on at least one of the following: It is determined that the call instruction was stored at a previous memory address immediately preceding the memory address; or Determine the correspondence between the memory address and the memory region mapped to the code segment of the executable file; and Based at least on the detection that the memory pointer was invalidated due to a PA failure, the PA failure is handled by performing at least one of the following: The PA was recorded as failing; Terminate the application; or Execution resumes at the machine code instruction stored at the memory address.

14. The computer system of claim 13, wherein the computer-executable instructions are executable by the processor to cause the computer system to detect whether the memory pointer is invalidated due to a PA failure only when the processor is determined to have PA capability.

15. The computer system of claim 13, wherein the computer-executable instructions are executable by the processor to cause the computer system to detect whether the memory pointer is invalidated due to a PA failure only when the application is compiled to have support for PA.

16. The computer system of claim 13, wherein handling PA failure based on the application being executed in audit mode comprises: (i) record the PA failure, and (ii) resume execution at the machine code instruction stored at the memory address.

17. The computer system of claim 13, wherein handling the PA failure based on the application being executed in strict mode comprises: (i) Log the PA failure, and (ii) Terminate the application.

18. The computer system according to claim 13, wherein, The computer system determines that the memory address corresponds to a memory region that is mapped to the code segment of the executable file; and Based on the application being executed in compatibility mode, handling the PA failure includes: terminating the application when the executable file corresponds to the application.

19. The computer system according to claim 13, wherein The computer system determines that the memory address corresponds to a memory region mapped to the code segment of the executable file; and Based on the application being executed in compatibility mode, handling the PA failure includes: When the executable file is a binary file loaded by the application, execution resumes at the machine code instructions stored at the memory address.

20. A hardware storage device for storing computer-executable instructions, said computer-executable instructions being executable by a processor to cause a computer system to handle a memory fault based on detecting whether a memory pointer has been invalidated due to a pointer authentication PA failure, said computer-executable instructions including instructions executable by the processor to cause the computer system to perform at least the following actions: Identify a memory pointer; access to this memory pointer during application execution results in a memory failure at the processor. Detecting that the memory pointer was invalidated due to a PA failure includes: A new memory pointer is created by replacing the multiple reserved bits with their default values. as well as The new memory pointer is determined to correspond to the memory address falling within the executable memory location based on at least one of the following: It is determined that the call instruction was stored at a previous memory address immediately preceding the memory address; or Determine the correspondence between the memory address and the memory region mapped to the code segment of the executable file; and Based at least on the detection that the memory pointer was invalidated due to a PA failure, the PA failure is handled by performing at least one of the following: The PA was recorded as failing; Terminate the application; or Execution resumes at the machine code instruction stored at the memory address.

Images