Pointer authentication

Abstract

In one embodiment, a processor includes hardware circuitry operable to detect that a return address has been modified since it has been generated. In response to detecting the modification, the processor may be configured to signal an exception or otherwise initiate error processing to prevent execution at the modified return address. In one embodiment, the processor may perform an encrypted signature operation on the return address to generate a signed return address, and may verify the signature before the address is used as a return target.

Description

Technical Field

[0001] Embodiments described herein relate to Return Oriented Programming (ROP) attacks and mechanisms to prevent such attacks. Background Art

[0002] ROP attacks are often used by malicious programmers (e.g., "hackers") to attempt to compromise the security of a system and thereby gain control of the system. Generally speaking, a ROP attack involves modifying the return address (ROP) on the stack so that execution returns to a different program location than the original return address would indicate. By finding various instructions or short sequences of instructions that then return or jump in the code on the machine (e.g., operating system code), a ROP attacker can build a list of "instructions." Once the list of instructions forms a Turing machine, the list can be used by a compiler to compile code to perform the tasks desired by the malicious programmer. BRIEF DESCRIPTION OF THE DRAWINGS

[0003] The following detailed description refers to the accompanying drawings, which are now briefly described.

[0004] Figure 1 is a block diagram of one implementation of a processor.

[0005] Figure 2 is a block diagram of one embodiment of a register / memory location for a return / jump address.

[0006] Figure 3 is an example of an instruction that signs a return / jump address.

[0007] Figure 4 is an example of an instruction that authenticates the return / jump address of the signature.

[0008] Figure 5 is a flow chart illustrating an exemplary subroutine.

[0009] Figure 6 is a flow diagram illustrating the pushing of a return address for one implementation.

[0010] Figure 7 is a flow diagram illustrating popping of a return address for one embodiment.

[0011] Figure 8 is a block diagram of one embodiment of a system.

[0012] Fig. 9 is a block diagram of one embodiment of a computer-accessible storage medium.

[0013] Although the embodiments described in the present disclosure may be subject to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will be described in detail herein. However, it should be understood that the drawings and specific embodiments thereof are not intended to limit the embodiments to the specific forms disclosed, but on the contrary, the present invention is intended to cover all modifications, equivalents and alternatives falling within the spirit and scope of the appended claims. The headings used herein are for organizational purposes only and are not intended to limit the scope of the specification. DETAILED DESCRIPTION

[0014] Normal software control flow typically requires multiple pairs of call and return operations. Each call operation pushes a return address onto the stack. The corresponding return operation pops the return address off the stack and jumps to the location indicated by the return address. A malicious programmer or attacker may attempt to hijack the call / return control flow to direct the return to a target code segment that was not intended by the original software program but is desired by the attacker. One mechanism employed by such attacks is a ROP attack, in which the return address is overwritten on the stack and / or in a register (e.g., a link register) that can be used as a source of a return address by a return instruction (e.g., the stack may be popped into the link register).

[0015] Pointer Authentication Feature (PAC) is a method for protecting control flow integrity (CFI) in software. In ROP-protected areas, PAC is used to sign the return address pushed on the stack. In a paired return operation, the signed return address is popped from the stack and authenticated before it is used to direct control flow. Therefore, even if an attacker has the ability to rewrite the return address on the stack, they will need to rewrite the return address with a correctly signed value. Otherwise, at the return operation, the authentication of the popped return address will fail and the attack will be terminated.

[0016] The scheme for signing the return address is to form a diversified key for cryptographically signing the return address using a secret key value (e.g., in a hidden hardware register) in combination with the value of the stack pointer and the address of the callee (e.g., the target address of the call in the call / return pair, such as the beginning of a function that will end with a return instruction). The secret key may also be referred to as an encryption key. The encryption key may be unique to a given system, which can help prevent attacks of the "crack once, run everywhere" type. That is, even if an attacker somehow succeeds in attacking one instance of the system, a ROP-type attack cannot be used for other instances of the system because the key is different, and therefore the signature will be different even for the same call / return pair. The stack pointer is a measure of the stack height at the time of the call and return operation, and is also an indication of where the return address is stored. The address of the callee identifies the location where the callee is stored in memory, and therefore identifies the callee in the signature. The return address identifies the calling code because it is associated with the call (e.g., it may point to the next sequential instruction after the call instruction). In this way, the signature has inputs for both the caller and the callee, thereby linking them together. Therefore, it is not possible to substitute different return addresses for different call / return pairs by monitoring the stack contents at the same height.

[0017] In one embodiment, the processor may be configured to perform a signature operation (e.g., by executing a signature instruction). The signature instruction may have a source operand (e.g., stored in a register of the processor), and a signature may be generated for the source operand. In one embodiment, the signature may be based on an encryption key, a stack pointer address (which may be stored in another register of the processor), and an address (also referred to as a program counter address or PC) where the signature instruction is stored. In one embodiment, the signature instruction may specify an offset (e.g., a displacement or immediate field of the signature instruction, or even another source operand of the instruction, such as another register). The offset may be added to the PC of the signature instruction to generate an address used in signature generation. The value of the signature may be stored in a storage location (e.g., a destination operand) specified by the signature instruction. A corresponding authentication operation may also be defined, which may authenticate the source operand (e.g., the value of the signature mentioned above) based on the PC of the stack pointer and the authentication instruction (e.g., plus the offset as mentioned above). For example, the offset may be used to generate the same address used in the signature instruction. In some cases, the offset of the signature instruction and / or the authentication instruction may be encoded as zero, or encoded as any positive or negative value that can be represented by the number of displacement / immediate bits specified by the instruction.

[0018] For example, in the case of preventing ROP attacks, the signature instruction can use the return address as the source operand, and the PC plus offset can be the initial instruction of the subroutine terminated by the return instruction. Alternatively, the PC plus offset can be, for example, the PC of the return instruction or any other instruction in the subroutine. In the subsequent description, the example of calling and returning from the subroutine will be used. However, more generally, the signature instruction and the authentication instruction can be defined as above.

[0019] Now turn to Figure 1 , a block diagram of one embodiment of the processor 10 is shown. Figure 1 In an embodiment of the present invention, processor 10 may include an execution core 12 coupled to a register file 14 and optionally one or more special purpose registers 16 .

[0020] Processor 10 may represent a general purpose processor that performs computing operations. For example, processor 10 may be a central processing unit (CPU), such as a microprocessor, a microcontroller, an application specific integrated circuit (ASIC), or a field programmable gate array (FPGA). Processor 10 may be a stand-alone component, or may be integrated onto an integrated circuit with other components (e.g., other processors or other components in a system on a chip (SOC)). Processor 10 may be a component in a multi-chip module (MCM) with other components.

[0021] like Figure 1 As illustrated, the processor 10 may include an execution core 12. The execution core 12 may be configured to execute instructions defined in an instruction set architecture implemented by the processor 10. As desired, the execution core 12 may have any microarchitecture features and specific implementation features. For example, the execution core 12 may include a superscalar or scalar specific implementation. The execution core 12 may include an in-order or out-of-order specific implementation, as well as a speculative or non-speculative specific implementation. The execution core 12 may include any combination of the above features. In some embodiments, the specific implementation may include microcode. The execution core 12 may include various execution units, each of which is configured to perform operations of various types (e.g., integer, floating point, vector, multimedia, load / store, etc.). The execution core 12 may include different numbers of pipeline stages and various other performance enhancement features, such as branch prediction. The execution core 12 may include one or more of an instruction decoding unit, a scheduler or reservation station, a reorder buffer, a memory management unit, an I / O interface, etc.

[0022] Register file 14 may include a set of registers that may be used to store operands for various instructions. Register file 12 may include registers of various data types, based on the type of operands execution core 12 is configured to store in registers (e.g., integer, floating point, multimedia, vector, etc.). Register file 14 may include architectural registers (i.e., those registers specified in the instruction set architecture implemented by processor 10). Alternatively or in addition, register file 14 may include physical registers (e.g., if register renaming is implemented in execution core 12).

[0023] Special registers 16 may be registers provided in addition to general registers. Although general registers may be operands of any instruction of a given data type, special registers are typically operands of specific instructions or subsets of instructions. For example, in some embodiments, a program counter register may be a special register storing the fetch address of an instruction. A link register may be a register storing a return address and may be accessible to a branch instruction. Although special registers 16 are shown as being separated from register file 14, in other embodiments, the special registers may be integrated into register file 14. In some embodiments, certain general registers may be reserved by compiler conventions or other software conventions to store specific values ​​(e.g., stack pointers, frame pointers, etc.).

[0024] The processor 10 may be configured to perform signing and authentication operations on the return address to detect whether the addresses have been modified between the time the addresses are created / stored and the time the addresses are to be used as targets. In some embodiments, the addresses may be signed when they are written to the memory. For example, the return address may be written to a stack in the memory. In other embodiments, the return address may be signed in the register to which it is stored when a subroutine call instruction (more simply, a "call instruction") is executed. For example, a link register to which the return address is stored may be provided. When the address is later retrieved for use as a return target address, the processor 10 may be configured to perform an authentication operation on the address. If the authentication operation fails, an error handling may be initiated instead of using the address as the fetch address. Performing a signing operation on a value may be more succinctly referred to herein as "signing" the value. Similarly, performing an authentication operation on a value may be more succinctly referred to herein as "authenticating". In one embodiment, the signature generation / authentication circuit 18 ( Figure 1 The signature generation / authentication circuit 18) in can implement signature generation and authentication features.

[0025] In general, performing a signature operation or "signing" an address may refer to applying a cryptographic function to the address using at least one cryptographic key and using 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 may be performed on the address (or the address may be "authenticated"). That is, if the address and / or signature has not been modified, the result of the cryptographic function should be equal to the signature. The cryptographic key may be specific to a thread including the generation of the address and the use of the address as a target, and therefore the likelihood of undetected modifications by a third party without the key may be very small. The cryptographic key may be generated based at least in part on a "secret" that is specific to an instance of the processor 10 and is inaccessible except in hardware. 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.

[0026] In one embodiment, the additional data used in the signature and authentication of the return address may include the address where the return address is stored. For example, the virtual address of the location (e.g., a virtual stack pointer, for storing the address on the stack) may be used. Other embodiments may use a physical address. In addition, the additional data may include the address of the callee (e.g., the first instruction of the function being called). In other words, the address may be the target address of the call instruction, referred to herein as the program counter address or PC of the callee. As mentioned above, the signature instruction may generally specify the source operand to be signed, and the signature may be generated based on the encryption key, the stack pointer, and the PC of the signature instruction (plus the offset specified by the signature instruction).

[0027] The encryption function applied to the return address may be an encryption of the address using a key. The result of the encryption may be a signature in its entirety, or a portion of the result may be a signature (e.g., the signature may be shortened via truncation or shifting). Any encryption algorithm may be used, including the various examples given below.

[0028] Instructions may be executable entities defined in an instruction set architecture implemented by the processor 10. There are a variety of 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 an instruction set architecture, including the encoding of instructions in memory, the operation of instructions, and the impact of instructions on registers, memory locations, and / or other processor states. A given specific implementation of an instruction set architecture may directly execute each instruction, but its form may be changed by decoding and other manipulations in the processor hardware. Another specific implementation may decode at least some instructions into multiple instruction operations for execution by the execution unit in the processor 10. In some embodiments, some instructions may be microcoded. Therefore, the term "instruction operation" may be used herein to refer to an operation in which the execution unit in the processor 10 / execution core 12 is configured to be executed as a single entity. An instruction may have a one-to-one correspondence with an instruction operation, and in some cases, an instruction operation may be an instruction (possibly modified in the form of the processor 10 / execution core 12). An instruction may also have a one-to-many (one-to-many) correspondence with an instruction operation. An instruction operation may be more simply referred to as an "operation" herein.

[0029] In one embodiment, processor 10 includes one or more registers and an execution core coupled to the one or more registers. The execution core can be configured to perform a signature operation on a first value to generate a signed value and store the signed value in a storage location for subsequent use. In one embodiment, the execution core is configured to perform a signature operation based on an encryption key, a value of a stack pointer stored in one of the one or more registers, and an address where an instruction corresponding to the signature operation is stored. In one embodiment, the execution core is configured to perform an authentication operation on the signed value before using the first value. In one embodiment, the signature operation is based on an address and an offset specified by an instruction.

[0030] An embodiment of the processor 10 may include one or more registers; and an execution core coupled to the one or more registers, wherein: the execution core is configured to perform a signature operation on a source operand of an instruction to generate a value of a signature, and store the value of the signature in a storage location specified by the instruction; and the execution core is configured to perform a signature operation based on an encryption key, a value of a stack pointer stored in one of the one or more registers, and an address of the instruction. In one embodiment, before returning to the value of the signature using the storage location, the execution core is configured to perform an authentication operation on the value of the signature. In one embodiment, the execution core is configured to execute another instruction defined as an authentication signature. In one embodiment, the storage location is a memory location, such as a stack location indicated by the value of the stack pointer. In another embodiment, the storage location is a register in one of the one or more registers. In one embodiment, the signature generated from the signature operation is reduced in size and replaces a subset of the bits of the source operand in the value of the signature. In one embodiment, the execution core is configured to execute an instruction, and wherein the instruction is defined as generating a value of a signature. In an example, the instruction can be used for a call to a subroutine terminated by a return instruction, and the source operand is a return address corresponding to the return instruction. In an example, the instruction can be an initial instruction in the subroutine.

[0031] Now go to Figure 2 , a block diagram of an embodiment of an example M-bit memory location or register is shown. M can be an integer greater than zero. More specifically, M can be the architectural size of the virtual address in the processor 10. For example, some instruction set architectures currently specify 64-bit addresses. However, the virtual address size actually implemented can be smaller (e.g., 40-bit to 48-bit addresses). Therefore, in such specific implementations, some of the address bits are not effectively used. In one embodiment, the most effective implemented virtual address bit can be copied in the remaining virtual address bits, up to the architectural maximum value. In one embodiment, one or more most significant bits of the architectural maximum value can be considered inactive, and the most significant address bit can be copied up to the most effective active address bit. For example, in one embodiment, the most significant bit can be considered active or inactive. In one embodiment, the unused bit can be used to store the signature of the address. Other embodiments can store the signature in another memory location.

[0032] exist Figure 2In an embodiment of the present invention, the t+1 bits of the virtual address (field 20) 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 22). The signature generated from the encryption algorithm can be larger than the signature field 22 (e.g., larger than M-(t+1) bits). Therefore, the signature actually stored for the address can be a portion of the signature. That is, the signature can be reduced in size from the signature generated by the signing operation, and a subset of the bits of the return address can be replaced. For example, the signature may be truncated. Alternatively, the signature may be right-shifted. Any mechanism for shortening the signature field may be used.

[0033] Processor 10 may implement signature generation and authentication in hardware. For example, signature generation / authentication circuit 18 is shown in FIG. Figure 1 and may include circuitry to sign and authenticate the return address (or more generally, to sign and authenticate the source operand). There may be instructions defined for the instruction set architecture that cause a signature to be generated or authentication to be performed. Figure 3 and Figure 4 Implementations of instructions for signature generation and authentication are illustrated respectively.

[0034] Figure 3 An embodiment of a signature generation instruction is illustrated. In this embodiment, the Sign instruction takes as input operands a virtual return address stored in a link register (LR), a virtual stack pointer address stored in a stack pointer register (SP), a virtual instruction address (PC), and a key. PC may be the address where the signature instruction is stored. The key may be stored in a hardware accessible register or other storage device accessible only by hardware. The key may be one key or multiple keys, depending on the encryption algorithm implemented by the processor 10. Figure 3 The illustrated encoding may be an example for return address authentication. More generally, LR may be any source operand (e.g., any register). In one embodiment, the signature instruction may also specify an offset, such as a displacement or immediate field. The displacement / immediate field may be added to the PC operand.

[0035] The Sign instruction may apply an encryption algorithm to the data, producing a signature that may be written to a target register (e.g., back to a link register). The data may be combined prior to encryption (e.g., the return address, stack pointer, and PC may be logically combined according to any desired logical function such as an XOR-based function) and the resulting data may be encrypted with a key. Block encryption (block cipher) mechanisms may be used one or more times to concatenate and encrypt data. Any type of encryption may be used, including any type of block encryption such as the Advanced Encryption Standard (AES), the Data Encryption Standard (DES), the International Data Encryption Algorithm (IDEA), PRINCE, etc. 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 resulting from the encryption may then be shortened to match field 22. The result in the target register may be Figure 2 The form shown.

[0036] As described above, various logical operations may be used to combine the data included in the signature generation. The least significant bit (LSB) of the address may contain maximum entropy, which may provide secure encryption. In one embodiment, the most significant bit (MSB) of the address distinguishes between privileged and non-privileged memory. As mentioned above, bits 0..t may contain addresses, and bits t+1 to M may be duplicated bits. Additionally, in one embodiment, the PC and LR registers may need to be aligned to 32-bit boundaries (e.g., instructions may be 32-bit fixed-length instructions in the implemented ISA). The stack pointer may be aligned to a 128-bit boundary (e.g., 64-bit value pairs may typically be pushed and popped on the stack).

[0037] Thus, the bits to be encrypted may include PC bits t to 2, LR bits t..2, and SP bits t..4. In one embodiment, the following mechanism may be used: forming a first value P using the least significant 21 bits from the LR, PC, and SP to form a 63-bit value, and appending bit t of the PC at bit position 63 to form a 64-bit value to be encrypted; forming a divider value D using the middle significant 21 bits of the LR, PC, and SP, and appending bit t of the LR at bit position 63 to form a 64-bit value used as a divider; forming a third value R by interleaving the remaining implementation bits of the LR, PC, and SP (e.g., up to bit t) and 0. Replicating the resulting value over 64 bits, leaving bit 63 zero; and encrypting the value as follows using cryptography that takes two 64-bit values ​​to generate a single encrypted 64-bit value C=E(X,Y), where X is R XOR P, and Y is R XOR D. The resulting encrypted value C may then be shortened to produce the signature field 22. For example, Mt bits may be extracted from C and used as a signature.

[0038] Figure 4An authentication instruction is illustrated. The Auth instruction can take the LR, SP and PC values ​​and the key as input operands. The Auth instruction can apply the same encryption algorithm as the Sign instruction to the return address field 20, thereby generating a signature. The resulting signature can be compared with the original signature in the signature field 22 (shortened in the same way as the original signature was shortened). If the signatures do not match, the authentication fails and a return to the address is blocked. If the signatures match, the authentication passes and a return to the address is allowed. The return can be prevented, for example, by taking an exception. As described above, more generally, the authentication instruction can take any source operand instead of the LR register. The authentication instruction can specify an offset (e.g., a displacement or immediate field) to be added to the PC.

[0039] In one embodiment, the Sign and Auth instructions may be implemented as two or more instruction operations in the processor 10. For example, in one embodiment, the callee address may be specified as the PC of the call instruction plus an offset or immediate field. One instruction operation may add the PC and the offset / immediate to produce a PC to be used by the Sign and Auth instructions. Another instruction operation may take the PC, LR, and SP values ​​generated by the first instruction operation and may perform a signing / authentication operation using a specified key.

[0040] Next turn Figure 5 , shows a flowchart illustrating an exemplary subroutine that may be executed by a processor 10 in the system. However, for ease of understanding, the blocks are shown in a particular order, and other orders may also be used. Instructions executed by the processor 10 and / or hardware in the processor 10 may implement Figure 5 The operations shown in .

[0041] The processor 10 may push the return address of the subroutine onto the stack (block 40). The push may occur in the calling code, before jumping to the address of the subroutine, or within the subroutine. Figure 6 Additional details of some embodiments of pushing a return address are described. The subroutine may include instructions (generally indicated by reference numeral 42) that perform the operation for which the subroutine is designed. The subroutine may pop the return address from the stack (block 44) and return to the return address (block 46). That is, the return address may be used as a fetch address to fetch the next instruction to be executed in processor 10. Figure 7 Additional details are described regarding some embodiments of popping the return address.

[0042] Now turn to Figure 6 , shows a flowchart illustrating one embodiment of pushing a return address (e.g., Figure 540 in FIG. 4). However, for ease of understanding, the blocks are shown in a particular order, and other orders may be used. Instructions executed by processor 10 and / or hardware in processor 10 may implement Figure 6 The operations shown in .

[0043] A signature based on the VA, the return address (LR), the callee's address (PC), and the key may be generated by applying the selected encryption algorithm to the data (block 52). The generated signature may be combined with the return address to form a signed return address (e.g., Figure 2 t of the return address (LR) and may be written to the LR as the return address for the signature. The return address for the signature from the LR may be pushed to the memory location indicated by the value of the stack pointer (block 56). As described above, any encryption algorithm may be used. For example, a block encryption algorithm may be used multiple times. In one embodiment, the PRINCE algorithm may be used.

[0044] Now turn to Figure 7 , shows a flowchart illustrating one embodiment of popping the return address (e.g., Figure 5 44 in FIG. 4). However, for ease of understanding, the blocks are shown in a particular order, and other orders may be used. Instructions executed by processor 10 and / or hardware in processor 10 may implement Figure 7 The operations shown in .

[0045] The signed return address may be loaded from the memory location indicated by the value of the stack pointer into the target register (e.g., LR) (block 70). The signed return address may be authenticated by applying the same operations that were applied when the return address was initially signed, thereby generating a signature S'. S' may be compared to the signature field 22 (block 74). If the signature remains valid (i.e., the signature S' generated in the authentication matches the original signature S in the address) (decision block 76, "yes" branch), the return address may be used, and thus operations may proceed to Figure 5 Otherwise (decision block 76, "no" branch), processor 10 may signal an exception to prevent use of the return address (block 78).

[0046] In one embodiment, a method includes generating a return address for a call to a subroutine terminated by a return instruction in a processor; performing a signing operation on the return address to generate a signed return address, wherein the signing operation is based on a cryptographic key, a value of a stack pointer, and an address of an initial instruction in the subroutine; detecting an attempt by the return instruction to use the signed return address; authenticating the signed address in response to detecting the attempt; and preventing a failure to return to the authenticated signed address.

[0047] As mentioned above, one embodiment of the encryption algorithm can be the PRINCE algorithm. The PRINCE algorithm uses a 128-bit key, which is represented as two 64-bit keys K0 and K1. The 128-bit key is expanded to 192 bits by generating K0'. K0' is the exclusive OR of K0 rotated right by one and K0 shifted right by 63. PRINCE is based on the so-called FX construction [7,30]: the first two subkeys K0 and K0' are whitened keys, while key K1 is called PRINCE 核心 The PRINCE algorithm is a 64-bit key for a 12-round block cipher. In some embodiments, 12 rounds may be deployed so that the latency of the cipher is 1 clock cycle. Additional details of the PRINCE algorithm are provided in the paper "PRINCE-A Low-latency BlockCipher for Pervasive Computing Applications" by Borghoff et al., edited by Xiaoyun Wang and Kazue Sako, Advances in Cryptology-ASI A CRYPT 2012-18th International Conference on the Theory and Application of Cryptology and Information Security, Beijing, China, December 2-6, 2012, pages 208-225.

[0048] Computer Systems

[0049] Next turn Figure 8 , a block diagram of one embodiment of a system 700 is shown. In the illustrated embodiment, the system 700 includes at least one instance of a system on a chip (SOC) 706 coupled to one or more peripheral devices 704 and an external memory 702. A power supply (PMU) 708 is provided that supplies a supply voltage to the SOC 706 and one or more supply voltages to the memory 702 and / or the peripheral devices 704. In some embodiments, more than one instance of a SOC may be included (and more than one memory 702 may also be included). In one embodiment, the SOC 706 may include Figure 1 One or more instances of processor 10 are illustrated.

[0050] Depending on the type of system 700, peripheral device 704 may include any desired circuit system. For example, in one embodiment, system 704 may be a mobile device (e.g., a personal digital assistant (PDA), a smart phone, etc.), and peripheral device 704 may include equipment for various types of wireless communications, such as Wi-Fi, Bluetooth, cellular, global positioning systems, etc. Peripheral device 704 may also include additional storage devices, which include RAM storage devices, solid-state storage devices, or disk storage devices. Peripheral device 704 may include user interface devices, such as a display screen, which includes a touch display screen or a multi-touch display screen, a keyboard or other input device, a microphone, a speaker, etc. In other embodiments, system 700 may be any type of computing system (e.g., a desktop personal computer, a laptop, a workstation, a network set-top box, etc.).

[0051] The external memory 702 may include any type of memory. For example, the external memory 702 may be an SRAM, a dynamic RAM (DRAM) such as a synchronous DRAM (SDRAM), a double data rate (DDR, DDR2, DDR3, etc.) SDRAM, a RAMBUS DRAM, a low power version of a DDR DRAM (e.g., LPDDR, mDDR, etc.), etc. The external memory 702 may include one or more memory modules to which a memory device may be mounted, such as a single inline memory module (SIMM), a dual inline memory module (DIMM), etc. Alternatively, the external memory 702 may include one or more memory devices mounted on the SOC 706 in a chip-on-chip or package-on-package implementation.

[0052] As illustrated, system 700 is shown as having applications in a wide range of fields. For example, system 700 can be used as a part of a chip, circuit system, component, etc. of a desktop computer 710, a laptop computer 720, a tablet computer 730, a cellular or mobile phone 740, or a TV 750 (or a set-top box coupled to a TV). Smart watches and health monitoring devices 760 are also illustrated. In some embodiments, smart watches may include various general computing related functions. For example, smart watches may provide access to email, mobile phone services, user calendars, etc. In various embodiments, health monitoring devices may be dedicated medical devices or otherwise include dedicated health-related functionality. For example, health monitoring devices may monitor the vital signs of users, track the proximity of users to other users for the purpose of epidemiological social distance, contact tracking, provide communications to emergency services in the event of a health crisis, etc. In various embodiments, the above-mentioned smart watches may include or may not include some or any health monitoring related functions. Other wearable devices are also envisioned, such as devices worn around the neck, devices that can be implanted in the human body, glasses designed to provide enhanced and / or virtual reality experiences, etc.

[0053] The system 700 may also be used as part of a cloud-based service 770. For example, the previously mentioned devices and / or other devices may access computing resources in the cloud (i.e., remotely located hardware and / or software resources). Still further, the system 700 may be used in one or more devices in a home 780 other than those previously mentioned. For example, a home appliance may monitor and detect noteworthy situations. For example, various devices in a home (e.g., a refrigerator, a cooling system, etc.) may monitor the status of the device, and an alert may be provided to the homeowner (or, for example, a maintenance agency) if a particular event is detected. Alternatively, a thermostat may monitor the temperature in a home, and may automatically adjust the heating / cooling system based on a history of responses by the homeowner to various situations. Figure 8 Also illustrated in the 700 are applications of various modes of transportation 790. For example, the system 700 may be used for control and / or entertainment systems for airplanes, trains, buses, taxis, private cars, watercraft ranging from private boats to cruise ships, scooters (for rental or private use), and the like. In various cases, the system 700 may be used to provide automated guidance (e.g., self-driving vehicles), general system control, and the like. Any of these and many other implementations are possible and contemplated. Note that Figure 8 The devices and applications shown are exemplary only and are not intended to be limiting. Other devices are possible and contemplated.

[0054] Computer readable storage medium

[0055] Now turn to Fig. 9, a block diagram of an embodiment of a computer-readable storage medium 800 is shown. Generally speaking, a computer-accessible storage medium may include any storage medium that can be accessed by a computer during use to provide instructions and / or data to a computer. For example, a computer-accessible storage medium may include a storage medium such as a magnetic or optical medium, for example, a disk (fixed or removable), a tape, a CD-ROM, a DVD-ROM, a CD-R, a CD-RW, a DVD-R, a DVD-RW or a blue-ray. The storage medium may also include a volatile or non-volatile memory medium, such as a RAM (for example, a synchronous dynamic RAM (SDRAM), a Rambus DRAM (RDRAM), a static RAM (SRAM) etc.), a ROM or a flash memory. The storage medium may be physically included in a computer to which the storage medium provides instructions / data. Alternatively, the storage medium may be connected to a computer. For example, the storage medium may be connected to a computer via a network or a wireless link such as a network attached storage device. The storage medium may be connected via a peripheral interface such as a universal serial bus (USB). Generally speaking, the computer-accessible storage medium 800 can store data in a non-transitory manner, where non-transitory in this context can refer to not transmitting instructions / data via signals. For example, a non-transitory storage device can be volatile (and may lose the stored instructions / data in response to a power outage) or non-volatile.

[0056] Fig. 9 The computer-accessible storage medium 800 in the computer-accessible storage medium 800 may store a database 804 representing the SOC 706. In general, the database 804 may be a database that can be read by a program and used directly or indirectly to manufacture hardware including the SOC 706. For example, the database may be a behavioral level description or a register transfer level (RTL) description of the hardware functions in a high-level design language (HDL) such as Verilog or VHDL. The description may be read by a synthesis tool, which may synthesize the description to generate a netlist including a list of gate circuits from a synthesis library. The netlist includes a set of gate circuits that also represent the functions of the hardware including the SOC 706. The netlist may then be placed and routed to generate a data set for describing the geometry to be applied to the mask. The mask may then be used in various semiconductor manufacturing steps to generate one or more semiconductor circuits corresponding to the SOC 706. Alternatively, the database 804 on the computer-accessible storage medium 800 may be a netlist (with or without a synthesis library) or a data set, as desired.

[0057] Although computer-accessible storage medium 800 stores a representation of SOC 706, other embodiments may carry a representation of any portion of SOC 706 as desired, including, for example, Figure 1 The processor 10 shown, or any subset thereof.

[0058] ***

[0059] The present disclosure includes references to "an embodiment" or groups of "embodiments" (e.g., "some embodiments" or "various embodiments"). Embodiments are different specific implementations or examples of the disclosed concepts. References to "an embodiment," "one embodiment," "a particular embodiment," etc. do not necessarily refer to the same embodiment. A large number of possible embodiments are contemplated, including those specifically disclosed, as well as modifications or alternatives that fall within the spirit or scope of the present disclosure.

[0060] The present disclosure may discuss potential advantages that may be generated by the disclosed embodiments. Not all of these implementations will necessarily exhibit any or all of the potential advantages. Whether a particular implementation achieves an advantage depends on many factors, some of which are outside the scope of the present disclosure. In fact, there are many reasons why a particular implementation that falls within the scope of the claims may not exhibit some or all of any of the disclosed advantages. For example, a particular implementation may include other circuit systems outside the scope of the present disclosure, which, in combination with one of the disclosed embodiments, negate or reduce one or more of the disclosed advantages. In addition, suboptimal design execution of a particular implementation (e.g., a specific implementation technique or tool) may also negate or reduce the disclosed advantages. Even assuming a specific implementation of the technology, the realization of the advantages may still depend on other factors, such as the environmental conditions in which the specific implementation is deployed. For example, the input provided to a particular implementation may prevent one or more problems solved in the present disclosure from occurring in a particular occasion, and as a result, the benefits of its solution may not be realized. In view of the existence of possible factors external to the present disclosure, it is hereby clarified that any potential advantages described herein should not be construed as claim limitations that must be met in order to prove infringement. Instead, the identification of such potential advantages is intended to illustrate the types of improvements available to designers who benefit from the present disclosure. Permanently describing such advantages (eg, stating that a particular advantage "may occur") is not intended to convey a doubt as to whether such advantage can actually be achieved, but rather to recognize that achievement of such advantage typically depends on technical realities of additional factors.

[0061] Unless otherwise stated, the embodiments are non-limiting. That is, the disclosed embodiments are not intended to limit the scope of the claims drafted based on the present disclosure, even if only a single example is described with respect to a particular feature. The embodiments disclosed by the present invention are intended to be illustrative and non-restrictive, without any contrary statement in the present disclosure. Therefore, the present application is intended to allow claims covering the disclosed embodiments, as well as such alternatives, modifications and equivalents, which will be apparent to those skilled in the art who are aware of the beneficial effects of the present disclosure.

[0062] For example, features in this application may be combined in any suitable manner. Accordingly, new claims may be made during the prosecution of this application (or an application claiming priority thereto) for any such combination of features. In particular, with reference to the appended claims, features of dependent claims may be combined, where appropriate, with features of other dependent claims, including claims that are dependent on other independent claims. Similarly, features from corresponding independent claims may be combined, where appropriate.

[0063] Thus, while the appended dependent claims may be drafted such that each dependent claim is dependent upon a single other claim, additional dependencies are also contemplated. Any combination of dependent features consistent with the present disclosure is contemplated and may be claimed in this or another application. In short, the combinations are not limited to those specifically recited in the appended claims.

[0064] It is also contemplated that claims drafted in one format or legal type (eg, apparatus) are intended to support corresponding claims in another format or legal type (eg, method), where appropriate.

[0065] ***

[0066] Because this disclosure is a legal document, various terms and phrases may be subject to regulatory and judicial interpretation. Notice is hereby given that the definitions provided in the following paragraphs and throughout this disclosure will be used to determine how to interpret claims drafted based on this disclosure.

[0067] Unless the context clearly dictates otherwise, reference to an item in the singular (i.e., a noun or noun phrase preceded by "a," "an," or "the") is intended to mean "one or more." Thus, reference to "an item" in a claim does not exclude additional instances of that item without the accompanying context. A "plurality" of an item refers to a group of two or more items.

[0068] The word "may" is used herein in a permissive sense (ie, having the potential to, being able to), rather than the mandatory sense (ie, must).

[0069] The terms "including" and "comprising" and forms thereof are open ended and mean "including, but not limited to."

[0070] When the term "or" is used in this disclosure with respect to a list of options, it will generally be understood to be used in an inclusive sense unless the context provides otherwise. Thus, the expression "x or y" is equivalent to "x or y, or both," and thus encompasses 1) x but not y, 2) y but not x, and 3) both x and y. On the other hand, phrases such as "either x or y, but not both" make it clear that "or" is used in an exclusive sense.

[0071] The expressions "w, x, y, or z, or any combination thereof" or "... at least one of w, x, y, and z" are intended to cover all possibilities involving individual elements up to the total number of elements in the set. For example, given the set [w, x, y, z], these phrases cover any single element in the set (e.g., w but not x, y, or z), any two elements (e.g., w and x, but not y or z), any three elements (e.g., w, x, and y, but not z), and all four elements. The phrase "... at least one of w, x, y, and z" thus refers to at least one element in the set [w, x, y, z], thereby covering all possible combinations in the list of elements. The phrase should not be interpreted as requiring the presence of at least one instance of w, at least one instance of x, at least one instance of y, and at least one instance of z.

[0072] In this disclosure, various "labels" may precede a noun or noun phrase. Unless the context provides otherwise, different labels used for a feature (e.g., "a first circuit," "a second circuit," "a particular circuit," "a given circuit," etc.) refer to different instances of the feature. Additionally, unless otherwise stated, the labels "first," "second," and "third" do not imply any type of ordering (e.g., spatial, temporal, logical, etc.) when applied to features.

[0073] The phrase "based on" or is used to describe one or more factors that influence a determination. This term does not exclude the possibility that additional factors may influence the determination. That is, a determination may be based only on the specified factors or on the specified factors and other unspecified factors. Consider the phrase "A is determined based on B." This phrase specifies that B is a factor used to determine A or that B influences the determination of A. This phrase does not exclude that the determination of A may also be based on some other factor such as C. This phrase is also intended to cover embodiments in which A is determined based only on B. As used herein, the phrase "based on" is synonymous with the phrase "based at least in part on."

[0074] The phrases "in response to" and "in response to" describe one or more factors that trigger an effect. The phrase does not exclude the possibility that additional factors may influence or otherwise trigger the effect, either in conjunction with the specified factors or independently of the specified factors. That is, the effect may be responsive to these factors alone, or may be responsive to the specified factors as well as other unspecified factors. Consider the phrase "A is performed in response to B." The phrase specifies that B is a factor that triggers the execution of A or triggers a specific result of A. The phrase does not exclude that the execution of A may also be responsive to certain other factors, such as C. The phrase also does not exclude that the execution of A may be performed jointly in response to B and C. This phrase is also intended to cover embodiments in which A is performed only in response to B. As used herein, the phrase "in response to" is synonymous with the phrase "at least partially in response to." Similarly, the phrase "in response to" is synonymous with the phrase "at least partially in response to."

[0075] ***

[0076] Within the present disclosure, different entities (which may be variously referred to as "units," "circuits," other components, etc.) may be described or claimed as being "configured to" perform one or more tasks or operations. This expression—[an entity] configured to [perform one or more tasks]—is used herein to refer to a structure (i.e., a physical thing). More specifically, this expression is used to indicate that this structure is arranged to perform one or more tasks during operation. A structure may be considered to be "configured to" perform a task even if the structure is not currently being operated. Therefore, an entity described or stated as "configured to" perform a task refers to a physical thing used to implement the task, such as a device, a circuit, a system with a processor unit, and a memory storing executable program instructions, etc. This phrase is not used herein to refer to an intangible thing.

[0077] In some cases, various units / circuits / components may be described herein as performing a set of tasks or operations. It should be understood that these entities are "configured to" perform those tasks / operations, even if not specifically stated.

[0078] The term "configured to" is not intended to mean "configurable to". For example, an unprogrammed FPGA would not be considered "configured to" perform a particular function. However, the unprogrammed FPGA may be "configurable to" perform that function. After being appropriately programmed, the FPGA may then be considered "configured to" perform the particular function.

[0079] For purposes of a U.S. patent application based on the present disclosure, stating in a claim that a structure is “configured to” perform one or more tasks is expressly intended not to invoke 35 U.S.C. §112(f) for that claim element. If the applicant wishes to invoke section 112(f) during prosecution of a U.S. patent application based on the present disclosure, it would use the “means for [performing the function]” construct to phrase the claim element.

[0080] Different "circuits" may be described in the present disclosure. These circuits constitute hardware that includes various types of circuit elements, such as combinational logic, clock storage devices (e.g., flip-flops, registers, latches, etc.), finite state machines, memories (e.g., random access memory, embedded dynamic random access memory), programmable logic arrays, etc. Circuits may be custom designed or taken from a standard library. In various specific implementations, circuits may include digital components, analog components, or a combination of both, as appropriate. Certain types of circuits may be generally referred to as "units" (e.g., decoding units, arithmetic logic units (ALUs), functional units, memory management units (MMUs), etc.). Such units are also referred to as circuits.

[0081] Thus, the disclosed circuits / units / components and other elements illustrated in the drawings and described herein include hardware elements, such as those described in the preceding paragraphs. In many cases, the internal arrangement of hardware elements in a particular circuit can be specified by describing the functionality of the circuit. For example, a particular "decode unit" may be described as performing the function of "processing an opcode for an instruction and routing the instruction to one or more of a plurality of functional units," meaning that the decode unit is "configured to" perform that function. For one skilled in the computer arts, this functional specification is sufficient to suggest a set of possible structures for the circuit.

[0082] In various embodiments, as discussed in the preceding paragraphs, circuits, units, and other elements defined by the functions or operations they are configured to implement. The arrangement of such circuits / units / components relative to each other and the way they interact form a microarchitecture definition of hardware, which is ultimately manufactured in an integrated circuit or programmed into an FPGA to form a physical implementation of the microarchitecture definition. Therefore, the microarchitecture definition is considered by those skilled in the art to be a structure from which many physical implementations can be derived, all of which fall into the broader structure described by the microarchitecture definition. That is, a technician with a microarchitecture definition provided in accordance with the present disclosure can implement the structure by coding a description of a circuit / unit / component in a hardware description language (HDL) such as Verilog or VHDL without excessive experimentation and using the application of ordinary technicians. HDL descriptions are often expressed in a way that can be displayed as functional. However, for those skilled in the art, the HDL description is a way to convert the structure of a circuit, unit, or component into the next level of specific implementation details. Such HDL descriptions may take the form of behavioral code (which is generally non-synthesizable), register transfer language (RTL) code (which is generally synthesizable compared to behavioral code), or structural code (e.g., a netlist specifying logic gates and their connectivity). The HDL description may be sequentially synthesized for a library of cells designed for a given integrated circuit manufacturing technology, and may be modified for timing, power, and other reasons to obtain a final design database that is sent to the factory to generate masks and ultimately produce integrated circuits. Some hardware circuits or portions thereof may also be custom designed in a schematic editor and captured into an integrated circuit design along with the synthesized circuits. The integrated circuit may include transistors and other circuit elements (e.g., passive elements such as capacitors, resistors, inductors, etc.), as well as interconnects between transistors and circuit elements. Some embodiments may implement multiple integrated circuits coupled together to implement the hardware circuit, and / or discrete elements may be used in some embodiments. Alternatively, the HDL design may be synthesized into a programmable logic array such as a field programmable gate array (FPGA), and may be implemented in an FPGA. This decoupling between the design of a set of circuits and the subsequent low-level implementation of those circuits often leads to a situation where a circuit or logic designer never specifies a specific set of structures for the low-level implementation beyond a description of what the circuits are configured to do, because that process is performed at different stages of the circuit implementation process.

[0083] The fact that many different low-level combinations of circuit elements can be used to achieve the same specification of a circuit results in a large number of equivalent structures for that circuit. As noted, these low-level circuit implementations can vary depending on variations in manufacturing technology, the foundry selected to manufacture the integrated circuit, the cell libraries provided for a particular project, etc. In many cases, the selection made by different design tools or methodologies to produce these different implementations can be arbitrary.

[0084] Furthermore, for a given embodiment, a single implementation of a particular functional specification of a circuit typically includes a large number of devices (e.g., millions of transistors). Thus, the shear volume of this information makes it impractical to provide a complete description of the low-level structure used to implement a single embodiment, let alone the large number of equivalent possible implementations. For this reason, the present disclosure describes the structure of the circuit using functional shorthand commonly used in the industry.

[0085] Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to include all such variations and modifications.

Claims

1. A processor, comprising: one or more registers; and an execution core coupled to the one or more registers, wherein: The execution core is configured to perform a signing operation on the first value to generate a signed value and store the signed value to a storage location for subsequent use; and The execution core is configured to perform the signing operation based on a cryptographic key, a value of a stack pointer stored in one of the one or more registers, and an address storing an instruction corresponding to the signing operation.

2. The processor of claim 1, wherein the signature operation is based on the address and an offset specified by the instruction.

3. The processor of claim 1, wherein the storage location is a register of the one or more registers.

4. The processor of claim 1, wherein the storage location is indicated by the value of the stack pointer.

5. The processor of claim 1, wherein to store the value of the signature to the storage location, the execution core is configured to use a subset of bits of the storage location to store the value of the signature.

6. The processor of claim 1, wherein the signed value is an encrypted partial portion generated from the signing operation on the first value.

7. The processor of claim 1, wherein the signing operation is based on a block cipher algorithm.

8. The processor of claim 7, wherein the block cipher algorithm comprises one of: Advanced Encryption Standard (AES), Data Encryption Standard (DES), International Data Encryption Algorithm (IDEA), or PRINCE.

9. The processor of claim 1 , wherein before performing the signing operation, the execution core is configured to: performing a combine operation on the first value, the value of the stack pointer, and the address of the instruction to generate a combined value; and The signing operation is performed on the combined value based on the encryption key to generate the signed value.

10. The processor of claim 9, wherein the combining operation is based on an XOR function.

11. The processor of claim 1 , wherein before performing the signing operation, the execution core is configured to: performing a combination operation on the address and offset of the instruction to generate a combined value; and The signing operation is performed on the combined value based on the encryption key to generate the signed value.

12. The processor of claim 1, wherein the execution core is configured to perform an authentication operation using the signed value for subsequent use.

13. The processor of claim 12, wherein to perform the authentication operation, the execution core is configured to: obtaining a value from said storage location for subsequent use; Performing a second signature operation on the obtained value to generate a second signed value; The obtained value is authenticated based on the value of the signature and the value of the second signature.

14. The processor of claim 13, wherein to authenticate the obtained value, the execution core is configured to determine whether the value of the signature matches the value of the second signature based on a comparison of the value of the signature with the value of the second signature.

15. The processor of claim 13, wherein the obtained value is a return address of a call to a subroutine terminated by one or more return instructions.

16. The processor of claim 13, wherein the second signing operation is based on the encryption key, the value of the stack pointer, and an address of an initial instruction in the subroutine.

17. The processor of claim 13, wherein the second signing operation is based on the cryptographic key, the value of the stack pointer, and an address storing an instruction corresponding to the authentication operation.

18. A method comprising: Generates a return address for a call to a subroutine terminated by a return instruction; performing a signing operation on the return address to generate a signed return address, wherein the signing operation is based on an encryption key, a value of a stack pointer, and an address of an initial instruction in the subroutine; detecting an attempt by the return instruction to use the signed return address; authenticating the return instruction based on the signed address in response to detecting the attempt; as well as The return is prevented due to a failure to authenticate the return instruction.

19. The method of claim 18, wherein authenticating the signed address in response to detecting the attempt comprises: Obtaining the address of the return instruction; performing a second operation on the obtained address to generate a second signed return address, wherein the second signing operation is based on the encryption key, the value of the stack pointer, and the address of the return instruction; as well as The return instruction is authenticated based on a comparison of the address of the signature and the address of the second signature.

20. The method of claim 18, further comprising: Before performing the signing operation, performing a combine operation on the return address, the value of the stack pointer, and the address of the initial instruction to generate a combined value; as well as The signing operation is performed on the combined value based on the cryptographic key to generate the signed value.

Images