Hardware Support for Software Pointer Authentication in Computing Systems

Abstract

Disclosed are a processor and method for processing information that, in response to a function entry instruction occurring during execution of an application, calculates an entry hash value using a hash of three hashed input parameters, one of the input parameters being a private key stored in a dedicated register; and, in response to a function exit instruction occurring, calculates an exit hash value using the same three input parameters and the same hash used in calculating the entry hash value, and determines whether the entry hash value is the same as the exit hash value.

Description

[Technical Field]

[0001] The present invention relates generally to information and data processing systems, processors, and memory systems, and more particularly to providing improved security to information processing systems, processors, and memory subsystems, for example, while executing software applications. [Background technology]

[0002] Recent advances in information technology and the widespread use of the Internet to store and process information have placed increasing demands on computing systems to acquire, process, store, and distribute information. Computing systems are being developed to increase the speed at which computers can execute increasingly complex applications for business, personal use, and entertainment. The overall performance of a computer system is affected by each of the major elements of the computer's architecture, including the processor, any memory cache, the performance / structure of the input / output (I / O) subsystem, the efficiency of the memory control functions, the performance of the memory devices and memory systems and associated memory interface elements, and the type and structure of the memory interconnection interface.

[0003] Modern computer systems typically contain multiple integrated circuits (ICs), including a processor, which can be used to process information in the computer system. The information processed by the processor can include computer instructions executed by the processor as well as data manipulated by the processor using the computer instructions. The computer instructions and data are typically stored in main memory within the computer system.

[0004] Preventing unauthorized users and / or malicious software from accessing information and data processing systems is becoming increasingly important and difficult to achieve. In some situations, a user or software application may be permitted to have access to an information processing system, processor, register file, or memory subsystem, or a combination thereof, but may not be permitted to have complete access to the complete system, all register files, or all of the memory subsystem. Thus, a user or software application may be permitted to access a portion of the system, but the user and / or software application is not permitted to access the entire system, all register files, or all of the memory subsystem, or a combination thereof. In other situations, a user and / or software application is not permitted to access any portion of the computing system, any portion of the register files, or any portion of the memory subsystem, or a combination thereof. Protecting the system, register files, or memory subsystem, or a combination thereof, from being accessed by unauthorized users and / or software applications can be difficult.

[0005] When application software calls a function, it stores data on the stack, such as code pointers (such as the function's return address) or local variable values ​​or pointer variables. A malicious user can exploit code vulnerabilities, such as buffer overflows, unbounds-checked array accesses, use-after-free, and other techniques to attack and overwrite the contents of the stack, so that a code pointer or data value not intended by the software application is used upon return from the function. This allows the attacker to hijack the program's control flow because the return address is no longer the intended return target. This attack is sometimes called a return-oriented programming (ROP) attack. These techniques can also be used to manipulate software to access data values ​​not intended for the software program to access, disclosing confidential information without affecting control flow. This type of attack is sometimes called a data-oriented programming (DOP) attack. It would be beneficial if such attacks and their techniques could be overcome to provide more secure information processing systems, processors, memory subsystems, and the software applications that run on such systems, devices, and subsystems. Summary of the Invention

[0006] This summary of the disclosure is provided to aid in the understanding of computer systems, computer architectural structures, processors, their methods of operation, and software application execution, including techniques that provide more secure methods of operation of such systems, processors, and software applications running on such systems and / or devices, without intending to limit the disclosure or the present invention. This disclosure is directed to persons skilled in the art. It should be understood that various aspects and features of the disclosure may be used advantageously in some instances individually or in other instances in combination with other aspects and features of the disclosure. Accordingly, variations and modifications may be made to computer systems, architectural structures, processors, register files, their methods of operation, and methods of executing software applications to achieve different effects.

[0007] In one or more embodiments, aspects of the present disclosure provide a system, method, or computer program product, or combination thereof, for processing data in a processor, including: in response to a function call instruction occurring during execution of a software program, calculating an entry hash value using a hash of three hash input parameters, one of the input parameters being a secret key stored in a dedicated register; and storing the entry hash value in a first memory location. In one aspect, the first memory location is at a first offset from a stack pointer in a first general-purpose register. In embodiments, the system, method, or computer program product, or combination thereof, further includes copying a value provided by a link register to a second general-purpose register entry and storing a value from the second general-purpose register entry in a second memory location. Preferably, the second memory location is at a second offset from the stack pointer in the first general-purpose register entry. The three hash parameter inputs for computing the entry hash optionally include a first hash input parameter that is a value in a first general purpose register entry, a second hash input parameter that is a value in a second general purpose register entry, and a third hash input parameter that is a private key. In one aspect, the dedicated register storing the private key is accessible only at a privilege level higher than the privilege level at which the entry hash value is computed.

[0008] In one aspect, the method, system, or computer program product, or combination thereof, further includes, in response to a function exit instruction occurring during execution of the software application, calculating an exit hash value using the same three input parameters and the same hash used when calculating the entry hash value, and determining whether the entry hash value is the same as the exit hash value. In one or more embodiments, the method, system, or computer program product, or combination thereof, further includes, in response to the entry hash value being equal to the exit hash value, executing a function return to terminate the function by the processor, and in response to the entry hash value not being equal to the exit hash value, executing a trap interrupt. The trap interrupt preferably transfers control to an operating system. In a further aspect, in response to a function exit instruction occurring, the entry hash value is read from a second memory location into a third general-purpose register, the value is read from the first memory location into a second general-purpose register, and the value is moved from the second general-purpose register to a link register.

[0009] A system for executing instructions in a software application is disclosed, the system including a processor including circuitry and logic for executing the instructions, the processor comprising: a decode unit having circuitry and logic for decoding the instructions; an issue unit having circuitry and logic for receiving the decoded instructions and issuing the decoded instructions; and an execution unit having circuitry and logic for executing the decoded instructions issued by the issue unit, the execution unit being associated with a dedicated register; the system further includes a non-transitory computer-readable medium having program instructions embodied thereon, the program instructions being executable by the processor to cause the processor to, in response to a function entry instruction being generated, calculate an entry hash value using a hash of three hashed input parameters, one of the input parameters being a private key stored in the dedicated register; and, in response to a function exit instruction being generated, calculate an exit hash value using the same three input parameters and the same hash as used in calculating the entry hash value, and determine whether the entry hash value is the same as the exit hash value.

[0010] A method and / or system for processing data in a processor is disclosed, the method and / or system including: in response to a function call instruction being generated, calculating an entry hash value using a hash of one or more hashed input parameters, one of the input parameters being a private key stored in a dedicated register; in response to a function return instruction being generated, calculating an exit hash value using the same one or more input parameters and the same hash used in calculating the entry hash value; determining whether the entry hash value is the same as the exit hash value; and in response to the entry hash value not equaling the exit hash value, transferring control to an operating system and not executing the function return instruction.

[0011] The foregoing and other objects, features, and advantages of the present invention will become apparent from the following more particular description of exemplary embodiments of the invention, as illustrated in the accompanying drawings, in which like reference numerals generally represent like parts of the exemplary embodiments of the invention.

[0012] Various aspects, features, and embodiments of information processing systems, computer systems, computer architectural structures, processors, register files, their methods of operation, and methods of executing software applications will be best understood when read in conjunction with the provided figures. Although the figures provide embodiments for the purpose of illustrating various aspects, features, or various embodiments, or combinations, of computer systems, computer architectural structures, processors, register files, and their methods of operation, including methods of executing software applications, the claims should not be limited to the exact arrangements, structures, assemblies, subassemblies, functional units, mechanisms, features, aspects, embodiments, devices, methods, processes, or techniques shown, and the illustrated arrangements, structures, assemblies, subassemblies, functional units, mechanisms, features, aspects, embodiments, devices, methods, processes, and techniques may be used alone or in combination with other arrangements, structures, assemblies, subassemblies, functional units, mechanisms, features, aspects, embodiments, devices, methods, processes, or techniques, or combinations thereof. [Brief explanation of the drawings]

[0013] [Figure 1] 1 illustrates a typical computing system or data processing system according to an embodiment of the present disclosure. [Figure 2] FIG. 1 illustrates a processor and memory subsystem according to an embodiment of the present disclosure. [Figure 3] FIG. 2 illustrates a block diagram of a processor in accordance with an embodiment of the present disclosure. [Figure 4] 1 illustrates a flowchart of a method for computing a hash upon function entry during execution of a software program / application on a processor, according to an embodiment. [Figure 5] FIG. 1 illustrates a flowchart of a method for checking a hash when a function exit occurs during execution of a software program / application on a processor, according to an embodiment; and FIG. 2 illustrates a schematic diagram of code for insertion into a software program to check a hash at or before a function exit, according to an embodiment of the present disclosure. [Figure 6] FIG. 10 illustrates a schematic diagram of code to insert into a software program to calculate a hash at a function entry, according to an embodiment of the present disclosure. [Figure 7] FIG. 10 illustrates a schematic diagram of code to insert into a software program to check a hash at or before a function exit in accordance with an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0014] The following description is provided for the purpose of explaining the general principles of the present invention and is not intended to limit the inventive concepts claimed herein. Although the following detailed description sets forth numerous details to provide an understanding of information processing systems, computer systems, computer architecture structures, processors, memories, functional units, register files, memory subsystems, and their methods of operation, including methods for executing software applications, it will be understood by those skilled in the art that many different embodiments of computer systems, computer architecture structures, processors, functional units, register files, memory subsystems, and their methods of operation, including methods for executing software applications, may be practiced without these specific details, and that the claims and the present invention should not be limited to the embodiments, assemblies, subassemblies, structures, arrangements, mechanisms, functional units, features, aspects, processes, methods, techniques, or details specifically described and illustrated herein. Furthermore, particular features, functional units, mechanisms, structures, arrangements, embodiments, aspects, and techniques described herein may be used in combination with other described features, functional units, mechanisms, structures, arrangements, embodiments, aspects, and techniques, in each of a variety of possible combinations and permutations.

[0015] In this specification, unless otherwise specifically defined, all terms are to be given their broadest possible interpretation, including the meaning implied from the specification and the meaning understood by a person skilled in the art and / or as defined in dictionaries, treatises, etc. It should also be noted that as used in this specification and the appended claims, unless otherwise specified, the singular forms "a," "an," and "the" include plural referents, and the terms "comprises" and / or "comprising," when used, indicate the presence of stated features, integers, steps, operations, elements, or components, or combinations thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups thereof, or combinations thereof.

[0016] In the following description, conventional features of information processing systems, including processors (e.g., microprocessors), memory subsystems, and system architectures, and their methods of operation, including methods for executing software applications, that will be apparent to those skilled in the art are omitted or only briefly described. It is assumed that those skilled in the art are familiar with the general architecture of computer systems, memory subsystems, processors, register files, and their methods of operation, including methods for executing software applications. Note that numbered elements are numbered according to the figure in which they are introduced and will typically, but not necessarily, be referenced by that number throughout subsequent figures.

[0017] A computing system or data processing system 100 suitable for use in the present disclosure may take a variety of forms, one of which is shown in FIG. 1, in which the computing system or data processing (information processing) system 100 is configured to store and / or execute program code (e.g., software applications). In one embodiment, the information processing system 100 may include at least one processor 102, which may be or be part of a controller coupled directly or indirectly to memory devices and input / output devices via a system bus 106, as shown in FIG. 1. The computing system 100 of FIG. 1 is shown with the processor 102 (also called a central processing unit (CPU) or microprocessor), random access memory (RAM) 103, non-volatile memory 104, device-specific circuitry 101, and I / O interface 105. Alternatively or additionally, RAM 103 and / or non-volatile memory 104 may be included in processor 102, and device-specific circuitry 101 and I / O interface 105 may also be included in processor 102. Processor 102 may comprise, for example, an off-the-shelf microprocessor, a custom processor, a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), discrete logic, etc., or generally any device for executing digital instructions. RAM 103 is typically used to hold variable data, stack data, executable instructions, etc.

[0018] According to various approaches, non-volatile memory 104 may include any type of non-volatile memory, such as, but not limited to, electrically erasable programmable read-only memory (EEPROM), flash programmable read-only memory (PROM), battery-backed RAM, hard disk drive, etc. Non-volatile memory 104 is typically used to hold executable firmware and any non-volatile data, such as programming instructions and applications that may be executed to cause processor 102 to perform particular functions.

[0019] In some embodiments, I / O interface 105 may include a communications interface that allows processor 102 to communicate with devices external to the controller. Examples of communications interfaces may include, but are not limited to, serial interfaces such as RS-232, Universal Serial Bus (USB), Small Computer System Interface (SCSI), RS-422, or wireless communications interfaces such as Wi-Fi, Bluetooth, Near Field Communication (NFC), or other wireless interfaces. Computing system 100 may communicate with external devices via communications interface 105 in any communications protocol, such as Automation Device Interface (ADI).

[0020] FIG. 2 illustrates an exemplary processing system 180 in which the present disclosure may be practiced, which may be part of a larger computer system architecture or network. The processing system 180 includes a control processor system or processor 102, which is a processing subsystem including at least one processor unit (CPU) 125 that may be configured to interface with a memory control unit (MCU) 140. The CPU 125, also referred to as a microprocessor, may be a module that processes read, write, and configuration requests from a system controller (not shown). The CPU 125 may be a multi-core processor. The MCU 140 may include a synchronous memory controller (MCS) 142 (also referred to as a memory controller) that controls communication with one or more memory devices (e.g., DRAM) (not shown in FIG. 2) in the memory subsystem 103. The MCU 140 and MCS 142 may include one or more processing circuits, or processing may be performed by or in conjunction with the processor 125. The control processor system 102 communicates with the memory subsystem 103 via a communication bus 106 .

[0021] 3 illustrates a block diagram of a processor 102 according to an embodiment of the present disclosure. The processor 102 may be a pipelined processor configured to execute one or more streams of instructions or threads. A thread (also called an instruction stream) comprises a sequence or collection of instructions that together perform a particular task. Threads may be instruction streams from different parts of the same program running on the processor, or instruction streams from different programs running on the processor, or a combination thereof. In one embodiment, the processor may be a multithreaded processor and may process multiple threads simultaneously.

[0022] According to one embodiment, processor 102 may include memory 202, instruction cache 204, instruction fetch unit 206, branch predictor 208, processing pipeline 210, and destination resource 220. Processor 102 may be contained within a computer processor or may be otherwise distributed within a computer system. Instructions and data may be stored in memory 202, and instruction cache 204 may access instructions in memory 202 and store fetched instructions (e.g., instructions for various threads) in cache memory 204. Memory 202 may include any type of volatile or non-volatile memory, such as, for example, cache memory. Memory 202 and instruction cache 204 may include multiple cache levels. A data cache (not shown) may be included in processor 102. Processor 102 preferably allows multiple threads to share its functional units (e.g., instruction fetch and decode unit, cache, branch prediction unit, and execution unit), preferably in a concurrent manner.

[0023] FIG. 3 illustrates a simplified example of an instruction fetch unit 206 and a processing pipeline 210. In various embodiments, the processor 102 may include one or more processing pipelines 210 and an instruction fetch unit 206. In an embodiment, the processing pipeline 210 includes a decode unit 20, an issue unit 22, an execution unit 24, writeback logic 26, a logic register mapper 28, a history buffer (e.g., a save and restore buffer (SRB) 30), and a physical register file 32. The instruction fetch unit 206 and / or the branch predictor 208 may be part of the processing pipeline 210. The processing pipeline 210 may include other features, such as error checking and processing logic, one or more parallel paths through the processing pipeline 210, and other features now or hereafter known in the art. The pipeline may be decomposed and illustrated differently. While FIG. 3 illustrates a forward path through the processor 102, other feedback and signaling paths may be included between elements of the processor 102. The processor 102 may include other circuits, functional units, and components.

[0024] The instruction fetch unit 206 fetches instructions from the instruction cache 204 for further processing by the decode unit 20. The decode unit 20 decodes the instructions and passes the decoded instructions, instruction portions, or other decoded data to the issue unit 22. The decode unit 20 may detect branch instructions not predicted by the branch predictor 208. The issue unit 22 analyzes the instructions or other data and, based on this analysis, sends the decoded instructions, instruction portions, or other data to the execution units 24 in the pipeline 210. The execution units 24 perform the operations specified by the instructions issued to them. The execution units 24 may include multiple execution units, such as a fixed-point execution unit, a floating-point execution unit, a load / store execution unit, a vector / scalar execution unit, or other execution units, or a combination thereof. The physical register file 32 maintains the data for the execution units 24. Logic register mapper 28 contains entries that provide a mapping between logic register entries (LReg) and entries in physical register file 32. When an instruction needs to read a logic register entry (LReg), logic register mapper 28 provides information to issue unit 22 about where the data can be located in physical register file 32, and issue unit 22 provides this information to execution unit 24.

[0025] When a mispredicted branch instruction or other exception is detected, the instructions and data following the mispredicted branch or exception are discarded (e.g., flushed from various units of processor 110). A history buffer (e.g., save and restore buffer (SRB) 30) contains the state of both speculative and architected registers and backs up logic register file data when a new instruction is dispatched. In this regard, the history buffer 30 stores information from logic register mapper 28 when the new instruction is flushed and the old data needs to be restored. The history buffer (SRB) 30 maintains the stored information until the new instruction is completed. The history buffer (SRB) 30 interfaces with the logic register mapper 28 to update pointers in the logic register mapper 28 so that the instruction knows where to get the correct data and to restore the contents of the logic register entries from the history buffer (SRB) 30 to the logic register mapper 28, e.g., returning the processor to the state it was in before the interruptible instruction (e.g., before the branch instruction was mispredicted).

[0026] Writeback logic 26 writes the results of the executed instructions back to destination resources or targets 220. Destination resources 220 may be any type of resource, including registers, cache memory, other memory, I / O circuitry for communicating with other devices, other processing circuitry, or any other type of destination, for the instructions or data being executed. One or more of the processor pipeline units may provide information regarding the execution of conditional branch instructions to branch predictor 208.

[0027] Instructions may be processed within processor 102 in a series of logical, pipelined stages. However, it should be understood that the functionality of these stages may be merged together, such that this particular division of stages is not considered limiting unless a limitation is expressly set forth in the claims herein. Indeed, in Figure 3, some of the stages are shown as a single logical unit for ease of understanding, and related further details are provided below.

[0028] In certain aspects, processor 102 may include multiple execution / processing slices, each slice including one or more of the units shown in FIG. 3 . For example, each processing slice may include its own processing pipeline 210, including functional / execution unit 24. A processor 102 including multiple processing slices may be capable of executing multiple instructions simultaneously (e.g., one instruction in each processing slice simultaneously in one processing cycle). Such a processor including multiple processing slices may be referred to as a multi-slice processor or a parallel slice processor. Simultaneous processing on multiple slices can significantly increase processing speed. In single-thread (ST) mode, a single thread is processed, and in SMT mode, multiple threads are processed, e.g., in one or more embodiments, two threads (SMT2) or four threads (SMT4) are processed simultaneously.

[0029] Information and data processing systems, computer systems, processors, or digital logic systems, or combinations thereof, are vulnerable to attacks, such as return-oriented programming (ROP) attacks, which can hijack control over program flow. It would be advantageous and beneficial to provide systems and techniques for achieving better security against such attacks. In one or more embodiments, more secure information processing systems, processors, and techniques include computing and storing a cryptographic signature upon a function call and verifying the cryptographic signature upon function return (function exit), and in one embodiment, verifying the cryptographic signature before exiting the function and referencing a stack pointer for control over program flow or data access. In one or more embodiments, the cryptographic signature is a hash H(x, y, z) of three parameters, preferably one of which is a private key. In embodiments, a cryptographic signature of the stack pointer calculated using a private key provided elsewhere is utilized. In embodiments, the private key is accessible only in supervisor mode and, in one aspect, is stored in a special purpose register (SPR) at a privilege level above the privilege level at which the hash was computed. In embodiments, enhanced security (e.g., a more secure signature) is provided by the cryptographic strength of the hash function used to calculate the signature and by the private key used as one of the parameters to calculate the hash.

[0030] In one or more embodiments, a new processor instruction is introduced to calculate a cryptographic hash of three parameters, with a first register (preferably a general purpose register (GPR)) providing the first parameter (value), a second register (preferably a general purpose register (GPR)) providing the second parameter (value), and a third register (preferably a special purpose register (SPR)) providing the third parameter. In one or more embodiments, the third parameter is preferably a secret key configured in the special purpose register (SPR). The hash may be represented by RT<=H(RA,RB,<secret key>). In one or more embodiments, the special purpose register (SPR) that stores the secret key is not directly accessible at the privilege level that calculates the hash (e.g., the privilege level that performs the hash calculation), but is accessible at a privilege level above the privilege level that executes the hash calculation instruction.

[0031] In embodiments, a new privileged access only register (SPR) is used to store a current secret key per thread that is accessible only in supervisor mode. In one aspect, the exact function and secret key are implementation-specific, and the secret key can be part of the process's context. In embodiments, the secret key associated with a process in the special-purpose register (SPR) is set before the process is scheduled to a hardware thread. In one or more embodiments, the secret is set at the supervisor level of operation, also known as the state of execution on the processor. In this regard, applications such as email clients and browsers run in a privileged state known as user mode or problem state. Operating systems typically run on processors in a higher-privilege state known as the supervisor privilege state. Within the processor, there are registers that can be directly accessed (e.g., read or written) only in the supervisor privilege state and that cause an access exception if an attempt is made to directly access (read / write) the register in user mode / problem state. In one or more embodiments, a key is held within such a register, and thus this register is considered secret or hidden to applications running in user mode / problem state.

[0032] The special purpose registers (SPRs) for storing the private keys are, in embodiments, per hardware thread registers, and in one aspect, the special purpose registers (SPRs) 35 holding the private keys are in the physical register file 32 associated with the execution unit 24 of the processor 102 shown in Figure 3, although it is contemplated that the special purpose registers (SPRs) 35 holding the private keys may be elsewhere within the processor. For example, the physical register file 32 containing the special purpose registers (SPRs) 35 may reside within the execution unit 24, or another special purpose register (SPR) 35 may be within the execution unit 24, as shown by the dashed lines in Figure 3.

[0033] In one or more embodiments, the new instruction for computing a hash is called “hashgen,” although other terms for the new instruction are contemplated. In embodiments, the new “hashgen” instruction computes a cryptographic hash of three parameters, including, in embodiments, using a secret key value as one of the parameters. In embodiments, the secret key is stored in a special purpose register (SPR) with restricted access, and in one aspect, is stored in an SPR that is accessible only at a privilege level above the privilege level executing the new hash computation instruction (“hashgen”). In embodiments, the cryptographic hash instruction “hashgen” computes a cryptographic hash of a stack pointer provided by a double-word-wide (64-bit) general purpose register (GPR), a tag / context ID by another double-word-wide (64-bit) general purpose register (GPR), and a secret key. In embodiments, the secret key is a double-word (64-bit) field that is not directly accessible at the privilege level executing the cryptographic hash computation instruction (“hashgen”).

[0034] The processor is provided with assistance (e.g., circuitry, logic, firmware, etc.) to support a hash calculation function (i.e., a new ("hashgen") instruction), and the compiler inserts this instruction at appropriate locations, thus protecting the application code from attacks. The calculation of a hash (signature) using the "hashgen" instruction is typically performed at function call, for example, when the processor enters a function within a software application that is supposed to execute multiple instructions. Therefore, at function call time (e.g., at function entry), the hashgen instruction is inserted into the code and the hash (signature) is calculated and stored in memory. Typically, any choice of hash function, including the required input, output, and key width, may be used.

[0035] If the hashes(signatures) do not match, the application / processor may be under attack, so the hashes(signatures) should be checked before or upon returning from the function (e.g., exiting the function) to determine whether they match. Thus, upon function return, e.g., upon function exit, hash(signature2) should be recalculated and checked against hash(signature1) previously calculated and stored in memory upon function entry. In other words, the signature (hash value) should be authenticated so that software pointers are verified to be accurate and pointing to the intended target. In one or more embodiments, hash(signature2) may be recalculated before or upon function exit by using the same instruction used to generate the hash (e.g., the “hashgen” instruction used upon function entry). For example, upon or just before exiting the function, hash(signature2) may be recalculated using the new “hashgen” instruction used to calculate hash(signature1) upon function entry, and the recalculated hash(signature2) may be checked against the hash value(signature1) stored in memory upon function entry. The previously calculated hash (signature 1) stored in memory can be called and loaded, a new or recalculated hash (signature 2) can be generated using the same instruction (e.g., "hashgen") used to generate the hash upon function entry, and the recalculated hash (signature 2) can be compared against the hash value stored in memory (signature 1). If the two hash values ​​match (i.e., signature 1 = signature 2), there is a high probability that there was no malicious attack, and the code can exit (return) from the function and continue operating.

[0036] If the two hash values ​​do not match (signature 1 does not equal signature 2), there was an error and / or the possibility of a malicious attack that should be addressed. In one aspect, if the recalculated hash value (signature 2) and the stored hash value (signature 1) do not match, a trap function may be incorporated. The trap function or trap interrupt may direct control to the operating system if the hashes (signatures) do not match, as opposed to waiting for a fault or allowing a function return instruction to execute. In this regard, a new instruction called "trapne" or "tdne" is used to execute a function that compares the recalculated hash (signature 2) with the hash value from memory (signature 1) and executes a trap function (trap interrupt) if the hash values ​​(signatures) do not match, where control may be transferred to the operating system or some other trap may be established to prevent attacks or to further check for a mismatch (mismatched signatures).

[0037] In embodiments, a new "hashgen" instruction is used to calculate a double-word-sized hash (64 bits) from a double-word (64 bits) pointer, and in one aspect, the calculated hash is stored in a location separate from where the pointer is stored, providing additional security for the processor and software applications running on the processor. The hash calculation acts as a signature, making it more difficult to attack the processor and take control of the processor because modifying a single memory location is no longer sufficient to tamper with the signature and execute an attack. That is, in one or more embodiments, the return address of the stack pointer is saved in one memory location, and the calculated hash (e.g., signature) is stored in another memory location. Thus, to successfully attack a processor operating a software program, modifying only the return address of the stack pointer is not sufficient to take control of the processor and / or the running program.

[0038] Additionally, due to the ability to utilize wider signatures, more secure hash functions can be implemented. For example, a double-word (64-bit) sized hash can be implemented because a wider field is used as a parameter (base value) for calculating the hash. In embodiments, a 64-bit value is used as the signature instead of using a smaller field, such as packing the signature into a portion of the width of a register field (e.g., fitting the signature into a portion (15 bits) of the effective address (EA) itself). In one or more embodiments, if there is a mismatch between the calculated hash and the recalculated hash, a trap exception or trap interrupt is generated when checking the hash to transfer control from the application to system software. A trap exception or trap interrupt is a type of exception that is generated in a processor when a user-mode instruction experiences an error condition (in this case, a mismatch of the stored hash against the recalculated hash) and transfers control to supervisor state. In one aspect, an explicit hash check instruction is provided that transfers control from the running application to system software when a mismatch of the recalculated hash occurs. In an embodiment, if the signature (hash) does not match, an optional trap exception transfers / transitions program control to a supervisor state so that the return instruction is not executed, providing better control than waiting for a failure to occur.

[0039] While one or more embodiments of the present disclosure will be described in further detail, it should be recognized that the invention is not limited to these details unless expressly indicated by the language of the claims. An instruction for computing a hash (preferably a secret hash called "hashgen") takes the form hashgen RT, RA, RB, and performs the function RT <= hash function (RA, RB, secret key SPR), where RT, RA, and RB are all general-purpose registers, preferably 64-bit general-purpose registers. The secret key is preferably a 64-bit key specified by a special-purpose register (SPR) that is not directly accessible at the privilege level performing the hash via the move-to (mtlr) or move-from (mflr) SPR instructions, but is accessible at a privilege level above that privilege level. In an embodiment, RB provides the code pointer being protected (e.g., a general-purpose register that holds the memory address of the code pointer), RA provides the tag / context information (e.g., a general-purpose register that holds the context ID), "private key SPR" is the SPR that holds the private key, and RT is the return register to which the computed hash (e.g., result / signature) is output or returned.

[0040] An instruction to generate a hash at function call time (e.g., when entering a function) is typically used in conjunction with a store instruction to store the hash in memory. Thus, an instruction inserted into the code where the function call (function entry) is located might be used as follows: hashgen RT,RA,RB store RT,D(RA)[Memory[RA+D]<=temp] Here, the operation of storing the output (signature) of the hash calculation in memory is a separate instruction. In an embodiment, the hash calculation instruction "hashgen" outputs the hash signature to another general-purpose register (GPR) (e.g., RT), and then the operation for storing the hash result (signature) in memory may be performed using an existing store instruction (e.g., "std"). That is, the operation for storing the hash calculation (e.g., signature) from RT to memory may be a separate store instruction (e.g., "std"). In an embodiment, the value of the hash calculation may be stored in memory by specifying an offset with respect to an input register that specifies tag / context information.

[0041] In an alternative embodiment, the hash calculation / generation instruction may combine a store operation / instruction with the hash calculation instruction such that the hash calculation result (e.g., signature) is correctly stored in memory without using a separate store ("st") instruction. In an embodiment, the micro-operation that calculates the hash and stores the hash calculation result (signature) from the RT to memory may be a single instruction that may be called "hashgen" or may use the different term "hashst." In one aspect, the single instruction that performs the two micro-operations of calculating and storing the hash may include storing the hash by specifying an offset relative to an input register that specifies tag / context information.

[0042] Re-computing a hash (signature 2) using the same "hashgen" instruction and checking it against a previously computed and stored hash (signature 1) in memory can take the following form: load R1,D(RA) hashgen RT,RA,RB trapne R1,RT [compare and optionally trap if register values ​​differ] Here, "load" R1,D(RA) refers to loading a previously calculated and stored hash (signature1) value into R1, and "hashgen" RT,RA,RB recalculates a hash (signature2) based on the current values ​​in RA,RB, and, in one or more embodiments, an optional secret key. The instruction "trapne" (also called "tdne") checks or compares the hash value (signature1) loaded from memory into R1 against the currently generated hash (signature2) output to RT. In embodiments, the "trapne" or "tdne" instruction may also include a trap function. For example, when comparing the values ​​in the two registers R1,RT, if the values ​​are not the same, control is transferred to the operating system rather than waiting for a fault, or the operation terminates the function rather than executing a function return instruction to continue executing code, or both. An optional trap function (trap interrupt) may be combined with the hash check operation so that a single instruction performs the hash value (signature) comparison and the trap function.

[0043] In an alternative embodiment, a compact form of the instruction can incorporate a memory read instruction and a hash check / trap function into the same instruction. That is, a hash signature check instruction "trapne" or "tdne" (in an embodiment, optionally including a trap function) can incorporate a storage access (i.e., a read instruction to memory). Recalculating the hash (signature2) using the same "hashgen" instruction, reading the hash value (signature1) from memory, checking it against the previously calculated and stored hash (signature1), and optionally including a trap function, can take the following form: hashgen RT,RA,RB trapne R1,RT [compare and optionally trap if register values ​​differ] Here, "trapne" includes the operations of (1) reading a hash value (signature 1) from memory, (2) checking the hash value from memory (signature 1) against the recomputed hash (signature 2), and (3) optionally, if included, performing a trap micro-operation.

[0044] Checking the hash (signature) using the "hashgen" instruction, and in embodiments using the "tdne" or "trapne" instructions, is typically performed before or upon exit from a function within a software application. Thus, the "ld" (load), "hashgen", and "tdne" ("trapne") instructions (and in embodiments, compact forms of instructions incorporating load instructions) are inserted before or upon function exit (at or before the execution of the function return instruction), and the hash (signature 2) is recalculated and checked against the hash (signature 1) previously stored in memory upon or before entry into the function.

[0045] The processor has circuitry, logic, functional units (e.g., dedicated registers for secret keys), firmware, etc. to support the hash calculation function (e.g., a new (hashgen) instruction, or a compact version incorporating a store instruction), as well as the new hash check and optionally trap function (e.g., a "tdne" instruction, or a compact version incorporating a load instruction), and the compiler inserts the new instructions in appropriate places (function calls and function returns), thus protecting the application code from attacks.

[0046] FIG. 4 illustrates an embodiment of a method 400 for implementing a process for protecting a processor, and more particularly, for increasing the processor's resistance to attacks during the execution of a software application. Method 400 is more particularly directed to calculating and utilizing cryptographic signatures to make the processor more secure, particularly during the operation of a software application. While method 400 as illustrated in FIG. 4 is described for convenience and is not intended to limit the disclosure as including a series of steps and / or multiple steps, it should be understood that unless otherwise indicated, the process need not be performed as a series of steps and / or the steps need not be performed in the order shown and described with respect to FIG. 4, but that the process may be integrated and / or one or more steps may be performed together simultaneously, or the steps may be performed in the order disclosed or in another order.

[0047] A method 400 for making a processor executing a software application more secure, e.g., more resistant to attempts to control program flow or gain unauthorized data access, or both, includes, at 410, performing a function entry, e.g., during execution of the software application. In one example, a function call (also called a function prologue) occurs during processing. At 420, upon function entry, a return address value is copied to a general-purpose register (e.g., GRP r0). In one aspect, the copied return address is provided by a link register (LR). In one aspect, the general-purpose register (e.g., GRP r0) is a 64-bit GRP, although other sizes are contemplated. At 430, the return address value from general-purpose register GRP r0 is stored to a memory location. That is, in this example, the value from GRP r0 is moved to the memory location. In one or more embodiments, the value from GRP r0 is preferably stored in memory at an offset (e.g., offset 1) from a stack pointer in general-purpose register GRP r1. For example, this offset can be a negative or positive offset from the stack pointer in GRP r1.

[0048] At 440, a hash (e.g., a signature) is calculated using a hash function H. The hash calculation can include multiple inputs or parameters, and in embodiments, includes three parameters or inputs. In embodiments, the result or output of the hash calculation is generated in GRP r0 and is 64-bit in a preferred embodiment. The three inputs or parameters for the hash calculation are GRP r0, GRP r1, and a value in a special purpose register (SPR). The value in the special purpose register (SPR) is a private key, and in one aspect, the SPR is referred to as "HASHKEYR." In embodiments, the value in the special purpose register HASHKEYR is only accessible from a higher privilege level than the execution of the hash calculation. The hash function H can be any number of hash functions, and the method is not limited by the hash function H selected or used. In embodiments, a predefined hash function is used. The output to GRP r0 can be represented in certain preferred embodiments by r0 = H(GPR r0, GPR r1, HASHKEYR).

[0049] In one or more embodiments, at 450, the hash value output to GRP r0 is stored in a memory location, in embodiments, at another offset (offset 2) from the stack pointer in GRP r1. At 460, the remainder of the function entered at 410 is executed. Function processing is performed, and when the function is complete and the program exits the function (e.g., at function return), further processing is performed to check the hash signature performed on function entry against the recomputed hash performed at function exit.

[0050] FIG. 5 illustrates an embodiment of a method 500 for performing a process for protecting a processor, and more particularly, for increasing the processor's resistance to attacks during the execution of a software application. Method 500 is more particularly directed to calculating and utilizing cryptographic signatures to make the processor more secure, particularly during the operation of a software application. While method 500 as illustrated in FIG. 5 is described for convenience and is not intended to limit the disclosure as including a series of steps and / or multiple steps, it should be understood that unless otherwise indicated, the process need not be performed as a series of steps and / or the steps need not be performed in the order shown and described with respect to FIG. 5, but that the process may be integrated and / or one or more steps may be performed together simultaneously, or the steps may be performed in the order disclosed or in another order.

[0051] A method 500 for making a processor executing a software application more secure, e.g., more resistant to attempts to control program flow or gain unauthorized data access, or both, includes, at 510, generating a function exit (function return) instruction after a function has completed, e.g., during execution of the software application. In one example, during processing of a function, the function completes and terminates or returns (also known as a function epilogue). At 520, a hash signature is loaded from memory into a general-purpose register (e.g., GPR r31) at or before the end of the function. In one example, the value stored at offset 2 from the stack pointer in GRP r1 at function entry, as described at 450, is loaded into GPR r31. At 530, a return address (e.g., stored at offset 1 from the stack pointer in GRP r1, as described with reference to FIG. 4 at 430) is loaded from memory into GPR r31. At 540, the return address is moved from GRP r0 to the link register (LR).

[0052] At 550, a hash (e.g., a signature) is calculated using hash function H. In this regard, at 550, the hash is recalculated using values ​​in the same registers in the same manner as was used to calculate the hash upon entry to the function (e.g., the same manner as the hash was calculated at 440). This hash function H is the same hash function H used to calculate the hash upon function entry. This hash calculation includes the same parameters as were used in calculating the hash upon function entry. In an embodiment, the result or output of this hash calculation is produced in GRP r0 and is the same number of bits as the number of bits used to calculate the hash upon function entry. In an embodiment, the three inputs or parameters for the hash calculation are GRP r0, GRP r1, and the value in a special purpose register (SPR) (e.g., HASHKEYR). The output from 550 to GRP r0 may be represented, in certain preferred embodiments, by r0 = H(GPR r0, GPR r1, HASHKEYR).

[0053] At 560, it is determined whether the value in GRP r31 is the same as the value in GRP r0 (whether the hash signature at function entry equals the hash signature at function exit). If the hash signature values ​​are the same (“Yes” at 560), the process 500 continues to 570, where the security check has passed. At 570, GRP r31 is restored, and a function return or function exit to the address in the link register is performed. At 560, if the hash value in GRP r31 is not equal to the recalculated hash value in GRP r0 (“No” at 560), the process continues to 580, where the security check has failed. In an embodiment, at 580, control is transferred to the operating system (OS) via a trap interrupt.

[0054] An example of an instruction inserted into code to calculate a hash at function call (function entry) time according to an embodiment is described with reference to FIG. 6, in which a new instruction "hashgen" supported in the processor calculates a cryptographic hash of three parameters before or at function entry time during the processing of a software program / application. The calculated cryptographic hash serves as a signature and is stored in general-purpose register (GPR) 31. In FIG. 6, instructions numbers 0 and 1 perform the function of saving values ​​from logic registers. More specifically, instruction 0 (Move From Link Register (mflr)) moves the value from the link register to general-purpose register (GRP) r0, and instruction 1 stores the value from the link register at a memory location at offset 1 from the stack pointer in GRP r1. Instruction 2 executes the "hashgen" instruction to calculate the hash. In a preferred embodiment, a hash is calculated using three inputs, including the value in GRP r0, the value in GRP r1, and a secret key (preferably accessible from a dedicated register at a higher privilege level than the hashgen instruction), and outputs (returns) the hash calculation to r0. Instruction 4 stores the hash value output to GRP r0 into the memory location at offset 2 from the stack pointer in GRP r1. Instruction 5 saves the value in GRP31 into offset 3 from the stack pointer in GRP r1.

[0055] According to an embodiment, an example of an instruction inserted into code, for example, by a compiler, to check a hash signature upon function return (function exit) is described with reference to FIG. 7 , in which a new instruction “tdne” supported in the processor checks a cryptographic hash upon function exit (return) during the processing of a software program / application, and executes a trap interrupt function if the hash signature does not match. In FIG. 7 , instruction 0 loads the hash signature (e.g., the value stored at offset 2 from the stack pointer in GRP r1) calculated and stored in memory upon the function call into GPR 31. Instruction 1 loads the return address (e.g., stored at offset 1 from the stack pointer in GRP r1 during the function entry micro-op) from memory into GPR r0. Instruction 2 moves the return address from GRP r0 to the link register. Instruction 3 executes a “hashgen” instruction to calculate a second hash (signature 2) using the same hash function and parameters used to calculate the first hash calculated upon function call (function entry). The hash is recomputed using three inputs, including the value in GRP r0, the value in GRP r1, and a secret key (preferably accessible from a dedicated register at a higher privilege level than the hashgen instruction), and outputs (returns) the second hash calculation (signature 2) to r0. Instruction 4 checks the hash (signature 1) restored from memory (computed at function entry) against the hash (signature 2) recomputed in instruction 3 of Figure 7 to verify that the signatures match. Instruction 4 also executes an optional trap function if a micro-op is included in the instruction and if the condition is met (i.e., hash signature 1 does not match hash signature 2). Instruction 5 restores (loads) the GPR using the value at offset 3 from the stack pointer in GRP r1, and instruction 6 returns to the address in the link register.

[0056] The present invention may be a system, a method, or a computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium containing computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0057] A computer-readable storage medium may be any tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded devices such as punch cards or ridge-in-groove structures on which instructions are recorded, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as being ephemeral signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through fiber optic cable), or electrical signals transmitted over wires.

[0058] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device over a network (e.g., the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof). This network may include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage on a computer-readable storage medium within each computing / processing device.

[0059] Computer-readable program instructions for carrying out the operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or object-oriented programming languages ​​such as Smalltalk, C++, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, to carry out aspects of the present invention, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions to customize the electronic circuitry by utilizing state information of the computer-readable program instructions.

[0060] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0061] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to create a machine, where the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may be stored on a computer-readable storage medium and capable of directing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0062] The computer-readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operable steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, such that the instructions, which execute on the computer, other programmable apparatus, or other device, perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0063] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, comprising one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may be executed substantially concurrently or may be executed in the reverse order, depending on the functionality involved. It is also noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks included in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified function(s) or operation(s) or executes a combination of special-purpose hardware and computer instructions.

[0064] Additionally, systems according to various embodiments may include a processor and logic integrated with and / or executable by the processor, configured to perform one or more of the processing steps enumerated herein. By integrated, we mean that the logic is embedded in the processor as hardware logic, such as an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), etc. By executable by the processor, we mean that the logic is hardware logic accessible by the processor, software logic (such as firmware, part of an operating system, part of an application program, etc.), or some combination of hardware and software logic, configured to cause the processor to perform a function when executed by the processor. The software logic may be stored in any memory type known in the art, local or remote, or both. Any processor known in the art may be used, such as a software processor module and / or hardware processor, such as an ASIC, FPGA, central processing unit (CPU), integrated circuit (IC), or graphics processing unit (GPU).

[0065] It will be apparent from the description provided above that multiple combinations may be created and the various features of the systems and / or methods described above may be combined in any manner.

[0066] It will further be appreciated that embodiments of the present invention may be provided in the form of a service that is deployed for customers to provide the service on demand.

[0067] The description of various embodiments of the present invention is presented for illustrative purposes, but is not intended to be exhaustive and is not limited to the disclosed embodiments. Many changes and modifications that do not depart from the scope of the described embodiments will be apparent to those skilled in the art. The terms used in this specification are selected to best explain the principles of the embodiments, practical applications, or technical improvements beyond those found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A method of processing data in a processor, the processor comprising: In response to a function call instruction being generated to execute a function, copying a return address value for the function into a second general purpose register; storing the return address value from the second general purpose register in a second memory location; calculating an entry hash value using a hash of three hash input parameters, one of the hash input parameters being the return address value in the second general purpose register and another of the hash input parameters being a secret key stored in a special purpose register; storing the entry hash value in a first memory location; After the function is completed, but before the function terminates, reading the entry hash value from the first memory location into a third register; reading the return address value from the second memory location into the second general purpose register; How to perform.

2. After the function is completed, but before the function terminates, calculating an ending hash value using the same hash and three hash input ending parameters used in calculating the entry hash value; determining whether the entry hash value is the same as the ending hash value; The method of claim 1 , further comprising the processor:

3. After the function is completed, but before the function terminates, responsive to the entry hash value being equal to the termination hash value, executing a function return to terminate the function by the processor; executing a trap interrupt in response to the entry hash value not being equal to the ending hash value; The method of claim 2 , further comprising the processor:

4. a further one of the hash input parameters is a value in a first general purpose register; 4. The method of claim 3, wherein the three hash input end parameters for calculating the ending hash value include a first hash input end parameter that is the value in the first general purpose register, a second hash input end parameter that is the return address value in the second general purpose register, and a third hash input end parameter that is the private key.

5. 5. The method of claim 3, wherein the trap interrupt transfers control to an operating system.

6. Copying the return address value into the second general purpose register comprises: A method according to any preceding claim, comprising copying a value provided by a link register into said second general purpose register.

7. After the function is completed, but before the function terminates, moving said return address value from said second general purpose register to said link register; The method of claim 6 , further comprising the processor:

8. Storing the entry hash value in the first memory location includes:

4. The method of claim 1, further comprising storing the entry hash value in a first general purpose register at the first memory location at a first offset from a stack pointer.

9. Storing the return address value in the second memory location comprises:

9. The method of claim 8, further comprising storing the return address value in the first general purpose register at the second memory location at a second offset from a stack pointer.

10. 5. The method of claim 4, wherein the value in the first general purpose register is tag / context information.

11. The method of any one of claims 1 to 10, wherein the dedicated register storing the private key is accessible only at a privilege level higher than the privilege level at which the entry hash value is calculated.

12. 1. A system for executing instructions in a software application, comprising: a processor; a computer-readable medium storing program instructions; wherein the program instructions cause the processor to: In response to a function call instruction being generated to execute a function, copying a return address value for the function into a second general purpose register; storing the return address value from the second general purpose register in a second memory location; calculating an entry hash value using a hash of three hash input parameters, one of the hash input parameters being the return address value in the second general purpose register and another of the hash input parameters being a secret key stored in a special purpose register; storing the entry hash value in a first memory location; and the program instructions cause the processor to: After the function is completed, but before the function terminates, reading the entry hash value from the first memory location into a third register; reading the return address value from the second memory location into the second general purpose register; A system that executes the following.

13. The program instructions may cause the processor to: After the function is completed, but before the function terminates, calculating an ending hash value using the same hash and three hash input ending parameters used in calculating the entry hash value; determining whether the entry hash value is the same as the ending hash value; in response to the entry hash value being equal to the exit hash value, the processor executing a function return to exit the function; executing a trap interrupt in response to the entry hash value not being equal to the ending hash value; The system of claim 12 , wherein the system executes the following:

14. 14. The system of claim 13, wherein executing the trap interrupt transfers control to an operating system.

15. a further one of the hash input parameters is a value in a first general purpose register; 15. The system of claim 13 or 14, wherein the three hash input end parameters for calculating the ending hash value include a first hash input end parameter that is the value in the first general purpose register, a second hash input end parameter that is the return address value in the second general purpose register, and a third hash input end parameter that is the private key.

16. Copying the return address value into the second general purpose register comprises: copying the value provided by the link register into said second general purpose register; wherein the program instructions cause the processor to: After the function is completed, but before the function terminates, moving said return address value from said second general purpose register to said link register; The system according to any one of claims 12 to 15, further comprising:

17. Storing the entry hash value in the first memory location includes: storing the entry hash value in a first general purpose register at a first memory location at a first offset from a stack pointer; Storing the return address value in the second memory location comprises:

15. The system of claim 12, further comprising storing the return address value in the first general purpose register at the second memory location at a second offset from a stack pointer.

18. 16. The system of claim 15, wherein the value in the first general purpose register is tag / context information.

19. The system of any one of claims 12 to 18, wherein the dedicated register storing the private key is accessible only at a privilege level higher than the privilege level at which the entry hash value is calculated.

20. 1. A method of processing data in a processor, the processor comprising: In response to a function call instruction being generated to execute a function, copying a return address value for the function into a second general purpose register; storing the return address value from the second general purpose register in a second memory location; calculating an entry hash value using a hash of one or more hash input parameters, one of the hash input parameters being the return address value in the second general purpose register and another of the hash input parameters being a secret key stored in a special purpose register; storing the entry hash value in a first memory location; After the function is completed, but before the function terminates, reading the entry hash value from the first memory location into a third register; reading the return address value from the second memory location into the second general purpose register; calculating an ending hash value using the same one or more hash input ending parameters and the same hash used in calculating the entry hash value; determining whether the entry hash value is the same as the ending hash value; in response to the entry hash value not being equal to the exit hash value, transferring control to an operating system and not executing a return instruction of the function; How to perform.

21. A computer program comprising instructions which, when executed by the processor, cause the processor to carry out a method according to any one of claims 1 to 11.

22. A computer-readable recording medium having the computer program according to claim 21 recorded thereon.

Images