TW202407538A - No-operation-compatible instruction - Google Patents

Abstract

An apparatus comprises an instruction decoder to decode instructions; processing circuitry to perform data processing in response to decoding of the instructions by the instruction decoder; and at least one control register to specify instruction-function-selecting information. In response to a no-operation-compatible instruction, the instruction decoder is configured to control the processing circuitry to: treat the no-operation-compatible instruction as a no-operation instruction, when the instruction-function-selecting information specified by the at least one control register is in a first state; perform both a first operation and a second operation, when the instruction-function-selecting information specified by the at least one control register is in a second state; and perform the first operation but not the second operation, when the instruction-function-selecting information specified by the at least one control register is in a third state.

Description

No operational compatibility instructions

This technology is related to the field of data processing.

A data processing device has processing circuitry for performing data processing in response to instructions decoded by an instruction decoder. The format of instruction encoding and the functions represented by each instruction can be defined according to the instruction set architecture (ISA). The ISA represents a framework of agreement between hardware manufacturers who make the processing hardware for a given processor implementation and software developers who write code to run on that hardware, such that code written in accordance with the ISA will Works correctly on ISA-capable hardware. Selecting instructions supported by the ISA and its encoding can present design challenges. When planning the instruction definition of an ISA, the design decisions made by the ISA designer can have a significant impact on the real-world performance achieved by the processing hardware when executing a specific program.

At least some examples provide an apparatus that includes: an instruction decoder to decode instructions; processing circuitry to perform data processing in response to decoding of the instructions by the instruction decoder; and at least one control register, with specified instruction function selection information; wherein: in response to a non-operation compatible instruction, the instruction decoder is configured to control the processing circuitry to: when the instruction function selection information specified by the at least one control register is in When in a first state, the no-operation compatible instruction is regarded as a no-operation instruction; when the instruction function selection information specified by the at least one control register is in a second state, a first operation is performed and a second operation; and when the command function selection information specified by the at least one control register is in a third state, the first operation is performed but the second operation is not performed.

At least some examples provide a method that includes: decoding instructions; and performing data processing in response to decoding of the instructions; wherein: in response to decoding of a no-op compatible instruction, the method includes: when stored by at least one control buffer; When the instruction function selection information specified by the controller is in a first state, the no-operation compatible instruction is regarded as a no-operation instruction; when the instruction function selection information specified by the at least one control register is in a second state when the command function selection information specified by the at least one control register is in a third state, perform the first operation but not perform the Second operation.

At least some examples provide a computer program including instructions that, when executed by a host data processing device, control the host data processing device to provide an instruction execution environment for executing object code, the computer program including: an instruction decoding program Logic to decode the instructions of the object code; and register emulator logic to maintain data in the storage circuitry of the host data processing device to emulate at least one control register for designated instruction function selection information; wherein : In response to a no-op compliant command, the command decode program logic is configured to control the host data processing device to: treat the no-op compliant command as if the command function selection information is in a first state A no-operation instruction; when the instruction function selection information is in a second state, perform both a first operation and a second operation; and when the instruction function selection information is in a third state, execute the third operation one operation but does not perform the second operation.

The computer program can be stored on a storage medium. The storage medium may be a non-transitory storage medium or a transitory storage medium.

A device includes: an instruction decoder to decode instructions; processing circuitry to perform data processing in response to decoding of the instructions by the instruction decoder; and at least one control register to specify instruction function selection information. . In response to a no operation compatible (NOP compatible) instruction, the instruction decoder controls the processing circuitry to: when the instruction function selection information specified by the at least one control register is in a first state, The NOP compatible instruction is regarded as a no-operation (NOP) instruction; when the instruction function selection information specified by the at least one control register is in a second state, both a first operation and a second operation are performed. ; and when the command function selection information specified by the at least one control register is in a third state, the first operation is performed but the second operation is not performed.

NOP-compliant instructions can be used to perform optional operations that, if executed, may be useful but are not critical to the correct operation of the software program using the instructions. For example, the first operation and the second operation may be operations that provide optional security enhancement or performance prompting operations, which may help improve security and/or performance even though they are not necessary to obtain correct operating results of the program. These enhancements may not necessarily be required, and thus what is desirable is to be able to control, on a given instance executing a sequence of code that includes instructions for performing one or both of the first operation and the second operation, whether the The operation is actually performed. Not performing these operations can help save power or allow analysis of how the same code will run on legacy hardware that does not support the optional operations. By controlling the function of the instruction based on the instruction function selection information stored in at least one control register, the same program code can be executed in different usage scenarios, where the first operation and the second operation depend on the current value of the instruction function selection information. The different results (if any) of the two operations are executed by the processing circuitry in response to the instructions.

When the command function selection information is in the first state, the command acts like a NOP command. The NOP instruction can be an instruction whose execution does not result in any change in the architectural state except the change of the program counter. The change of the program counter can be implicit in the program flow that advances sequentially from the NOP instruction to the next instruction after the NOP (without branch). Therefore, the software developer has the option of turning off the features represented by the first and second operations together. This may be useful, for example, where the first operation and the second operation correspond to features introduced in newer ISA versions, which may not be available on legacy devices supporting older ISA versions. Another use case may be that the first and second operations may not always be required (for example, when executing code for a less safe use case, before executing a sequence of code that includes a NOP-compliant instruction, the The function selection information is returned to the first state, and the security enhancement represented by the first and/or second operation is turned off to save power).

When the instruction function selection information is in the second state, the processing circuit system performs both the first operation and the second operation in response to the NOP compatible instruction. When the command function selection information is in the third state, the processing circuit system performs the first operation in response to the NOP compatible instruction, but does not perform the second operation. Typically, to provide whether different combinations of a first operation and a second operation are performed by a sequence of code, one would expect each operation to be encoded in a separate instruction, such that performing the combination of two operations would require two different instructions, and if this is required only one of these operations, then only one of these instructions will be included in the software code. However, with the NOP compatible instructions described above, both the first and second operations can be executed in response to the same instruction (and the option with the same instruction executed is that only the first operation is executed, but not the second operation) ). Therefore, identical code bins for a portion of code that includes a NOP-compliant instruction may behave in different ways depending on how the instruction function selection information has been executed prior to executing that portion of the code. This provides a more efficient ISA encoding than an implementation that provides two different NOP compliant instructions corresponding to the first operation and the second operation respectively. First, this avoids the need for the ISA to use up to two different instruction encodings for different NOP-compliant instructions corresponding to the first operation and the second operation, saving encoding that could be used for another type of instruction, and thus improving usage The performance of the code for the other type of instruction (compared to the need to split the operation of the other type of instruction into multiple simpler instructions). Furthermore, software code using NOP-compliant instructions will only require processing circuitry to use a single instruction slot for instructions in the fetch, decode, issue, and execution stages of the processing pipeline (and the instruction cache or instruction in another memory that stores the executing code), which saves an instruction slot used by another instruction that performs a different operation, and therefore improves performance, as well as improving the code in the cache and in memory Storage density.

Therefore, the NOP compliant instructions described above can help improve the performance and efficiency of ISA encoding for use cases where optional operations may not always be required.

In some examples, NOP-compliant instructions may not support the option of performing a second operation without performing the first operation. For example, any remaining encoding of the instruction function selection information (in addition to the first, second, and third states described above) may be used to control other features of how the first or second operation is performed (e.g., adjust the first operation or a control parameter of the behavior of the second operation), rather than indicating that the second operation should be performed but the first operation should not.

However, in other examples, when the instruction function selection information is in a fourth state, in response to the NOP compliant instruction, the instruction decoder may control the processing circuitry to perform the second operation, but not execute The first operation. This can be particularly useful so that NOP compatible instructions can be used to perform the first operation but not the second operation, or the second operation but not the first operation, or both operations together, or can act as a NOP , making both the first operation and the second operation unexecutable. Therefore, the command function selection information can be used to independently turn on and off each of the first operation and the second operation. This provides the same flexibility in selecting which operation is performed as would be the case if each of the first and second operations were encoded as different NOP-compliant instructions, but with more efficient instruction encoding.

In some examples, when the command function selection information is in the second state, the processing circuitry may control a relative sequence of applying the first operation and the second operation based on the command function selection information. For example, a first operation may be performed before a second operation, or the second operation may be performed before the first operation, or both operations may be performed in parallel. Command function selection information may be used to select between two or more of these options. This can be useful because one order between the first operation and the second operation can have advantages over the other order. For example, the first order may provide greater security, but the second order may be more efficient for performance. Thus, control states are provided that allow configurations of the relative order of use to be used to allow the same code binary to execute with different use cases, which may have different preferences for priority security and/or processing performance.

A wide range of processing operations can be implemented as the first operation and the second operation respectively.

However, NOP compliant instructions may be particularly useful for function preamble operations associated with function calls. Therefore, for the function preamble variant of the NOP compliant instruction, the first operation and the second operation are the function preamble operations associated with the function call. For example, a function preamble operation may be a preliminary operation performed before entering the function body, before, during, or shortly after making a function call. Because the same function can be called a large number of times during the execution of a given software workload, even relatively small performance savings achieved on a single instance of the calling function can result in a large improvement in overall software workload performance because the improvement is The function is visible every time it is called. Therefore, by enabling the first operation and the second operation associated with the function call to be executed in response to a single NOP-compliant instruction, rather than requiring multiple instructions, this can provide significant performance improvements to the overall workload.

For similar reasons, NOP-compliant instructions may be used in function wrap-up operations associated with returns from processing of a function. These can be operations performed after the main body of the function has completed, in preparation for returning to the background process that called the function. Such wrap-up operations can be performed before, during, or after the return branch that actually returns processing to background processing. Therefore, for the function wrap-up variant of the NOP-compliant instruction, the first operation and the second operation are the function wrap-up operations associated with the return from the processing of the function.

In some examples, for at least one variant of the NOP-compliant instruction, one of the first operation and the second operation includes an authentication code generation operation to generate an authentication code based on an operand, and The authentication code is associated with the operand.

This authentication code generation operation can be applied to any operand, but is particularly useful where it is applied to a function return address that is set on a function call to indicate a subsequent return branch once the function body has completed. The address of the instruction processed should be returned to provide defense against Return-oriented-programming (ROP) attacks.

ROP attacks are a common type of attack on data processing systems. A ROP attack is an attack that attempts to cause a program to behave in an unexpected manner by corrupting the return status information used to return from function calls or exceptions. Typically, software will store return status information in memory, for example, to facilitate nesting of function calls or exceptions. Before the return status information available for an inner function call or exception overwrites in the scratchpad the return status information for an outer function call or exception (a nested collection of function calls or exceptions), the return status information for an outer function call or Exception return status information can be saved to memory to preserve it. ROP attacks can attempt to tamper with return status information while it is stored in memory before it is restored to a register and used to control function returns or exception returns. A successful ROP attack can cause a function return or exception return to return program flow to an instruction other than the next instruction after the point where the function was called or the exception was taken, which can allow the attacker to control the processing circuitry to execute the programmer's Any operation outside the intended sequence of operations.

Authentication code generation helps protect against such ROP attacks by generating authentication codes corresponding to operands (e.g., function return addresses) so that subsequent attempts to tamper with operands stored in memory can be based on experience. Delete the mismatch between the tampered operand and the corresponding authentication code. If the operand has been tampered with, the authentication code may no longer correspond to the operand. Although the authentication code generation operation can be used for security, it is not necessary, and in some use cases it is better to omit the authentication code generation operation for performance reasons. Therefore, it may be useful to provide NOP-compliant instructions whose implementation responds to the instructions by selecting whether to perform the authentication code generation operation, so that the same sequence of code can be executed differently in different contexts as to whether to perform the authentication code generation operation. result. Therefore, it may be useful for one of the first operation and the second operation to include an authentication code generation operation.

Although the operand used in the authentication code generation operation can be any operand (e.g., an operand obtained from a register specified by a NOP-compliant instruction), in some examples, the operand includes an operand obtained from a linked register. of a value. In response to a function return branch instruction, the instruction decoder may control the processing circuitry to branch to an address specified in the link register. Therefore, when applying an authentication code generation operation to an operand in a link register, typically the operand used for the authentication code generation operation can be the function return address. This can be useful to provide defense against ROP attacks. In the case where an authentication code generation operation is applied to a function return address, then this may be an example of a function preamble operation as discussed above, as this is typically the case where this operation will be related to the execution of a function call.

In the authentication code generation operation, the generated authentication code can be associated with the operands in different ways. For example, the authentication code may be stored in a specific register that has a known association with the register providing the operand. However, this may not be necessary, and in some cases the authentication code may be embedded as part of the operand itself. Thus, associating the authentication code with the operand may include embedding the authentication code in a portion of the more significant bits of the operand. This can be useful because, by embedding the authentication code in the operand itself, this means that any subsequent operation to move the operand from one location to another (e.g., pushing the operand from a register to The stacked data structure in memory) also implicitly causes the authentication code to be transferred together with the operand, without the need for a separate operation to transfer the authentication code. More significant bits of the operand may be used to represent the authentication code because, in general, although in practice processor architectures can support addresses with a certain number of bits (e.g., 64 bits), real-world data processing devices may not yet Memory storage using the entire 64-bit address space is required. So while an address can be 64 bits, in practice only a smaller number of bits are used, with the most significant bits corresponding to zeros (or some other fixed value). Therefore, since some upper bits are practically unused, these bits can be replaced by an authentication code (the authentication code can be inserted into any subset of these unused bits at the upper end of the address).

The authentication code generation operation may include generating the authentication code according to a cryptographic function based on at least the operand and a key. By generating the authentication code based on a cryptographic security function (such as QARMA-64, QARMA-128 or SHA256), for example based on a key, the authentication code can be generated in a manner that makes it difficult for an attacker to predict the authentication code corresponding to a given address.

In some instances, the authentication code may also depend on modifier input to the password function. The modifier may, for example, be a value associated with the current point of processing, such as a current value of a stack pointer. This helps prevent reuse attacks, in which the attacker obtains a valid operand authentication code pair used at one point in the program and attempts to substitute that operand for a different operand used at a different point in the program.

In some examples, for at least one variant of the NOP compliant instruction, one of the first operation and the second operation includes a guarded-control-stack (GCS) push operation to push the The operand is pushed to a GCS data structure that protects the returned status information. This type of GCS push operation is another example of a defense against ROP attacks, but instead of relying on assigning authentication codes to protect return status from tampering, a protected GCS data structure can be created that has at least one defense to limit the GCS data The ability to write data into the structure provides some additional protection relative to normal memory areas. Again, a GCS push operation can be an instance of a function preamble operation, as it can be used to perform a GCS push operation on the function return address when calling the function. While such a GCS push operation can be used for security, it has a performance cost, and therefore some use cases with lower security requirements may prefer not to perform it. Thus, a GCS push operation is another instance of an operation that can be efficiently implemented using NOP-compliant instructions such that the same sequence of code including NOP-compliant instructions can be executed in different use cases, where the instruction function selection information controls GCS Whether the push operation is actually performed.

The NOP-compliant instruction is particularly useful in a variant of the NOP-compliant instruction, wherein one of the first operation and the second operation includes an authentication code generation operation to generate an authentication code based on an operand, and associating the authentication code with the operand; and the other of the first operation and the second operation includes a protection control stack (GCS) push operation to push the operand to the protection return status information A GCS data structure. Since the authentication code generation operation and the GCS push operation can be considered as alternative techniques for protecting function return state from ROP attacks, they are usually required at the same program point (which is associated with the function call), and it is therefore useful to separate them etc. are combined into a single command, with the option to turn off one or both of these operations. Although both operations nominally protect against the same class of attacks, they can have different pros and cons, and therefore for "defense depth" some developers may wish to include both measures so that they can be used to support a function call option to perform two actions. By using NOP compatible instructions, only a single instruction can be executed to perform both types of operations (in the case where the instruction function selection information is in the second state).

In the case where the first operation and the second operation are the authentication code generation operation and the GCS push operation respectively (or vice versa), there may be a different order between these operations. Some implementations may thus allow selection of which order to use, depending on the instruction function selection information.

In response to the NOP-compliant instruction, when the instruction function selection information is in one of the first sub-states of the second state, the processing circuitry may push both the operand and the authentication code to the GCS data structure ( For example, this may correspond to first performing the authentication code generation operation to embed the authentication code in the operand, and then performing a GCS push operation on the result of the authentication code generation operation). This approach improves security by using GCS data structures to protect authentication codes.

In response to the NOP-compliant instruction, when the instruction function selection information is in one of the second sub-states of the second state, the processing circuitry may push the operand but not the authentication code to the GCS data structure . In this case, the authentication code generation operation and the GCS push operation may be independent of each other, and thus may be performed in parallel or in either order. This improves performance by supporting the option to execute them in parallel, but means that the GCS data structure does not protect the authentication code.

In another example, for at least one variant of the NOP compliant instruction, one of the first operation and the second operation includes an authentication code check operation to check an associated authentication associated with an operand whether the code matches an expected authentication code generated based on the operand, and an error handling response is triggered in response to detecting a mismatch between the associated authentication code and the expected authentication code. This operation can be used to check the validity of the authentication code generated by the authentication code generation operation described above, and although it can be performed on any operand, it can usually be performed as a function wrap-up operation to check the return address Is it safe to use (as mentioned above to defend against ROP attacks). Therefore, for the corresponding reason of the authentication code generation operation, the NOP compliant instructions can be used for the authentication code checking operation.

In some examples, the authentication code associated with the authentication code checking operation may be obtained from a portion of the more significant bits of the operand.

In a corresponding manner to the authentication code generation operation, in the authentication code checking operation, the expected authentication code may be based on at least the operand and a key (and in some cases also based on modifiers (such as stacking indicators)) according to Generated by password function.

For at least one variant of the NOP compliant instruction, one of the first operation and the second operation may include a protection control stack (GCS) fetch operation to return information from a GCS data structure used to protect the function Retrieve function returns information. This can be used to obtain return status information that was previously pushed to the GCS data structure by a previous GCS push operation. For similar reasons for GCS push operations, GCS fetch operations (instances of function wrap-up operations) can be implemented using NOP-compliant instructions.

Third, some variations of NOP-compliant instructions may support both authentication code checking operations and GCS fetching operations. Accordingly, one of the first operation and the second operation may include an authentication code checking operation to check whether an associated authentication code associated with an operand matches an expected authentication code generated based on the operand , and triggering an error handling response in response to detecting a mismatch between the associated authentication code and the expected authentication code; and the other of the first operation and the second operation includes a protection control stack (GCS) fetch operation to fetch function return information from a GCS data structure used to protect the function's return information. These operations can be used to combine into the same NOP compatible instruction because if both are required, they will usually be executed at the same point in the program, as before the function returns and after the completion of the main body of the function. Function closing operation.

The sequence between the authentication code checking operation and the GCS retrieval operation can be controlled based on the command function selection information. In response to the NOP compliant instruction, when the instruction function selection information is in one of the first sub-states of the second state, the processing circuit system can perform the GCS fetch operation and perform the authentication code check operation on the GCS A fetch operation retrieves a value from the GCS data structure; and in response to the NOP compatible instruction, when the instruction function selection information is in one of the second sub-states of the second state, the processing circuit system may execute the The authentication code is performed before the GCS fetch operation to check a value in a given register, and the GCS fetch operation is performed to fetch the function return information from the GCS data structure to the given register. Again, this provides different options for trade-offs between performance and security.

For the case where a NOP compatible instruction implements a GCS push operation or a GCS fetch operation as one of the first/second operations, respond to the NOP compatible instruction when the instruction function selection information indicates access to the GCS data structure In a state of execution in response to a NOP-compliant instruction (i.e., when one of a GCS push operation and a GCS fetch operation is to be executed), the processing circuitry may respond to detection of the NOP-compliant instruction. A memory region at a target address that is specified by the memory attribute data as a memory region other than the GCS region used to store the GCS data structure denies memory accesses triggered by NOP-compliant instructions. Therefore, access to memory areas not designated as GCS data structures may be denied if the access is triggered by an instruction of the GCS access type. This prevents GCS access type instructions (including NOP compatible instructions when performing a GCS push operation or a GCS fetch operation) from being misused to access memory areas that are not intended to store GCS data structures, which can reduce The attack surface available to attackers.

Similarly, the processing circuitry may reject a non-GCS access type in response to detecting that a memory region corresponding to a target address of the non-GCS access type instruction is specified by the memory attribute data as the GCS region. A write memory access triggered by the command. By limiting the ability to write to the GCS area to GCS access type instructions (including NOP compatible instructions when the instruction function selection information is in a state indicating that a GCS access will be performed), other more general memory storage Instructions cannot tamper with the contents of the GCS data structure, providing a greater security guarantee for the protected return status information stored in the GCS data structure. Again, this reduces the attack surface that attackers can exploit when trying to install ROP attacks.

Command function selection information can be represented in different ways. In some examples, the first, second, and third states mentioned earlier correspond to different (possibly arbitrarily selected) encodings of command function selection information. Therefore, any mapping between different combinations of first, second, and third states and bit values of the command function selection information may be used.

However, in some instances, it may be useful for the instruction function selection information to include a first operation indicator to indicate whether the first operation will be executed in response to the NOP compliant instruction; and a second operation indicator , to indicate whether the second operation will be executed in response to the NOP-compliant instruction. For example, the instruction function selection information may include a set of bits, each bit corresponding to one of the operations that may be selected to be performed in response to the NOP-compliant instruction, and indicating whether the operation needs to be performed. This encoding of instruction function selection information can be easily understood by software developers and simpler to decode by processing circuitry hardware or instruction decoders because the selection of each operation depends only on a single indicator (e.g., a single bit) rather than More complex decoding circuit logic is required.

In some instances, a NOP-compliant instruction may support options selected from more than two operations based on instruction function selection information. Therefore, the instruction function selection information may further indicate whether the processing circuit system should perform a third operation in response to the NOP-compliant instruction. For example, the instruction function selection information includes a set of bits, each indicating whether a respective operation should be performed in response to the NOP-compliant instruction, which can relatively efficiently add support for desired additional operations. Therefore, while the examples discussed below show examples with two operations, the scope of the patent claims is not limited thereto and additional operations may be supported.

The techniques discussed above may be implemented within a data processing device having hardware circuitry provided for implementing the processing circuitry and instruction decoders discussed above.

However, the same techniques may also be implemented within a computer program that is executed on a host data processing device to provide an instruction execution environment for the execution of object code. This computer program can control the host data processing device to simulate the architectural environment it would provide on a hardware device that actually supports object code based on an instruction set architecture, even if the host data processing device itself does not support the architecture. The computer program may have instruction decode program logic and register emulation program logic that control the host data processing device to emulate the features discussed above, including support for NOP-compliant instructions as described above. The instruction decoder logic decodes the instructions of the object code and generates instructions for the native architecture supported by the host to emulate the functionality represented by the decoded instructions in the object code. Register emulator logic maintains data in the storage circuitry of the host data processing device to emulate the contents of at least one control register, including the register(s) that store command function selection information as discussed above device. Therefore, when the object code including the NOP-compatible instructions is executed in the instruction execution environment provided by the simulated computer program executed on the host data processing device, even if the host data processing device itself does not support the NOP-compatible instructions, the above can be achieved. The same functions as discussed in the article.

For example, this emulation may be useful when code written for one instruction set architecture is executed on a host processor that supports a different instruction set architecture. Furthermore, because the execution of software on a simulated execution environment allows software testing to be paralleled by the ongoing development of hardware devices that support the new architecture, simulation can allow software development for a newer version of the instruction set architecture to support the new architecture. Processing of the architectural version begins before the hardware is ready. The simulation program may be stored on a storage medium, which may be a non-transitory storage medium.

Figure 1 schematically illustrates an example of a data processing device 2. The data processing device has a processing pipeline 4 consisting of several pipeline stages. In this example, the pipeline stages include a fetch stage 6 for fetching instructions from the instruction cache 8; a decode stage 10 for decoding fetched program instructions to generate micro-operations to be processed by the remaining stages of the pipeline. operation) (decoded instruction); used to check whether the operands required by the micro-operation are available in the register file 14, and to issue the available micro-operation system for executing the required operands of a given micro-operation once Release level 12; execution level 16 for performing data processing operations corresponding to micro-operations that produce result values by processing operands read from the scratchpad file 14; and for writing the results of the processing back to scratchpad Write back level 18 of device file 14. It should be understood that this is only one example of a possible pipeline architecture and other systems may have additional stages or different stage configurations. For example, in an out-of-order processor, a register cache may be included for mapping architectural registers specified by program instructions or micro-operations to physical register descriptors identifying physical registers in register file 14 . Named level. In some examples, there may be a one-to-one relationship between program instructions decoded by decode stage 10 and corresponding micro-operations processed by the execution stage. There may also be a one-to-many or many-to-one relationship between program instructions and micro-operations, such that, for example, a single program instruction can be divided into two or more micro-operations, or two or more program instructions can be fused to function as a single micro-operations to handle.

Execution stage 16 (an example of processing circuitry) includes a number of processing units for performing different types of processing operations. For example, the execution unit may include a scalar arithmetic/logic unit (ALU) 20 for performing arithmetic or logical operations on scalar operands read from the register 14; for performing operations on floating point values; a floating point unit 22; a branch unit 24 for evaluating the results of the branch operation and adjusting the program counter accordingly representing the current execution point; and for performing load/store operations to access the memory system 8, 30, 32, 34 data loading/storage unit 26. A memory management unit (MMU) 28 is provided, which is an example of a memory management circuit system, for executing the virtual address specified by the load/store unit 26 based on the operand of the data access instruction. Address translation to and from a physical address that identifies where data is stored in a memory system. The MMU has a translation lookaside buffer (TLB) 29, which is used to cache address translation data from the page table cache stored in the memory system, where the page table entry of the page table defines the address translation mapping and storage. Access permissions, which (for example) control whether a given program executing on the pipeline is allowed to read or write data from a given memory area or execute instructions. MMU 28 may have circuitry to request memory access during a page table walk when the page table structure is traversed to locate the page table entry corresponding to the desired address.

In this example, the memory system includes L1 data cache 30 , L1 instruction cache 8 , shared L2 cache 32 , and main system memory 34 . It will be understood that this is only one example of a possible memory hierarchy and that other configurations of cache memory may be provided. The specific type of processing units 20 - 26 shown in execution stage 16 is one example only, and other implementations may have different sets of processing units or may include multiple instances of the same type of processing units such that multiple processing units may be processed in parallel. micro-operations of the same type. It should be understood that Figure 1 is only a simplified representation of some components of a possible processor pipeline implementation, and that the processor may include many other elements not shown for the sake of brevity. Although FIG. 1 shows a single processor core with access to memory 34, the device 2 may also have one or more additional processor cores that share access to memory 34, with each core having its own processor core. Take memory 8, 30, 32.

FIG. 2 shows examples of some registers 14 of the device 2 . It should be understood that not all registers are shown in Figure 2 - the device may include other registers as well. A set of general-purpose registers 50 are provided for storing general-purpose operation elements and results of processing operations. Some of these general purpose registers may also have more specific functions, such as a link register (LR) used to store function return addresses, which may use one of the general purpose register identifiers ( For example, register X30) to address. The register also includes a stack pointer (SP) register 52 for storing stack pointers. The device also has control registers 56 for storing control information used to control the operation of the processor. For example, control register 56 may include a guard control stack (GCS) stack pointer register 58 that controls access to the GCS, as discussed further below with respect to FIG. 6; and at least one register, It provides instruction function selection information 60 used to control the behavior of NOP-compliant instructions as discussed further below. Although FIG. 2 shows the command function selection information 60 as a single register, this information may also be divided into two or more registers.

Figure 3 shows an example of a NOP compliant instruction 70. The instruction encoding includes an operation code 72 that identifies the instruction type, and one or more operand fields 74, 76 used to specify the operands of the instruction. Operands 74, 76 may be specified using an immediate value, or using a register identifier specifying the register 14 in which the operand is stored, or a combination of at least one immediate value and at least one register identifier. In some cases, the instruction may also specify an additional destination field of the register that identifies the result of the instruction to be written, or alternatively target one of the operand fields that may also serve as the destination register. One of the specified registers. Although Figure 3 shows two operands for the sake of example, other instances of NOP-compliant instructions may have larger or smaller numbers of operands.

Within a single instruction code with the same opcode 72 and the same definition of operand fields 74 and 76, a NOP-compatible instruction means performing no operation at all (making the instruction behave like a NOP instruction) or performing at least two different processing operations One or more options (including at least the first operation and the second operation). Based on the instruction function selection information 60 stored in the control register 56 , which combination of operations is selected to be executed (by the instruction decoder 10 and/or the execution stage 16 of the processing pipeline 4 ) in response to the NOP compatible instruction. This information can be set by instructions executed by the processor. For example, system register modification instructions (which may be restricted to execution in certain execution states or priority levels) may be used to set the instruction function selection information 60 . Alternatively, there may be a dedicated type of instruction used to set command function selection information, which is different from the system register modification instructions used to modify other control registers 56 . In the case of use that executes a section of code that includes a NOP-compliant instruction, some examples may use an earlier instruction of the same section of code to set the instruction function selection information 60. In other examples, command function selection information 60 may be set by supervisory code that manages the execution of code that includes NOP-compliant instructions (e.g., by an operating system that manages the execution of an application, or by a supervisor that manages the execution of an operating system device).

Figure 4 is a flowchart illustrating a method of processing NOP compliant instructions. At step 100, instruction decoding circuitry 10 determines whether the NOP-compliant instruction was decoded. If not, instruction decoding circuitry 10 decodes another type of instruction, controls the processor to perform the operation represented by the instruction, and continues to wait for a decoded NOP-compliant instruction.

When the NOP compliant instruction is decoded, then at step 102 , the instruction decoder 10 checks (or controls another portion of the processor, such as the execution stage 16 to check) the instruction function selection information 60 stored in the control register 56 status.

If the instruction function selection information 60 is in the first state, then at step 104, the instruction decoder 10 controls the execution stage 16 to treat the NOP-compliant instruction as a NOP instruction. Therefore, processing circuitry does not cause any changes in architectural state in response to a NOP-compliant instruction (other than advancing the program counter to point to the next sequential instruction after the NOP instruction).

If the command function selection information 60 is in the second state, then at step 106, processing depends on whether the command function selection information is a first sub-state or a second sub-state of the second state. If the command function selection information 60 is the first sub-state of the second state, then at step 108 , the processing circuitry 16 is controlled to perform both the first operation and the second operation (the difference between the first operation and the second operation). first order among them). If the command function selection information 60 is the second sub-state of the second state, then at step 110 , the processing circuit system 16 is controlled to perform both the first operation and the second operation (the difference between the first operation and the second operation). a second order between, which is different from the first order). The first and second orders may differ in whether the first and second operations are performed sequentially or in parallel, or in which of the first and second operations are performed first and which are performed second. The order may also differ in whether there are any dependencies between the first operation and the second operation (ie, whether one operation depends on the result of the other or whether the two operations are independent).

Support for controlling the sequence between the first operation and the second operation is optional, and in some examples, steps 106 and 110 may be omitted, so that when the command function selection information is in the second state, the method Continue to step 108 to perform the first operation and the second operation in a preset selected first order.

Specific examples of sequences between control operations are described below with respect to FIGS. 9-12.

At step 102, if the command function selection information 60 is in the third state, then at step 112, the processing circuit system 16 is controlled to perform the first operation but not the second operation.

If the command function selection information is in the fourth state, at step 114, the processing circuit system 16 is controlled to perform the second operation but not the first operation. Support step 140 may be optional, and in some examples, it is not possible for a NOP-compliant instruction to perform the second operation without performing the first operation. For example, in some use cases, some implementations may prefer to use command function selection information 60 if there is unique room for four different states of command function selection information (e.g., because only 2 bits are used for this information 60 ) The fourth encoding is to allow two different sub-states of the second state, as shown in steps 108 and 110, so that the sequence of operations can be controlled. Other examples may support all states and sub-states of Figure 3, and thus may use command function selection information with 3 or more bits to allow these additional encodings of command function selection information.

One possible encoding of command function selection information (without support for controlling the sequence between the first operation and the second operation) could be as follows: • 0b00-The first operation is disabled, the second operation is disabled-instruction action such as NOP (first state); • 0b01-The first operation is enabled, the second operation is disabled (the third state); • 0b10-The first operation is disabled, the second operation is enabled (the fourth state); • 0b11-The first operation is enabled, the second operation is enabled (second state).

This encoding can provide different bits for each operation, which independently indicate whether to enable or disable the operation. This can be extended to a third or further operation by providing additional bits per operation (respectively enabling/disabling any additional operations).

Another example encoding of command function selection information assigns the ability to perform a second operation without performing the first operation, but uses a fourth encoding of command function selection information 60 to indicate the first operation and the second operation when both operations are performed. Desired order between operations: • 0b00-The first operation is disabled, the second operation is disabled-instruction action such as NOP (first state); • 0b01-The first operation is enabled, the second operation is disabled (the third state); • 0b10-The first operation is enabled, the second operation is enabled, the first sequence between the first operation and the second operation (second state-first sub-state); • 0b11-The first operation is enabled, the second operation is enabled, the second sequence between the first operation and the second operation (second state-second sub-state);

Another example encoding can use more than 2 bits and leave some encoding for future use, for example, when adding support for additional operations or configuration options: • 0bX00-The first operation is disabled, the second operation is disabled-instruction action such as NOP (first state); • 0bX01-The first operation is enabled, the second operation is disabled (the third state); • 0bX10-The first operation is disabled, the second operation is enabled (the fourth state); • 0b011-The first operation is enabled, the second operation is enabled, the first sequence between the first operation and the second operation (second state-first sub-state); • 0b111-The first operation is enabled, the second operation is enabled, the second sequence between the first operation and the second operation (second state-second sub-state);

It should be understood that all of these examples are but some of the ways in which the operations to be performed for a NOP instruction may be encoded by the instruction function selection information 60.

Various processing operations can be used as the first and second operations. However, a specific use case can be used when a function intro or wrap-up operation is performed on a function call or function return respectively. In particular, it may be useful that the first operation and the second operation are alternative operations on the return state of the function to protect against return oriented programming (ROP) attacks. For example, the first operation and the second operation may be indicator authentication/checking operations or GCS push/fetch operations described further below.

Figure 5 illustrates an example of a call function (labeled fn1 for ease of reference) and a return from the function. A function (also called a program) is a sequence of instructions that can be called from another part of the program and, when completed, returns processing to the part of the program flow from which the function was called. The same function can be called from many different locations in the program, and therefore the function return address is stored when the function is called, so that the function return can distinguish to which address the program flow should return.

For example, as shown in Figure 5, a branch with a join instruction BLR can be executed at the point (represented by address #add1) where the function will be called, causing program flow to branch to the operand using the branch with a join instruction. The instruction at the specified branch target address #add2. The branch with the join instruction also causes the processing circuitry to set the link register (the designated register used to track the return address of the function, such as the general purpose register shown above) to the branch after the branch with the join instruction. The address of the next instruction (in this example, the function return address is #add+4). After the branch has been taken, several instructions (e.g., LD, MUL, ADD, etc.) are executed in the function code, and when the function is completed, the return branch instruction RET is executed, which causes the branch to the return stored in the link register The instruction indicated by the address.

If no other function is called from fn1, and no exception occurs before the return branch at the end of fn1 is reached, the address in the link register should still be the same as it was set when fn1 was called.

Typically, however, the first function fn1 called by the background code can itself call another function (say fn2) in a nested manner, and in this case the function call to fn2 will overwrite the link register the return address in the link register, and therefore before calling another function, the function code of the first function fn1 should include an instruction to store the return address from the link register into a data structure in memory (e.g., Stacked structure, operating in last-in-first-out (LIFO) mode), and after returning from fn2, the function code of fn1 should restore the return address to the link register before executing the return branch . The responsibility for storing and restoring function return status (such as return addresses) will typically lie with software (there may be no architecturally mandated hardware mechanism for storing return addresses).

However, when the function return address is stored in memory, it may be vulnerable to an attacker modifying this data, such as using another thread executing on another processor core, or by interrupting the calling function and simultaneously Other code is executed that overwrites the return address stored in memory. Alternatively, the attacker can execute instructions whose goal is to modify the address operand of the instruction that restores the return address from memory to the scratchpad so that the data loaded from memory is different from the data loaded in the call. The return address originally stored in memory before the nested function. If an attacker can cause a return branch to a point in the program flow that is not an instruction following the function call branch, the attacker may be able to cause the software to behave incorrectly, and may be able to bypass certain security protections or cause unintended operations to be performed.

A function call is an instance of an operation that generates return state information that provides information about a state to which the processing circuitry will later be restored. Another situation in which return status information may be retrieved may be when exceptions are taken, where exception handling circuitry is provided in hardware, or a software exception handler may retrieve exception return status information, such as to indicate when returning from handling an exception. An exception return address that is the address of an instruction that will later be executed, and/or stored processor state information that indicates the mode or execution state in which the processor will execute after returning from an exception. For example, stored processor state information may indicate the exception level at which the exception was taken, as well as other information about the operating state of the processor when the exception was taken. Like function calls, exceptions can be nested, and thus the exception return status retrieved for one exception can be stored in memory (either automatically in hardware, or by a software exception handler) when another exception is taken, and Therefore, when stored in storage memory, it may be vulnerable to tampering by attackers. These types of attacks may be called return-oriented programmed (ROP) attacks. It may be desirable to provide architectural countermeasures against such attacks.

Figure 6 illustrates a method for protecting against ROP attacks using a protected data structure 120 in memory called a guarded control stack (GCS). The location of the GCS data structure within the memory address space can be selected by software, but the hardware provides architectural features designed to protect the GCS data structure from tampering by malicious attackers.

As shown in FIG. 2, register 14 includes control register 56, which includes one or more protected control stack pointer (GCS pointer) registers 58 for storing a stack pointer indicative of GCS data. The address on the structure. In some examples, the GCS indicator register 58 may be a stacked register group provided for at least two execution states (eg, exception levels) to implement software reference memory operating in different execution states. Different GCS structures without the need to reprogram the shared stack pointer register after each transition in execution state. Other examples may use a single GCS indicator register, and the software may update stacked indicators stored in GCS indicator register 58 on transitions between execution states.

As shown in Figure 6, the GCS data structure 120 is stored in memory specified directly or indirectly by the associated paging table entry of the paging table used by the memory management unit (MMU) 28 for controlling address translation and access permission checking. In the memory area specified by the volume attribute as the GCS area of the memory. GCS region attributes can be specified directly in the code corresponding to the paging table entry, or they can be indirectly referenced in the register referenced by the paging table entry.

When a memory region is identified as a GCS region, then write access to that region is limited to write requests triggered by processing circuitry 16 when a specific subset of GCS access instructions are executed. General store instructions used by software for general store operations that are not intended to access GCS structures are not considered to be among the restricted subset of GCS access instructions. The MMU 28 may still allow the GCS structure to be read using a general load instruction that results in the issuance of a read request that is not a GCS memory access request. When a memory access request requests access to a GCS region, the request is a write request, and the request is not a GCS memory access request triggered by one of the restricted subsets of GCS access instructions, then the memory access request The body access request was denied with a subpoena error. A subset of GCS access instructions may include at least one GCS push instruction that results in the return of status information (such as a function return address from a link register, or an exception return address, or a stored handle that is retrieved when an exception is taken) processor status) is pushed to the location on the GCS structure determined using the stacking metric indicated in GCS metric register 58 . GCS access instructions may also include at least one form of GCS fetch instructions that retrieve protected return information from a GCS structure.

Conversely, GCS access instructions may not be allowed to access memory areas that are not specified as GCS area types by the paging table attribute. Therefore, an error may be signaled if a GCS access is attempted when the memory region targeted by the access is not marked as a GCS region type. By prohibiting the use of GCS access commands to access non-GCS regions, this discourages programmers from using GCS access commands unless GCS access is truly intended, thereby reducing the attack surface available to attackers.

The GCS structure is separate from any data structures used by software to maintain stored return status information in memory to handle nesting of function calls or exceptions. Therefore, the GCS architecture is not intended to eliminate the need for the software itself to track the storage and restoration of return status information when function calls or exceptions are nested (software-triggered storage of return status may occur if the architecture does not support the GCS protection measures discussed above continue in the same manner on the processor). Alternatively, the GCS structure provides a region of protected memory that is protected from tampering with compromising code, which can be used to provide verification of return status information intended to be used by software to return from the handling of function calls or exceptions. information.

In some implementations, a GCS fetch instruction that causes protected return status information to be fetched from a GCS structure may also cause processing circuitry 16 to compare the fetched return status to the current return status information stored in a register (e.g., for a function the return link register 54, or the exception return address register and/or the stored processor status register for exception returns), and if the return status information retrieved from the GCS structure 120 is intended to be used by the software If there is a mismatch between the expected return status information returned by the function/exception, a signaling error occurs. Therefore, software can be protected from tampering by including instances of GCS push and GCS fetch instructions within the code that executes on function calls/returns or exception entries/returns.

Other implementations may define separate instructions for verifying that the intended return status information is valid, separate from the instructions for retrieving the return status information from the GCS structure 120 .

Alternatively, the GCS fetch instruction may directly fetch the protected return status from GCS into one or more registers specifying the return status of an exception return or functional return (or may be combined with an exception/function return instruction to fetch protected return state and using that state for controlling exceptions/function returns), in which case it is not necessary to perform verification that the intended return state information provided by the software is valid, because in this implementation, the GCS protected return state It is used directly to control exceptions/function returns. For example, for GCS protection of a function return address, the function return address may be fetched directly into link register 54, replacing any software-managed function return bits that the software may place there based on its own managed stack structure. site.

In addition, other types of GCS can also support access instructions. When the GCS mode is enabled (the control status in the control register 56 can control whether the GCS mode is enabled), some instructions (which have other functions in the mode in which GCS is disabled), when executed, may cause the processing circuitry 16 Perform additional functionality (such as additional GCS mode specific security checks).

Generally speaking, by providing architectural support for defining GCS memory region types for GCS structure 120 and restricting write access to GCS region types to a limited subset of GCS access instructions (which may not be Allowing access to memory regions other than GCS region types), this reduces the attack surface that attackers can use to attempt to tamper with the protected return state information stored on the GCS structure 120.

GCS provides a defense against ROP attacks. Another option for protecting against ROP attacks is to use an authentication code associated with the returned status information. FIG. 7 illustrates an example of an authentication code generation operation performed based on the first source operand src1 in response to an authentication code generation instruction. The source operand can be any value, but it is particularly useful for applying authentication code generation operations to address pointers, such as function return addresses. The source operand may specify (e.g., by reference to a source register, such as a link register) an address containing a certain number of bits X, but in fact only a certain number Y of those bits is available for the significant bits address (for example, X could equal 64 and Y could equal 48 or 52). Therefore, the X-Y upper bits of the address can be set to zero by default.

During an authentication code generation operation, source operands may be passed to encryption/decryption circuitry of processing circuitry 16 (e.g., execution stage 16 may include encryption similar to other execution units 20, 22, 24, 26 shown in FIG. 1 /decryption function), which can apply an authentication code generation function 140 to the first source value based on the key from the key store and at least one modifier value. The resulting authentication code (PAC) is inserted into the unused upper bit of the pointer address to produce the result of the instruction. The result can, for example, be written back to the same register that stored the source operand. For example, if the current function return address stored in the link register 54 is executed with the source operand, the result is written back to the link register 54 . The authentication code generation function 40 may use a cryptographic hash function (e.g., SHA256, SHA128, QARMA-128, QARMA-256, etc.) that makes it computationally infeasible to guess the authentication code associated with a specific address without knowing the key . The modifier value can be a value used to connect the specific instance of the authentication code produced by the operation to a specific execution value reached in the code, thereby reducing the risk of re-use attacks, where one comes from a portion of the code. A valid address/PAC pair was incorrectly substituted for use in another part of the code. For example, a stacking pointer from stacking pointer register 52, or a call path indicator representing the history of function calls taken to reach the current processing point, may be used as modifiers.

Figure 8 shows the corresponding authentication code check operation performed on the second source operand src2. The second source operand is expected to be the pointer address, which has been previously authenticated by inserting the authentication code PAC into its upper bit in the authentication code generation operation shown in Figure 7, but if the attacker has modified the pointer, then the authentication The PAC may not be valid. In an authentication code checking operation, processing circuitry 16 converts the same authentication code to the same authentication code using key and modifier values that correspond to those expected to have been used when the authentication code represented by the upper bit of the address was generated. The code generation function 140 applies to the address bits of the second source operand (excluding the authentication code PAC). Next, the expected authentication code PAC is compared with the associated authentication code PAC extracted from the upper element of the second source operand src2, and it is determined whether the expected authentication code matches the associated authentication code. If so, processing is allowed to continue, and if there is a mismatch between the expected and associated codes, an error handling response is triggered, such as triggering an exception or setting the upper bit of the source register to a value corresponding to the invalid address. Such that subsequent accesses or instruction fetches to that address will trigger the MMU 28 to trigger a memory error due to accessing an invalid address (this means that if the address with an incorrect PAC is used for a function return, subsequent accesses after the return branch Attempts to fetch an instruction from this address will trigger an error, preventing the processing circuitry from continuing beyond the incorrect function return).

By using the authentication code generation and checking operations of Figures 7 and 8, this allows the indicator to be authenticated, making it more difficult for an attacker to inject an unauthenticated indicator and successfully branch the code to the location identified by the indicator, protecting against ROP attacks. . By using the password function as the authentication code generation function 140, this can make brute force guessing of the authentication code associated with a specific address difficult. Instructions for performing authentication code generation operations may be included in the code at the point when the pointer address is generated (e.g., in response to a function call to set the link register and store the link register to memory function between return addresses), and when that address is actually used later (for example, before a function returns a branch), the authentication code check instruction AUT can be included to double-check the authentication code before actually branching to that address. .

The authentication code generation function 140 may vary from implementation to implementation, or may be configurable on a given implementation based on the control status in the control register 56 . The modifier values used for the authentication code generation function may also be configurable or may differ for different variants of the instructions that perform the authentication code generation/checking operations.

Both the GCS operations and the authentication code operations described above with respect to Figures 6-8 can be considered defenses against ROP attacks, but some users may prefer to use one form of defense, and other users may use the other. Some users may prefer to use a combination of both defenses in a depth approach. In addition, there may be times when a piece of code that is used in a use case that requires the security of ROP defense can also be executed in a use case that does not require this security. It may sometimes be desirable to omit these operations. In this case It might be better to omit this operation for performance reasons. Therefore, these operations may be useful examples for the first and second operations of the NOP compliant instructions described above.

In some cases, it may be desirable to provide program binaries that are backwards compatible with older hardware that does not support GCS and authentication code features, and that support new functionality when running on newer hardware that supports these features. Therefore, opcode 72 selected for a NOP compatible instruction may be considered one of the NOP instructions on older hardware.

Typically, when a new architectural feature is added to the ISA, the control register can be used to indicate whether the feature is supported, and software may need to check whether the feature is implemented before using it. This is acceptable for many features, but for features that are expected to be executed very frequently, such as features used for feature intros and wrap-ups, this is not feasible for performance reasons. For such features, it may be useful to provide encoding for a set of NOP instructions that perform no operations, at least until some functionality is added to the encoding for newer hardware that supports newer architectures. As more features are added to the architecture, more NOP-compliant instructions can be added to the function intro and outro corresponding to each additional feature, but this will make the function larger because adding more NOP-compliant instructions will lead to faster This takes the cost of structure and instruction throughput, and therefore reduces performance.

Therefore, multiple operations can be overloaded onto a single NOP-compliant code using the NOP-compliant instructions described above, where command function selection information 60 in one or more control registers 56 is provided to enable/disable independently. Each characteristic.

For example, as discussed above, for the protected control stack feature, where one wishes to push the contents of the link register (e.g., the function return address) onto the protected stack upon function entry, and the authentication mentioned above Code generation operations (PAC characteristics) sign indicators, such as function return addresses, which will typically involve two instructions to perform a GCS push operation (GCSPUSH) and a signing operation (PACIASP). Similarly, when the function returns, there are corresponding instructions to perform the GCS pop operation (GCSPOP) and the authentication code checking operation (AUTIASP). myfunc(): PACIASP LR GCSPUSH LR ... //My function content GCSPOP LR AUTIASP LR RET

In contrast, by using the NOP compatible instructions described above to provide two stages of functionality, this allows us to have smaller functionality and also allows it to work on both old and new hardware (since the old hardware can see it is a NOP, and even on newer hardware, there is a configuration option to disable both operations by setting the command function selection message to the first state).

For example, if the combined instructions (in this example, assumed to have PACIASP encoding) perform all operations, we can have a smaller function: myfunc(): PACIASP LR //Also execute GCSPUSH ...//My function content AUTIASP LR //Also execute GCSPOP RET

It should be noted that AUTIASP is the complement of PACIASP, and in the above example, by performing the GCSPOP operation, is also the complement of GCSPUSH.

For example, we can provide 2 control bits to manage the behavior of these codes 00 - PAC disabled, GCS disabled 01 - PAC enabled, GCS disabled 10 - PAC disabled, GCS enabled 11 - PAC enabled, GCS enabled

This can be extended in the future with new features, adding control bits to turn functions on/off, all performed by a single code. Additionally, control states will likely control the relative order in which operations are performed.

Therefore, multiple new features can turn the same command code on and off without rebuilding the program binary.

The above example shows the situation where the first operation and the second operation are any of the following: • For the function introduction variant, it is the GCS push operation and the authentication code generation operation, or vice versa; or • For the function closing variant, it is the GCS removal operation and the authentication code checking operation, or vice versa.

Both variants can be supported in the same ISA, with different encodings of opcode 72 for the function introductory variant and the function tail variant.

However, in other instances, it is possible to provide NOP-compliant instructions that combine a GCS push operation with another operation other than an authentication code generation operation, or that combine an authentication code generation operation with another operation other than a GCS push operation. Similarly, it is possible to provide NOP-compliant instructions that combine a GCS fetch operation with another operation than an authentication code check operation, or that combine an authentication code check operation with another operation than a GCS fetch operation.

Figures 9 to 12 show different examples of controlling the sequence between PAC/AUT and GCS operations in the case where both operations are performed in response to a NOP compliant instruction.

Figure 9 shows an example in which a NOP-compliant instruction (executed as a function preamble) performs an authentication code generation operation (PAC) and a GCS push operation, where the GCS push operation depends on the result of the authentication code generation operation, causing the function to return the address and its associated The joint authentication codes are pushed to GCS. In other words, this is equivalent to performing a PAC operation and then proceeding with a GCS push operation, where the destination register for the PAC operation is the same as the source register for the GCS push operation. In contrast, Figure 10 shows PAC and GCS push operations performed in a different order, with GCS push operations being independent of PAC operations. This allows the push of the function's return address to the GCS structure to begin in parallel with the calculation of the authentication code for the PAC operation. This may be useful because the PAC generation function 140 and memory accesses for GCS push operations may be relatively slow, and thus parallelizing these operations may have improved performance compared to the sequence of Figure 9. On the other hand, the example of Figure 9 can improve security because the generated authentication code is protected on the GCS, not only the function return address is protected.

Similarly, Figures 11 and 12 show an alternative sequence in which a NOP-compliant instruction (executed as a function wrapper) performs a GCS fetch operation and an authentication code check (AUT) operation as examples of the first and second operations (either way - The first operation may be a GCS fetch operation and the second operation may be an AUT operation, or vice versa). Figure 11 shows a sequence in which the AUT operation depends on the results of the GCS fetch row operation because the values fetched from GCS by the GCS fetch operation are used as inputs to the AUT operation. This approach may be used in an example where executing a corresponding NOP compliant instruction as a function introduction uses the approach shown in Figure 9. Again, this has the advantage of greater security since the authentication code is protected from tampering using the GCS memory area protection implemented by the MMU 28. On the other hand, Figure 12 shows a sequence in which the AUT operation and the GCS fetch operation are independent so that they can be started in parallel. In this case, the authentication code check can be applied to the value in the link register, and then separately, the GCS fetch operation can also fetch the value in the destination register (without the associated authentication code). Assuming that the old value in the link register is read for the AUT operation before the value fetched from the GCS structure is returned from memory, the destination register for the GCS fetch operation can still be the same as the source operation used for the AUT operation In this case, if the AUT operation detects a mismatch, an error or other error response action is taken, and if the code matches, the GCS fetch operation is allowed to complete, and then the GCS fetch operation is fetched The address can be used for function returns. Alternatively, a GCS fetch operation may fetch the protected return address of the GCS structure from memory to a register other than the register checked by the AUT operation, and the value checked by the AUT operation may then be compared with Comparison between the values taken out from the GCS structure to confirm whether the GCS protection address matches the AUT check address, thereby providing further checking whether it is safe to perform function return based on this address.

Therefore, it is useful for instruction decoder 10 and execution level 16 to support: - A first NOP-compliant instruction for a functional preamble, wherein one of the first/second operations is the authentication code generation operation (PAC), and the other of the first/second operations is GCS push operations; and - a second NOP-compliant instruction for a functional closure (with a different encoding than the first NOP-compliant instruction), where one of the first/second operations is the authentication code check operation (AUT), And the other one of the first/second operations is a GCS fetch operation.

The command function selection information 60 can specify which of the first operation and the second operation (if any) will be executed in response to the command, and can also control the relative order of the operations shown in FIGS. 9 to 12 .

Figure 13 is a flowchart showing the steps performed by the MMU 28 for checking memory access permissions of a memory access request. In step 200, the instruction triggering the load/store operation is decoded. If the instruction function selection information 60 specifies that a GCS push or fetch operation is to be performed, then the above-mentioned NOP compatible instruction that supports the GCS push or fetch operation is regarded as a load/store instruction.

In step 202, it is determined whether the instruction that triggered the load/store operation is a GCS access instruction (one of a restricted subset of GCS access instructions that are allowed to access the GCS area of the memory). When the command function selection information indicates that a GCS push or fetch operation is required, the NOP compatible command is treated as a GCS access command. Other types of instructions can also be considered GCS access instructions. In some cases, NOP-compliant instructions are not considered GCS access instructions if the instruction function selection information is in a state indicating that no GCS push or fetch operation is required. Alternatively, if the GCS push or fetch operation is the only operation that can generate a load/store operation in response to a NOP-compliant instruction (e.g., the PAC/AUT operation described above cannot generate any load/store request), then the NOP corresponds to The content command can always be regarded as a GCS access command, regardless of the value of the command function selection information 60.

If the decoded instruction is a GCS access instruction, then at step 204, the MMU 28 checks whether the memory attribute data corresponding to the target address accessed by the load/store operation specifies the memory address space corresponding to the target address. The area is a GCS area. This memory attribute data may be derived from the page table entry corresponding to the target address or an indirect register specified by the page table entry (and may be cached in the translation lookaside buffer (TLB) of MMU 28). If the instruction is a GCS access instruction, but the memory attribute data specifies that the area corresponding to the target address is not a GCS area, then at step 206, the load/store operation is rejected and an error is transmitted. This prevents GCS access commands from being used to access non-GCS memory, which is more secure and reduces the attack surface available to attackers. Otherwise, if the GCS access instruction accesses the GCS region, then at step 212, the MMU 28 checks whether any other access rights checks were passed by the load/store operation. If these other checks fail, then at step 214 the load/save operation is rejected and an error is signaled. If these other checks are passed, then at step 216, the load/store operation is allowed. These other checks may, for example, check read/write permissions indicating whether reading or writing to the memory region is allowed, or may check other security attributes that are not relevant to the GCS region check (e.g., restricting access to the memory region) properties of the execution state of the processor in ).

If the instruction that triggered the load/store operation is not a GCS access instruction, then at step 208, the MMU 28 checks whether the memory attribute data corresponding to the target address accessed by the load/store operation is specified to correspond to the target address. The memory address space area is the GCS area. However, in this case, in contrast to step 204, the response is that the load/store request may be accepted if the non-GCS access instruction does not access the GCS region, but may be rejected if it accesses the GCS region. More specifically, if the memory attribute data corresponding to the region of the target address specifies a GCS region, then at step 205 the MMU checks whether the memory access is a write memory access, and if so, at step 210 Load/save operation rejected with error message. By restricting write access to the GCS region to a dedicated class of GCS access instructions, this prevents most regular store instructions in the code from tampering with the protected return state on the GCS data structure. This reduces the chance of an attacker modifying the operands of a regular store instruction when trying to corrupt the protected return state on GCS.

On the other hand, if the non-GCS access instruction does not attempt to access the GCS region (at step 208, No) or attempts to access the GCS region, but is a read request (at step 205, no), then the method continues again to step 212 in order to apply any other access rights checks and then control whether the load/save operation is denied or allowed depending on the results of these checks, also as discussed above for steps 212, 214, 216.

Figure 14 illustrates a simulator implementation that may be used. Although the embodiments described earlier implement the present invention with apparatus and methods for operating specific processing hardware supporting the technology of interest, it is also possible to provide an instruction execution environment in accordance with the embodiments described herein by using Computer program implementation. Such computer programs are often called emulators because they provide a software-based implementation of the hardware architecture. Types of simulator computer programs include emulators, virtual machines, models, and binary translators (including dynamic binary translators). Generally speaking, emulator implementations may run on a host processor 1330 that optionally runs a host operating system 1320 and supports an emulator program 1310. In some configurations, there may be multiple layers of emulation between the hardware and the instruction execution environment provided and/or multiple distinct instruction execution environments provided on the same host processor. Historically, powerful processors have been required to provide emulator implementations that execute at reasonable speeds, but this approach may be justified in certain circumstances, such as when this is required for compatibility or reuse reasons. When executing code native to another processor. For example, an emulator implementation may provide an instruction execution environment with additional functionality not supported by the host processor hardware, or provide an instruction execution environment typically associated with different hardware architectures. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques", Robert Bedichek, Winter 1990 USENIX Conference, pp. 53-63.

Where embodiments have been previously described with reference to particular hardware architectures or features, equivalent functionality may be provided by suitable software architectures or features in a simulated embodiment. For example, certain circuit systems may be implemented as computer program logic in simulated embodiments. Similarly, memory hardware (such as registers or caches) may be implemented as software data structures in simulated embodiments. Where one or more of the hardware elements mentioned in previously described embodiments reside in a configuration on host hardware (eg, host processor 1330 ), some simulation embodiments may utilize host hardware (where appropriate) .

The emulator program 1310 can be stored on a computer-readable storage medium (which can be a non-transitory medium) and provide a program interface (command execution environment) to the object code 1300 (which can include an application, an operating system, and a hypervisor) ), the program interface is the same as the interface of the hardware architecture modeled by the simulator program 1310. Accordingly, program instructions of object code 1300 including NOP compliant instructions as described above may be executed using emulator program 1310 within an instruction execution environment such that a host computer 1330 does not actually have the hardware features of device 2 discussed above. These characteristics can be imitated. Similarly, the memory management check functionality of Figure 13 may be simulated using the memory management program logic 1318 of the simulator program 1310.

Therefore, the simulator program 1310 may have a processing program logic 1312 that simulates the state for the above-mentioned processing of the hardware device 2 . For example, handler logic 1312 may control transitions in execution state (eg, exception level) in response to events occurring during simulated execution of object code 1300 . Instruction decoding program logic 1314 emulates the behavior of instruction decoder 10 and decodes the instructions of target code 1300 and maps these instructions to corresponding instruction sets in the native instruction set of host device 1330 . Register emulator logic 1316 maps register accesses requested by the object code into accesses to corresponding data structures maintained on the host hardware of host device 1330 , such as by accessing the registers of host device 1330 Or the data in memory 1332. Memory manager logic 1318 performs address translation, page table walks, and access control checks in a manner corresponding to the MMU 28 described in the hardware embodiment above, but also has a mapped simulated physical address (based on the target The page table defined by code 1300 is obtained by address translation) to the host virtual address used to access host memory 1332. These host virtual addresses may themselves be translated into host physical addresses using standard address translation mechanisms supported by the host (translation of host virtual addresses into host physical addresses is outside the scope of control of the emulator program 1310 ).

In this application, the term "configured to" is used to mean that an element of a device has a configuration capable of performing the defined operation. In this context, "configuration" means the arrangement or manner of interconnection of hardware or software. For example, the device may have specialized hardware that provides a defined job, or a processor or other processing device may be programmed to perform the function. "Configured to" does not mean that the device element needs to be changed in any way to provide the defined operation.

Although illustrative embodiments of the present invention have been described in detail herein with reference to the accompanying drawings, it is to be understood that the invention is not limited to the precise embodiments, and that various changes and modifications may be made therein by those skilled in the art without departing from the The scope of the invention is defined by the appended claims.

2: Data processing equipment 4: Processing pipeline 6: Extraction level 8: Instruction cache/memory system/cache 10: Decoding level 12: Release level 14: scratchpad file 16:Executive level 18: Write back to level 20: Arithmetic/logic unit (ALU)/processing unit/execution unit 22: Floating point unit/processing unit/execution unit 24: Branch unit/processing unit/execution unit 26:Load/storage unit/processing unit/execution unit 28: Memory management unit (MMU) 29: Translation lookaside buffer (TLB) 30:Memory system/cache 32:Memory system/cache 34:Memory system 50: General purpose register 52: stack pointer (SP) register 54: Link register 56: Control register 58: Protection control stack (GCS) stack indicator register/GCS indicator register 60: Command function selection information 70:NOP compatible instructions 72:Operation code 74,76: Operator field/operator 120:Data structure/GCS structure/GCS data structure 100,102,104,106,108,110,112,114,140: Steps 140: Authentication code generation function 200,202,204,205,206,208,210,212,214,216: Steps 1300:Object code 1310:Simulator program 1312: Processing program logic 1314: Instruction decoding program logic 1316: Register emulation program logic 1318: Memory management program logic 1320: Host operating system 1330: Host processor/Host device/Host computer 1332: Scratchpad or memory/host memory

Further aspects, features, and advantages of the present technology will become apparent from the following example description, read in conjunction with the accompanying drawings, in which: [Fig. 1] Schematically illustrates an example of data processing equipment; [Figure 2] shows an example of the device's register; [Figure 3] illustrates an example of a no-operation-compatible (NOP-compatible) instruction; [Figure 4] illustrates the method of processing NOP compatible instructions; [Figure 5] illustrates an example of function call and function return; [Figure 6] illustrates an example of a protection control stack (GCS) push operation and a GCS fetch operation; [Figure 7] illustrates an example of the authentication code generation operation; [Figure 8] illustrates an example of the authentication code checking operation; [Figure 9] and [Figure 10] illustrate examples of performing GCS push operations and authentication code generation operations in different orders; [Figure 11] and [Figure 12] illustrate examples of performing GCS retrieval operations and authentication code checking operations in different orders; [Figure 13] illustrates the steps of checking whether memory access is allowed based on memory attribute data; and [Figure 14] shows a simulation example.

100,102,104,106,108,110,112,114: Steps

Claims (23)

A device containing: an instruction decoder to decode instructions; Processing circuitry to perform data processing in response to decoding of the instructions by the instruction decoder; and At least one control register to specify command function selection information; in: In response to a no-operation compatible instruction, the instruction decoder is configured to control the processing circuitry to: When the command function selection information specified by the at least one control register is in a first state, treating the no-op compatible command as a no-op command; When the command function selection information specified by the at least one control register is in a second state, perform both a first operation and a second operation; and When the command function selection information specified by the at least one control register is in a third state, the first operation is performed but the second operation is not performed. The device of claim 1, wherein when the instruction function selection information is in a fourth state, in response to the incompatible instruction, the instruction decoder is configured to control the processing circuit system to execute the second operation, but does not perform the first operation. The device of any one of the preceding claims, wherein when the instruction function selection information is in the second state, the processing circuit system is configured to control application of the first operation and the third operation based on the instruction function selection information. A relative sequence of two operations. The device of any one of the preceding claims, wherein the first operation and the second operation are function preamble operations associated with a function call; or The first operation and the second operation are function closing operations associated with returning from processing one of the functions. The apparatus of any one of the preceding claims, wherein for at least one variant of the no-operation compatible instruction, one of the first operation and the second operation includes an authentication code generation operation based on an operand An authentication code is generated, and the authentication code is associated with the operand. The device of claim 5, wherein the operand contains a value obtained from a link register; and In response to a function return branch instruction, the instruction decoder is configured to control the processing circuitry to branch to an address specified in the link register. An apparatus as claimed in any one of claims 5 and 6, wherein associating the authentication code with the operand includes embedding the authentication code in a portion of the more significant bits of the operand. The device of any one of claims 5 to 7, wherein the authentication code generating operation includes generating the authentication code according to a cryptographic function based on at least the operation element and a key. The device of any one of the preceding claims, wherein for at least one variant of the no-operation compatible instruction, one of the first operation and the second operation includes a guarded-control-stack, GCS) push operation to push the operand to a GCS data structure used to protect the returned status information. Equipment as in any of the preceding requirements, wherein: For at least one variant of this no-op compatible directive: One of the first operation and the second operation includes an authentication code generation operation to generate an authentication code based on an operand and associate the authentication code with the operand; The other of the first operation and the second operation includes a guard control stack (GCS) push operation to push the operand to a GCS data structure for guard return status information. Such as the equipment of request item 10, wherein: In response to the incompatible instruction, when the instruction function selection information is in a first sub-state of the second state, the processing circuitry is configured to push the operand and the authentication code to the GCS data structure; and In response to the incompatible instruction, when the instruction function selection information is in one of the second sub-states of the second state, the processing circuitry is configured to push the operand but not push the authentication code to The GCS data structure. A device as in any one of the preceding claims, wherein for at least one variant of the incompatible instruction: One of the first operation and the second operation includes an authentication code check operation to check whether an associated authentication code associated with an operand matches an expected authentication code generated based on the operand, and respond An error handling response is triggered upon detecting a mismatch between the associated authentication code and the expected authentication code. The device of claim 12, wherein the associated authentication code is obtained from a portion of the more significant bits of the operand. The device of any one of the preceding claims, wherein for at least one variant of the no-operation compatible instruction, one of the first operation and the second operation includes a protection control stack (GCS) fetch operation, to Retrieve the function return information from a GCS data structure used to protect the function return information. A device as in any one of the preceding claims, wherein for at least one variant of the incompatible instruction: One of the first operation and the second operation includes an authentication code check operation to check whether an associated authentication code associated with an operand matches an expected authentication code generated based on the operand, and respond triggering an error handling response upon detecting a mismatch between the associated authentication code and the expected authentication code; and The other of the first operation and the second operation includes a guard control stack (GCS) fetch operation to fetch function return information from a GCS data structure used to protect the function return information. Such as the equipment of request item 15, wherein: In response to the non-operation compatible command, when the command function selection information is in one of the first sub-states of the second state, the processing circuitry is configured to perform the GCS fetch operation and perform the authentication code check operates on a value retrieved from the GCS data structure by the GCS fetch operation; and In response to the non-operation compatible command, when the command function selection information is in one of the second sub-states of the second state, the processing circuitry is configured to perform the authentication code check before performing the GCS fetch operation. Operate on a value in a given register and perform the GCS fetch operation to retrieve the function return information from the GCS data structure to the given register. Such as requesting any one of the equipment in items 9, 10, 11, 14, 15 and 16, where: In response to the no-op compliant instruction, when the command function selection information is in a state indicating that an access to the GCS data structure will be executed in response to the no-op compliant instruction: The processing circuitry is configured to respond to a detection that a memory region corresponding to a target address of the no-operation compatible instruction is designated by the memory attribute data as a GCS region for storing the GCS data structure A memory access outside of a memory area that is triggered by the incompatible instruction is denied. The apparatus of claim 17, wherein the processing circuitry is configured to respond to detection that a memory region corresponding to a target address of a non-GCS access type instruction is designated by the memory attribute data as GCS area, denying a write memory access triggered by the non-GCS access type command. The device of any one of the preceding claims, wherein the command function selection information includes: a first operation indicator to indicate whether the first operation will be executed in response to the incompatible operation command; and a second operation An indicator indicating whether the second operation will be performed in response to the no-operation compatible instruction. As in any one of the preceding claims, the device, wherein the command function selection information further indicates whether the processing circuit system should perform a third operation in response to the incompatible command. A method that contains: Decode instructions; and Perform data processing in response to the decoding of such instructions; where: In response to the decoding of a no-op compatible instruction, this method contains: When the command function selection information specified by at least one control register is in a first state, treating the no-op compatible command as a no-op command; When the command function selection information specified by the at least one control register is in a second state, perform both a first operation and a second operation; and When the command function selection information specified by the at least one control register is in a third state, the first operation is performed but the second operation is not performed. A computer program containing instructions that, when executed by a host data processing device, controls the host data processing device to provide an instruction execution environment for executing object code, the computer program includes: Instruction decoding program logic to decode the instructions of the object code; and Register emulation program logic to maintain data in the storage circuitry of the host data processing device to emulate at least one control register for designated command function selection information; wherein: In response to a no-op compatibility command, the command decoder logic is configured to control the host data processing device to: When the instruction function selection information is in a first state, treating the no-operation compatible instruction as a no-operation instruction; When the command function selection information is in a second state, perform both a first operation and a second operation; and When the instruction function selection information is in a third state, the first operation is performed but the second operation is not performed. A storage medium storing the computer program of claim 22.