Pointer authentication and dynamic switching between pointer authentication schemes

Abstract

The embodiments described herein enable interoperability between processes configured for pointer authentication and processes not configured for pointer authentication. Enabling interoperability between such processes enables basic libraries, such as system libraries, to be compiled with pointer authentication while still enabling those libraries to be used by processes that have not been compiled or configured to use pointer authentication.

Description

[0001] Cross-references

[0002] This application claims priority to U.S. Patent Application No. 16 / 539,356, filed on August 13, 2019, entitled “Dynamic Switching Between Pointer Authentication Regimes,” granted to Bernard J. Semeria et al., and U.S. Provisional Patent Application No. 62 / 729,958, filed on September 11, 2018, entitled “Dynamic Switching Between Pointer Authentication Regimes,” granted to Bernard J. Semeria et al., both of which are incorporated herein by reference in their entirety to the extent consistent with the present disclosure. Technical Field

[0003] Embodiments described herein relate generally to computing systems that support pointer and memory authentication, and more particularly to enabling dynamic switching between pointer authentication schemes. Background Art

[0004] ROP / JOP attacks are often used to attempt to compromise the security of a computer system, thereby allowing an attacker to gain control of the system. A ROP (return-oriented programming) attack is an advanced version of a stack overflow attack, in which an attacker manipulates the program call state to overwrite the return address with an arbitrary address selected by the attacker. When the executed function returns, the function will pop the overflowed return address from the stack and return to the address selected by the attacker. A JOP (jump-oriented programming) attack manipulates the control flow of a program by attacking program code, which includes indirect jump instructions or function pointers that can be manipulated using, for example, forced data type confusion. An attacker can force program code to jump to a "gadget" in memory, which is a part of an existing instruction that is manipulated to perform tasks that help the attacker. An attacker can link gadgets together to execute malicious code on a victim processor. Summary of the invention

[0005] The embodiments described herein enable interoperability between processes configured for pointer authentication and processes not configured for pointer authentication. Enabling interoperability between such processes enables basic libraries, such as system libraries, to be compiled with pointer authentication while still enabling those libraries to be used by processes that have not been compiled or configured to use pointer authentication.

[0006] One embodiment provides a system comprising an integrated circuit including a memory for storing data and instructions and one or more processors coupled to the memory. Each of the one or more processors may be configured as an execution agent for the integrated circuit. The one or more processors may derive one or more agent master keys for use by the one or more execution agents, the one or more agent master keys being derived from a master key of the integrated circuit, deriving a set of signature and authentication keys for use by the one or more execution agents, the execution agent using one or more of the signature and authentication keys associated with the execution agent to sign a memory address of a pointer, store the pointer to the memory, and authenticate the pointer before executing instructions associated with the pointer.

[0007] Another embodiment provides a non-transitory machine-readable medium storing instructions that cause at least one processor of a plurality of processors of a system-on-chip integrated circuit (SOC) to perform operations including deriving one or more proxy master keys for use by one or more of the plurality of processors of the SOC, wherein the one or more proxy master keys are derived from a master key of the SOC. The operations also include: deriving a set of signature and authentication keys for use by one or more of the plurality of processors; signing an address of a pointer using one or more of the signature and authentication keys; storing the pointer to a memory; and authenticating the pointer before executing instructions associated with the pointer.

[0008] An additional embodiment provides a method comprising, on a processor of an electronic device: generating a pointer; selecting a hardware-based key for generating a signature for the pointer; diversifying the hardware-based key using selected key diversification data to generate a diversified key; signing the value of an address within the pointer using the diversified key to generate a pointer signature, and verifying the pointer signature before invoking the address within the pointer using the processor.

[0009] The above summary does not include an exhaustive list of all embodiments of the present disclosure. All systems and methods can be practiced according to all suitable combinations of the various aspects and embodiments of the above Summary and those disclosed in the following Detailed Description. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.

[0011] Figure 1 A block diagram showing the hardware logic of a processor according to the embodiments described herein;

[0012] Figure 2A technique for signing and authenticating memory locations and registers according to one embodiment is shown;

[0013] Figure 3A-3C Methods for signing return and authentication pointer values ​​and switching between authenticated and non-authenticated procedures are shown;

[0014] Figure 4A-4C illustrating differences between software architecture elements when address signing is enabled and disabled according to an embodiment;

[0015] Figure 5 is a block diagram illustrating a linking and loading process according to one embodiment;

[0016] Figure 6 A system for enabling legacy processes to use signed shared libraries according to one embodiment is shown;

[0017] Figure 7A-7B shows a processor and SOC key domain including a plurality of secret keys in various embodiments;

[0018] Figure 8 A method for runtime key diversification according to one embodiment is shown;

[0019] Figure 9A-9C A system for key diversification and data structure protection according to embodiments described herein is shown;

[0020] Figure 10A-10B The use of pointer value signatures to detect malicious or unintentional memory corruption is shown;

[0021] Fig.11 A system for pointer-authenticated ABI versioning according to one embodiment is shown;

[0022] Fig.12 A system for dynamic pointer authentication ABI versioning via bitcode is shown according to one embodiment;

[0023] Fig.13 is a block diagram illustrating an exemplary API architecture that may be used in some embodiments;

[0024] Figure 14A-14B is a block diagram of an exemplary API software stack according to an embodiment;

[0025] Fig.15 is a block diagram of a mobile device architecture according to one embodiment; and

[0026] Fig.16 is a block diagram illustrating an exemplary computing system that may be used with one or more of the embodiments of the present disclosure. DETAILED DESCRIPTION

[0027] Computer processor designers have developed various techniques as countermeasures against a variety of malicious exploits, including ROP / JOP attacks. For example, data execution prevention can be used to prevent attackers from injecting arbitrary code, because code injected into the data segment of a program will not be executed by the processor. Data execution prevention forces attackers to use gadgets, which are existing instructions in the code segment of a program. In addition, some processors include technologies that allow pointers and data structures to be signed and authenticated, which can be used to detect modifications to those pointers or data structures.

[0028] For example, the processor may assign cryptographic signatures to pointers such as function pointers or return addresses. When the pointer is used, the processor authenticates the signature to ensure that the details of the pointer have not been manipulated. Programs may be compiled or recompiled to utilize the data protection features of pointers and pointer authentication processors, where the compiler automatically inserts additional instructions to sign and authenticate pointers and data structures. In addition, processors with pointer or data authentication features may be made backward compatible so that programs that have not been compiled with such protections can still be executed.

[0029] However, some processors have pointer and data authentication mechanisms that by themselves do not allow mixing of programs with and without pointer and data authentication. For example, if the operating system's system libraries are compiled with pointer and data authentication, those libraries cannot automatically be used by programs that have not been compiled with pointer and data safety enabled.

[0030] As described herein, where reference is made to pointer authentication, the description is generally applicable to pointer and data authentication and protection techniques implemented by a computer processor unless any exceptions are explicitly noted.

[0031] Embodiments described herein realize the interoperability between the process configured for pointer authentication and the process not configured for pointer authentication.Realizing the interoperability between such processes enables basic libraries such as system libraries to be compiled with pointer authentication, while enabling those libraries to still be used by processes that have not yet been compiled or configured to use pointer authentication.In one embodiment, interoperability is realized in the following manner: a copy of only a portion of the system library used by a process without authentication is placed in a separate area of ​​virtual memory, and this separate area of ​​virtual memory is mapped to those processes instead of the virtual memory containing the authenticated version of the system library.In addition, when context switching occurs between a process with pointer authentication and a process without pointer authentication, the authentication feature of the processor can be dynamically enabled or disabled.

[0032] Embodiments described herein also provide an authentication key mechanism that can use different authentication keys when kernel mode and user mode pointers are signed. The first group of keys is used to sign the user mode pointer, and different and / or additional keys can be used when the address of the kernel mode pointer is signed. In such embodiments, the user mode pointer that causes the attacker to sign in a certain way will not be effectively used in kernel mode. However, the kernel can sign the pointer that can be effectively used in user mode by temporarily disabling the use of kernel keys when signing the address used for user mode and / or enabling user mode keys.

[0033] The embodiments described herein also provide thread state signatures to ensure that the thread state of a dormant or waiting thread is not manipulated when the thread waits to resume execution. When a thread is in a dormant or waiting state, or when an interrupt or exception occurs during the execution of a thread, the thread state of the thread can be stored in a memory. The thread state may include details such as the execution state of the thread (e.g., register values) and a program counter or instruction pointer associated with the thread. When a thread is sent to a dormant or waiting state, sensitive portions of the thread state may be signed by the processor before the thread state is stored in the memory. When the thread is resumed, those pointers to the thread state may be authenticated to ensure that the thread state has not been manipulated when the thread is in a waiting or dormant state. Once the thread state is authenticated, the thread state may be restored to the processor and thread execution may be restored.

[0034] Embodiments described herein also provide pointer application binary interface (ABI) version control. The ABI version control scheme enables the specific details of the signed or unsigned elements of the system library to be changed between the major and minor version revisions of the operating system. The program code for signing the pointer or data structure in the system library can be annotated with a version number scheme associated with a set of specific signed or unsigned data structures and pointers. Third-party applications can be compiled for use for specific pointer authentication ABI versions, wherein during compilation, the third-party applications are compiled to know which system library pointers and data structures are expected to be signed. If a third-party application is executed on a system with mismatched pointer authentication ABI, address signatures can be disabled for the application, thereby allowing the application to execute without crashing, although the application can be executed in a slightly less secure state. It is not allowed to execute a system binary with a mismatched pointer authentication ABI, because the pointer authentication ABI version of the system binary and the library should always match. The mismatch of the pointer authentication ABI between the system binary and the system library may indicate that the system has been compromised.

[0035] In one embodiment, dynamic pointer authentication ABI versioning can be enabled for third-party applications submitted in bitcode format. Such applications can be dynamically compiled for the target OS and pointer version on which the application will be executed.

[0036] Figure 1 1 is a block diagram showing details of a processor 100 according to an embodiment described herein. The processor 100 includes an L1 cache 103, an instruction fetch unit 101, a branch unit 104, an execution core 110, and a register file 120. The L1 cache 103 can cache instructions and / or data used by the execution core 110. The fetch unit 101 can fetch instructions from the L1 cache 103 (or L2 cache) and provide those instructions to the execution core 110 for processing. The branch unit 104 can be configured to generate a branch target program counter address (PC) of the fetch unit 101 for branch instructions. The branch unit 104 can include a branch prediction unit to predict whether a branch will be taken or not taken. In one embodiment, the execution core 110 includes an integer execution unit 112, a floating point execution unit 114, a vector execution unit 116, and a signature generator / authentication unit 118. The integer execution unit 112, the floating point execution unit 114, and the vector execution unit 116 as a group are interchangeably referred to as "execution units". The execution unit may, for example, perform a computational operation, such as a logical operation, a mathematical operation, or a bitwise operation, for an operand of an associated type. The signature generator / authentication unit 118 may be used to generate signatures for pointers and data structures of program codes executed on the processor 100. Many execution units may reside in each execution core of the processor 100, and the processor 100 may include multiple instances of the execution core 110. In addition, multiple instances of the execution core 110 may have different architectures. The register file 120 may include a group of general registers 122 (GPR) or special registers 124 (SPR) for storing data or status information of instructions executed by the execution core 110. The general register 122 may be configured to store data of various types (e.g., integer, floating point, multimedia, vector, etc.). The special register 124 may store operands or data for a specific instruction or instruction subset. For example, in some embodiments, the program counter register may be a special register for storing the fetch address of the instruction. The link register may be a register for storing the return address used by the branch instruction.

[0037] Although processor 100 is shown as having a particular set of components, in various embodiments, processor 100 may include different numbers or types of execution units, functional units, and pipeline stages, such as instruction decode units, schedulers or reservation stations, reorder buffers, memory management units, I / O interfaces, and other components that may be coupled to the execution units. Additionally, in various embodiments, the components shown may exist in different combinations or arrangements than shown, with some components combined with other components into a single module.

[0038] Processor 100 may be configured to perform signature and authentication operations on return address and / or jump address, and detect whether the address has been modified between the time when the address is created / stored and the time when the address will be used as the target. In some embodiments, the address may be signed when writing to the memory. For example, the return address of a subroutine call may be written to a stack in the memory. The jump address may be written to any memory location for later retrieval. When the address is retrieved later to be used as a jump / return target address, processor 100 may be configured to perform authentication operations on the address. If the authentication operation fails, an error handling operation may be initiated instead of branching or jumping to a certain address. In one embodiment, signature and authentication operations may also be performed on the address in the register. For example, the general register 122 in register file 120 may be used as the source of the return address or jump address, and may be signed and authenticated. In addition, in some embodiments, special registers 124 such as link registers may be signed and authenticated. Performing a signature operation on a value may be more concisely referred to as "signing" the value in this article. Similarly, performing an authentication operation on a value may be more concisely referred to as "authentication" in this article. In one embodiment, data pointers (addresses of data in memory where data is manipulated during execution of instructions in processor 100) may also be signed and authenticated. In one embodiment, data structures, either as a whole or specific portions thereof, may be signed and authenticated.

[0039] Generally speaking, performing a signature operation or "signing" an address refers to applying a cryptographic function to the address using at least one cryptographic key and optionally additional data. The result of the cryptographic function is a signature. By later applying the cryptographic function again and comparing the resulting value with the signature, an authentication operation can be performed on the address (or the address can be "authenticated"). That is, if the address and / or signature is not modified, the result of the cryptographic function should be equal to the signature. The cryptographic key may be specific to the thread, process, or context in which the address is generated and used, so the possibility that a third party has not detected the modification may be very small. In some cases, a global key that is not specific to a thread, process, or context is used. For example, a global or context-independent key may be used to sign an address or data that can be reasonably used or modified by other contexts. The cryptographic key may be generated at least in part based on a "secret" that is specific to an instance of the processor 100 and is inaccessible to software. The cryptographic key itself may also not be accessible to software, and therefore the key may remain secret and difficult to be discovered by a third party.

[0040] In one embodiment, the optional additional data used in the signature and authentication of the return or jump address may include the address of the storage return or jump address. For example, a virtual address of the location, such as a virtual stack pointer, may be used to store the address on the stack, or a virtual address to a memory location. Other embodiments may use a physical address. The encryption function applied to the return / jump address may be an encryption of the address using a key. The encryption result may be a signature as a whole, or a portion of the result may be a signature (e.g., the signature may be shortened via truncation or offset). Any encryption algorithm may be used, and some details about key length, key whitening, and key diversification data may vary based on the underlying encryption implementation.

[0041] As described herein, hardware instructions refer to executable entities defined in the instruction set architecture implemented by the processor 100. There are multiple instruction set architectures (e.g., x86 architecture originally developed by Intel, ARM from ARM Holdings, Power and PowerPC from IBM / Motorola, etc.). Each instruction is defined in the instruction set architecture, including the encoding of the instruction in the memory, the operation of the instruction, and the effect of the instruction on registers, memory locations, and / or other processor states. A given specific implementation of the instruction set architecture can directly execute each instruction, but its form can be changed by decoding and other manipulations in the processor hardware. Another specific implementation can decode at least some instructions into multiple instruction operations for execution by the execution unit in the processor 100.

[0042] Some instructions may be microcode instructions in some architectures. Thus, the term "instruction operation" may be used herein to refer to an operation that an execution unit in processor 100 and / or execution core 110 is configured to perform as a single entity. An instruction may have a one-to-one correspondence with an instruction operation or may have a many-to-one correspondence with an instruction operation.

[0043] In some cases, software instructions are described, which refer to commands or other elements of program code that can be compiled or interpreted as hardware instructions executed by processor 100. The software instructions may be high-level program code, an intermediate representation of program code, or low-level program code that may correspond directly to underlying hardware instructions executed by processor 100.

[0044] Figure 2 A technique for signing and authenticating memory locations and registers according to one embodiment is shown. A block diagram illustrating an M-bit memory location or register (220) is shown, where the value M can be an integer value greater than zero. In one embodiment, M represents Figure 1 The architectural size of the memory address space of the processor 100 of the instruction set architecture. For example, some instruction set architectures specify 64-bit addresses. However, the actual implementation size of the address space may be less than 64 bits, such as between 40 bits and 48 bits. In such specific implementations, some of the address bits are not effectively used. The unused bits may alternatively be used to store a signature of the address (field 222), but in some specific implementations, the signature may be stored in a different memory location.

[0045] In this embodiment, the t+1 bits of the return address or jump address (field 221) are implemented, where t is less than M and is also an integer. The remaining bits of the register / memory location store the signature (field 222). The signature generated from the encryption algorithm may be greater than M-(t+1) bits, which is greater than the signature (field 222). Therefore, in some specific implementations, only a portion of the signature is stored. For example, the signature may be truncated or offset to the right before being stored. Any mechanism for shortening the signature field may be used.

[0046] The processor 100 may, for example, Figure 1 The signature generation / authentication circuit 118 in the implementation of signature generation and authentication in hardware. The signature generation / authentication circuit may include circuits for signing and authenticating return addresses and jump addresses. In addition, there may be instructions defined for the instruction set architecture that generate signatures or perform authentication.

[0047] In one embodiment, a special pointer format may be used only for return address protection, where the link register uses a larger (M+K bit) pointer type than other user-level pointers. This larger pointer can carry a K-bit return address signature while also carrying the unmodified return address. The larger pointer can be used in recompiled 64-bit code without changing the normal program. In addition, for any 32-bit value that will be signed and stored in a 64-bit register, the signature can be added in the upper 32 bits without overwriting part of the 32-bit value.

[0048] Code block 230 shows several code sequences that utilize signature generation using a signature generation instruction. For example, the signature instruction takes an optional virtual address (VA), a source register (RS), and a key as input operands. The virtual address may also be in a register. The key may be stored in a hardware accessible register or other storage device accessible only by hardware. The key may be a single key or multiple keys, depending on the encryption algorithm implemented by processor 100.

[0049] The signature instruction may apply an encryption algorithm to data (e.g., RS, VA) to generate a signature that can be written to the target register RT. When more than one reference is provided, the data may be combined before encryption. For example, the source register RS ​​and the virtual address VA may be logically combined according to any desired logical function. The resulting data from the combination may then be encrypted. Alternatively, multiple block encryptions (such as a block cipher mechanism) may be used to concatenate and encrypt the data. Any type of encryption may be used, including the Advanced Encryption Standard (AES), the Data Encryption Standard (DES), the International Data Encryption Algorithm (IDEA), or the PRINCE algorithm. A factor in determining the encryption algorithm to be used is the latency of the algorithm. Therefore, a single encryption may be selected that is strong enough to protect the encrypted data to the desired security level. The signature generated by the encryption may then be shortened to match the signature field (field 222), such as Figure 2 shown.

[0050] The virtual address can be an optional part of the signature generation. The inclusion of the virtual address provides information related to the location where the return address / jump address is stored. Therefore, if the signed return address / jump address is moved and later retrieved from a different location, the authentication using the virtual address of the new location may fail. In some cases, it may be desirable to move the signed address (e.g., when used in a shared library). In this case, the virtual address may not be included in the signature generation or the corresponding authentication. In such cases, a constant value may be used instead of the virtual address.

[0051] In one embodiment, the signature generation instruction can operate on the data stored in the memory. For example, the ystp instruction of code block 230 can store a pair of registers RS1 and RS2 in the stack at a position identified by the immediate field imm5. That is, the imm5 field can be an offset relative to the stack pointer. The ystp instruction can also use a key and a selected encryption algorithm (and optionally, store the virtual address of the pair, for example, the stack pointer plus the imm5 field) to sign at least one of the register values, or in another embodiment, sign both. The pair of registers can be, for example, a general register that is usually used as a frame pointer and a link register by the compiler of the processor 100. The link register can be signed in response to the instruction, and the signed value can be stored in the memory. When the ystp instruction stores a pair of registers in the memory, a corresponding yst instruction that stores a register in the memory and generates a signature for the register data can be defined. Other instructions can store other numbers of registers in the memory, and signatures can be generated for any subset of registers. In addition, other instructions can use other addressing modes, and there is no need to store the signed address on the stack.

[0052] Code block 240 shows several code sequences that utilize the authentication instruction. For example, the Auth instruction takes an optional virtual address (VA), a source register (RS), and one or more keys as input operands. The virtual address may also be in a register. The key may be stored in a hardware accessible register or other storage device that is only accessible by hardware.

[0053] The Auth instruction may apply the same encryption algorithm as the Sign instruction to the virtual address and return / jump address (field 221) of the source register data (e.g., RS, VA), thereby generating a signature that can be written to the target register RT. The resulting signature may be compared with the signature (field 222) of the source register data. The resulting signature may be shortened in the same manner as the original signature was shortened. If the signatures do not match, the verification fails and a return / jump to the address is prevented. If the signatures match, the authentication passes and a return / jump to the address is allowed. For example, a return / jump may be prevented by causing an exception or trapping the program to execute. With respect to a data pointer, if the authentication fails, an exception may be signaled instead of allowing the use of the data pointer.

[0054] In one embodiment, the authentication instruction can operate on data read from memory. For example, the yldp instruction shown in Figure 4 can load a pair of registers RT1 and RT2 from the position identified by the immediate field imm5 in the stack. That is, the imm5 field can be an offset relative to the stack pointer. The yldp instruction can also use a key and a selected encryption algorithm (and optionally a virtual address from which the pair is read, for example, the stack pointer plus the imm5 field) to authenticate at least one of the register values, or in another embodiment, authenticate both. The pair of registers can be, for example, a general register that is usually used as a frame pointer and link register by the compiler of the processor 100. The link register can be authenticated in response to the instruction, and if the authentication fails, an exception can be signaled. When the yldp instruction reads a pair of registers from memory, a corresponding yld instruction that reads a register from memory (and authenticates the data) can be defined. Other instructions can load other numbers of registers from memory, and can authenticate any subset or all of the registers, and can use other addressing modes, and can store addresses elsewhere except the stack.

[0055] In one embodiment, it may be desirable to remove the signature from the address without authenticating the address. A stripping instruction may be defined that removes the signature and replaces it with the original bits from the address, such as a sign extension (field 221) of the address or zero. Code block 250 includes an exemplary stripping instruction that may take a source register RS ​​and a key that is used to sign the address in the source register and output the address to a target register (RT) from which the signature is removed. The stripping instruction may be used to write an authenticated pointer to a memory that will be used by legacy software that does not support pointer and / or data authentication, or when generating output for debugging purposes. For example, a debugger may be configured to detect signatures and strip signatures from pointers in various features, such as printing values, forming backtraces, and establishing breakpoints. A stack unwinder may be configured to identify a signed return address and strip the signature while grabbing the stack. Other dynamic tools, such as a stack trace collector, may be configured to strip signatures when symbolizing a function address. Tools that process core dumps or other remaining portions of a crashed program may also be configured to strip addresses using stripping instructions. Each of these tools can be configured to be pointer authentication ABI-aware so that the tools know which keys and additional data to use to correctly strip addresses.

[0056] Figure 3A-3C Methods for signing return and authentication pointer values ​​and switching between authenticated and non-authenticated processes are shown. However, for ease of understanding, the operations shown and described below are shown in a particular order, but other orders may also be used. The operations shown in the following flow charts may be performed by Figure 1 The processor 100 or a component thereof is implemented.

[0057] Method 300 Figure 3A , and includes a method for processor 100 to use Figure 2 , a variant of the instruction shown in is used to sign the subroutine return address (block 301). The virtual address (VA) to be used to sign the return address can be the stack pointer (SP), or alternatively, the stack pointer is added to an offset identifying the location where the return address will be pushed. The signature can be based on the VA, the return address (RA), and the key. The signature can be generated by applying a selected encryption algorithm to the input data (VA, RA, key). In one embodiment, the signature can be generated based on multiple keys. For example, the encryption algorithm can use a key pair (K0 and K1), where K0 can be a "whitening" key and K1 can be a "core" key. The core key can be used in iterations of the block cipher, and the whitening key can be used before and / or after the iterations are completed to further modify the data. The generated signature can be combined with the return address to form a signed return address (e.g., as Figure 2 Field 222 in ).

[0058] The processor 100 may then push the signed return address of the subroutine onto the stack (block 302). The push may occur in the calling code, before jumping to the address of the subroutine, or within the subroutine. In one embodiment, the signing subroutine return address (block 301) and the pushing subroutine return address (block 302) each occur within the subroutine, allowing the callee to determine the signature details of the return address. In the case where the signature is an internal implementation detail of each function, the return address will be unsigned because at the function boundary.

[0059] The subroutine may include instructions for performing one or more operations for which the subroutine is designed. The instructions for performing the subroutine may be executed (block 303), and when the subroutine is completed, the subroutine may pop the subroutine return address from the stack (304), and authenticate the subroutine return address (block 305). The signed return address may be loaded from the stack memory location into the target register. Similar to the original signature generation, VA may be set to the stack pointer or the stack pointer plus the offset to the location of the return address. The signed return address may be authenticated by applying the same operation applied when the return address was initially signed and comparing the generated value with the signature. If the signature remains valid (e.g., the signature generated in the authentication matches the original signature in the address) (block 306, "yes"), the return address may be used. That is, the processor 100 may jump to the return address (block 307). Otherwise (block 306, "no"), the processor 100 may trap the execution (block 308) or otherwise signal an exception to prevent the return address from being used.

[0060] Figure 3BThe method 310 shown in FIG. 310 shows that signing and authentication can be performed on any memory address and is not limited to a subroutine return address. A pointer to memory can be generated and written to the memory or register (block 311). This can be similar to the method in FIG. Figure 3A The address of the pointer is signed (box 312) in the same manner as the return address was signed at box 301 of the present invention. Subsequently, the pointer can be read (box 314) and authenticated (box 315). Authenticating the pointer at box 315 can be performed similarly to authenticating the return address at box 305, except that the signed address does not need to be in the stack and can be stored in a register. Similarly, if the pointer value is valid (box 316, "yes"), the processor 100 can jump to the pointer value or access the data at the pointer value (box 317). Otherwise, (box 316, "no") the processor 100 can capture execution (box 318) or otherwise signal an exception to prevent the return address from being used. In one embodiment, the failed verification additionally causes the address value guaranteed by the processor to be an illegal address, and using the illegal address can result in the following. Figure 3A A trap or exception of block 318 and / or block 308 in FIG.

[0061] As described above, for example, when switching between applications that support or do not support address signatures, it may be necessary to switch between enabling pointer or return address authentication and disabling pointer or return address authentication. In one embodiment, enabling or disabling signatures and / or authentication can be performed at the context switch boundary between processes. Enabling or disabling signatures and / or authentication can be performed by enabling or disabling one or more keys for generating and authenticating signatures. When the key for signing or authenticating instructions is disabled, the instruction effectively becomes a NO-OP. In one embodiment, the signing or authenticating instructions can still be executed by the processor, but the processor will output the input value unchanged.

[0062] Figure 3CThe method 320 shown shows the operation performed by the operating system kernel executed on the processor 100. The kernel may enter the context switch subroutine (box 321) when the context switch between processes is executed on the processor 100. The context switch routine may determine whether pointer authentication is enabled for the current process (box 322). The context switch routine may then determine whether pointer authentication is enabled for the next process (box 323). If there is a change in authentication state (box 326, "yes"), the kernel may switch the key enablement setting in the processor 100 (box 327). The switch key enablement setting will enable pointer signatures when switching to a process configured to use pointer signatures, or disable pointer signatures when switching to a process not configured to use pointer signatures. In one embodiment, the switch key enablement setting may enable or disable specific keys without enabling or disabling other keys. If switching is not required (box 326, "no"), the kernel may simply continue the context switch (box 328). In one embodiment, when switching from two processes in which pointer authentication is enabled, the per-process key may be changed to a key associated with the target context of the context switch.

[0063] Figure 4A-4C Illustrated are the differences between software architecture elements when address signing is enabled and disabled, according to an embodiment. Figure 4A Virtual function tables with and without pointer signatures are compared. Figure 4B A subroutine call with and without pointer protection is shown. Figure 4C Jump authentication with and without pointer projection is shown.

[0064] like Figure 4A As shown, a signed virtual function table (signed vtable 425) or a similar data structure containing function pointers may store a set of signed pointers including a set of signatures 422 and a set of pointers 420. In one embodiment, for each function pointer (FN1-FN3), a signature in the form of a pointer authentication code (PAC) may be appended to the pointer value, although other types of signatures may be used. In one embodiment, to enable signed vtable 425 to be used by legacy code, a strip instruction (such as Figure 2 ) creates a legacy vtable 435 to authenticate and remove signature 422 from pointer 420 of signed vtable 425. Legacy processes can then access legacy vtable 435 without triggering a runtime error when accessing a function pointer.

[0065] In one embodiment, a traditional vtable 435 is initially created and pointer signature functions such as Figure 2422. The program loader may use the signature instruction shown in 424 to create a signed vtable 425. In such embodiments, the program loader may load pointer 420 into memory and apply signature 422 based on load information provided with the program binary. The load information may include additional information specifying how signature 422 is generated, including a key used to generate the signature and diversification data used when generating the signature. The additional information does not significantly increase the size of the program binary. When loading a traditional binary, the signing operation may be bypassed.

[0066] In one embodiment, the signature 422 applied to the signed vtable 425 can be applied by the linker at link time, so that the signed vtable 425 can be written to the binary in a signed state. For situations where the system can commit to using a constant signing key for the binary, the signature 422 can be applied at link time, and applying the signature at load time enables the load to use a key that is unknown to the linker at link time. The signature 422 generated for the pointer 420 applied to the binary file can be diversified based on the address of the pointer, thereby associating the pointer with a specific location in memory. If a function pointer is to be copied in memory, the copy can be performed using specific API commands or instructions that strip, copy, and re-sign the copied pointer with the target address to which the pointer is copied. The intra-binary pointer signature can be best applied when the base address to which the binary will be loaded is known at link time. If the base address is unknown at link time, the pointer signed using the pointer address as diversified data will be dynamically re-signed by the program loader.

[0067] like Figure 4B As shown, when the key used by the instruction is disabled, the instruction for signing and authenticating the pointer is processed as a NO-OP instruction. Figure 4B Return authentication 440 is shown, where return address signing and authentication is performed for program code compiled to use pointer authentication. In one embodiment, signing and authentication of the return address is performed by the callee, and the return address is unsigned at the subroutine boundary. The subroutine prologue and epilogue may include instructions that are automatically added to the subroutine at compile time. In some implementations, the subroutine return address is stored in a link register, but in other implementations, the link register may not exist. The return address in the link register can be signed using the return address signing method described herein (e.g., Figure 3A 442 and the return address may be pushed onto the stack. However, when the key used to sign the link register is disabled, for example, when a conventional process is executing, the instruction to sign the link register will be processed as a NO-OP 442 and no operation will be performed. Instead, the conventional process will push the link register onto the stack without applying the signature.

[0068] When the subroutine execution is complete, the subroutine epilogue is executed, where the return address is popped from the stack and stored in the link register. For procedures compiled with signatures and authentication enabled, the authentication instruction is executed. For legacy procedures executed with the associated key disabled, NO-OP 444 is executed instead of the authentication operation of the link register. The legacy procedure and the signature-enabled procedure can then each perform a return by branching to the address in the link register.

[0069] like Figure 4C As shown, before jumping to the specified jump target, jump authentication 450 may be performed as a NO-OP 446 for legacy processes that are executed with the key disabled. The key used for return protection (ROP) may be different from the key used for jump protection (JOP), allowing JOP protection to be disabled in legacy code while maintaining ROP protection.

[0070] In one embodiment, fusion instructions are provided to enable efficient execution of the signing and push, authentication and jump operations, or to otherwise combine the operations with the generation or authentication of a signature. Figure 2 The variant of the yst instruction shown in the code block 230 can be used to sign a register value (such as a link register) and store the signed value to the stack. For such fused instructions, if the key used to perform the signature authentication operation is disabled, the processor can bypass the signature or authentication portion of the instruction.

[0071] Figure 5 is a block diagram illustrating a link and load process according to one embodiment. In one embodiment, a system-level shared library for a computing system will be compiled to support address signing and authentication. Without the ability to switch between a signed context and an unsigned context, a process that does not support signing and authentication will not be able to execute subroutines loaded from a system-level shared library. An overview of static and dynamic linking is provided to give context to the further description that follows.

[0072] In one embodiment, linker 500 generates an executable file 510 that runs on processor 100 by combining binary object files (e.g., object A 502, object B 504) and any statically linked libraries (e.g., static library 506). At a later point in time, such as when the executable file is loaded for execution, or dynamically during runtime, dynamic loader 520 may perform operations to replace dynamic library stubs included in executable file 510 with references through which executable file 510 may indirectly call functions in dynamic shared library 508.

[0073] For example, object A 502 and object B 504 are compiled object files that are outputs of a compiler process that converts high-level instructions into binary data that can be executed by a data processing system. Object A 502 includes a function call to function B stored in object B 504, and calls to functions C and D stored in static library 506. Object B 504 includes a call to function C in static library 506 and a call to function E in shared library 508. Linker 500 can resolve symbolic references to functions within object A 502, object B 504, and static library 506 at initial link time to create executable file 510. However, the reference to function E is a stub reference that can be resolved by dynamic linker 520 at runtime to implement an indirect call to function E in shared library 508.

[0074] In one embodiment, executable file 510 may be a legacy file compiled to not support signed and authenticated pointers and data. However, shared library 508 may be a system library compiled to support signed and authenticated pointers and data. Figure 3C The operations of the illustrated method 320 may be used to disable signing and authentication during a context switch to a process associated with the executable file 510. However, if the process then attempts to execute a function loaded from the shared library 508, the system will crash without a system to enable interoperability between legacy processes and signed system libraries.

[0075] Figure 6 A system 600 is shown that enables a legacy process to use a signed shared library according to one embodiment. System 600 shows a memory layout including an operating system kernel 601, a storage space for a legacy process 602 (process L), a storage space for an authenticated process 620 (process A), a storage space including an authenticated shared library 622, and a storage space for a copy of a shared library 612 in which address signing and authentication are disabled. The specific functions, libraries, and storage space layout are not limited to any one embodiment and are shown for exemplary purposes.

[0076] Traditional process 602 can represent a third-party application, which may not yet be configured to use a signed pointer, but is still expected to be correctly executed on a platform that supports a signed pointer, and in which the system and / or shared library is compiled to utilize pointer signature and authentication. A simple solution would be to provide two copies of a system library, one of which is compiled to use a pointer signature and authentication, and the second copy is compiled to disable pointer signature. However, this solution may be expensive in terms of storage and memory space, and may not be suitable for mobile or embedded devices with reduced memory and storage capacity. On the contrary, the embodiment described herein provides a single group of shared libraries, which, in one embodiment, is merged into a shared library cache. By default, a shared library is configured to sign and authenticate pointers, return addresses, and selected data structures. However, the selected portion of the same shared library can be mapped twice in a virtual memory, wherein an instance is mapped so that the signature applied to the address associated with the shared library will be stripped and / or the authentication key will be disabled when the instance is loaded into the memory. In one embodiment, when specific elements (e.g., classes, methods, objects, functions, data structures, subroutines, etc.) of a shared library are dynamically loaded by a legacy application, the elements may be mapped to separate virtual memory addresses. When elements are loaded to separate virtual memory address mappings, pointer signing may be disabled for those elements, and encryption keys used by those elements may be disabled.

[0077] As shown, the authenticated process 620 includes a plurality of functions (function A-function E), wherein the address of one or more functions (e.g., function E (626)) of the authenticated process 620 is a stub mapped to one or more addresses (e.g., function E (623)) associated with the authenticated shared library 622. The traditional process 602 may also include a plurality of functions (function F-function G), wherein the address of one or more functions (e.g., function F (605)) is a stub mapped to one or more addresses (e.g., function G (615)) associated with the copy of the shared library 612. The copy of the shared library 612 includes only those elements loaded by the traditional function. Therefore, the specific elements of the copy of the shared library 612 loaded into the memory may be different from the elements of the authenticated library 622 loaded into the memory.

[0078] In some embodiments, the signing and authentication hardware of the processor may be configured to utilize multiple keys when signing and authenticating pointer values, return addresses, and data. Specific keys may be assigned to specific purposes. For example, specific keys may be used for instructions, while different sets of keys may be used for data. In addition, some keys may be context-specific keys, while other keys may be global keys. In one embodiment, specific keys may be used for shared libraries, so that when a key-disabled copy of an element of a shared library is loaded into memory, the key used by that specific library or a specific element of that specific library is disabled in the processor, while other keys used for other purposes may remain enabled. Reference is made below to Figure 7A-7B Additional information is provided regarding encryption keys used by some implementations.

[0079] Figure 7A-7B The processor 700 and SOC 730 key domains are shown including multiple secret keys in various embodiments. Fig. 7A A processor 700 is shown, which may be Figure 1 The processor 700 may include a plurality of instruction cores 710, at least one of which is similar to the execution core 110 of the processor 100. In one embodiment, the signature generation and authentication unit 118 of the execution core 110 includes a key block 701. In one embodiment, one or more keys within the key block 701 may be directly encoded into the hardware of the processor 700, or may be derived based on a master secret key embedded in the hardware of the processor. Based on the configuration of the processor 700 and the signature generation and authentication unit 118, one or more keys in the key block 701 may be read and written by a high-privilege process such as a kernel process, but cannot be read by user mode software.

[0080] In one embodiment, key block 701 includes, but is not limited to, key enable switch 702, which can be used to enable or disable specific keys used by processor 700 for signing and authentication. In such embodiments, some or all individual keys can be enabled or disabled in a fine-grained manner. Individual keys include, but are not limited to, one or more general keys 703, one or more instruction keys 704, one or more data keys 705, and one or more kernel keys 706. In some embodiments, one or more keys cannot be disabled and are always in use. For example, in one embodiment, at least one of the general keys 703 cannot be disabled. In one embodiment, there is also a kernel key enable 707, which can enable or disable the use of kernel keys 706 individually.

[0081] In one embodiment, the instruction set architecture of processor 700 supports the use of instruction keys 704 when adding signatures to instruction pointers and supports the use of data keys 705 when adding signatures to data pointers. In one embodiment, the instruction set architecture supports common keys 703 when generating independent arbitrary signatures.

[0082] In one embodiment, the signature generation and authentication unit 118 is coupled to or otherwise communicates with a cryptographic accelerator 720 that can be used to perform or accelerate cryptographic operations for deriving keys for the key block 701 and signing and authenticating addresses using keys for the key block 701. The cryptographic accelerator 720 can be present in each execution core 110. In other embodiments, the cryptographic accelerator 720 can be a separate processor core coupled to the execution core via an intra-processor bus, or can be a separate multi-core processor coupled to the illustrated processor 700 via an inter-processor bus. In one embodiment, the cryptographic accelerator 720 is a secure processor (such as a secure element or secure enclave processor) or is included within a secure processor.

[0083] In one embodiment, instruction key 704 and data key 705 can be used for signing the address associated with instruction address or data address respectively.Instruction key 704 and data key 705 can comprise the global key for signing the address, and this address can be accessed by any process with the access right to the correct key or can be context specific, so that the signature generated by utilizing context specific key can only be authenticated by identical software context.In one embodiment, general key 703 can be used for signing any data, and these data can be pointer value, return address, data address or other data.In one embodiment, the signature generated using general key 703 can be stored separately from the address or data based on the signature, rather than being embedded in the pointer like instruction key 704 and data key 705.For example, the signature of data structure can be generated and written into the signature field in the data structure, and the pointer of data structure can be signed separately by a data key in the data key 705.

[0084] In one embodiment, except any one of the general key 703, instruction key 704 or data key 705 that may also have been used to generate a signature, any signature generated by the kernel process automatically attaches one or more kernel keys 706. Kernel keys 706 are used to distinguish the signature generated by the user mode process from the signature generated by the kernel mode process, so that if an attacker can hijack the user mode process in some way and make it generate a signature, the signature is still considered invalid for the kernel. For example, one or more kernel keys 706 can be XORed with any other key that will be used to generate or authenticate a signature, and the combined key can be provided to the encryption function that generates or authenticates a signature. Other techniques can also be used. For example, when generating a derived key for signature generation and authentication of an address or other data, one or more kernel keys 706 can be used to diversify additional keys.

[0085] In one embodiment, kernel key enable 707 is provided to allow a kernel mode process to manually disable the use of kernel key 706. In such embodiments, kernel key enable 707 is automatically turned on when a kernel mode process is context switched and the execution level of the processor is raised. For kernel mode processes used to generate signatures that are intended to be valid in user mode, the kernel mode process may automatically disable kernel key enable 707 before a signature is generated or authenticated.

[0086] As described above, in one embodiment, one or more keys within key block 701 may be encoded directly into the hardware of processor 700, or may be derived based on a master secret key written into the processor's hardware at boot time. Figure 7B A SOC 730 (system on chip integrated circuit) with multiple agents (e.g., processors) is shown, each agent having a separate key domain. In one embodiment, SOC 730 includes a SOC master key 731, which is a hardware key unique to each boot cycle. SOC master key 731 is written to a write-only memory when booting, and is invisible to software at runtime. SOC master key 731 can be used by each agent 732A-732D to derive agent master keys 734A-734D. The derivation of agent master keys 734A-734D can be performed by applying a key derivation function to SOC master key 731 together with some additional inputs. In one embodiment, the additional input can be an identifier of a key domain associated with an agent, and the agent is associated with the agent master key to be generated. Any number of key derivation functions and techniques can be used. In one embodiment, agent master keys 734A-734D are derived from SOC master keys 731 when booting, and keys can be different in each boot cycle. In one embodiment, each agent master key 734A-734D is a physical copy of a single logical agent master key that is shared by all agents.

[0087] The agent master keys 734A-734D may be used to generate agent keys 736A-736D. In one embodiment, each agent 732A-732D is an application processor within SOC 730, although address signature generation and authentication are possible for other types of processors. For example, each agent 732A-732D may be Fig. 7A 736A-736D of processor 700 or one of processor core 710. The agent key 736A-736D of each agent may include the key in the key box 701 shown for execution core 110. Like the key of key block 701, some of the agent keys 736A-736D in each agent may be global keys, while other keys are context specific keys. Some of the agent keys 736A-736D may be used exclusively with instruction addresses, while other agent keys may be used exclusively with data addresses. Some of the agent keys 736A-763D may be general keys for signing common data. The agent keys 736A-736D may be enabled or disabled based on each agent, or a single key may be enabled or disabled. In one embodiment, the agent keys 736A-736D may include a key dedicated to the use of an agent of a specific execution level. In addition, the agent keys 736A-736D include one or more kernel specific keys that are automatically enabled for kernel mode processes and can be manually disabled by kernel mode processes. In one embodiment, the corresponding proxy key 736A-736D can be configured to be the same in all agents 732A-732D, and derived from a physical copy of the same logical key. However, in one embodiment, one or more of the proxy keys 736A-736B can be configured as a proxy-specific key, which can be used to generate a signature that can be authenticated only by the same agent. For example, a security processor, such as a security element or a secure area processor, can be one of the agents 732A-742B, and can have a set of proxy-specific keys. The security processor can execute a separate security processor operating system to manage the process executed on the security processor. The security processor can support the signature and authentication instructions described herein, and the process executed on the security processor can implement the address and data signature technology described herein. In one embodiment, the process executed on the security processor does not share a key, and each process uses a process-specific key to perform signature and authentication.

[0088] In addition to agent-specific key domains, runtime key diversification techniques can be used when generating keys for signing and authentication, such as Figure 8 shown.

[0089] Figure 8A method 800 of runtime key diversification according to one embodiment is shown. Runtime key diversification can be performed by a process that generates a signature to further strengthen the generated signature for attack. Different processes can use different diversification techniques, with user mode processes using different techniques than kernel mode processes.

[0090] The method 800 begins when a process is to generate a pointer for a function, a return address, an indirect jump, a data structure, or another pointer using an address signature (block 801). The method 800 also includes selecting a key for generating a signature for the pointer (block 802). The method 800 also includes diversifying the selected key using key diversification data (block 803).

[0091] The key diversification data used may be variable, and the techniques used to diversify the keys may also be variable. For example, the key and key diversification data may be provided to the key derivation function. In one embodiment, the diversification data may be XORed with the selected key. When authenticating a signature, the same key diversification data used to generate the signature is used to authenticate the signature. Diversification may be performed in a variety of different ways. Address diversification may be used, where the signature is diversified with its address. Any address-diversified signed pointer previously stored at a given address may be replayed at the same address. Type diversification may also be used, where the signature is diversified according to the type hierarchy of the pointer or the class to which the pointer belongs. Alternatively, diversification may not be used, which allows non-diversified pointers signed with the same key to be freely replaced with each other. In one embodiment, in the case where the same key is used with the same diversification data for different use cases, additional pointer management operations that modify the address to be signed in a predetermined manner may be applied. Different management operations or different management values ​​may be used to distinguish use cases. Management operations may be reversed before authentication.

[0092] The use of different types of diversification enables fine-grained control flow integrity, which minimizes the number of branch targets that are considered valid at a given branch site. In addition, different diversification techniques can be used to restrict the execution of certain types of code to certain execution domains. For example, code generated by a just-in-time (JIT) compiler can be restricted so that the signature generated by the code will only be considered valid by other JIT-compiled code.

[0093] In one embodiment, method 800 also includes determining whether the process is a kernel mode process (box 804). If the process is not a kernel mode process (box 804, "No") (e.g., a user mode process), method 800 includes causing the process to sign the address of the pointer using a diversified key (box 808). If the process is a kernel mode process (box 804, "Yes"), method 800 includes causing the processor to determine whether the pointer is for user mode (805). If the pointer is for user mode (box 805, "Yes"), method 800 includes causing the processor to, for example, disable the pointer. Fig. 7A 800 , the processor may use the kernel key to automatically diversify the signature key (block 807). After either block 806 or block 807, method 800 includes causing the processor to sign the address of the pointer using a diversified key (block 808), which was diversified at block 803 and may be further diversified at block 807.

[0094] In one embodiment, some signature and authentication use cases have dedicated keys, while some keys are used for multiple related use cases. In addition, some types of keys may have subgroups that are only available in the execution level of higher privileges. For example, a first group of keys may be made available to a process executed at the lowest execution level, such as a user mode process, while a process executed at a higher privilege execution level, such as a kernel mode process, may access the first group of keys and an additional second group of keys. In one embodiment, a higher execution level process uses a higher execution level key by default, and may selectively enable or disable keys for lower execution level processes, for example, to generate signatures that can be authenticated as valid by lower execution level processes. However, when a higher execution level process enables the use of lower level keys, some processor operations are disabled. For example, in one embodiment, when lower level keys are enabled, a high execution level process cannot be interrupted. In one embodiment, the group of higher execution level keys is a supplement to and separate from the one or more kernel keys that are automatically enabled when a kernel process is executing.

[0095] Figure 9A-9C A system for key diversification and data structure protection according to embodiments described herein is shown. Fig.9A A key derivation system 900 is shown for use with a signature generation and authentication unit as described herein. Fig. 9B A system 950 is shown that uses diversified keys to protect the contents of a data structure stored in memory. Fig. 9CA system 960 is shown for signing a key data structure to prevent impersonation in a data-only attack.

[0096] like Fig.9A As shown, key derivation system 900 includes a key derivation function (KDF 910) which, in one embodiment, accepts context 902, key 904, and diversification data 906 as inputs and outputs a derived key 914. In one embodiment, key 904 may be a master key such as Figure 7B The derived key 914 may be any one of the proxy keys 736A-736D, including Fig. 7A The derived key 914 may be applied to the pointer value 912 via the encryption algorithm 920 to generate a signed address 930. The signed address may be appended to the address to generate the signed address. Alternatively, the signed address may instead be a generic signature stored in the signature field of the data structure, as shown below Fig. 9C Further described in .

[0097] like Fig. 9B As shown, a system 950 of diversified keys can be used to protect the contents of data structures stored in memory. Exemplary data structures that can be protected include thread state structures of dormant or waiting threads stored in memory when those threads are suspended. When a thread is in a dormant or waiting state, or when an interrupt or exception occurs during thread execution, the thread state of the thread can be stored in memory. The thread state can include details such as the execution state of the thread (e.g., register values) and the program counter or instruction pointer associated with the thread. When a thread is sent to a dormant or waiting state, sensitive portions of the thread state can be signed by the processor before the thread state is stored in memory. When the thread is resumed, those pointers to the thread state can be authenticated to ensure that the thread state has not been manipulated when the thread is in a waiting or dormant state. Once the thread state is authenticated, the thread state can be restored to the processor and thread execution can be resumed.

[0098] In addition to pointers in saved thread state, function pointers in data structures can also be protected. For example, function pointers in method lists, pointers to code blocks, or pointers in method caches can all be protected.

[0099] In one embodiment, system 900 includes a data structure 952 to be protected, wherein the data structure includes multiple pointers (pointer A-pointer D). The pointer can be a function pointer, a data pointer, or a pointer of any other type. In one embodiment, the pointer stores execution state, including register values. Exemplary register values ​​include link register (LR), frame pointer (FP), stack pointer (SP), program counter (PC), and current program status register (CPSR). Some or all of the exemplary register values ​​can be signed when stored in the memory and authenticated before being restored to the processor.

[0100] The system 900 also includes one or more keys 954. In one embodiment, a single key may be used to sign each pointer. In one embodiment, a different key is used to sign each pointer. In such an embodiment, a specific key may be associated with different pointers. In addition, one or more diversifications 956 may be used to diversify the keys used to sign pointer addresses. In one embodiment, diversification is performed at runtime using constants or context-specific data. Keys 954 and diversifications 956 may be used to generate signed addresses 958A-958D for the pointers, where the signatures are, for example, Figure 2 The M-bit memory location or register 220 is integrated into the pointer value in the manner shown.

[0101] In one embodiment, specific keys associated with specific pointers and specific diversification data used on those keys may be encoded and versioned. For a given pointer authentication ABI version, specific pointers, keys, and diversification data to be used by system libraries may be specified. Third-party programs that support address and data signing and authentication may determine which pointers to sign and how to sign them based on the pointer authentication ABI version. Third-party binaries that are compatible with older and outdated versions may be conditionally downgraded. In addition, program code may be future-proofed by configuring it to support a released but not yet enabled pointer authentication ABI version. Program code will continue to run in the manner specified by the current ABI version, and then behavior may be seamlessly switched to that version when the new ABI version becomes active on the system. See below for more information. Fig.11 and Fig.12 Describes additional details about pointer ABI versioning.

[0102] like Fig. 9CAs shown, key signature system 960 can be applied to data structure to prevent counterfeiting in pure data attack. Due to the interdependence of signatures generated for pointer values, authenticated pointer chain (pointer E-pointer H) can be used to prevent any pointer in the pointer list in replacement data structure 962. Although four pointers are shown, the chain can include any number of pointers. In one embodiment, signature 969 is applied to the field in data structure 962 as an additional mechanism for authentication. One or more keys 964 can be used to generate signatures, which are used to generate signed addresses 968A-968D of pointers, wherein initial value 966 is used as key diversification or key whitening data. In one embodiment, initial value 966 is a predetermined constant value, which is known to the process of authenticating data structure 962. For example, initial value 966 can be the virtual address of data structure 962.

[0103] An initial signed address 968A may be generated for a first pointer (pointer E), wherein one of the one or more keys 964 used to generate the signed address 968A is diversified or whitened using the initial value 966. A set of hash functions 967A-967D may then be used to generate the diversified or key whitened data when generating subsequent signed addresses 968B-968D. For example, a hash value may be derived by applying the hash function 967A to the address of the first pointer, the signed address 968A generated for the first pointer, or some combination of the first pointer and the first signed address 968A. The resulting hash value may then be used as an input to an encryption algorithm used to generate a signed address 968B for a second pointer (pointer F). In one embodiment, a hash value for generating a second signed address 968B may also be derived based in part on the initial value 966 or some predetermined modification of the initial value. This loop may continue for each successive pointer (pointer G, pointer H, etc.) and each successive signed address (signed address 968C, signed address 968D, etc.), where these signed addresses are generated based on the pointer value, a key, and a hash value derived based on a previous pointer, a signed address of a previous pointer, or a specified combination of hash values ​​used to generate the signed address of a previous pointer. The specific formula used to protect a given data structure may vary based on the pointer authentication ABI version and may change periodically. After a signed address is generated for each pointer or a predetermined subset of pointers in data structure 962, signature 969 is generated based on using hash function 967D and some predetermined combination of hash values ​​of a previous signed pointer, a signed address of a previous signed pointer, or a signed address of a previous signed pointer used to generate the signed address of a previous signed pointer. This signature generation chain can be used to prevent replacement of any particular signed pointer with a signed pointer from a different data structure, because due to the interdependency of the signatures used within data structure 962, replacement or modification of any one pointer will be detected during authentication, even a pointer with a signature that could otherwise be validly generated.

[0104] use Figure 9A-9C Exemplary data structures that can be protected by the technology are shown in Tables 1 and 2 below. Table 1 shows an exemplary jump buffer that can be used by a setjmp, longjmp instruction combination. Table 2 shows an exemplary thread state structure. The data structures shown are exemplary and not limiting of all embodiments, because the jump buffer and thread state structures can vary across platforms and processor architectures. Each structure stores execution state information in memory, and an attacker may attempt to manipulate this information to change the control flow of the executing thread.

[0105] Table 1 - Jump buffer for Setjmp / Longjmp commands

[0106]

[0107] The exemplary jump buffer shown in Table 1 comprises a program counter, a link register, a stack pointer, a program status register preserved and an additional execution status register. The setjmp instruction can sign the selected value of the jump buffer when preserving the jump location and execution status, and the longjmp instruction can authenticate the selected value when loading from the jump buffer. In one embodiment, only a subset of the registers of the jump buffer are signed and authenticated, for example, a subset of the register set is considered to be sensitive because they are return addresses or point to the region containing the return address of the memory. For example, some combinations of program counter, link register, stack pointer, frame pointer and / or the program status register preserved can be signed.

[0108] In one embodiment, each register value is independently signed using a selected key and diversified using selected data. For example, Fig. 7A One of the instruction keys 704 of the data keys 705 can be used to sign the link register, and one of the data keys 705 can be used to sign other sensitive registers. The value of one of the registers can be used as diversified data to generate a signature for signing the register value. In one embodiment, a constant value is used as diversified data to generate a signature for the stack pointer value, and the value of the stack pointer is used as diversified data for other sensitive registers. In one embodiment, context-specific versions of the instruction key and the data key are used to sign the registers of the jump buffer so that threads that are only executed under the same context can effectively authenticate the generated signature.

[0109] Table 2 - Thread state structure

[0110]

[0111] The exemplary thread state structure, frame pointer, link register, stack pointer and program counter shown in Table 2 are opaque to the viewer unless the signature is stripped from the register value using the correct key. The thread state structure can be used by the thread_get / set API of the thread in the current process or other processes (such as tools or debuggers). In addition, the kernel can manipulate the thread state structure of the thread during exception handling. Since the thread state structure can be used by multiple processes, a key independent of the context can be used to sign sensitive register values. Threads that can legally view or modify sensitive opaque registers can authenticate register values, strip signatures from register values, manipulate these values ​​as needed, and store these values ​​in hardware or re-sign these values ​​when the thread state will be written back to the memory. In one embodiment, register diversification is performed using a string discriminator based on register names, wherein PC and LR register values ​​are signed using an instruction key independent of the process, and SP and FP registers are signed using a data key independent of the process.

[0112] In one embodiment, the opaque_flags field replaces the padding data used in the thread state data structure known in the art. The opaque_flags field may include a flag describing the current format for the structure. Various types of flags may be set within the opaque flags field, including a no_ptr_auth flag and an lr_context_signed indicating that the thread state includes an unsigned register state. The no_ptr_auth flag may be set by the kernel when the subject or receiver thread of the thread state is executed with the key for JOP protection disabled and pointer authentication should not be performed. The no_ptr_auth flag cannot be effectively set for threads executed with the JOP protection key enabled. The lr_content_signed flag indicates that the opaque_lr value includes a link register value that was found to have been signed with a context-specific key and not re-signed with a context-independent key. If the link register value is determined to contain a non-pointer value, for example, if the thread is using the link register as a temporary register when the thread state is captured, the lr_context_signed key may also be set. In one embodiment, when the lr_context_signed flag is set, the value of the link register is verified to ensure that the link register value is non-pointer or actually signed to prevent an attacker from fraudulently setting the flag. The link register can be verified by executing a strip instruction on the link register. If the link register is unchanged after the strip instruction, the link register is actually not signed and the lr_context signed flag is ignored.

[0113] In one embodiment, a special subroutine is provided to convert the user mode thread state to an unsigned representation that can be manipulated by the kernel. Interrupts can be disabled on the processor, and while interrupts are disabled, user mode keys can be enabled and used to authenticate the signature of opaque register values. If the opaque register values ​​are authenticated, the signature can be stripped from the register values, and unsigned values ​​can be written to the registers, where these values ​​can be manipulated by the kernel.

[0114] The specific data structures described are exemplary, and the techniques provided by the embodiments described herein can be used to protect data in any data structure. Additional exemplary data that can be protected include security attributes, task virtual memory mappings, code signing flags, or other data that may be tampered with by an attacker.

[0115] Figure 10A-10B The use of pointer value signatures to detect malicious or unintentional memory corruption is shown. Fig. 10A A stack 1000 is shown including a signed stack cookie for detecting stack overflow attacks that modify vulnerable pointers on the stack. Fig. 10B A data structure 1010 is shown that includes memory pointers that may be signed to detect software defects that result in memory corruption.

[0116] like Fig. 10A As shown, the technology of using stack cookies to detect overflow attacks can be enhanced by using signed stack cookies. Stack 1000 includes stack utilization buffer 1002, and attackers can use this stack utilization buffer to attempt buffer overflow attacks to rewrite the stack memory containing vulnerable pointer 1006 or register data (such as function pointer parameters or subroutine return addresses). A countermeasure to buffer overflow attacks is to store stack security cookies (also referred to as canaries) in front of the vulnerable pointer when calling a function. Because if the overflow of the stack utilization buffer occurs, the function writes data on the stack data in a predefined order, so the security cookie is overwritten on the way to overwrite the vulnerable pointer 1006. Before the function returns, the cookie can be checked against the certified version of the security cookie. If the security cookie does not match, it is assumed that the buffer has overflowed, and the process can be suspended and / or other appropriate actions can be taken. However, it is possible to trigger an overflow attack in a way that deceives the value of a conventional stack cookie.

[0117] As a countermeasure to stack cookie spoofing exploits, one embodiment provides a method to convert a subroutine preamble and epilogue (such as Figure 4BThe prologue and epilogue shown in ) are configured to sign and authenticate the stack cookie inserted to protect the vulnerable pointer on the stack. The subroutine prologue can be configured to insert the signed stack cookie 1004 into the stack in the rewrite path between the buffer overflow (or underflow) and the vulnerable pointer data stored in the stack. The epilogue can then authenticate the signed stack cookie 1004 before returning to the caller of the subroutine. The signed stack cookie 1004 resists attacks that attempt to copy the cookie value in the data used to overflow into the vulnerable pointer. Even if the value of the signed stack cookie 1004 can be predicted by an attacker, it is unlikely that the attacker will apply the correct signature to the cookie.

[0118] In one embodiment, signing and authentication can be performed transparently to program code and can be used in scenarios where ROP protection is otherwise disabled. For example, a subset of keys can be disabled when executing traditional code, but special traditional security keys that are not otherwise used when executing traditional code can remain enabled for signing and authenticating stack cookies. In one embodiment, the stack cookie signature can be generated based on one or a combination of stack pointer values, program counter values, or other data that explicitly links the signed stack cookie to the stack frame in which the cookie is placed. In addition, signed stack cookies can be more efficient than conventional stack cookies, in some specific implementations, the values ​​of which are generated using global data that is slower than register data accesses used to generate and sign signed stack cookie 1004.

[0119] like Fig. 10B As shown, pointers within generic data structures may be signed as a generic mechanism for memory integrity protection. Specifically, signed pointers may be used in certain data structures to detect the presence of memory corruption faults that may be unrelated to malicious attacks. For example, the std::vector template data structure 1010 may be modified to use a signed start pointer 1012 and a signed end pointer 1014 that may be used to detect the incidence of memory corruption faults. Pointer signatures may be used to detect memory corruption in other similar data structures and are not limited to the std::vector template data structure 1010 shown. Any stack-based or dynamically allocated data structure may use signed memory boundary pointers to detect potential memory corruption within or adjacent to a data structure.

[0120] When using signed boundary pointers such as signed start pointer 1012 and signed end pointer 1014, memory writes that cause overflow or underflow of data structures will rewrite boundary pointers. Before accessing data in a data structure, one or more boundary pointers of the data structure can be verified. If any boundary pointer of the data structure is invalid, the data in the data structure may be damaged by software defects or malicious attacks. In addition to edge boundary pointers, pointers in the data structure may also be signed. In one embodiment, additional pointers that are not used in other ways can be inserted into the data structure and signed. Because boundary pointers are not used in other ways, operating system data structures accessed by traditional processes may also use signed boundary pointers, wherein the boundary pointers are signed and authenticated using traditional security keys.

[0121] In one embodiment, the address referenced by the boundary pointer may be set to a known value, such as a value associated with the address of a data structure, a value associated with the address of the boundary pointer, or a context identifier of the current process. In addition to signature verification, the address value stored in the boundary pointer may also be verified.

[0122] Fig.11 A system 1100 for pointer-authenticated ABI versioning according to one embodiment is shown. The pointer-authenticated ABI versioning scheme can be used to enable specific details of signed or unsigned elements of system libraries to change between revisions of an operating system. For example, a pointer-authenticated ABI version tree 1102 can be defined where, for each ABI version, a specific set of structures in a software development kit (SDK) contains signed or unsigned function pointers.

[0123] For example, the first SDK version (Ver_0 1110) that supports signed pointers may specify a specific group of structures in the SDK that contain signed pointers (SDK_Signed_Pointer 1112) and a specific group of structures in the SDK that contain unsigned pointers (SDK_Unsigned_Pointer 1114). Changing the group of structures in the SDK that contain signed function pointers (or other types of signed pointers) is an ABI breaking change, and will typically only occur during an operating system revision. However, if an exploit is discovered and applied against an existing pointer certification ABI version, or another event occurs that warrants an ABI change, it is desirable to be able to revise the ABI version and push a hot fix without requiring a major software version update.

[0124] Therefore, a second SDK version (Ver_1 1120) may be released that specifies different signed pointer groups (SDK_Signed_Pointer 1122) and different unsigned pointer groups (SDK_Unsigned_Pointer 1124) used within data structures provided by the SDK. In addition to changing signed or unsigned pointers, the way pointers are signed may also be changed. For example, between pointer authentication ABI versions, different keys and / or different diversification or key whitening data may be specified for use when signing and authenticating pointers, data structures, or other SDK elements that may be signed and authenticated. Execution of a system binary with a pointer authentication ABI mismatch may not be allowed because the pointer authentication ABI versions of the system binary and the library should always match. A mismatch in the pointer authentication ABI between the system binary and the system library may indicate that the system has been compromised.

[0125] In one embodiment, third-party applications designed and compiled to support pointer authentication are compiled for a specific pointer authentication ABI version. If a third-party application is executed on a system with a mismatched pointer authentication ABI, address signing can be disabled for the application, allowing the application to execute without crashing, although the application may execute in a slightly less secure state. For third-party applications delivered via online application and media stores, some embodiments provide techniques for dynamically compiling and delivering a version of the application that matches the pointer authentication ABI version of the target device.

[0126] Fig.12 A system 1200 for pointer authentication ABI versioning via bitcode according to one embodiment is shown. In one embodiment, dynamic pointer ABI versioning can be enabled for third-party applications submitted in bitcode format. Such applications can be dynamically compiled for the target OS and pointer version on which the application will be executed.

[0127] For example, a developer may develop an application using one or more programming languages, and utilize a modular compilation tool chain including one or more front-end compilers (e.g., a first language front-end compiler 1202, a second language front-end compiler 1203, and other front-end compilers 1204) and link the application through a linker 1205 to compile the application. The linker 1205 may communicate with an intermediate language bit code optimizer 1206 that outputs an intermediate language bit code 1215. The application may then be provided to one or more application store servers 1220 in the form of the intermediate language bit code 1215 rather than a fully compiled version. The intermediate language bit code 1215 may then be stored in a non-volatile memory 1221 within or coupled to the application store server 1220.

[0128] In one embodiment, the intermediate language bitcode 1215 includes embedded metadata that allows the application store server 1220 to generate bitcode for a set of signed pointers in multiple ABIs, thereby allowing pointer signing and authentication to remain enabled even when deployed back to older devices. For example, the application store server can use the embedded metadata to generate application bitcode 1224A-122C representing different versions of the same application, where the different versions support different pointer authentication ABI versions. The different bitcodes can then be compiled by the backend compiler 1222 and provided to different devices (e.g., device 1232, device 1234, device 1236), where the different devices each have a different operating system version that otherwise requires a different pointer authentication ABI version to enable pointer signing and authentication.

[0129] Embodiments described herein include one or more application programming interfaces (APIs) in an environment, wherein the calling program code interacts with other program codes called by one or more programming interfaces. Various function calls, messages, or other types of calls may also include various parameters, which may be transmitted via the API between the calling program and the called code. In addition, the API may provide the calling program code with the ability to use data types or categories defined in the API and implemented in the called program code.

[0130] An API allows developers of API-calling components (which may be third-party developers) to utilize specified features provided by an API-implementing component. There may be one API-calling component or there may be more than one such component. An API may be a source code interface provided by a computer system or a program library to support service requests from an application. An operating system (OS) may have multiple APIs to allow applications running on the OS to call one or more of those APIs, and a service (e.g., a program library) may have multiple APIs to allow applications using the service to call one or more of those APIs. An API may be specified in a programming language that can be interpreted or compiled when building an application.

[0131] In some embodiments, the API implementation component may provide more than one API, each API providing a different view or having different aspects that access different aspects of the functionality implemented by the API implementation component. For example, one API of the API implementation component may provide a first set of functions and may be exposed to third-party developers, and another API of the API implementation component may be hidden (not exposed) and provide a subset of the first set of functions, and also provide another set of functions, such as testing or debugging functions that are not in the first set of functions. In other embodiments, the API implementation component itself may call one or more other components via the underlying API, thereby being both an API calling component and an API implementation component.

[0132] The API defines the language and parameters used by the API calling component when accessing and using the specified features of the API implementation component. For example, the API calling component accesses the specified features of the API implementation component through one or more API calls or references exposed by the API (for example, implemented by function or method calls), and uses parameters to pass data and control information via API calls or references. The API implementation component can return values ​​through the API in response to API calls from the API calling component. Although the API defines the syntax and results of API calls (for example, how to cause API calls and what API calls can do), the API may not reveal how the API call completes the function specified by the API call. Various API calls are transmitted via one or more application programming interfaces between the call (API calling component) and the API implementation component. Transmitting API calls may include issuing, initiating, referencing, calling, receiving, returning or responding to function calls or messages; in other words, the transmission can describe the actions of either the API calling component or the API implementation component. Function calls or other references of the API can send or receive one or more parameters through parameter lists or other structures. A parameter may be a constant, a key, a data structure, an object, an object class, a variable, a data type, a pointer, an array, a list, or a pointer to a function or method or another way of referencing data or other items to be passed via an API.

[0133] In addition, data types or classes can be provided by the API and implemented by the API implementation component. Therefore, the API calling component can use the definitions provided in the API to declare variables, use pointers to such types or classes, and use or instantiate constant values ​​of such types or classes.

[0134] Typically, API can be used to access the services or data provided by the API implementation component, or to start the operation or calculation provided by the API implementation component. By way of example, the API implementation component and the API call component can each be any one of an operating system, a library, a device driver, an API, an application, or other modules (it should be understood that the API implementation component and the API call component can be modules of the same or different types). In some cases, the API implementation component can be implemented at least partially in firmware, microcode, or other hardware logic components. In some embodiments, the API can allow client programs to use the services provided by the software development kit (SDK) library. In other embodiments, the application or other client programs can use the API provided by the application framework. In these embodiments, the application or client program can be combined with the call to the function or method provided by the SDK and provided by the API, or use the data type or object defined in the SDK and provided by the API. In these embodiments, the application framework can provide a main event loop for the program, which responds to various events defined by the framework. The API allows the application to specify events and responses to events using the application framework. In some specific implementations, API calls can report the capabilities or status of hardware devices to applications, including capabilities or status related to aspects such as input capabilities and status, output capabilities and status, processing capabilities, power status, storage capacity and status, communication capabilities, etc., and the API can be partially implemented by firmware, microcode, or other low-level logic components that are partially executed on hardware components.

[0135] The API calling component can be a local component (i.e., on the same data processing system as the API implementing component) or a remote component (i.e., on a data processing system different from the API implementing component), which communicates with the API implementing component through the API via a network. It should be understood that the API implementing component can also act as an API calling component (i.e., it can make API calls to APIs exposed by different API implementing components), and the API calling component can also act as an API implementing component by implementing APIs exposed to different API calling components.

[0136] The API may allow multiple API-calling components written in different programming languages ​​to communicate with the API-implementing component (so that the API may include features for converting calls and returns between the API-implementing component and the API-calling component); however, the API may be implemented in a specific programming language. In one embodiment, the API-calling component may call APIs from different providers, such as one set of APIs from an OS provider and another set of APIs from a plug-in provider, and another set of APIs from another provider (e.g., a provider of a software library) or a creator of another set of APIs.

[0137] Fig.13 is a block diagram illustrating an exemplary API architecture that may be used in some embodiments of the present invention. Fig.13 As shown in , the API architecture 1300 includes an API implementation component 1310 (e.g., an operating system, library, device driver, API, application, software, or other module) that implements an API 1320. The API 1320 specifies one or more functions, methods, classes, objects, protocols, data structures, formats, and / or other features of the API implementation component that can be used by an API calling component 1330. The API 1320 may specify at least one calling convention that specifies how functions in the API implementation component receive parameters from the API calling component and how functions return results to the API calling component. The API calling component 1330 (e.g., an operating system, library, device driver, API, application, software, or other module) makes an API call through the API 1320 to access and use the features of the API implementation component 1310 specified by the API 1320. The API implementation component 1310 may return a value to the API calling component 1330 through the API 1320 in response to the API call.

[0138] It should be understood that the API implementation component 1310 may include additional functions, methods, classes, data structures, and / or other features that are not specified by the API 1320 and are not available to the API calling component 1330. It should be understood that the API calling component 1330 may be on the same system as the API implementation component 1310, or may be located remotely and access the API implementation component 1310 using the API 1320 over a network. Fig.13 A single API calling component 1330 is shown interacting with API 1320 , but it should be understood that other API calling components written in a different language than API calling component 1330 (or the same language) may use API 1320 .

[0139] The API implementation component 1310, API 1320, and API calling component 1330 may be stored in a machine-readable medium, which includes any mechanism for storing information in a form readable by a machine (e.g., a computer or other data processing system). For example, a machine-readable medium includes a disk, an optical disk, a random access memory, a read-only memory, a flash memory device, etc.

[0140] Figure 14A-14B is a block diagram of an exemplary API software stack 1400, 1410 according to an embodiment. Fig.14AAn exemplary API software stack 1400 is shown, where an application 1402 can use a service API to make calls to service A or service B and use an OS API to call an operating system 1404. In addition, service A and service B can call the operating system 1404 using several OS APIs.

[0141] Fig. 14B An exemplary software stack 1410 is shown, including application 1, application 2, service 1, service 2, and operating system 1404. As shown, service 2 has two APIs, one of which (service 2 API 1) receives calls from application 1 and returns values, and the other (service 2 API 2) receives calls from application 2 and returns values. Service 1 (e.g., can be a software library) makes calls to OS API 1 and receives returned values, and service 2 (e.g., can be a software library) makes calls to both OS API 1 and OS API 2 and receives returned values. Application 2 makes calls to OS API 2 and receives returned values.

[0142] Additional Exemplary Computing Devices

[0143] Fig.15 1500 is a block diagram of a device architecture 1500 for a mobile or embedded device according to an embodiment. The device architecture 1500 includes a memory interface 1502, a processing system 1504 including one or more data processors, an image processor and / or a graphics processing unit, and a peripheral device interface 1506. As used herein, the term "processor" means any type of computing element, such as but not limited to a microprocessor, a microcontroller, a complex instruction set computing (CISC) microprocessor, a reduced instruction set (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, or any other type of processor or processing circuit. Various components can be coupled via one or more communication buses or signal lines. Various components can be separate logic components or devices or can be integrated in one or more integrated circuits, such as a system-on-chip integrated circuit. The memory interface 1502 can be coupled to a memory 1550, which can include a high-speed random access memory such as a static random access memory (SRAM) or a dynamic random access memory (DRAM) and / or a non-volatile memory, such as but not limited to a flash memory (e.g., NAND flash, NOR flash, etc.).

[0144] Sensors, devices, and subsystems may be coupled to the peripheral device interface 1506 to facilitate multiple functions. For example, a motion sensor 1510, a light sensor 1512, and a proximity sensor 1514 may be coupled to the peripheral device interface 1506 to facilitate mobile device functions. There may also be one or more biometric sensors 1515, such as a fingerprint scanner for fingerprint recognition or an image sensor for facial recognition. Other sensors 1516 may also be connected to the peripheral device interface 1506, such as a positioning system (e.g., a GPS receiver), a temperature sensor, or other sensing devices to facilitate related functions. A camera subsystem 1520 and an optical sensor 1522 (e.g., a charge coupled device (CCD) or a complementary metal oxide semiconductor (CMOS) optical sensor) may be utilized to facilitate camera functions, such as taking pictures and video clips.

[0145] Communication functionality may be facilitated by one or more wireless communication subsystems 1524, which may include radio frequency receivers and transmitters and / or optical (e.g., infrared) receivers and transmitters that may be configured to receive or transmit data packets and / or data streams from a remote source. The specific design and implementation of the wireless communication subsystem 1524 may depend on the communication network over which the mobile device is intended to operate. For example, a mobile device including the illustrated device architecture 1500 may include a wireless communication subsystem 1524 designed to operate over a GSM network, a CDMA network, an LTE network, a Wi-Fi network, a Bluetooth network, or any other wireless network. Specifically, the wireless communication subsystem 1524 may provide a communication mechanism in which a media playback application may retrieve resources from a remote media server or retrieve scheduled events from a remote calendar or event server.

[0146] Audio subsystem 1526 may be coupled to speaker 1528 and microphone 1530 to facilitate voice-enabled functions such as voice recognition, voice replication, digital recording, and telephony. In the smart media devices described herein, audio subsystem 1526 may be a high-quality audio system including support for virtual surround sound.

[0147] I / O subsystem 1540 may include touch screen controller 1542 and / or other input controller 1545. For computing devices that include a display device, touch screen controller 1542 may be coupled to a touch-sensitive display system 1546 (e.g., a touch screen). Touch-sensitive display system 1546 and touch screen controller 1542 may detect contact and motion or pressure using, for example, any of a variety of touch and pressure sensing technologies, including but not limited to capacitive, resistive, infrared, and surface acoustic wave technologies, as well as other proximity sensor arrays or other elements for determining one or more points of contact with touch-sensitive display system 1546. Display output of touch-sensitive display system 1546 may be generated by display controller 1543. In one embodiment, display controller 1543 may provide frame data to touch-sensitive display system 1546 at a variable frame rate.

[0148] In one embodiment, a sensor controller 1544 is included to monitor, control, and / or process data received from one or more motion sensors 1510, light sensors 1512, proximity sensors 1514, or other sensors 1516. The sensor controller 1544 may include logic to interpret the sensor data to determine the occurrence of one of a plurality of motion events or activities by analyzing the sensor data from the sensors.

[0149] In one embodiment, the I / O subsystem 1540 includes other input controllers 1545 that may be coupled to other input / control devices 1548 such as one or more buttons, rocker switches, thumb wheels, infrared ports, USB ports, and / or pointer devices such as a stylus or controls / devices such as up / down buttons for volume controls for the speaker 1528 and / or microphone 1530.

[0150] In one embodiment, memory 1550 coupled to memory interface 1502 may store instructions for an operating system 1552, including portable operating system interface (POSIX) compliant and non-compliant operating systems or embedded operating systems. Operating system 1552 may include instructions for handling basic system services and for performing hardware-related tasks. In some specific implementations, operating system 1552 may be a kernel.

[0151] The memory 1550 may also store communication instructions 1554 to facilitate communication with one or more additional devices, one or more computers and / or one or more servers, such as obtaining network resources from a remote network server. The memory 1550 may also include user interface instructions 1556, including graphical user interface instructions to facilitate graphical user interface processing.

[0152] In addition, the memory 1550 may store sensor processing instructions 1558 to facilitate sensor-related processing and functions; phone instructions 1560 to facilitate processes and functions related to phone calls; instant messaging instructions 1562 to facilitate processes and functions related to electronic message processing; web browser instructions 1564 to facilitate processes and functions related to web browsing; media processing instructions 1566 to facilitate processes and functions related to media processing; location service instructions including GPS and / or navigation instructions 1568 and Wi-Fi-based location instructions to facilitate location-based functionality; camera instructions 1570 to facilitate processes and functions related to cameras; and / or other software instructions 1572 to facilitate other processes and functions, such as security processes and functions and system-related processes and functions. The memory 1550 may also store other software instructions, such as web video instructions to facilitate processes and functions related to web videos; and / or web shopping instructions to facilitate processes and functions related to web shopping. In some specific implementations, the media processing instructions 1566 are divided into audio processing instructions and video processing instructions to facilitate processes and functions related to audio processing and processes and functions related to video processing, respectively. A mobile device identifier, such as an International Mobile Equipment Identity (IMEI) 1574 or similar hardware identifier may also be stored in memory 1550 .

[0153] Each of the instructions and applications identified above may correspond to an instruction set for performing one or more of the functions described above. These instructions need not be implemented as separate software programs, processes, or modules. Memory 1550 may include additional instructions or fewer instructions. In addition, various functions may be performed in hardware and / or software, including in one or more signal processing and / or application specific integrated circuits.

[0154] Fig.16 1600 is a block diagram of a computing system 1600 according to an embodiment. The computer system 1600 shown is intended to represent a series of computing systems (wired or wireless), including, for example, a desktop computer system, a laptop computer system, a tablet computer system, a cellular phone, a personal digital assistant (PDA) including a cellular PDA, a set-top box, an entertainment system or other consumer electronic device, an intelligent electrical appliance, or one or more specific implementations of an intelligent media playback device. Alternative computing systems may include more, less and / or different components. Computing system 1600 can be used to provide a server device that may be connected to a computing device and / or a computing device.

[0155] The computer system 1600 includes a bus 1635 or other communication device for communicating information, and a processor 1610 coupled to the bus 1635 that can process information. Although the computing system 1600 is illustrated as having a single processor, the computing system 1600 may include multiple processors and / or coprocessors. The computing system 1600 may also include a memory 1620, such as a random access memory (RAM) or other dynamic storage device coupled to the bus 1635. The memory 1620 may store information and instructions that can be executed by the processor 1610. The memory 1620 may also be used as a main memory to store temporary variables or other intermediate information during the execution of instructions by the processor 1610.

[0156] The computing system 1600 may also include a read-only memory (ROM) 1630 and / or other data storage device 1640 coupled to the bus 1635 that may store information and instructions for the processor 1610. The data storage device 1640 may be or include a variety of storage devices, such as a flash memory device, a magnetic disk, or an optical disk and may be coupled to the computing system 1600 via the bus 1635 or via a remote peripheral interface.

[0157] The computing system 1600 may also be coupled to a display device 1650 via bus 1635 to display information to a user. The computing system 1600 may also include an alphanumeric input device 1660, which includes alphanumeric and other keys, which may be coupled to the bus 1635 to send information and command options to the one or more processors 1610. Another user input device includes a cursor control 1670 device, such as a touch pad, mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 1610 and controlling cursor movement on the display device 1650. The computing system 1600 may also receive user input from a communicatively coupled remote device via one or more network interfaces 1680.

[0158] The computing system 1600 may also include one or more network interfaces 1680 to provide access to a network such as a local area network. The network interface 1680 may include, for example, a wireless network interface having an antenna 1685, which may represent one or more antennas. The computing system 1600 may include multiple wireless network interfaces, such as Wi-Fi and A combination of near field communication (NFC) and / or a cellular phone interface. The network interface 1680 may also include, for example, a wired network interface to communicate with a remote device via a network cable 1687, which may be, for example, an Ethernet cable, a coaxial cable, a fiber optic cable, a serial cable, or a parallel cable.

[0159] In one embodiment, the network interface 1680 may provide access to a local area network, for example by complying with the IEEE 802.11 standard, and / or the wireless network interface may provide access to a personal area network, for example by complying with the Bluetooth standard. Other wireless network interfaces and / or protocols may also be supported. In addition to or in lieu of communicating via a wireless LAN standard, the network interface 1680 may provide wireless communications using, for example, a time division multiple access (TDMA) protocol, a global system for mobile communications (GSM) protocol, a code division multiple access (CDMA) protocol, a long term evolution (LTE) protocol, and / or any other type of wireless communication protocol.

[0160] The computing system 1600 may also include one or more energy sources 1605 and one or more energy measurement systems 1645. The energy source 1605 may include an AC / DC adapter coupled to an external power source, one or more batteries, one or more charge storage devices, a USB charger, or other energy sources. The energy measurement system includes at least one voltage or current measurement device that can measure the energy consumed by the computing system 1600 over a predetermined time period. In addition, one or more energy measurement systems may be included to measure, for example, the energy consumed by a display device, a cooling subsystem, a Wi-Fi subsystem, or other commonly used or high energy consumption subsystems.

[0161] In some embodiments, the hash functions described herein may utilize dedicated hardware circuitry (or firmware) of the system (client device or server). For example, the function may be a hardware accelerated function. In addition, in some embodiments, the system may use functions that are part of a dedicated instruction set. For example, an instruction set may be used that is an extension of an instruction set architecture for a particular type of microprocessor. Thus, in one embodiment, the system may provide a hardware acceleration mechanism for performing cryptographic operations, thereby increasing the speed at which the functions described herein are performed using these instruction sets.

[0162] In addition, the hardware acceleration engine / function is contemplated to include any implementation in hardware, firmware, or a combination thereof, including various configurations that may include hardware / firmware integrated into the SoC as a separate processor, or included as a dedicated CPU (or core), or integrated into a co-processor on a circuit board, or contained on a chip on an expansion circuit board, etc.

[0163] It should be noted that the terms "approximately" or "substantially" may be used herein and may be interpreted as "as close to practical as possible", "within technical limitations", etc. Additionally, unless otherwise specified, the use of the term "or" indicates an inclusive or (e.g., and / or).

[0164] In the foregoing description, exemplary embodiments of the present disclosure have been described. It is apparent that various modifications may be made thereto without departing from the broader essence and scope of the present disclosure. Accordingly, the specification and the accompanying drawings are to be regarded as illustrative rather than restrictive. The specific details in the description and examples provided may be used anywhere in one or more embodiments. The various features of different embodiments or examples may be combined differently with some of the included features and other excluded features to accommodate a variety of different applications. Examples may include subject matter, such as methods, devices for performing the behavior of the method, at least one machine-readable medium including instructions, the instructions causing the machine to perform the behavior of the method when executed by the machine, or the actions of the device or system according to the embodiments and examples described herein. In addition, the various components described herein may be devices for performing the operations or functions described herein.

[0165] Embodiments described herein realize the interoperability between the process configured for pointer authentication and the process not configured for pointer authentication.Realizing the interoperability between such processes enables basic libraries such as system libraries to be compiled with pointer authentication, while enabling those libraries to still be used by processes that have not yet been compiled or configured to use pointer authentication.In one embodiment, interoperability is realized in the following manner: a copy of only a portion of the system library used by a process without authentication is placed in a separate area of ​​virtual memory, and this separate area of ​​virtual memory is mapped to those processes instead of the virtual memory containing the authenticated version of the system library.In addition, when context switching occurs between a process with pointer authentication and a process without pointer authentication, the authentication feature of the processor can be dynamically enabled or disabled.

[0166] Embodiments described herein also provide an authentication key mechanism that can use different authentication keys when kernel mode and user mode pointers are signed. The first group of keys is used to sign the user mode pointer, and different and / or additional keys can be used when the address of the kernel mode pointer is signed. In such embodiments, the user mode pointer that causes the attacker to sign in a certain way will not be effectively used in kernel mode. However, the kernel can sign the pointer that can be effectively used in user mode by temporarily disabling the use of kernel keys when signing the address used for user mode and / or enabling user mode keys.

[0167] The embodiments described herein also provide thread state signatures to ensure that the thread state of a dormant or waiting thread is not manipulated when the thread waits to resume execution. When a thread is in a dormant or waiting state, or when an interrupt or exception occurs during the execution of a thread, the thread state of the thread can be stored in a memory. The thread state may include details such as the execution state of the thread (e.g., register values) and a program counter or instruction pointer associated with the thread. When a thread is sent to a dormant or waiting state, sensitive portions of the thread state may be signed by the processor before the thread state is stored in the memory. When the thread is resumed, those pointers to the thread state may be authenticated to ensure that the thread state has not been manipulated when the thread is in a waiting or dormant state. Once the thread state is authenticated, the thread state may be restored to the processor and thread execution may be restored.

[0168] Embodiments described herein also provide pointer application binary interface (ABI) version control. The ABI version control scheme enables the specific details of the signed or unsigned elements of the system library to be changed between the major and minor version revisions of the operating system. The program code for signing the pointer or data structure in the system library can be annotated with a version number scheme associated with a set of specific signed or unsigned data structures and pointers. Third-party applications can be compiled for use for specific pointer authentication ABI versions, wherein during compilation, the third-party applications are compiled to know which system library pointers and data structures are expected to be signed. If a third-party application is executed on a system with mismatched pointer authentication ABI, address signatures can be disabled for the application, thereby allowing the application to execute without crashing, although the application can be executed in a slightly less secure state. It is not allowed to execute a system binary with a mismatch of pointer authentication ABI, because the pointer authentication ABI version of the system binary and the library should always match. The mismatch of the pointer authentication ABI between the system binary and the system library may indicate that the system has been compromised. In one embodiment, dynamic pointer authentication ABI version control can be enabled for third-party applications submitted in bit code format. Such applications may be dynamically compiled for the target OS and pointer version on which the application will be executed.

[0169] In addition, an embodiment of a system is described herein, the system comprising an integrated circuit, the integrated circuit comprising a memory for storing data and instructions and one or more processors coupled to the memory. Each of the one or more processors can be configured as an execution agent of the integrated circuit. The one or more processors can derive one or more agent master keys for use by one or more execution agents, the one or more agent master keys are derived from the master key of the integrated circuit, derive a set of signatures and authentication keys for use by one or more execution agents, the execution agent uses one or more of the signatures and authentication keys associated with the execution agent to sign the memory address of the pointer, store the pointer in the memory, and authenticate the pointer before executing the instruction associated with the pointer.

[0170] Another embodiment provides a non-transitory machine-readable medium storing instructions that cause at least one processor of a plurality of processors of a system-on-chip integrated circuit (SOC) to perform operations including deriving one or more proxy master keys for use by one or more of the plurality of processors of the SOC, wherein the one or more proxy master keys are derived from a master key of the SOC. The operations also include: deriving a set of signature and authentication keys for use by one or more of the plurality of processors; signing an address of a pointer using one or more of the signature and authentication keys; storing the pointer to a memory; and authenticating the pointer before executing instructions associated with the pointer.

[0171] An additional embodiment provides a method comprising, on a processor of an electronic device: generating a pointer; selecting a hardware-based key for generating a signature for the pointer; diversifying the hardware-based key using selected key diversification data to generate a diversified key; signing the value of an address within the pointer using the diversified key to generate a pointer signature, and verifying the pointer signature before invoking the address within the pointer using the processor.

[0172] In one embodiment, a system includes a memory for storing data and instructions and a processor coupled to the memory. The processor includes an execution core capable of switching between a first mode and a second mode. In the first mode, the execution core is used to authenticate the memory address via a signature associated with the memory address before executing the instruction associated with the memory address. In the second mode, the execution core is used to bypass the authentication of the memory address, and the processor is used to switch between the first mode and the second mode in response to the execution of the instruction taken from the memory.

[0173] One embodiment provides a non-transitory machine-readable medium storing instructions that cause a processor on a system-on-chip integrated circuit (SOC) to perform operations including authenticating a memory address at a processor of the system via a signature associated with the memory address prior to executing instructions associated with the memory address, the authentication being performed when the processor is in a first operating mode. The operations also include bypassing authentication of the memory address prior to executing instructions associated with the memory address when the processor is in a second operating mode, and causing the processor to switch between the first mode and the second mode in response to execution of instructions fetched from a memory.

[0174] One embodiment provides a non-transitory machine-readable medium storing instructions that cause one or more processors of a computing device to perform operations including loading a first process into a memory of the computing device. The first process is linked to a shared library stored on the computing device. The operations also include loading a second process into the memory of the computing device, wherein the second process is linked to a shared library stored on the computing device, and the second process includes a program code for authenticating a signature of an address of a pointer used by a program code of the second process. The program code is used to authenticate the signature using instructions provided by an instruction set architecture of one or more processors. The operations also include mapping a first portion of a shared library stored on the computing device to a first virtual memory address in an address space of the first process, mapping a second portion of the shared library to a second virtual memory address in an address space of the second process, wherein the second portion of the shared library is configured to authenticate the signature of an address of a pointer used by a program code of the shared library using instructions provided by the instruction set architecture of the one or more processors, configuring the one or more processors to enable signature authentication during a context switch to the second process, and configuring the one or more processors to disable signature authentication during a context switch to the first process.

[0175] One embodiment provides a method comprising: generating a pointer on a processor of an electronic device; selecting a hardware-based key to generate a signature for the pointer; diversifying the hardware-based key using the selected key diversification data to generate a diversified key; signing the value of an address within the pointer using the diversified key to generate a pointer signature; and verifying the pointer signature before using the processor to invoke the address within the pointer.

[0176] One embodiment provides a data processing system, the data processing system including a memory for storing data and instructions and a processor coupled to the memory. The processor is configured to execute instructions stored in the memory. The instructions cause the processor to derive a processor master key from a master key of an integrated circuit including the processor; derive a signature and authentication key based on the processor master key; write a stack cookie to a stack stored in the memory along a stack overflow path leading to a secure pointer; sign the stack cookie using the signature and authentication key to generate a signed stack cookie; and authenticate the signed stack cookie via the signature and authentication key before accessing the address of the secure pointer.

[0177] One embodiment provides a non-transitory machine-readable medium storing instructions that cause a processor on a system-on-chip integrated circuit (SOC) to perform operations, the operations including: selecting a hardware-based key to generate a signature for one or more pointers; diversifying the hardware-based key using the selected key diversification data to generate a diversified key; signing the values ​​of addresses within the one or more pointers using the diversified key to generate one or more pointer signatures, wherein the one or more pointers include one or more boundary pointers at the beginning or end of a memory allocation associated with a data structure; and verifying the one or more pointer signatures before accessing data within the data structure to detect memory corruption associated with the data structure.

[0178] Other features of the present embodiments will become apparent from the accompanying drawings and from the above detailed description. Therefore, the true scope of these embodiments will become apparent to the skilled practitioner upon studying the drawings, the specification and the appended claims.

Claims

1. A method comprising: On an integrated circuit comprising one or more processors coupled to a memory: deriving one or more agent master keys for use by one or more execution agents, the one or more agent master keys being derived from a master key for the integrated circuit; deriving a set of signing and authentication keys for use by the one or more execution agents; signing, by an execution agent, a memory address of a pointer using one or more of the signing and authentication keys associated with the execution agent; storing the pointer in the memory; as well as The pointer is authenticated prior to executing instructions associated with the pointer.

2. The method of claim 1 , wherein deriving the set of signing and authentication keys for use by the one or more execution agents comprises deriving keys for each execution agent based on the agent master key of the execution agent.

3. The method of claim 2, wherein the set of signing and authentication keys comprises a first set of keys associated with a first execution level and a second set of keys associated with a second execution level, the second execution level having higher execution privileges relative to the first execution level. 4 . The method of claim 3 , wherein a signature generated using the first set of keys is not trustworthy during execution at the second execution level.

5. The method according to claim 3, further comprising: generating the first set of keys for the execution agent via a key derivation function that accepts a context identifier, the agent master key for the execution agent, and a key diversification value; generating the second set of keys for the execution agent via the key derivation function, the key derivation function being operable to accept the context identifier, the agent master key for the execution agent, and the key diversification value, wherein the key diversification value comprises a kernel key associated with an operating system kernel; enabling the first set of keys during execution at the second execution level; as well as A signature is generated for the pointer for use by a process to be executed at the first execution level.

6. The method according to claim 1, further comprising: signing a data structure to be stored in the memory, signing the data structure with a signature based on a key in the set of signing and authentication keys associated with the execution agent; as well as One or more pointers stored in the data structure are signed, the one or more pointers being signed using the signature based on one or more keys of the set of signing and authentication keys associated with the execution agent.

7. The method of claim 6, wherein the set of signing and authentication keys associated with the execution agent includes a data key and a general key.

8. The method of claim 7, wherein signing the one or more pointers stored in the data structure comprises: generating a first signature based on a first key and the memory address of a first pointer, the first key being derived from the data key and an initial value; applying the first signature to the first pointer; generating a second signature based on the memory of a second key and a second pointer, the second key being derived from the data key and a hash value generated based on the first signature; as well as The second signature is applied to the second pointer.

9. The method of claim 7, wherein signing the data structure comprises: generating a third signature based on a third key and a hash value generated based on one or more addresses of one or more pointers to the data structure, wherein the third key is the universal key; as well as The third signature is applied to a signature field of the data structure.

10. A non-transitory machine-readable medium storing instructions for performing the operations of the method according to any one of claims 1-9.

11. A system comprising: An integrated circuit comprising a memory for storing data and instructions and one or more processors coupled to the memory, wherein each of the one or more processors is an execution agent of the integrated circuit, and the one or more processors are used to execute the method according to any one of claims 1-9.

12. A system on chip integrated circuit SOC, comprising: a plurality of processors coupled to the memory; A non-transitory machine-readable medium storing instructions that cause at least one of a plurality of processors to perform operations comprising: deriving one or more proxy master keys for use by one or more of the plurality of processors of the SOC, the one or more proxy master keys being derived from a master key of the SOC; deriving a set of signing and authentication keys for use by one or more of the plurality of processors; Signing the address of the pointer using one or more of the signature and authentication keys; storing the pointer to a memory; and The pointer is authenticated prior to executing instructions associated with the pointer.

13. The system on chip integrated circuit of claim 12, wherein the set of signature and authentication keys includes an instruction key, a data key, and a general key.

14. The system-on-chip integrated circuit of claim 12, wherein the set of signing and authentication keys includes a first set of keys associated with a first execution level and a second set of keys for use during a second execution level, the second execution level having higher execution privileges relative to the first execution level.

15. The system on chip integrated circuit of claim 14, wherein a signature generated using the first set of keys is not trustworthy during execution at the second execution level.

16. The system on chip integrated circuit of claim 14, the operations further comprising: enabling the first set of keys during execution at the second execution level; as well as A signature is generated for a pointer for use by a process executing at the first execution level.

Images