KR102514351B1 - Techniques for metadata processing - Google Patents

Abstract

Techniques for metadata processing that can be used to encode any number of security policies for code running on a processor are described. Metadata can be added to every word in the system and the metadata processing unit can be used to enforce an arbitrary set of policies working in parallel with the data flow. In one aspect, metadata can be characterized as infinite and software programmable so as to be applicable to a wide range of metadata processing policies. Technologies and policies have a wide range of uses including, for example, safety, security and synchronization. In addition, aspects and techniques are described with respect to metadata processing in embodiments based on the RISC-V architecture.

Description

Metadata processing technology {TECHNIQUES FOR METADATA PROCESSING}

CROSS REFERENCES TO RELATED APPLICATIONS

This application is based on U.S. Provisional Application No. 62/268,639 for Software Defined Metadata Processing, filed on December 17, 2015, and U.S. Provisional Application No. 15 for SOFTWARE DEFINED METADATA PROCESSING, filed on May 31, 2016. /168,689, all of which provisional applications are incorporated herein by reference in their entirety.

background

This application relates generally to data processing, and in particular to a programmable unit for metadata processing.

Today's computer systems are notoriously difficult to secure. For example, typical processor architectures enable various behaviors that violate higher-level abstractions, such as buffer overflow, pointer forging, and the like. Bridging the gap between programming languages and hardware can be left to software, where the cost of implementing tight abstractions is often considered too high.

Some recent efforts have demonstrated the value of enforcing policies that propagate metadata during execution to catch safety violations and malicious attacks as they occur. Such policies can be enforced in software, but typically result in high and undesirable overhead, e.g. in performance and/or cost, which makes deploying policies discouraging or low-level approximations, resulting in less protection. do. Hardware support for fixed policies can reduce overhead to an acceptable level and prevent most unwanted code violations that can be performed, for example, by malicious code or malware attacks. For example, Intel recently announced hardware for boundary inspection and isolation. These mitigate many of today's attacks, but you'll need more than memory safety and isolation to fully secure your system. Attacks evolve rapidly to exploit any remaining forms of vulnerability.

Therefore, a flexible security architecture that can quickly adapt to this ever-changing environment is needed. It is desirable for such an architecture to support software-defined metadata processing with minimal overhead. It is desirable that such architectures be extensible to generally support and enforce arbitrary numbers and types of policies, generally without imposing hard and visible limits on the number of bits allocated to metadata. Metadata can be propagated during execution to enforce policies and catch violations of those policies, such as malicious code or malware attacks.

According to one aspect of the technology described herein, a method of processing an instruction includes: receiving, for metadata processing, a current instruction having an associated metadata tag, the metadata processing performing code execution comprising the current instruction performed in a metadata processing domain isolated from the code execution domain -; determining, in the metadata processing domain, whether a rule exists in the rules cache for the current instruction, according to the metadata tag and the current instruction, wherein the rule cache contains metadata used by the metadata processing that defines allowed actions; rules are included -; and in response to determining that no rule exists in the rule cache for the current instruction, performing rule cache miss processing in the metadata processing domain; The steps include: determining whether execution of the current instruction is permitted; in response to determining that the current instruction is allowed to execute in the code execution domain, generating a new rule for the current instruction; writing to a register; and in response to writing to the register, inserting the new rule into the rule cache. The first metadata used to select a rule for the current instruction may be stored in a first portion of the plurality of control status registers used by metadata processing, the first portion of the plurality of control status registers being used for the current instruction. It can be used to convey a plurality of metadata tags for a metadata processing domain, and a plurality of metadata tags can be used as data in a metadata processing domain. The register may be a first control status register of a plurality of control status registers used by metadata processing, a first portion of the plurality of control status registers used to transfer a plurality of metadata tags from the metadata processing domain to the rules cache. Can be used. Multiple metadata tags can be for the current command. A new rule may be inserted into the rule cache in response to writing another metadata tag to the first control status register, and the other metadata tag may be placed in the result of the current instruction, with the result in one of the destination registers or memory locations. which one can be The plurality of control status registers include: a bootstrap tag control status register containing an initial metadata tag from which all other generated metadata tags are derived; a default tag control status register that specifies a default metadata tag; a public untrusted control status register that specifies a public untrusted metadata tag used to tag instructions and data classified as public and untrusted; an opgroup value control status register containing data written to a table including information on opgroups and care information on different opcodes; an opgroup address control status register that specifies a location in the table where data of the opgroup value control status register is written; and a pumpflush control status register, wherein a write to the pumpflush control status register triggers flushing of the rules cache. The plurality of control status registers may include a tag mode control status register indicating the current mode of metadata processing. The tag mode control status register may indicate when a metadata process is disengaged where the rules of one or more defined policies are not enforced by the metadata process. The tag mode control status register can be set to one of a defined set of allowed states representing the current mode of metadata processing. The allowed states are: any of the off state, states where metadata processing writes defaults to all results, and states where metadata processing is associated and indicates that instructions operate when executed in code domains at one or more specified privilege levels. can include Rule cache miss processing may be performed in a first state of a defined set of allowed states in which metadata processing is disassociated. The allowed state is a first state indicating that metadata processing is only involved when the instruction is executed in the code domain at the user privilege level; a second state indicating that metadata processing is only involved when the instruction is executed in the code domain at the user or supervisor privilege level; a third state indicating that metadata processing is only involved when the instruction is executed in the code domain at the user, supervisor, or hypervisor privilege level; and a fourth state indicating that metadata processing is engaged when the instruction is executed in the code domain at the user, supervisor, hypervisor, or machine privilege level. Whether metadata processing is associated or disassociated may be determined by the current tag mode in the tag mode control status register in combination with the current privilege level of the code executing in the code domain, and the rules of one or more defined policies are associated with metadata processing. may not be enforced when is unassociated, and rules may be enforced when metadata processing is unassociated. The table may include information mapping opcodes of instruction sets to corresponding opgroups and bit vector information. An opgroup may represent a group of related opcodes that are treated similarly by a metadata processing domain. Bit vector information may indicate which specific inputs and outputs for the metadata processing domain are used in connection with processing opcodes. The table may be indexed with a first portion of opcode bits less than the maximum allowable number of opcode bits, and the maximum number may represent an upper bound on the number of bits of an opcode in an instruction set. The first portion of the plurality of control status registers may include an extended opcode control status register containing additional opcode bits, if any, for the current instruction, the current instruction may be included in an instruction set with variable length opcodes; Each opcode in the instruction set may optionally contain additional opcode bits, and the extended opcode control status register contains the additional opcode bits for the current instruction, if any. For each opcode mapped using the table, there is a resulting bit vector corresponding to each opcode, which, if any, is some portion of the additional opcode bits of the extended opcode control status register to perform metadata processing. It can indicate whether it is used together with each of the above opcodes. The current instruction is one of multiple instructions stored in a single word of memory associated with a single metadata tag, and the single metadata tag may be associated with multiple instructions contained in a single word. The plurality of control status registers may include a sub-instruction control status register indicating which of a number of instructions stored in a single word is the current instruction. A single metadata tag may be a first pointer pointing to a first memory location that contains a different metadata tag for each of multiple instructions within a single word. At least a first metadata tag stored in a first memory location for a first command of the plurality of commands may include a second pointer pointing to a second memory location including metadata tag information for the first command. The metadata tag information for the first command may include a complex structure. A complex structure may include at least one scalar data field and at least one pointer field pointing to a third memory location.

According to another aspect of the techniques herein, the non-transitory computer readable medium includes stored code that when executed performs a method of processing instructions, the method of processing instructions comprising: for metadata processing, associated metadata receiving a current instruction with a tag, where metadata processing is performed in a metadata processing domain isolated from a code execution domain containing the current instruction; determining, in the metadata processing domain, whether a rule exists in the rules cache for the current instruction, according to the metadata tag and the current instruction, wherein the rules cache contains information about metadata used by the metadata processing that defines allowed actions; Rules are included -; and in response to determining that no rule exists in the rule cache for the current instruction, performing rule cache miss processing in the metadata processing domain; The steps include: determining whether execution of the current instruction is permitted; in response to determining that the current instruction is allowed to execute in the code execution domain, generating a new rule for the current instruction; writing to the register; and in response to writing to the register, inserting the new rule into the rule cache.

According to another aspect of the technology herein, a system includes: a processor; and a memory containing stored code that, when executed by the processor, performs a method of processing an instruction, the method of processing an instruction comprising: receiving, for metadata processing, a current instruction having an associated metadata tag; - Metadata processing is performed in a metadata processing domain isolated from the code execution domain containing the current instruction -; determining, in the metadata processing domain, whether a rule exists in the rules cache for the current instruction, according to the metadata tag and the current instruction, wherein the rules cache contains information about metadata used by the metadata processing that defines allowed actions; Rules are included -; and in response to determining that no rule exists in the rule cache for the current instruction, performing rule cache miss processing in the metadata processing domain; The steps include: determining whether execution of the current instruction is permitted; in response to determining that the current instruction is allowed to execute in the code execution domain, generating a new rule for the current instruction; writing to a register; and in response to writing to the register, inserting the new rule into the rule cache. The processor may be a pipelined processor of a reduced instruction set computing architecture.

According to another aspect of the techniques herein, a method for processing a command includes: receiving a current command for metadata processing performed in a metadata processing domain isolated from a code execution domain containing the current command doing; and determining, by the metadata processing domain in conjunction with the metadata for the current instruction, whether to allow execution of the current instruction according to the set of one or more policies, the current instruction being in the first stack frame of the first routine. A location is accessed, the location of the current instruction and stack frame has an associated metadata tag, and a set of one or more policies provides stack protection and prevents improper access to a stack storage location that includes the storage location of the first routine's stack frame. includes a stack protection policy that prevents The stack protection policy may include a first rule used in metadata processing of a current instruction accessing a first location in a stack frame of a first routine. The first rule may allow execution of the current instruction if the first position is the stack location of the first routine and the first position has metadata indicating that the current instruction is included in the first routine. The current instruction may be used by a particular invocation instance of the first routine, and the stack protection policy may include a first rule used for processing the metadata of the current instruction. The first rule may allow execution of the current instruction if it is included in the first routine and is also used by a particular invocation instance of the first routine. A first rule may include examining metadata associated with a program counter and indicating any of authorizations and capabilities to determine whether to allow execution of the current instruction by a particular invocation instance of the first routine. A stack protection policy may provide any of object level protection - different objects within a single stack frame have different color metadata tags - and hierarchical object protection for hierarchical objects that contain multiple sub-objects; Each of the multiple sub-objects of a single stack frame has different metadata. The method includes creating a new stack frame for calling the new routine; and tagging or coloring the memory location of the new stack frame according to strict object initialization or lazy-object-coloring, wherein the strict object initialization assigns information to the new stack frame. performing an initialization process that executes one or more instructions that triggers metadata processing of one or more rules that initially tag each memory location of the new stack frame prior to storage, wherein slow object colorization is performed to perform data at specific memory locations; Tag a specific memory location of a new stack frame in relation to metadata processing of a rule triggered in response to a command that stores . One or more policies may include a set of rules for enforcing a dynamic control flow integrity policy that ensures that a return to a particular return location is only valid when made subsequent to a particular call. A first position may contain a call instruction that transfers control to a called routine that contains a return instruction, a second position may contain a second instruction, and the second position may contain a return instruction of a called routine. As a result of execution, the return target position to which control is transferred can be indicated. The method includes tagging a first location containing an invocation instruction with a first code tag; tagging a second position indicating a return target position with a second code tag; performing metadata processing of rule 1 of the set for invocation instructions tagged with the first code tag, wherein metadata processing of rule 1 for invocation instructions tagged with the first code tag causes the return address register to tagging the return address register with an effective return address tag indicating that it contains an effective return address for a location, wherein execution of the calling instruction places a tag on the return address register to indicate an ability to return to a second location. updated -; Metadata of the second rule of the set for the return instruction of the called routine that allows execution of the return instruction to transfer control to the return address stored in the return address register if the return address register is tagged with a capability tag as an effective return address. performing processing, the second rule propagating the effective return address capability tag in the return address register to the program counter tag used in the next instruction following run-time execution of the return instruction; and performing metadata processing of a third rule of the set for a second command that follows run-time execution of the return instruction, wherein metadata processing of the third rule determines that the second instruction is equal to the second code tag. code tag, and if the program counter tag is a valid return address capability tag, allows execution of the second instruction, and the third rule clears the program counter tag used for the next instruction following run-time execution of the second instruction. do.

According to another aspect of the techniques herein, a method of processing an instruction includes: receiving a current instruction for metadata processing performed in a metadata processing domain isolated from a code execution domain containing the current instruction; and determining, by the metadata processing domain in conjunction with the metadata for the current instruction, whether to allow execution of the current instruction according to a set of one or more policies, wherein the one or more policies determine whether to allow execution of the current instruction from the first instruction in the complete sequence. It contains a set of rules that enforce execution of a complete sequence of instructions in a specified order up to the last instruction in the sequence. The method includes mapping a first shared physical page into a first virtual address space of a first process; and mapping a first shared physical page into a second virtual address space for a second process, wherein the first shared physical page includes a plurality of memory locations, each of the plurality of memory locations It is associated with one of a plurality of global metadata tags used in connection with rule processing in the metadata processing domain. The plurality of global metadata tags may represent a set of metadata tags shared by a plurality of processes, including at least a first process and a second process, both of the first process and the second process by a metadata processing domain. The same policy can be enforced for Enforcement of the same policy by the metadata processing domain may use metadata that enables a first process to perform actions not otherwise permitted by the same policy for a second process, and the program counter is associated with a program counter tag. , and different values of the associated program counter tags can be used by the rules of the same policy to allow the first process to perform actions not otherwise permitted by the same policy to the second process. The method may further include performing a first process by an assignment routine of the application to generate a next color for the application using a current color for the application, the current color for the application being application-specific for the application. Indicates the current state of the color sequence, the next color indicates the next state of the application-specific color sequence for the application, the current color is stored in the first metadata tag on the first atom. The first processing may include executing a first one or more instructions, the first one or more instructions triggering, by the metadata processing domain, metadata processing using one or more rules; Metadata processing using one or more rules uses the current color to generate the next color, and updates the current state of the application-specific color sequence for the application by storing the next color in the first metadata tag of the first atom. . The first one or more instructions may be included in an allocation routine of an application, and the first atom may be any of a register and a memory location. An application-specific color sequence can be an infinite sequence of different colors available for use by an application. , the next color may be stored as a tag value for each one or more memory locations used by the application, and the one or more memory locations may be allocated by an allocation routine. The set of rules may include a first rule and a second rule, and the complete command sequence may include a first command and a second command, the second command being executed immediately following the first command. The method comprises performing metadata processing of a first rule for a first instruction, wherein metadata processing of the first rule converts a program counter tag of a program counter used in a next instruction following runtime execution of the first instruction into a special tag. Including the step of setting to a value -; and performing metadata processing of a second rule for the second instruction, wherein the metadata processing of the second rule performs processing of the second rule only when the program counter tag of the program counter for the second instruction is equal to the special tag. and ensuring that the execution of the instruction is permitted.

According to another aspect of the techniques herein, the non-transitory computer readable medium includes stored code that, when executed, performs a method of processing an instruction, the method of processing the instruction: from a code execution domain containing the current instruction. Receiving a current command for metadata processing performed in an isolated metadata processing domain; and determining, by the metadata processing domain in conjunction with the metadata for the current instruction, whether to allow execution of the current instruction according to the set of one or more policies, the current instruction being in the first stack frame of the first routine. A location is accessed, the location of the current instruction and stack frame has an associated metadata tag, and a set of one or more policies provides stack protection and prevents improper access to a stack storage location that includes the storage location of the first routine's stack frame. includes a stack protection policy that prevents

According to another aspect of the technology herein, a system includes: a processor; and a memory containing stored code that, when executed by the processor, performs a method of processing the instruction, wherein the method of processing the instruction is performed in a metadata processing domain that is isolated from the code execution domain containing the current instruction. Receiving a current command for metadata processing; and determining, by the metadata processing domain in conjunction with the metadata for the current instruction, whether to allow execution of the current instruction according to the set of one or more policies, the current instruction being in the first stack frame of the first routine. A location is accessed, the location of the current instruction and stack frame has an associated metadata tag, and a set of one or more policies provides stack protection and prevents improper access to a stack storage location that includes the storage location of the first routine's stack frame. includes a stack protection policy that prevents

According to another aspect of the technology herein, a non-transitory computer-readable medium containing stored code that, when executed, performs a method of processing instructions, the method of processing instructions comprising: currently receiving a current instruction for metadata processing performed in a metadata processing domain isolated from a code execution domain containing the instruction; and determining, by the metadata processing domain in conjunction with the metadata for the current instruction, whether to allow execution of the current instruction according to a set of one or more policies, wherein the one or more policies determine whether to allow execution of the current instruction from the first instruction in the complete sequence. It contains a set of rules governing the execution of a complete sequence of instructions in a specified order up to the last instruction in the sequence.

According to another aspect of the technology herein, a system includes: a processor; and a memory containing stored code that, when executed by the processor, performs a method of processing the instruction, wherein the method of processing the instruction is performed in a metadata processing domain that is isolated from the code execution domain containing the current instruction. Receiving a current command for metadata processing; and determining, by the metadata processing domain in conjunction with the metadata for the current instruction, whether to allow execution of the current instruction according to a set of one or more policies, wherein the one or more policies determine whether to allow execution of the current instruction from a first instruction in the complete sequence. It contains a set of rules governing the execution of a complete sequence of instructions in a specified order up to the last instruction in the complete sequence.

According to another aspect of the techniques herein, a method of generating and using a metadata tag includes: a bootstrap tag in a first specified register of a plurality of specified registers used in a metadata processing domain isolated from a code execution domain; Storing (bootstrap tag); and performing a first process that derives one or more additional metadata tags from the bootstrap tag, the first process comprising one or more processes within the code execution domain that trigger metadata processing of one or more rules within the metadata processing domain. This includes executing commands. The bootstrap tag can be used as an initial seed tag from which all other metadata tags used by the metadata processing domain are derived. Bootstrap tags can be hardwired or stored in a portion of read-only memory. The storing step and the first processing may be included in the processing performed by executing the first code part of the bootstrap program when booting the system including the metadata processing domain and the code execution domain. The method includes deriving a default tag from a bootstrap tag stored in a first specified register; storing the default tag in a second specified register among a plurality of specified registers; and executing a sequence of instructions that triggers metadata processing of a rule in the metadata processing domain that writes a default tag from the second specified register as a metadata tag for each of a plurality of memory locations used by the code execution domain. can include The first process may include generating an initial set of metadata tags derived from the bootstrap tag, each metadata tag in the initial set of metadata processing domains for which no rule exists in the rules cache for the current instruction. may be generated by executing a current instruction within a code execution domain that triggers processing of a rule cache miss within, the rules cache containing rules relating to metadata used by metadata processing domains defining allowed actions. Handling a rule cache miss includes: calculating, by a rule cache miss handler running in a metadata processing domain, a new rule for the current instruction, the new rule of an initial set of metadata tags. Include the resulting metadata tag. Each metadata tag in the initial set may be a tag generator that may further be used to derive other metadata tags. Execution of the first set of one or more specified instructions will trigger processing of rules and rule cache misses in the metadata processing domain generating each metadata tag indicated by the tag generator used to generate the sequence of one or more other metadata tags. and execution of the second set of one or more specified instructions generates metadata for each metadata tag marked as a non-generating tag that cannot be used to further generate additional metadata tags. It can trigger processing of rules and rule cache misses within a processing domain. Bootstrap programs are rules processed in the metadata processing domain that write one or more special metadata code tags on one or more instructions of a designated code section to provide extended privileges, capabilities, or authorizations to the tagged one or more instructions. A triggering command may be further included. The designated code portion may include one or more of kernel code and loader code. One or more special metadata code tags are derived from a first metadata tag of the initial set of metadata tags, the first metadata tag being a special instruction tag generator. An initial set of metadata tags may include: an initial instruction metadata tag, which is a tag generator used to generate a sequence of one or more code tags used to tag instructions; An initial malloc metadata tag, which is a tag generator used to generate a sequence of one or more other malloc tag generators - each of which has one or more other malloc tag generators allocated memory cells and allocated memory cells used by different applications. used to generate a sequence of one or more other metadata tags for different applications with respect to colorizing any of the pointers pointing to -; An initial control flow integrity tag, which is a tag generator used to generate a sequence of one or more other control flow integrity tag generators - each of one or more other control flow integrity tag generators that tag a different application's control transfer target. used to generate a sequence of one or more other metadata tags for different applications with respect to; and an initial taint tag, which is a tag generator used to generate a sequence of one or more other taint tag generators, each of the one or more other taint tag generators for a different application. It is used to generate a sequence of one or more other metadata taint tags for different applications in conjunction with tagging data items used by a metadata taint tag based on the code that created or modified the data item. Sequences of metadata tags can be generated by executing commands that trigger other processing of rules in the metadata processing domain. Another processing step is to use the current metadata tag in the sequence to generate the next metadata tag in the sequence, the current metadata tag representing the current state of the sequence and stored as a metadata tag associated with an atom, the atom being a register or memory location. which of -; and updating the current state of the sequence by storing the next metadata tag as the metadata tag associated with the atom.

According to another aspect of the techniques herein, a method of obtaining control flow information for an application includes: executing a loader that loads the application for execution by a processor, wherein the executing the loader includes a metadata processing domain Executing a first code portion comprising one or more instructions triggering metadata processing of one or more rules in a first set in the metadata processing domain; collecting and storing control flow information for the application as application metadata that is accessible and inaccessible to the code execution domain; and executing instructions of the application in the code execution domain, wherein executing the instructions of the application transfers control of the application from a first source location to a first target location using at least a portion of the control flow information. Trigger metadata processing of a second set of rules in the control flow policy that determine whether to migrate. The first target location may have a set of one or more allowable source locations that are allowed to transfer control to the first target location. Collecting control flow information for the application and storing it as application metadata may further include the metadata processing domain performing other processing. Another process may include tagging the first target location with first metadata that identifies a set of one or more acceptable source locations, the first metadata stored as part of the control flow information of the application metadata. . A first instruction of the application may transfer control from a first source location to a first target location, and the first instruction may use the first metadata to allow the first source location to transfer control to the first target location. Determining whether it is included in the set of one or more allowable source locations may trigger metadata processing of one or more rules of the control flow policy that determine whether to allow execution of the first instruction. Another process may also include tagging each acceptable source location in the set with a unique source metadata tag. Each unique source metadata tag of each allowable source location may be included in a first sequence of source metadata tags for the application, the first sequence being a unique sequence of source metadata tags generated from a control flow generator tag. can A control flow generator tag may be generated from an initial control flow generator tag derived from an initial bootstrap tag. The initial control flow generator tag can be used to generate a plurality of additional control flow generator tags, and each additional control flow generator tag can be used to generate a unique sequence of source metadata tags for a different application.

According to another aspect of the technology herein, a non-transitory computer-readable medium is a non-transitory computer-readable medium comprising stored code that, when executed, performs a method of generating and using a metadata tag, comprising: A method of generating and using includes: storing a bootstrap tag in a first specified register of a plurality of specified registers used in a metadata processing domain isolated from a code execution domain; and performing a first process that derives one or more additional metadata tags from the bootstrap tag, the first process code executing one or more instructions that trigger metadata processing of one or more rules in the metadata processing domain. Including the steps to run on the domain.

According to another aspect of the technology herein, a system includes: a processor; and a memory containing stored code that, when executed, performs a method of generating and using metadata tags, wherein the method of generating and using metadata tags is used in a metadata processing domain isolated from a code execution domain. storing a bootstrap tag in a first specified register among a plurality of specified registers; and performing a first process that derives one or more additional metadata tags from the bootstrap tag, the first process code executing one or more instructions that trigger metadata processing of one or more rules in the metadata processing domain. Including the steps to run on the domain.

According to another aspect of the technology herein, a non-transitory computer-readable medium includes stored code that, when executed, performs a method of obtaining control flow information for an application, comprising: a method for obtaining control flow information for an application; B: Executing a loader that loads an application for execution by a processor, wherein executing the loader includes one or more instructions that trigger metadata processing of one or more rules of a first set in a metadata processing domain. 1 executing the code portion, wherein metadata processing of the one or more rules of the first set collects control flow information for the application as application metadata accessible to the metadata processing domain and inaccessible to the code execution domain; Including the step of storing -; and executing instructions of the application in the code execution domain, wherein executing instructions of the application determines whether to transfer control of the application from a first source location to a first target location using at least a portion of the control flow information. triggers metadata processing of a second set of rules of the determining control flow policy.

According to another aspect of the technology herein, a system includes: a processor; and a memory containing stored code that, when executed, performs a method of obtaining control flow information for the application, wherein the method of obtaining control flow information for the application comprises: a loader that loads the application for execution by the processor; executing a - executing the loader comprises executing a first code portion comprising one or more instructions that trigger metadata processing of one or more rules of a first set in a metadata processing domain; metadata processing of one or more rules of the set includes collecting and storing control flow information for the application as application metadata accessible to the metadata processing domain and inaccessible to the code execution domain; and executing instructions of the application in the code execution domain, wherein executing instructions of the application determines whether to transfer control of the application from a first source location to a first target location using at least a portion of the control flow information. triggers metadata processing of a second set of rules of the determining control flow policy.

According to another aspect of the techniques herein, a method of performing a processor-mediated data transfer between a tagged data source and an untagged data source includes: on a processor, loading first data from an untagged data source. executing the first instruction, wherein the untagged data source includes a memory location that does not have an associated metadata tag; tagging, by first hardware, the first data with a first metadata tag indicating that the first data is untrustworthy and is from a public data source, the first data having the first metadata tag stored in the first buffer -; and executing, on the processor, first code that triggers metadata processing using the first one or more rules, wherein metadata processing using the first one or more rules indicates that the first data is trustworthy. 2 Re-tagging is performed to re-tag the first data to have a metadata tag. The second metadata tag may further indicate that the first data is from a public source. The first data with a second metadata tag may be stored in a memory that is a tagged data source that includes memory locations each having an associated metadata tag. The memory may be a reliable memory containing data from one or more trusted data sources. Metadata processing may be performed in a metadata processing domain isolated from a code execution domain containing the first code. The first one or more rules may be rules relating to metadata used by the metadata processing to define allowed actions. The first code may include one or more instructions, each special instruction indicating that the respective instruction has an authorization to invoke one or more rules to retag the first data to have a second metadata tag. can have tags. The first data having the first metadata tag may be encrypted, and the method executes one or more instructions on a processor to decrypt the first data having the first metadata tag and decrypting the first data having the first metadata tag. 1 generating a decrypted form of data; and executing one or more additional instructions on the processor to perform validation processing using a digital signature to ensure that the decrypted form of the first data is valid; The re-tagging is performed after successful verification processing of the first data. The first data having the second metadata tag may be stored in decrypted form in a first memory location of the tagged memory, the method encrypting the first data to produce the first data in encrypted form and generating the first data in encrypted form. generating a digital signature according to the data, wherein the encrypting and generating steps are performed by executing additional code on a processor; and executing, on the processor, a second instruction to store the encrypted form of the first data from the first memory location in the tagged memory to the destination location in the untagged memory, The form is stored at the destination location without an associated metadata tag, and the second metadata tag is removed by the second hardware prior to storing the encrypted form of the first data at the destination location. At a first point in time, the first data may be stored in a first location in an untagged memory portion, and at a second point in time, the first data has a first metadata tag indicating that the first data is untrustworthy and is from a public data source. 1 data may be stored in the second location of the tagged memory portion. Where the untagged memory portion and the tagged memory portion are included in the same memory serviced by the same memory controller, the second metadata processing rule causes the processor to untagged data with an associated metadata tag indicating that the data is public. Direct memory operations from external, untagged sources that operate on untagged data may only be allowed to access the untagged memory portion of the same memory. . At least some of the second metadata processing rules may cause the processor to perform only operations to write data to an untagged portion of memory that has an associated metadata tag indicating that the data is public and additionally untrustworthy. An untagged data source may be coupled to a first interconnect fabric comprising only untagged data sources, and the first data having a second metadata tag may be coupled to a memory coupled to a second data source interconnect fabric comprising only tagged data sources. can be stored in the location of A second processor may be coupled to the first interconnect fabric and may execute other instructions using untagged data from an untagged data source. Other instructions may be executed without performing metadata processing and without using rules regarding metadata to enforce permissible actions, and execution of the other instructions by the second processor may process the untagged data of the first interconnect fabric. performing one or more operations including any of reading data from the source and writing data to an untagged data source of the first interconnect structure.

According to another aspect of the technology herein, a system includes: a processor; and one or more tagged memories, each memory location of the one or more tagged memories having an associated metadata tag; one or more untagged memories including a first untagged memory, wherein the memory locations of the one or more untagged memories do not have associated metadata tags; A rules cache containing rules relating to metadata used to perform metadata processing, defining allowed actions associated with an instruction - prior to execution of the current instruction by the processor, a metadata using one or more rules of the rules cache. Data processing is performed to determine if execution of the current instruction is allowed -; first instructions that, when executed by a processor, load first data from a first untagged memory into a data cache used by the processor, the first data stored in the data cache having an associated first metadata tag; second instructions that, when executed by a processor, store second data from the data cache to a first untagged memory, the second data stored in the data cache having an associated second metadata tag; A first hardware component that converts untagged data to tagged data used by the system in the system - in response to execution of the first instruction, the first hardware component converts any associated metadata from the first untagged memory Receive untagged first data and output first data with an associated first metadata tag; and a second hardware component that converts tagged data to untagged data, wherein in response to execution of the second instruction, the second hardware component receives second data having an associated second metadata tag and any The second data without associated metadata tag is output. the first data without any associated metadata tag may be encrypted, the first hardware component may convert the first data into a decrypted form, perform verification processing of the first data using a digital signature; Upon successful attestation processing, the first data may be tagged with an associated first metadata tag indicating that the first data is authentic. The second data with a second associated metadata tag may be in decrypted form, and the second hardware component may convert the second data to encrypted form and generate a digital signature according to the second data. The first hardware component can tag the first data with an associated first metadata tag indicating that the first data is trustworthy and also identifying that the first data is from a public source. One or more sets of cryptographic keys may be one of encoded in hardware and stored in memory. A set of one or more cryptographic keys may be used by a first hardware component in connection with performing decryption and verification processing and may be used by a second hardware component in connection with performing encryption and generating a digital signature. The first data identifies a particular one of the set of cryptographic keys used by the first hardware component to decrypt the first data, and the associated metadata tag of the second data identifies the cryptographic key used by the second hardware component. A particular one of the set can be identified to encrypt and sign the second data.

According to another aspect of the techniques herein, a method of processing a current instruction includes: receiving, for metadata processing, a current instruction; and performing metadata processing for a current instruction in a metadata processing domain isolated from a code execution domain containing the current instruction, wherein the current instruction has a first metadata tag used in metadata processing. 1 memory location is referenced, and the metadata processing for a current instruction includes: performing processing to retrieve a first metadata tag from memory; prior to receiving the first metadata tag for the first memory location from the memory, determining a predicted value of a first metadata tag of the first memory location; determining a first result metadata tag for a result operand of a current instruction using the predicted value of the first metadata tag of the first memory location; and receiving, from the memory, a first metadata tag; step c of determining whether the first metadata tag matches the predicted value of the first metadata tag; and in response to determining that the first metadata tag matches the predicted value of the first metadata tag, using the first result metadata tag as a final result metadata tag for the result operand. Metadata processing for a current instruction comprises determining, according to the current instruction and the set of input metadata tags for the current instruction, a first rule for the current instruction, the first rule being a first metadata tag in a first memory location. contains a predicted value of and includes a first result metadata tag, and the first rule is included in a rule cache used for metadata processing in the metadata processing domain; and in response to determining that the first metadata tag does not match the predicted value of the first metadata tag, performing rules cache miss processing in the metadata processing domain for the current instruction. Processing a rule cache miss in the metadata processing domain for the current instruction determines whether execution of the current instruction is permitted in the code execution domain; In response to determining that execution of the current instruction is permitted in the code execution domain, generating a new rule for the current instruction, the new rule being generated according to the current instruction, the set of input metadata tags, and the first metadata tag. ; and inserting a new rule into a rule cache used for metadata processing in the metadata processing domain. The set of other input metadata tags may include a plurality of other metadata tags for a current instruction, the set of other metadata input tags comprising: a program counter, a metadata for any of the current instruction and input operands of the current instruction. Can contain data tags. The result operand can be a destination memory location or destination register that stores the result of executing the current instruction. An instruction may be processed according to a plurality of stages including a first stage and a second stage, where the first stage may precede the second stage. A predicted value of a first metadata tag of a first memory location may be determined in a first stage, and a second stage may perform said determination whether the first metadata tag matches the predicted value of the first metadata tag. The second stage may also include handling a rule cache miss in the metadata processing domain for the current instruction in response to determining that the first metadata tag does not match the predicted value of the first metadata tag. may include performing The rules cache may be configurable to operate in either prediction mode or normal processing mode depending on the prediction selector mode. The rules cache may be configured to operate in speculative mode when performing metadata processing for the current instruction. When the rules cache is configured to operate in the prediction mode, the rules cache may generate a first output according to a first rule. The first output may include a metadata tag for the program counter of the next instruction, a first result metadata tag for the result operand of the current instruction, and a predicted value of the metadata tag as an output of the first stage. When the rules cache is configured to operate in the normal processing mode, the rules cache may generate a second output according to a second rule different from the first rule, the second output comprising a predicted value of the first metadata tag. Otherwise, the second output may include a metadata tag for the result operand of the current instruction and for the program counter of the next instruction. The rules cache may use a first version of the rules of the first policy when operating in predictive mode, otherwise it may use a second version of the rules of the first policy when operating in normal processing mode, the first rule being the rule cache may be included in the first version of and the second rule may be included in the second version of the rules.

According to another aspect of the techniques herein, a system includes: a pipeline processor including a plurality of pipeline stages, the plurality of stages including a memory stage and a writeback stage; Memory Stage A unified programmable unit for metadata processing (PUMP) that operates prior to completion of the memory stage - the PUMP references a first memory location having a first metadata tag used in metadata processing. performs metadata processing for a current instruction that does, the PUMP receives a first input comprising a first metadata tag for the current instruction, the PUMP generates a first output that is provided as an input to a writeback stage; The first output includes the predicted value of the first metadata tag of the first memory location and the first result metadata tag for the result operand of the current instruction, the first result metadata tag for the first memory location. 1 Determined by PUMP according to predicted value of metadata tag -; and determine whether the first metadata tag for the first memory location matches the predicted value of the first metadata tag, and when the first metadata matches the predicted value of the first metadata tag, a first resulting metadata. It includes a hardware component of the writeback stage that uses the data tag as the final result metadata tag for the result operand. The PUMP may be a first PUMP operating concurrently with the memory stage and further operating in predictive mode and determining the predicted value of the first metadata tag of the first memory location, the system operating in normal non-predictive mode. and may not determine any predicted value for the first metadata tag of the first memory location. A second PUMP may be incorporated as another stage between the memory stage and the writeback stage. The first PUMP may use the first version of the rules of the first policy for use when operating in predictive mode, and the second PUMP may use the first version of the rules of the first policy for use when operating in normal non-predictive mode. A second version is available. The first PUMP may determine the first output according to the first rule from the first version, and the second PUMP may determine the second output according to the second rule from the second version. The second output may include a second resulting metadata tag for the first memory location and the second output may be provided as an input to the writeback stage. The hardware component of the writeback stage may further use the second result metadata tag as the last result metadata tag for the result operand when the first metadata tag does not match the predicted value.

According to another aspect of the technology herein, a non-transitory computer-readable medium includes stored code that, when executed, performs a processor-mediated data transfer method between a tagged data source and an untagged data source, comprising: A processor-mediated data transfer method between a data source and an untagged data source comprises: executing, on a processor, a first instruction to load first data from an untagged data source, wherein the untagged data source includes associated metadata Contains memory locations that do not have tags -; tagging, by first hardware, the first data with a first metadata tag indicating that the first data is untrustworthy and is from a public data source - the first data having the first metadata tag stored in the first buffer -; and executing, on the processor, first code that triggers metadata processing using the first one or more rules, wherein metadata processing using the first one or more rules indicates that the first data is trustworthy. 2 Re-tagging is performed to re-tag the first data to have a metadata tag.

According to another aspect of the techniques herein, the non-transitory computer readable medium includes stored code that, when executed, performs a method of processing a current instruction, the method of processing a current instruction comprising: for processing metadata; receiving a current command; and performing metadata processing for the current instruction in a metadata processing domain isolated from a code execution domain containing the current instruction, wherein the current instruction has a first metadata tag used in metadata processing. Referring to the memory location, metadata processing for the current instruction includes: performing processing to retrieve the first metadata tag from memory; prior to receiving the first metadata tag for the first memory location from the memory, determining a predicted value of a first metadata tag of the first memory location; determining a first result metadata tag for a result operand of a current instruction using the predicted value of the first metadata tag of the first memory location; and receiving, from the memory, a first metadata tag; determining whether the first metadata tag matches the predicted value of the first metadata tag; and in response to determining that the first metadata tag matches the predicted value of the first metadata tag, using the first result metadata tag as a final result metadata tag for the result operand.

The features and advantages of the technology disclosed herein will become more apparent from the following detailed description of embodiments, taken in conjunction with the accompanying drawings.
1 is a schematic diagram illustrating an example of a PUMP cache integrated as a pipeline stage in a processor pipeline.
2 is a schematic diagram illustrating the PUMP Evaluation Framework.
FIG. 3A is a graph showing performance results for a single runtime policy implemented simply using the evaluation framework shown in FIG. 2 .
3B is a graph showing the performance results of a single energy policy according to a simple implementation.
4A is a series of histograms showing the composite policy runtime overhead of a simple implementation with a 64b Tag, where the composite policy is the following policies (i) spatial and temporal memory safety; It simultaneously enforces (ii) taint tracking, (iii) control-flow integrity, and (iv) code and data separation.
4B is a series of histograms illustrating the complex policy energy overhead of a simple implementation with a 64b tag.
4C is a series of histograms illustrating the power ceiling for a simpler implementation compared to the baseline.
5A is a bar graph comparing the number of PUMP rules without opgroup optimization and with opgroup optimization.
5B is a series of graphs illustrating the impact of miss rate of various opgroup optimizations based on PUMP capacity.
6A is a graph showing the distribution of unique tags for each DRAM transfer for the gcc benchmark according to the composite policy, showing that most words have the same tag.
6B is a diagram illustrating main memory tag compression.
7A is a schematic diagram showing conversion between a 16b L2 tag and a 12b L1 tag.
7B is a schematic diagram showing conversion between a 12b L1 tag and a 16b L2 tag.
8A is a schematic graph showing the effect of L1 tag length on L1 PUMP flush.
8B is a schematic graph showing the effect of L1 tag length on L1 PUMP miss rate.
9A is a series of bar graphs showing miss rates for different policies.
9B is a line graph depicting cache hit rates for four exemplary microarchitectural optimizations.
9C is a line graph showing miss service performance.
9D is a line graph showing miss handler hit rate based on capacity.
9E is a series of bar graphs illustrating the impact of optimization on a composite policy.
10A is a series of graphs illustrating the runtime overhead of an optimized implementation.
10B is a series of histograms illustrating the energy overhead of an optimized implementation.
10C is a series of bar graphs depicting the absolute power of an optimized implementation compared to a baseline.
11A is a series of shaded graphs illustrating the runtime overhead impact of tag bit length and UCP-cache ($) capacity for different representative benchmarks.
11B is a series of shaded graphs illustrating the energy overhead impact of tag bit length and UCP-$ capacity for different representative benchmarks.
12A is a series of graphs depicting the runtime impact of optimization on representative benchmarks: A: simple; B: A + Op grouping; C: B + DRAM compression; D: C + (10b L1, 14b, L2) short tag; E: D + (2048-UCP; 512-CTAG).
12B is a series of graphs depicting the energy impact of optimization on representative benchmarks: A: simple; B: A + Op grouping; C: B + DRAM compression; D: C + (10b L1, 14b, L2) short tag; E: D + (2048-UCP; 512-CTAG).
13A is a series of graphs illustrating runtime policy impact in composites for representative benchmarks.
13B is a series of graphs illustrating energy policy impacts in the complex.
Figure 14 is the first table, labeled "Table 1", which provides a summary of the policies examined.
Figure 15 is a second table, labeled "Table 2", which provides a summary of the classification of tagging schemes.
16 is a third table, labeled “Table 3,” which provides a summary of memory resource estimates for baseline and simple PUMP-extended processors.
Figure 17 is a fourth table, labeled "Table 4", which provides a summary of the PUMP parameter ranges used in the experiments.
18 is a fifth table, designated “Table 5”, which provides a summary of memory resource estimates for a PUMP-optimized processor.
Figure 19 is the first algorithm, denoted "Algorithm 1", which provides a summary of the taint tracking miss handler.
Figure 20 is a second algorithm, denoted "Algorithm 2", which provides a summary of N-Policy miss handlers.
Figure 21 is a third algorithm, denoted "Algorithm 3", which provides a summary of HW supported N-Policy miss handlers.
Figure 22 is a schematic diagram of PUMP rule cache data flow and microarchitecture.
23 is a schematic diagram of the PUMP microarchitecture.
FIG. 24 is a schematic diagram similar to FIG. 1 , illustrating an example PUMP cache integrated as a pipeline stage in a processor pipeline and its opgroup translation, UCP and CTAG caches.
25 is an example of a control status register (CSR) in an embodiment consistent with the techniques herein.
26 is an example of a tagmode in an embodiment according to the technology herein.
27 is an example illustrating a separate metadata processing subsystem/domain having a separate processor in an embodiment consistent with the techniques herein.
28 illustrates PUMP inputs and outputs in an embodiment consistent with the techniques herein.
29 illustrates inputs and outputs in relation to an opgroup table in an embodiment consistent with the techniques herein.
30 illustrates processing performed by PUMP in an embodiment according to the techniques herein.
31 and 32 provide additional details regarding control and selection of PUMP inputs and outputs in embodiments consistent with the techniques herein.
33 is an example illustrating a six-stage processing pipeline in an embodiment according to the techniques herein.
34 to 38 are examples illustrating sub-instructions and associated techniques in embodiments.
36 to 38 are examples illustrating sub-instructions and associated techniques in embodiments.
39-42 are examples illustrating byte-level tagging and associated techniques in an embodiment.
43 is an example illustrating a variable length opcode in an embodiment according to the technology herein.
44 is an example illustrating an opcode mapping table in an embodiment according to the technology herein.
45 is an example illustrating a shared page in an embodiment according to the technology herein.
46 is an example illustrating transfer of a control point in an embodiment according to the technology herein.
47 is an example illustrating a call stack in an embodiment according to the techniques herein.
48 to 49 are examples illustrating memory location tagging or coloring in embodiments according to the technology herein.
50 is an example illustrating setjmp and longjmp in an embodiment according to the technology herein.
51, 52 and 53 are tables of different runtime behaviors and associated protection behaviors and mechanisms used to implement protection behaviors in embodiments consistent with the techniques herein.
54, 55 and 56 are examples illustrating processing that may be performed to learn or determine policy rules in embodiments according to the techniques herein.
Figures 57, 58, 59 and 60 are examples illustrating components in an embodiment with respect to conversion between external and internal tagged versions of data.
61, 62, and 63 are examples illustrating aspects of performing tag prediction in an embodiment according to the technology herein.
64 and 65 illustrate the use of the colorized memory location detection technique of the present application where memory is allocated in an embodiment.
66 and 67 illustrate different components for providing hardware rule support in embodiments consistent with the techniques herein.
68-70 are examples illustrating the use of techniques herein in embodiments where PUMPs return values.
71 is an example illustrating the use of techniques herein in an embodiment having a sequence of instructions.
72 is a flow diagram of processing steps that may be performed in connection with booting a system in an embodiment consistent with the techniques herein.
73 is an example of a tree tag hierarchy associated with tag occurrence in an embodiment according to the techniques herein.
74, 75, 76, and 77 are examples illustrating aspects and characteristics related to an I/O PUMP in an embodiment according to the technology herein.
78, 79, 80, 81, and 82 are examples illustrating layers used in relation to storing and determining a tag value in an embodiment according to the description herein.
83 and 84 are examples illustrating control flow integrity and associated processing in embodiments in accordance with the techniques herein.

The following paragraphs describe various embodiments and aspects of a Programmable Unit for Metadata Processing (PUMP) that inextricably associates a metadata tag with every word in the system's main memory, caches, and registers. To support unlimited metadata, tags are large enough to indirectly specify data structures in memory. In every instruction, the tag of the input is used to determine if the operation is allowed, and if so, to calculate the tag of the result. In some embodiments, tag inspection and propagation rules are defined in software; However, to minimize performance impact, these rules are cached in the PUMP rule cache, a hardware structure that operates in parallel with the arithmetic logic unit (ALU) portion of the processor. In some embodiments, a miss handler, which may be implemented using, for example, software and/or hardware, may be used to service cache misses based on currently enforced policies.

The performance impact of PUMPs stresses PUMPs in different ways and exemplifies a range of security properties, e.g. (1) using tags to distinguish code from data in memory and to protect against simple code injection attacks. a Non-Executable Data and Non-Writable Code (NXD+NWC) policy that provides protection against (2) Memory safety, which detects all spatial and temporal violations of heap-allocated memory extending to a virtually unlimited number of colors ("taint marks"); Safety) policy; (3) Control-flow integrity, which prevents return-oriented-programming-style attacks by restricting indirect control transfers to only allowed edges in the control-flow graph of the program ( Control-Flow Integrity (CFI) policy (fine-grained CFI is enforced, but not approximated at a low level potentially vulnerable to attack); and (4) a fine-grained Taint Tracking policy (generalization) where each word can potentially be tainted by multiple sources (libraries and 10 streams) simultaneously. In at least one embodiment using a composite of policies, the performance impact of PUMP can be measured (see FIG. 14).

The foregoing are examples of well-known policies that may be used in embodiments consistent with the techniques herein. For those well-known policies for which protective capabilities have been established in the literature, the techniques herein can be used to enforce such policies while also reducing the performance impact of enforcing the policies using PUMP. Except for NXD+NWC, each of these policies must distinguish essentially an infinite number of unique items; In contrast, a solution with a limited number of metadata bits can support only an extremely simplified approximate solution at best.

As shown and described elsewhere herein, one embodiment in accordance with the techniques herein uses pointer-sized (64b or byte) tags to 64b words to reduce the size and energy usage of all memory in the system. A simple and straightforward implementation of PUMP that at least doubles is available. The rule cache adds realms and energies to this. In this particular example, an area overhead of 190% (see Fig. 16) was measured and an energy overhead in a geometric sense of about 220% was measured; Moreover, the runtime overhead can exceed 300% for some applications. This high overhead can discourage adoption if this is the best that can be done.

However, as explained in more detail below, most policies exhibit spatial and temporal locality both to tags and to the rules defined for them. Thus, embodiments in accordance with the techniques herein reduce the number of unique rules by defining rules for groups of similar (or even identical) instructions, reducing compulsory misses and increasing the effective capacity of the rule cache. can be significantly reduced. Off-chip memory traffic can be reduced by exploiting the tag's spatial locality. On-chip area and energy overhead can be minimized by using a small number of bits to represent a subset of point-sized tags in use at a time. The runtime cost of composite policy miss handlers can be reduced by providing hardware support for caching component policies. Accordingly, embodiments in accordance with the techniques herein may include such optimizations, thereby enabling PUMP to achieve lower overhead without compromising its rich policy model.

Embodiments in accordance with the techniques herein may enrich memory words and internal processor state with metadata that may be used to encode any number of security policies that may be enforced separately or concurrently. Embodiments according to the technology herein are implemented by adding a metadata processing unit (PUMP) that operates in parallel with the data flow to a "normal" processor (eg, RISC-CPU, GPU, vector processor, etc.) can achieve bar; The techniques of this disclosure specifically make metadata unrestricted and software programmable so that the techniques herein can be adapted and applied to a wide range of metadata handling policies. For example, PUMP can be integrated as a new/separate pipelined stage in a conventional (RISC) processor, or as a standalone piece of hardware running in parallel with the “host” processor. In the former case, there may be command-level simulators, sophisticated policies, implementation optimization and resource estimation, and extensive simulations to characterize the design.

Existing solutions that try to enforce policy at a fine (ie command) granularity level cannot enforce arbitrary sets of policies. Usually, only a few fixed policies can be enforced at the instruction level. Enforcing policies at higher levels of granularity (i.e., threads) does not prevent certain classes of Return Oriented Programming attacks, thus limiting those types of enforcement in their usefulness. In contrast, embodiments in accordance with the techniques herein enable the expression of an infinite number of policies that can be enforced singly or concurrently at the instruction level (metadata is a set of address pointers that can point to any and all data structures). Since it is expressed in terms, the only limitation is the size address space).

It should be noted that the various figures described in the following paragraphs depict various examples, methods and other illustrative embodiments of various aspects of the technology described herein. It will be appreciated that in such figures, the depicted element boundaries (eg, boxes, groups of boxes or other shapes) generally represent examples of boundaries. Those skilled in the art will recognize that in some instances one element may be designed as multiple elements or multiple elements may be designed as one element. In some examples, an element shown as an internal component of another element may be implemented as an external component and vice versa. In addition, elements may not be drawn to scale.

Referring to FIG. 1, a programmable unit for metadata processing (PUMP) 10 is a typical reduced instruction set with an in-order implementation suitable for energy-conscious applications and a 5-stage pipeline. It can be integrated into a Reduced Instruction Set Computing or Computer (RISC), effectively transforming it into a 6-stage pipeline with the addition of a PUMP 10. The first stage is the fetch stage (14), the second stage is the decode stage (16), the third stage is the execute stage (18), and the fourth stage is the memory stage. stage (memory stage) 20, and the fifth stage is a writeback stage (writeback stage) (22). The PUMP 10 is interposed between the memory stage 20 and the writeback stage 22 .

Various embodiments may implement PUMP 10 using electronic logic, a mechanism that provides policy enforcement and metadata propagation. Embodiments of PUMP 10 include (i) empirical evaluation of the runtime, energy, power capping and area impact of a simple implementation of PUMP 10 on a standard set of benchmarks under four different policies and combinations of policies; (ii) a set of micro-architectural optimizations; (iii) a typical runtime overhead of less than 10%, a power cap of 10%, and a typical energy overhead of less than 60% by using 110% extra area for the on-chip memory structure.

In computing, benchmarking may be characterized as the act of executing a computer program, set of programs, or other operations, by normally running a number of standard tests and trials of tests, to evaluate the relative performance of an object. The term 'benchmark' used herein refers to the benchmarking program itself. The types of benchmark programs used across these applications and drawings are GemsFDTD, astar, bwaves, bzip2, cactusADM, calculix, deall, gamess, gcc, gobmk, gromacs, h264ref, hmmer, IBM, leslie3d, libquantum, mcf, mile, namd , omnetpp, perlbench, sjeng, specrand, sphinx3, wrf, zeusmp and mean. See, for example, FIGS. 10A, 10B and 10C.

As used herein, "logic" means hardware, firmware, software and/or each component that performs function(s) or behavior(s) and/or causes that function or behavior from other logic, methods and/or systems. Combinations include, but are not limited to. For example, depending on the desired application or needs, the logic may be discrete logic such as software controlled microprocessors, processors (eg, microprocessors), application specific integrated circuits (ASICs), programmed logic devices. , a memory device containing instructions, an electrical device having memory, and the like. Logic may include one or more gates, combinations of gates, or other circuit components. The logic may also be implemented entirely in software. Where multiple logics are described, it may be possible to incorporate multiple logics into one physical logic. Similarly, where a single piece of logic is being described, it may be possible to distribute that single piece of logic among multiple physical logic.

In at least one embodiment according to the techniques herein, PUMP 10 may be characterized as an extension to a conventional RISC processor 12 . The following paragraphs describe the instruction set architecture (ISA)-level extensions that make up the hardware interface layer of the PUMP 10, basic microarchitectural changes, and accompanying low-level software that may be used in embodiments according to the techniques herein. provides additional details of

In embodiments consistent with the techniques herein, each word of a PUMP-enriched system may be associated with a pointer-sized tag. These tags are not interpreted at the hardware level. At the software level, tags are defined by policy and can represent metadata of infinite size and complexity. A simpler policy requiring only a few bits of metadata could store the metadata directly in the tag; If more bits are needed, indirection is used to store the metadata in memory as a data structure, and the address of this structure is used as the tag. In particular, this pointer-sized tag is one exemplary aspect of the present disclosure and is not to be considered limiting. The basic addressable memory word is indivisibly extended to the tag, making all value slots, including memory, cache and registers, appropriately wide. A program counter (PC) is also tagged. This concept of software-defined metadata and its representation as a pointer-sized tag extends pre-hardwired tagging approaches with interpretations where only a few bits are used in a tag and/or a few bits are fixed. Some exemplary classifications of tagging schemes are presented in Table 2 reproduced in FIG. 15 .

Metadata tags cannot be addressed by user programs. Rather, metadata tags are addressed by policy handlers that are invoked on rule cache misses detailed below. All updates to tags are realized through PUMP (10) rules.

In addition to infinite metadata, another feature of embodiments of PUMP 10 according to the techniques herein is hardware support for single cycle common-case computations on metadata. This calculation is defined in terms of a rule of the form opcode: (PC, CI, OP1, OP2, MR) => (PC _new , R), which means "if current opcode is opcode, current tag on program counter is PC and , if the tag on the current instruction is CI, the tags on its input operands (if any) are OP1 and OP2, and the tag on the memory location (for load/store) is MR, then the program in the next machine state The tag on the counter should be PC _new and the tag on the command result (destination register or memory location, if any) should be R". This rule format, allowing two output tags to be computed from up to five input tags, is significantly more flexible than that considered in the previous operation, which typically computes one output from up to two inputs (Table 15, Figure 15). 2). In addition to previous solutions that only track data tags (OP1, OP2, MR, R), the present disclosure provides a current instruction tag that can be used to track and enforce the origin, integrity and usage of a block of code. (CI) provided; In addition, it provides PC tags that can be used to record "control states" including execution history, ambient authority, and implicit information flow. The CFI policy uses PC tags to record the source of indirect jumps and CI tags to identify jump targets, and NXD + NWC actively utilizes CI to ensure that data is not executable. Enforce, and Taint Tracking uses CIs that taint data based on the code that created them.

To resolve rules in a single cycle in the typical case, embodiments in accordance with the techniques herein may use a hardware cache of most recently used rules. Depending on the command and policy, one or more of the input slots in a given rule may not be used. To avoid polluting the cache with rules for all possible values of unused slots, the rules-cache lookup logic ensures that for each input slot-opcode pair, the corresponding tag is actually Refers to the bit vector containing the "don't-care" (see Figure 1) bit, which determines whether it is used. To efficiently process these "money-care" inputs, these inputs are masked before presenting them to PUMP 10. The don-care bit vector is set by a privileged instruction as part of the miss handler installation.

Figure 1 shows one embodiment according to the techniques herein having a modified 5-stage processor 12 pipeline generally incorporating PUMP 10 hardware. Rule cache lookups are added independently as additional stages and bypass tags and data so that the PUMP 10 stage does not create additional stalls in the processor pipeline.

Placing PUMP 10 as a separate stage (between memory stage 20 and writeback stage 22) is driven by the need to provide (load) tags on words read from memory (load) or by the PUMP Motivated by the need to have the memory (store) overwritten as an input to (10). A write operation becomes a read-modify-write operation, since rules that depend on the existing tag of the memory location being written are allowed. Existing tags are read during the memory stage 20, such as read rules, read rules are checked in the PUMP 10 stage, and writes are performed during the commit stage, which may also be referred to as writeback stage 22. . Multiple levels of cache may be used with PUMP 10, along with any caching scheme. As described in more detail below, embodiments in accordance with the techniques herein may utilize a two-level cache. Extensions to multi-level caches are readily apparent to those skilled in the art.

In one non-limiting example, when a last level miss occurs in the rules cache of writeback stage 22, the following is processed: (i) the current opcode and tag are stored in ( new) set, (ii) control transfers to the Policy Miss Handler (described in more detail below), and (iii) determines whether the action is allowed and, if so, appropriate rules are created. When the miss handler returns, the hardware (iv) installs this rule into the PUMP 10 rule cache, and (v) re-issues the faulting instruction. To provide separation between authorized miss handlers and the rest of the system software and user code, a miss handler mode of operation is added to the processor, controlled by bits in the processor state that are set on rule cache misses and reset when the handler returns. do. To avoid the need to save and restore registers on every rule cache miss, the integer register file can be extended with 16 additional registers available only to the miss handler.

Rule inputs and outputs also appear as registers, in miss handler mode (e.g., register windows), which allows miss handlers (but not others) to manipulate tags to generic values. Again, these are all non-limiting examples of the writeback stage 22.

A new miss handler return instruction has been added to install the rule into the PUMP(10) rule cache and return to user code. In this particular non-limiting embodiment, this command may only be issued when in miss handler mode. While in miss handler mode, the rule cache is ignored and instead the PUMP 10 applies a single hardwired rule instead: all instructions and data touched by the miss handler must be tagged with the predefined MISSHANDLER tag, and all Command results are given the same tags. In this way, the PUMP 10 architecture prevents user code from weakening the protection provided by the policy. Alternatively, PUMP can be used to enforce flexible rules on miss handler access. Tags are not segmentable, addressable, or replaceable by user code; Metadata data structures and miss handler code cannot be touched by user code; User code cannot directly insert rules into the rule cache.

Referring to FIG. 19, Algorithm 1 shows the operation of the miss handler for the taint tracking policy. To minimize the number of individual tags (and rules), the miss handler "canonicalizes" any new data structures it builds, using a single tag for logically equivalent metadata.

Instead of forcing users to choose a single policy, enforce multiple policies simultaneously and add new ones later. An exemplary advantage of these "infinite" tags is that they can enforce any number of policies at the same time. This can be achieved by making the tag a pointer to a tuple of tags from several component policies. For example, to combine an NXD+NWC policy with a taint tracking policy, each tag could be a pointer to a tuple (s, t), where s is an NXD+NWC tag (DATA or CODE) and t is A taint tag (a pointer to a set of taints). Rule cache lookups are similar; However, when a miss occurs, the two component policies are evaluated separately: the action is allowed only if both policies allow it, and the resulting tag is a pair of results of the two component policies. However, in other embodiments, it may be possible to express how policies should be combined (and not simply as an AND between all constituent components).

Referring to Figure 20, Algorithm 2 shows the general behavior of a compound miss handler for all N policies. Depending on how the tags within the tuple are correlated, this can result in a large increase in the number of tags and number of rules. To support multiple policies simultaneously and measure their impact on working set size, a composite policy (“composite”) was implemented experimentally, where the composite policy contained all four policies described above. do. Composite policies represent the types of policy workloads supported and are detailed below. As shown in FIGS. 4A and 20 , the composite policy concurrently implements the following policies: (i) spatial and temporal memory safety, (ii) taint tracking, (iii) control flow integrity, and (iv) code and data separation. enforce

Most policies dispatch on opcodes to select the appropriate logic. Some policies like NXD+NWC will check right away if the action is allowed. Other policies may reference data structures (e.g., CFI policies reference graphs of allowed indirect calls and return ids). Memory safety checks for equality between the address color (i.e. pointer color) and the memory area color. Taint tracking calculates a new result tag by combining the input tags (Algorithm 1). Policies that require access to large data structures (CFIs), or policies that require standardization across large aggregates (taint tracking, complex), can cause many memory accesses that go to DRAM with misses in the on-chip cache. Averaging across all benchmarks, it took 30 cycles to service misses for NXD+NWC, 60 cycles for memory safe, 85 cycles for CFI, 500 cycles for trace trace and 800 cycles for composite.

If the policy miss handler determines that the operation is not allowed, it calls the appropriate security fault handler. What this fault handler does depends on the runtime system and policy; Typically, this will terminate the offending process, but may instead return an appropriate "safe value" as the case may be. For incremental deployment using UNIX-style operating systems, the assumed policy is applied per process, so each process can have a different set of policies. The recitations applied per process are non-limiting but rather illustrative and will be recognized by those skilled in the art. It also allows us to place tags, rules, and miss handling support into the address space of a process, eliminating the need for OS-level context switching. In the long term, perhaps the PUMP policy can be used to protect the OS as well.

The following detailed evaluation methodology for measuring runtime, energy, area and power overhead uses 128b words (64b payload and 64b tags) and the modified pipeline processor 12 shown in FIG. Applies to simple implementations of software. It is useful to first describe and measure a simple PUMP implementation, even though the optimized implementation is the version where the overhead (relative to the baseline processor) is ultimately desired. Both are explained as this enumerates the basic version of the core mechanism in detail before getting to the more elaborate version.

To evaluate the physical resource impact of PUMP, memory cost was first of all focused, since memory is a major area and energy consumer for simple RISC processors and PUMP hardware expansion. 32 nm Low Operating Power (LOP) process is considered for L1 memory (see Fig. 1), Low Standby Power (LSTP) is considered for L2 memory, area, access CACTI 6.5 is used to model the time, energy per access, and static (leakage) power of main memory and processor on-chip memory.

Baseline processors (no PUMP) have separate 64KB L1 caches for data and instructions and a unified 512KB L2 cache. A latency-optimized L1 cache and an energy-optimized L2 cache were used. All caches use writeback discipline. The baseline L1 cache has a latency of about 880 ps; It is estimated that it can return a result in one cycle and set its clock to 1 ns to provide a 1 GHz cycle target comparable to current embedded cell phone processors. The parameters of this processor are presented in Table 3 of FIG. 16 .

One embodiment of a PUMP rules cache 10 hardware implementation may include two parts: extending all architectural state in stages 14, 16, 20 into tags, and adding a PUMP rules cache to processor 12. can Extending each 64b word in the on-chip memory to a 64b tag increases area and energy per access and worsens access latency. This already has multi-cycle access latencies, and the L2 cache potentially goes unused every cycle. However, adding an extra cycle of latency to access the L1 cache (see Figure 1) can cause a stall in the pipeline. To avoid this, in this simple implementation, the effective capacity of the L1 cache is reduced to half of the basic design and then tags are added; This provides the same single cycle access to the L1 cache, but can degrade performance due to increased misses.

In an embodiment according to the techniques herein, the PUMP rules cache 10 uses a long match key (5 pointer-sized tag and Use instruction opcode or 328b) and return 128b result. In one embodiment, a fully associative L1 rule cache may be used but may result in high energy and latency (see Table 3 in FIG. 16). Alternatively, embodiments consistent with the techniques herein may use a multiple hash cache scheme inspired by four hash functions, as shown in FIG. 22 . The L1 rule cache produces results in a single cycle and checks for false hits in a second cycle, while the L2 rule cache is designed for low energy use and provides multi-cycle access latency. Again, Table 3 of FIG. 16 shows the parameters of the 1024-entry L1 and 4096-entry L2 rule caches used in a simple implementation. When these caches reach capacity, a simple first-in-first out (FIFO) replacement policy is used, which seems to work well in practice under the current operating load (FIFO is the LRU's in this application). within 6%).

Referring to Figure 2, the performance impact assessment of PUMP identifies a combination of ISA, PUMP and address-trace simulator. The gem5 simulator 24 generates an instruction trace for the SPEC CPU2006 program (omitting xalancbmk and tonto, where gem5 fails) on the 64-bit Alpha baseline ISA. Each program simulates for each of the four policies listed above and for a composite policy during a warm-up period of 1B instructions, then evaluates 500M instructions. In the gem5 simulator 24, each benchmark runs on the baseline processor without tags or policies. The resulting instruction trace 26 is then run through the PUMP simulator 28 which performs metadata calculations for each instruction. This "phased" simulation strategy is correct for a fail-stop policy in which the result of a PUMP cannot divert the program's control flow from its baseline execution. Address-trace simulations may not be accurate for highly pipelined, out-of-order processors, but are very accurate for simple, sequential 5-stage and 6-stage pipelines. In the baseline configuration, custom address trace simulation and counting in address simulator 32 followed by gem5 instruction simulation and address trace generation 30 were within 1.2% of gem5's cycle-accuracy simulation.

The PUMP simulator 28 contains miss-handler code (written in C) that implements each policy, and metadata tags are allocated on initial memory according to the policy. The PUMP simulator 28 captures access patterns within the PUMP 10 rule cache and estimates the associated runtime and energy cost given the longer wait cycles required to access the L2 rule cache. Since the PUMP simulator 28 with the miss handler code also runs on the processor, a separate simulation is performed for the miss handler on gem5 to capture the dynamic behavior. Because miss-handler code potentially affects data and instruction caches, a merged address-trace is created that contains properly interleaved memory accesses from both user and miss-handler code, which has no performance impact on the memory system. It is used for the final address-trace simulation to be evaluated.

In the following paragraphs, an evaluation of a simple PUMP implementation compared to a baseline without PUMP is provided.

As one evaluation point, it should be noted that the overhead of the entire area of the PUMP 10 besides the baseline processor is 190% (see Table 3 in FIG. 16). A major part (110%) of this region overhead comes from the PUMP 10 rules cache. The unified L2 cache accounts for most of the remaining area overhead. The L1 D/I cache remains approximately the same as its effective capacity is cut in half. This high memory area overhead roughly triples the static power, contributing 24% of the energy overhead.

Another evaluation point has to do with runtime overhead. For every single policy in most benchmarks, the average runtime overhead of this simple implementation is only 10% (see Figs. 3a and 3b; to read the boxplots: bars are the medians, boxes are the top and bottom 1s). occupies the /4 quartile (middle 50% of cases), dots represent each individual data point, whiskers represent the full range excluding outliers (each quartile greater than 1.5x), and the major overhead is from the additional DRAM traffic required to transfer tag bits to and from the processor). For the memory safety policy (FIGS. 3A and 3B), there are several benchmarks that show high miss handler overhead, boosting the total overhead by 40-50% due to forced misses in newly allocated memory blocks. For the composite policy runtime (labeled "CPI" or "CPI overhead" in the figure), five of the benchmarks suffer from very high overhead in the miss handler (see Figure 4a), and in the worst case GemsFTDT it suffers from 780% overhead. , and in geomean it amounts to 50%. For the composite policy energy shown in Fig. 4b (labeled "EPF" or "EPI overhead" in the figure), three of the benchmarks (e.g., GemsFTDT, astar, omnetpp) show very high overhead in the miss handler. heads, worst case is 1600% on GemsFTDT, 600% on astar, and close to 520% on omnetpp).

Two factors contribute to this overhead: (1) the large number of cycles required to resolve last-level rule cache misses (because all component miss handlers are referenced) and (2) scaling the working set size and It is an explosion in the number of rules that increases the rule cache miss rate. In the worst case, the number of unique composite tags can be a result of unique tags in each component policy. However, the overall rule increases by a factor of 3x to 5x compared to memory safety, which is the largest single policy.

Another point of evaluation is the energy overhead. Moving more bits due to wider words and executing more instructions due to miss handler code both contribute to energy overhead, affecting both single and compound policies (FIG. 3b and Fig. 4b). CFI and memory safety policies - and hence complex policies - access large data structures that often require energy-expensive DRAM accesses. The worst-case energy overhead is close to 400% for a single policy, about 1600% for a composite instance policy, and about 220% for a geomean overhead.

In many platform designs, worst case power or equivalently energy per cycle is the limiter. This power cap can be pushed by the maximum current the platform can draw from the battery or the maximum sustained operating temperature in a mobile or wired device using ambient cooling. Figure 4c shows that a simple implementation raises the maximum power cap by 76% using lbm to rush to maximum power in both the baseline implementation and the simple PUMP implementation. These power cap increases are lower than the worst-case energy overhead in part because some benchmarks are slower than the extra energy they consume, and benchmarks with high energy overhead are cycles away from the baseline design. It should be noted that this is because they consume the least absolute energy per Typically, the data working set of these energy-efficient programs fits in an on-chip cache, so they seldom cost more than the cost of a DRAM access.

Embodiments incorporating the foregoing implementations described above achieve reasonable performance in most benchmarks, runtime overhead for complex policies in some of the benchmarks, and energy and power overhead in all policies and benchmarks are acceptable. It seems impossibly high. To address this overhead, a series of targeted microarchitectural optimizations may be introduced and incorporated into embodiments according to the techniques herein. In Table 4 of FIG. 17, these optimizations are examined for the impact of architectural parameters associated with PUMP components on overall cost. Grouping opcodes with identical rules reduces the effective capacity of the PUMP rule cache, tag compression that reduces latency and energy before DRAM transfers, short tags that reduces area and energy in on-chip memory, and a unified component that reduces the overhead of miss handlers. Used to increase Unified Component Policy (UCP) and Composition Tag (CTAG) caches.

What is now described are “opgroups” that may be used in embodiments according to the techniques herein. It is common in pragmatic policies to define similar rules for multiple opcodes. For example, in the taint tracking policy, the rules for Add and Sub instructions are the same (see Algorithm 1 in FIG. 19). However, in simple implementations, these rules occupy separate entries in the rules cache. Based on these observations, instruction opcodes ("opcodes") allow identical rules to be grouped into "opgroups" to reduce the number of rules needed. The opcodes that can be grouped together depend on the policy; Therefore, the "don-care" SRAM is expanded in execution stage 18 (FIG. 1) to also convert opcodes to opgroups prior to rules cache lookups. For compound policies, over 300 Alpha opcodes are reduced to 14 opgroups, and the total number of rules is reduced by a factor of 1.1x to 6x with an average of 1.5x (Fig. 5a measures this impact across all SPEC benchmarks). ). This effectively increases the rule cache capacity for a given investment in the silicon realm. Opgroups also reduce the number of forced misses because a miss on a single instruction in a group establishes a rule that applies to all instruction opcodes in the group. Figure 5b summarizes miss rates across all SPEC benchmarks for different L1 rule cache sizes for composite policies with and without opgrouping. 5b shows that both the range and the average of the miss rates are reduced by opgrouping. In particular, the 1024-entry rule cache after opgroup optimization has a lower miss rate than the 4096-entry rule cache without optimization. A lower miss rate naturally reduces the time and energy spent in miss handlers (see FIGS. 12A and 12B ), and a smaller rule cache directly reduces area and energy.

Embodiments consistent with the techniques herein may utilize main memory tag compression, which will now be described. Using a 64b tag for a 64b word doubles the off-chip memory traffic, almost doubling the associated energy. Typically, tags indicate spatial locality - many adjacent words have the same tag. For example, Fig. 6a plots the unique tag distribution for each DRAM transfer of the gcc benchmark according to the composite policy, showing that most words have the same tag; On average, there are only about 1.14 unique tags per DRAM transfer of 8-word carry lines. This spatial tag locality is used to compress the tag bits that must be transferred to and from off-chip memory. Because data is transferred in cache lines, cache lines are used as the basis for this compression. To simplify address specification, 128B per cache line is allocated to main memory.

However, instead of directly storing 128b tagged words, eight 64b words (payloads) are stored, followed by eight 4b indices, and then up to eight 60b tags, as shown in Figure 6b. The index identifies which of the 60b tags matches the associated word. The tag is truncated to 60b to accommodate the index, but this does not break the use of the tag as a pointer: assuming byte addressing and a 16B (two 64b words) aligned metadata structure, the lower 4b of the 64b pointer is It can be filled with 0. Consequently, after sending 4B of the index, all that remains must transfer the unique 7.5B tag in the cache line. For example, if all words in a cache line use the same tag, the first read transfers 64B+4B = 68B, the second read transfers 8B, for a total of 76B transferred instead of 128B. The 4b index can be either a direct index or a special value. A special index value representing the default tag is defined, so that there is no need to send any tag in this case. By compressing the tags in this way, the average energy overhead per DRAM transfer is reduced from 110% to 15%.

The compression scheme presented above may be used in embodiments according to the techniques herein due to the combination of simplicity and effectiveness in reducing off-chip memory energy, for example. Those of ordinary skill in the art will appreciate that additional and alternative sophisticated approaches exist for fine-grained memory tagging, including multi-level tag page tables, variable-grained TLB-like structures, and range caches; and It is expressly appreciated that these may be used to reduce the DRAM footprint in embodiments according to the techniques herein.

It will now be described how tag translation can be performed in embodiments according to the techniques herein. Referring back to Figure 1, each cached rule is 456b wide, which is large for a simple PUMP rule cache (adding 110% area). To support PUMP 10, it was necessary to expand the baseline on-chip memory (RF and L1/L2 cache) to 64b tags. Here, using a full 64b (or 60b) tag for each 64b word introduces dense area and energy overhead. However, the 64KB L1-D$ accommodates only 8192 words and thus holds at most 8192 unique tags. With 64KB L1-I$, there can be at most 16384 unique tags in the L1 memory subsystem; These can be represented by just 14b tags, reducing latency, area, energy and power in the system. The caches (L1, L2) exist to take advantage of temporal locality, and this observation suggests that locality can be actively used to reduce area and energy. When the tag bits are reduced to 14b, the PUMP rules cache match key is reduced from 328b to 78b.

To achieve the aforementioned savings without losing the flexibility of full pointer-size tags, different-width tags can be used in different on-chip memory subsystems and converted between them as needed. there is. For example, you can use a 12b tag in L1 memory and a 16b tag in L2 memory. 7A details tag translation that may be performed between the L1 and L2 memory subsystems. Moving a word from the L2 cache 34 to the L1 cache 36 requires converting its 16b tag to the corresponding 12b tag, creating a new association if necessary. The simple SRAM 38 for L2-tag-to-L1-tag translation has an extra bit to indicate if there is an L1 mapping for an L2 tag. FIG. 7B details the conversion from L1 tag 40 to L2 tag 42 where an SRAM 39 lookup is performed (either during writeback or L2 lookup) using the L1 tag as the address. A similar conversion occurs between the 60b main memory tag and the 16b L2 tag.

When there is no long tag in the long-to-short conversion table, a new short tag is assigned, potentially reverting previously assigned short tags that are no longer in use. There is a rich design space for determining when short tags can be returned, including garbage collection and tag-usage counting. For simplicity, short tags are allocated sequentially and all caches above a certain level (instruction, data and PUMP) are flushed when short tag space is exhausted, keeping track of when a particular short tag can be returned. avoid the need Caches can be designed with suitable techniques to make cache flushes cheap. For example, in embodiments according to the description herein, all caches are known in the art, such as those described in, for example, K. Mai, R. Ho, E. Alon, D. Liu, Y. In Kim, D. Patil, M. Horowitz, Architecture and Circuit Techniques for a 1.1GHz 16-kb Reconfigurable Memory in 0.18um-CMOS, IEEE J. Solid-State Circuits, 40(l):261-275, January 2005) It can be designed with the described lightweight gang clear, which document is incorporated herein by reference.

If each L1 rule cache access costs 51 pJ, compared to Table 3 (reproduced in Figure 16), the technique herein provides a reduction down to 10 pJ with 8b L1 tag or 18 pJ with 16b L1 tag; , the energy scales linearly with the tag length between these points. The energy impact on the L1 instruction and data cache is small.

Similarly, using a 16b L2 tag, the L2 PUMP access cost is 120pJ, lower than the 173pJ using a 64b tag. By slimming the L1 tag, the capacity of the L1 cache can be restored. With a 12b tag, the full-capacity (76KB, effective 64KB) cache will meet the single-cycle timing requirements, reducing the performance penalty for simpler implementations by reducing the L1 cache capacity. As a result, the L1 tag length lookup is limited to 12 bits or less. Even shorter tags reduce energy, but shorter tags increase the frequency of flushes.

8A and 8B show how flushes decrease as the L1 tag length increases, as well as the effect on the L1 rule cache miss rate.

Various techniques that may be used in conjunction with miss handler acceleration will now be described. Embodiments according to the techniques herein may combine four policies into a single composite policy. Referring to FIG. 20 , in Algorithm 2, each invocation of the N-Policy miss handler must resolve a tuple of tags, and the rules needed for the composite policy increase the rule cache miss rate identified in FIG. 9A. Although the taint tracking and CFI policies individually have low miss rates, the higher miss rates resulting from the memory safety policies drive the miss rates of the composite policies high as well. The lower miss rates of the individual policies suggest that the results of the miss rates are cacheable even in the absence of compound rules.

In conjunction with various aspects of the PUMP microarchitecture as shown in FIG. 23, hardware structures may be used to optimize composite policy miss handling. Embodiments according to the techniques herein may use a Unified Component Policy (UCP; see Algorithm 3 of FIG. 21) cache (UCP $) in which the most recent component policy result is cached. In this embodiment, the generic miss-handler needed for the composite policy is modified to perform a lookup in this cache while resolving the component policy (eg, algorithm of Figure 21, see policy at line 3). When this cache generates a miss for a component policy, the cache's policy calculation is performed in software (and the result is inserted into this cache).

As also shown in FIG. 24, the UCP cache can be implemented with the same hardware configuration as the regular PUMP rules cache, with the addition of a policy identifier field. A FIFO replacement policy can be used for this cache, but it is possible to achieve better results by prioritizing space using metrics such as recalculation cost for component policies. This cache filters out most of the policy re-computation with normal capacity (Fig. 9Bb; hit rate to memory safety is low due to compulsory misses associated with new memory allocation). As a result, the average number of miss handler cycles is reduced by a factor of 5 for the most demanding benchmark (Fig. 9e). Since the required composite rules can be the result of a small number of component policy rules, there is a chance that all policies will hit the UCP cache when there is a miss at the L2 PUMP. In the case of GemsFDTD, three or more component policies hit about 96% of the time.

As also shown in Figures 23 and 24, a cache can be added to convert a tuple of result tags to its standard composite result tag. The aforementioned cache may be referred to as a de facto composite tag (CTAG) cache (CTAG $) (FIG. 9D) since it is common for some component policy rules to return identical tuples of result tags. For example, even if the resulting tags are different, in most cases the PC _tag will be the same. Also, many different rule inputs can lead to the same output. For example, in a set of taint traces, unions are performed, and many different unions will have the same result; For example, (Blue, {A, B, C}) returns the result of both {A} U {B, C} and {A, B} U {B, C} (the taint trace) to the Blue slot ( It is a composite answer to write to memory safe). A FIFO replacement policy is used for this cache. The CTAG cache reduces the average miss handler cycle by another factor of 2 (see Fig. 9e).

When used together, the 2048-entry UCP cache and the 512-entry CTAG cache reduce the average time spent on each L2 rule cache miss from 800 cycles to 80 cycles.

Embodiments according to the techniques herein may also improve performance by prefetching one or more rules stored in one or more caches containing rules. Therefore, the forced miss rate can be reduced by using a precompute rule that may be needed in the near future. The example instance has a high value for the memory safety rule. For example, when a new memory tag is allocated, the new rule is for that tag (initialize (1), add offset to pointer and move (3), scalar load (1), scalar store (scalar store) (2)). As a result, all of these rules can be immediately added to the UCP cache. For the single policy memory safety case, rules can be added directly to the rule cache. This reduces the number of memory-safe miss handler calls by a factor of 2x.

Referring to Fig. 11a with respect to the overall evaluation, architectural parameters monotonically affect a particular cost, providing a trade-off between energy, delay and area, but do not define a minimum within a single cost criterion. Once the tag bits get small enough, the L1 D/I cache can be restored to its baseline capacity, which has the effect of a threshold where the baseline is taken as an upper bound to explore the L1 tag length, but beyond that point if the tag length is reduced Energy is reduced with a small impact on performance.

11b shows that reducing the tag length has a dominant energy effect for most benchmark programs (e.g., Ieslie3d, mcf), and some programs show equal or greater gains with increasing UCP cache capacity ( For example, GemsFDTD, gcc). A large miss handler cache and a few tag bits are chosen to save energy, ignoring other cost concerns. Runtime overhead (see Fig. 11a) is also minimized by using a larger miss handler cache, but more than less tag bits are beneficial (eg GemsFDTD, gcc).

The size of the gain depends on the benchmark and policy. Across all benchmarks, the advantage over the 10b L1 tag for the SPEC CPU2006 benchmark is small, so 10b is used as a compromise between energy and latency and is explored using a 2048-entry UCP cache and a 512-entry CTAG cache. It reduces overhead while approaching the minimum energy level within the space of architectural parameters.

12A and 12B show the overall impact on runtime and energy overhead of applying optimizations. All optimizations dominate some benchmarks (e.g. opgroup for astar, DRAM tag compression for lbm, short tag for h264ref, miss handler acceleration for GemsFDTD), and each optimization in succession breaks one bottleneck. Remove and expose the next bottleneck. Behavior different from the benchmark follows the baseline characteristics as detailed below.

Applications with low locality have primary energy and performance driven by DRAM due to high main memory traffic. Overhead in these benchmarks (eg lbm) tends to be DRAM overhead, so any reduction in DRAM overhead directly affects runtime and energy overhead. Applications that are more local are faster, consume less energy, and suffer less DRAM overhead in the baseline configuration; As a result, these benchmarks are more severely affected by the reduced L1 capacity and reduced tag energy in the L1 D/I and rule caches. DRAM optimization has a small impact on these applications, but using short tags has a large energy impact and eliminates the L1 D/I cache capacity penalty (eg h264ref).

In benchmarks with a lot of dynamic memory allocation, forced misses result in higher L2 rule cache miss rates because newly created tags must be installed in the cache. This led to high overhead for several benchmarks in a simple implementation (GemsFDTD, omnetpp). The miss handler optimization described in this application reduces the cost of common cases of such misses, and the opgroup optimization reduces the capacity miss rate. For a simple implementation, GemsFDTD caused an L2 rule cache miss every 200 instructions and took 800 cycles to handle each miss, which led to the majority of the 780% runtime overhead (see Fig. 4a). According to the optimization, the GemsFDTD benchmark services L2 rule cache misses every 400 instructions and uses only 140 cycles on average per miss, reducing runtime overhead by about 85% (see Fig. 10a).

Overall, these optimizations bring runtime overhead down by 10% for all benchmarks except GemsFDTD and omnetpp, which have high memory allocations (see eh 10a). The average energy overhead is close to 60%, and only four benchmarks exceed 80% (see Fig. 10b).

To illustrate, the performance impact of PUMPs is highlighted in several ways by four different policies that highlight PUMPs and illustrate a range of different security characteristics: (1) use tags to distinguish code from data in memory and simple code injection; a Non-Executable Data and Non-Writable Code (NXD+NWC) policy that provides protection from attacks; (2) a memory safety policy that detects all spatial and temporal violations of heap-allocated memory, extending to an effectively infinite (260) number of colors ("taint marks"); (3) a Control Flow Integrity (CFI) policy that prevents attacks in the return-oriented programming style by restricting indirect control transfers to only allowed edges in the program's control flow graph (enforcing fine-grained CFI; except those approximated to potentially vulnerable to attack); (4) can be measured using a complex fine-grained taint tracking policy (generalization) where each word can potentially be polluted by multiple sources (libraries and 10 streams) at the same time (see Table 1 in Fig. 14) . As noted elsewhere in this application, these are known policies whose protective capabilities have been established in the literature of this application, and the description herein focuses on measuring and reducing the performance impact of enforcing them using PUMP. put With the exception of NXD+NWC, each of these policies distinguishes essentially an unlimited number of unique items; In contrast, solutions with a limited number of metadata bits can only support extremely simplistic approximations at best. As also mentioned above, a simple and straightforward implementation of PUMP can be costly. For example, adding a pointer-sized 64b tag to a 64b word at least doubles the system's total memory size and energy usage; In addition to this, area and energy are added to the rule cache. For this simple implementation, the measured area overhead is about 190% and the geometrical energy overhead is about 220%; Moreover, the runtime overhead in some applications is disappointing (over 300%). If this high overhead is the best it can do, it will discourage adoption.

Micro-architectural optimizations such as those described herein can be included in an embodiment according to the techniques herein to reduce the power limit by 10% (see FIG. 10C ), such that the optimized PUMP has little impact on the operating envelope of the platform. imply that it does not DRAM compression reduces energy overhead by 20% for lbm; This also slows it down by 9%, so the power requirement only increases by 10%.

The area overhead of the optimized design is about 110% (eg, see Table 5 in FIG. 18 ) compared to 190% for the simple design (eg, see Table 3 in FIG. 16 ). Short tags significantly reduce the area of the L1 and L2 caches (now only 5% more than baseline) and the area of the rules cache (only 26% more). Conversely, an optimized design spends little area reducing runtime and energy overhead. UCP and CTAG caches add 33% region overhead, while translation memory for short tags (both L1 and L2) adds another 46%. These additional hardware structures add area, but provide net energy reduction, as they are infrequently accessed and miss handler cycles are significantly reduced due to the UCP and CTAG caches.

One goal of the models and optimizations described herein is to make the implementation of adding additional policies concurrently enforced relatively simple. The compound policy of the simple PUMP design resulted in a significant increase in miss handler runtime, costing more than incremental cost for several benchmarks, but these are reduced due to miss handler optimization.

Figures 13a (CPI Overhead) and 13b (EPI Overhead) show the overhead of each single policy first, then the composite of adding the policy to the most complex single policy, Memory Safety, allowing incremental addition of policies. Shows how it affects runtime overhead. This progression makes it clear what overhead is introduced by the simple addition of an arbitrary policy as opposed to adding a higher overhead policy. To achieve scalability beyond the four policies here, the CFI policies (return and computed-jump/call) and taint tracking policies (code tainting and I/O Each of the tainting (I/O tainting) is divided into two parts: it is shown tracking that the run-time overhead of the additional policy gradually increases over the first complex policy (memory safety), which is non-outlier ), there is no notable runtime impact on the worst non-outliers (it rises from 9% to 10% overhead), mainly because each new kind of policy is added due to increased miss handler resolution complexity. Larger increases (20 to 40%) Energy follows a similar trend (geomean increases from 60% to 70%) with moderate impact on non-outlier policies accounting for everything except GemsFDTD.

A brief summary of the relevant operations is found in Table 2 reproduced in FIG. 15 .

According to the policy programming model according to the description herein, a PUMP policy includes a set of tag values and a collection of rules that manipulate those tags to implement the desired tag propagation and enforcement mechanism. Rules come in two forms: the software layer of the system (symbolic rules) or the hardware layer (concrete rules).

For example, to illustrate the operation of PUMP, consider a simple example policy that limits return points during program execution. The motivation for this policy comes from a class of attack known as return-oriented programming (ROP), in which an attacker identifies a set of "gadgets" in the binary executable of an to assemble complex malicious behavior by constructing a sequence of appropriate stack frames, each stack frame containing a return address pointing to some gadget; A buffer overflow or other vulnerability can then be exploited to overwrite the top of the stack with the desired sequence, causing snippets to be executed in sequence. One simple way to limit ROP attacks is to limit the targets of return instructions to well-defined return points. This is done by using PUMP to tag instructions that are valid return points with metadata tag targets. Whenever a return instruction is executed, a metadata tag on the PC is set to check to indicate that a return has just occurred. In the next instruction, the PC tag is checked and verifies that the tag on the current instruction is the target, otherwise signals a security violation. By making the metadata richer, it is possible to control precisely which return commands can return to which return points. By making the metadata richer, checking the entire CFI can be implemented.

From the perspective of the policy designer and software portion of PUMP 10, policies can be concisely described using symbolic rules written in a small domain-specific language. Exemplary symbolic rules and their programming language are described, for example, in the section entitled “Programming the PUMP, Hardware-Assisted Micro-Policies for Security”.

Symbolic rules can succinctly encode various metadata tracking mechanisms. However, at the hardware level, rules for the coordinated representation are needed for efficient interpretation to avoid slowing down the underlying calculations. To this end, a lower level rule form called a concrete rule can be introduced. Intuitively, each symbolic rule for a given policy can be extended to an equivalent set of concrete rules. However, since a single symbolic rule can generally generate an infinite number of specific rules, this completion is slow, generating specific rules as needed while the system is running.

For policies with metadata tags (e.g. richer than ROPs), the conversion from symbolic rules to concrete rules follows the same general lines, but the details get a bit more complicated. For example, a taint-tracking policy allows tags to be pointers to memory data structures, each of which contains a set of taints (representing a data source or system component from which a given fragment's data may originate). Describes a set of arbitrary size. The symbolic rule for load opgroups says that the taints on the values loaded must be the union of the taints on the instruction itself, the target address for the load, and the memory at that address. The Symbolic Rules and its programming language are included by reference from a paper titled "Programming PUMPs, Hardware-Assisted Micro-Policies for Security," previously identified and publicly available.

To reduce the number of distinct tags (and thereby reduce the pressure on the rules cache), metadata structures can be stored internally in canonical form, and since tags are immutable, they are outright exploitable when shared (e.g. For example, since set elements are given a standard order, sets can be concisely expressed by sharing a common prefix subset). When no longer needed, these structures can be returned (eg by garbage collection).

Embodiments may use composite policies. Multiple orthogonal policies can be enforced concurrently by having the tags be pointers to tag tuples of multiple component policies. (In general, multiple policies may not be orthogonal.) For example, to create a first-return opgroup (ROP) policy using a taint-tracking policy, each tag is a representation of a tuple (r; t) Let it be a pointer to , where r is a ROP tag (code location identifier) and t is a taint tag (pointer to a set of taints). The cache lookup process is exactly the same, but when a miss occurs it extracts the components of the tuple and dispatches a set of symbolic rules to a routine that evaluates both. Actions are allowed only if both policies have rules that apply; In this case, the result tag is a pointer to a pair containing the result of the two subpolicies.

In the connection policy system and protection, the policy system exists as a separate memory area within each user process. A policy system may include, for example, code for miss handlers, policy rules, and data structures representing the policy's metadata tags. Placing the policy system in the process minimizes intrusion in the traditional Unix process model and facilitates lightweight transitions between the policy system and user code. The policy system is separated from user code using the mechanisms described below.

Obviously, the protection provided by PUMP is useless if an attacker can rewrite the metadata tag or change its interpretation. The techniques described herein are designed to prevent such attacks. The kernel, loader and (for some policies) compiler are reliable. In particular, the compiler needs to assign initial tags to words and, if necessary, pass rules to the policy system. The loader will preserve the tags provided by the compiler, and the path from the compiler to the loader is protected from tampering using, for example, cryptographic signatures.

Embodiments according to the techniques herein may use a standard Unix-style kernel that sets up an initial memory image for each process. (It may be possible to further reduce the size of the TCB using micro-policies to eliminate some of these assumptions). In this embodiment, it is further assumed that the rule-cache-miss-handling software is correctly implemented. It is small and, as such, a good target for formal verification. One concern is to prevent user code running in a process from weakening the protection provided by the process' policy. User code must (i) not be able to directly manipulate tags - all tag changes must be performed in accordance with currently enforced policies/policy rules; (ii) cannot manipulate data structures and code used by the miss handler; (iii) It must not be possible to insert rules directly into the hardware rule cache.

Regarding addressing, to prevent direct manipulation of tags by user code, tags attached to every 64b word cannot itself be separately addressed. In particular, it is not possible to specify an address corresponding to only a tag or a part of a tag in order to read or write a tag. All user accessible instructions operate on (data, tag) pairs as atomic units - the standard ALU operates on the value part and the PUMP operates on the tag part.

With respect to the miss handler architecture of embodiments according to the techniques herein, the policy system may only act on misses to the PUMP cache. To provide separation between the policy system and user code, a miss handler mode of operation is added to the processor. The integer register file is extended with 16 additional registers available only to the miss handler to prevent saving and restoring of registers. It should be noted that the use of 16 additional registers is exemplary and in practice the integer register file may need to be extended with fewer/more registers. PCs of fault-inducing instructions, rule inputs (opgroups and tags), and rule outputs appear as registers while in miss handler mode. A miss-handler-return directive is added to finish installing the specific rule into the cache and return to the user code.

In an embodiment consistent with the techniques herein, the normal behavior of PUMP 10 is disengaged while processor 12 is in miss handler mode. Instead, a single hardwired rule applies; All commands and data touched by the miss handler must be tagged with a predefined miss handler tag that is completely different from the tag used by any policy. This ensures separation between miss handler code and data and user code in the same address space. User code cannot tamper with or execute policy system data or code, and miss handlers cannot inadvertently tamper with user data and code. Because the miss-handler-return command can only be issued in miss-handler mode, user code is prevented from inserting arbitrary rules into the PUMP.

Previous operations have used sophisticated methods to concisely express or approximate safety and security policies, but this is often a compromise to the intended policy, which trades complexity for brevity. As described herein, it is possible to include rich metadata that captures the needs of a security policy more completely and more naturally, with little or no additional runtime overhead. Instead of imposing fixed boundaries on metadata representation and policy complexity, PUMP 10 provides a reasonable degradation in performance. This allows policies to use more data where needed without affecting size and performance in the general case. Since even complex policies can be easily expressed and enforced, it also enables incremental granularity and performance tuning of policies.

Growing evidence for the value of metadata-based policy enforcement, this disclosure defines an architecture for software-defined metadata processing and identifies accelerators that eliminate most of the runtime overhead. An unlimited number of metadata bits or policies supported simultaneously (i.e. , without any boundaries) architectures are introduced and described herein. The software-defined metadata policy model and its acceleration include sound information flow control, fine-grained access control, integrity, synchronization, race detection, debugging, application-specific policies, and controlled generation and execution of dynamic code. It may be applicable to a wide range of policies other than those described herein.

Some non-limiting advantages of the various aspects and embodiments described herein include (i) a programming model and supporting interface model for concisely and accurately describing the policies supported by this architecture; (ii) detailed examples of policy encoding and construction using four different classes of well-studied policies; (iii) provide quantification of the requirements, complexity and performance of these policies;

The programming model of the embodiments described herein may encode a number of different policies. Information-flow control here is richer than the simple taint tracking model, but implicit flow tracking can be supported using RIFLE-style binary translations or using PC tags with some support from the compiler. Micro-policies can support lightweight access control and compartmentalization. Tags can be used to distinguish unforgeable resources. A unique generated token can act as a key for sealing and guaranteeing data, which in turn can be used for powerful abstractions, thus ensuring that data is created and destroyed only by authorized code components. Micro-policy rules can enforce data immutability such as immutability and linearity. A micro-policy can support parallel processing as out-of-band metadata for synchronization primitives, such as filled/empty bits for data or presents, or as a condition to detect race conditions on locks. System designers can apply specific micro-policies to existing code without having to audit or rewrite every line.

The PUMP 10 design described in this application provides an attractive combination of flexibility and performance, supporting a diverse collection of low-level, fine-grained security policies with a single policy performance comparable to dedicated mechanisms in most cases, while maintaining rule complexity. As it increases, it supports richer and more complex policies, most of which have moderately degraded performance. Also, mechanisms provided by PUMP can be used to protect its own software structures. Embodiments according to the techniques herein can replace special miss handler operation modes by using PUMP 10 to implement a "compartmentalization" micro-policy and use it to protect miss handler code. Finally, as described herein, an orthogonal set of policies may be combined if the protection provided by each policy is completely independent of the other policies. However, policies often interact: for example, an information-flow policy may require placing a tag in a new area allocated by a memory safety policy. Policy construction requires analysis in terms of both representation and efficient hardware support.

이 사용할 수 있다. 따라서, 일반적으로, 실시예는 메모리 위치에 대해 컬러 c 또는

중 어느 하나인 태그 t를 기입할 수 있다. Another example will now be described showing the implementation of a memory safety policy in an embodiment according to the techniques herein to identify all temporal and spatial violations in heap allocated memory. In at least one embodiment, for each new allocation, the process of constructing a new color id, c, and writing c as a tag on each memory location within the newly created memory block (e.g., via memset, for example). can be performed. A pointer to the new block is also tagged with c. Later, when a process of dereferencing the pointer is performed, that process may include checking that the pointer's tag is the same as the tag on the memory cell to which the pointer refers or points. When a block is freed, the tags on every cell in the block can be modified with a constant F representing empty memory. A heap may initially be tagged with an F. If it is not a pointer, the special tag

this can be used Thus, in general, embodiments may use color c or

Any one of the tag t can be written.

Because memory cells can contain pointers, each word in memory can typically be associated with two tags. In this embodiment, the tag on each memory cell is a pointer to the pair (c, t), where c is the id of the memory block to which this cell was allocated and t is the tag of the word stored in the cell. Embodiments may use a domain specific language based on the rule functionality described elsewhere herein to specify policies in terms of symbolic rules. Note that the rules for loads and stores, along with packing and unpacking these pairs, check that each memory access is valid (i.e., that the cell accessed is within the block pointed to by this pointer):

The performance of the check in the aforementioned rules and other rules appears as a condition under which the symbolic rule is valid (eg, c ₂ =c ₃ above in the store rules). A "-" sign indicates a money-care field in a rule.

Address arithmetic operations preserve pointer tags:

로 설정한다.In order to maintain the immutability that tags on pointers only arise from assignments, operations that create data from scratch (e.g., loading of constants) have their tags.

set to

In embodiments implementing a memory safety policy, operations such as malloc and free may be tagged with memory regions using, for example, tagged instructions and transient rules (eg, that may be deleted from the cache once used). can be modified to In terms of malloc, the process can generate a new tag where the pointer points to a new area via the temporal convention. For example, a rule for a move could be a temporary rule such as:

)는 일시적 규칙을 나타낼 수 있다. 그런 다음 태깅된 포인터를 리턴하기에 앞서, 새로 태깅된 포인터는 특수 스토어 규칙을 사용하여 할당된 영역의 모든 동작에 0을 기입하는데 사용될 수 있다:An arrow with a superscript of 1 (e.g.

) may represent a temporary rule. Then, prior to returning the tagged pointer, the newly tagged pointer can be used to write zeros to all operations in the allocated area using special store rules:

At a later point, before returning the region to the free list, free can use the modified store command to re-tag the region as unallocated:

In this embodiment using a memory safety policy, an opgroup can be used to describe a set of rules as follows:

을 0으로 인코딩하고 돈-케어 필드를 0으로 표시한다고 가정하면, 위의 상징적 규칙(3)에 대해 구체적 규칙은 다음과 같다:The symbolic rules used above for policy specifications can be written using variables, allowing a small number of symbolic rules to describe a policy through an infinite world of distinct values. However, specific rules stored in the rule cache refer to specific specific tag values. For example, if 23 and 24 are valid memory block colors, an embodiment may use concrete rules with concrete instances of symbolic rule (3) above in the PUMP rule cache for c = 23 and c = 24. for example,

Assuming that we encode as 0 and denote the money-care field as 0, the concrete rule for symbolic rule (3) above is:

Consistent with discussion elsewhere herein, in at least one embodiment, a miss handler obtains concrete input tags and executes code compiled from symbolic rules to insert rules into the PUMP rule cache, resulting in associated concrete output tags. can create When a symbolic rule identifies a violation, control passes to the error handler and no new concrete rule is inserted into the PUMP rule cache.

Now, to the description herein based on the RISC-V architecture being further extended with metadata tags and PUMP to support software defined metadata processing (SDMP) consistent with the discussion herein. A following embodiment will be described. RISC-V can be characterized as an open source implementation of the reduced instruction set computing (RISC) instruction set architecture (ISA). In this embodiment, metadata tags are placed in both the instructions and data for each word. In the RISC-V architecture, words are 64 bits. The RISC-V architecture offers different word size variants - RV64 is a 64 bit word size and RV32 is a 32 bit word size. The width or size of the register and user address space may vary depending on the word size. The tag size or width may be independent of the word size or width, but in one embodiment may be more typically equal. As is known in the art, the RISC-V architecture has 32-bit instructions, so embodiments that support and operate using a 64-bit word size can store 2 instructions in a single tagged word. The foregoing and other aspects of the RISC-V architecture are discussed elsewhere herein with respect to the use of different technologies and features related to extending the RISC-V architecture for use with the metadata tags PUMP and SDMP. .

The RISC-V architecture is described in, for example, ["The RISC-V Instruction Set Manual Vol. I, User-Level ISA, Version 2.0", May 6, 2014, Waterman, Andrew, et. al., ("also referred to as the "RISC-V user level ISA")], which is incorporated herein by reference, and for example on the RISCV.ORG web Site and is available to the public as Technical Report UCB/EECS-2014-54 through the University of California, Berkeley The RISC-V architecture is also described in ["The RISC-V Instruction Set Manual Volume II: Privileged Architecture, Version 1.7", May 9, 2015, also referred to as the "RISC-V privileged ISA")], privileged commands necessary to run the operating system, attached external devices, etc., and Incorporates a privileged architecture that includes additional functionality, which document is incorporated herein by reference, eg, Technical Report UCB/EECS-2015-49 via the RISCV.ORG website and the University of California, Berkeley. as available to the public.

An embodiment of the RISC-V architecture has four RISC-V permission levels: Level 0 for user/application (U) permission level, level 1 for supervisor (S) permission level, and hypervisor (H) permission level. level for level and level 3RISC-V permission level for machine (M) permission level. In the foregoing, RISC-V privilege levels can be ranked from 0 to 3, from highest to lowest, with level 0 representing the highest or greatest privilege level and level 3 representing the lowest or least privilege level. These privilege levels can be used to provide protection between different components, and cause an exception such as a trap to be directed to the default execution environment if an attempt is made to execute code that performs an operation that is not permitted by the current privilege level or mode. The machine level has the highest privilege and is the only mandatory privilege level on RISC-V hardware platforms. Code running in machine mode (M-mode) is inherently trusted because of its low level of access to the machine implementation. User mode (U-mode) and supervisor mode (S-mode) are intended for normal applications and operating systems, respectively, while hypervisor mode (H-mode) is intended to support virtual machine monitors. Each privilege level has a set of core privilege ISA extensions with arbitrary extensions and variations. It should be noted that implementations of the RISC-V architecture must support at least M-mode and most implementations support at least U-mode and M-mode. S-mode can be added to provide further separation between code in the supervisor-level operating system and other more privileged code running in M-mode. User or application code typically triggers a trap (e.g. supervisor call, page fault) or interrupt to generate one of the higher privilege modes or levels supported (e.g. H, S or M modes). It can run in U-mode until it forcibly transfers control to a trap handler running on The code in the trap handler can then be executed and control returned to the original user code or application that caused the trap. Execution of this user code or application can resume at or after the original trapped instruction in U-mode that triggered the trap handler call. The various combinations of modes supported in a RISC-V implementation may include: a single M mode, two modes - M and U, three modes - M, S and U, or only four modes M, H, S, U. there is. In at least one embodiment described herein, all four of the aforementioned privilege levels may be supported. At least an embodiment according to the technology herein may support the M AND U mode.

The RISC-V architecture has a Control Status Register (CSR) that can be read and modified atomically by one or more associated privilege levels. In general, a CSR can be accessed at the first of the four permission levels and at any other permission level of the four higher permission levels. For example, assuming a program is running in U-mode (level 3) and a trap such as a rules cache miss occurs, control is passed to a higher privilege or mode (e.g., levels 0 to 2), such as the rules cache miss handler code. at any level of ) to the running trap handler. When a trap occurs, the information runs at a lower privilege level that would otherwise be accessible to the trap handler running in M-mode (e.g. not accessible to code in H, S or U modes). can be placed in the CSR, which is not accessible to any other code that is In at least one embodiment, the rule cache miss handler may run at a privilege level above the PUMP protection level (eg, in H-mode, S-mode or M-mode). In such an embodiment, as described elsewhere herein, tag definitions and policies at the rule cache miss handler level may be operating system wide (eg, per virtual machine), thus allowing the same tag definition. and policies can be applied across all executable code. In at least one embodiment, per-application or per-process policies may be supported where such policies are installed globally, and the PC (program counter that identifies the current instruction) and/or code may set process or application-specific rules. They can be tagged to distinguish them. In embodiments where virtual machines (VMs) do not share memory, policies may be defined on a per-VM basis.

Consistent with discussion elsewhere herein, PUMP can be characterized as a rule cache for SDMP. There may be a mapping between a set of tags on a command and a command input for an operation result and a tag. Tag processing is independent of and parallel to the normal operation of the instruction. In at least one embodiment, PUMP runs in parallel with normal RISC-V operation, supplying tags for the result of the operation. Because PUMP is a cache, a rule cache miss occurs when PUMP first receives a specific matching set of specific instructions and thus PUMP inputs (eg, forcing), or when PUMP cannot hold a rule in cache (eg, forcing). , when the capacity of the cache is exceeded and so a rule is evicted from the rule cache or possibly conflicts). A rules cache miss causes a miss trap that is handled by code in the miss trap system (e.g., a rules cache miss handler). Input can be passed to the miss handler via the PUMP CSR, and rule insertion can be provided via the CSR also back to the PUMP. This is discussed in more detail below. A first embodiment is discussed elsewhere in this specification where there is a 5 PUMP input tag. As a variation, an embodiment may include a different number of tags and other PUMP inputs. The specific number of PUMP tag inputs may vary depending on the instruction set and operands. For example, the following may be included as PUMP inputs in one embodiment based on the RISC-V architecture:

1. Opgrp - Indicates that a specific opgroup contains the current instruction. In general, an opgroup is an abstraction of a group of instructions and is discussed elsewhere in this specification.

2. PCtag - Tag on PC

3. CItag - tag on command

4. OP1tag - tag on RS1 input to command

5. OP2tag - tag on RS2 input to command (or tag on CSR when CSR command)

6. OP3tag - tag on RS3 input for command

7. Mtag - Tag on memory input to instruction or memory target of instruction

8. funct12 (funct7) - Extended opcode bits that occur in some instructions as described elsewhere in this specification.

9. subinstr - When a word is filled with multiple instructions, this input identifies which instruction in the word is the current instruction being operated on by PUMP.

The following may be included as pump outputs in one embodiment based on the RISC-V architecture:

1. Rtag - result: tag on destination register, memory or CSR

2. newPCtag - The tag on the PC after this operation (eg, sometimes referred to as the PCnew tag).

Information can be passed via a CSR, for example, from user code running in U-mode when a trap occurs to a trap handler, such as a rules cache miss handler running in M-mode. In a similar manner, information may be passed through the CSR between trap handlers in M-mode when resuming program execution in U-mode if the information in the CSR can be placed in a corresponding register accessible in U-mode. . In this way, there may be a mapping between a CSR at one privilege level and a register at another privilege level. For example, in an embodiment consistent with the techniques herein, an M-mode handler and PUMP are accessible if a specific instruction operand tag is written to the CSR on occurrence of a trap to pass the tag as input to the PUMP and rules cache miss handler. A CSR can be defined. In a similar fashion, the CSR traps information when resuming program execution, e.g., after a rule cache miss (e.g., if a rule cache miss occurs when a matching rule is not found in the PUMP rule cache for the current instruction). It can be used to pass from a handler and/or PUMP (operating at a higher privilege level than U-mode) to other code running in U-mode. For example, CSR can be used to output or propagate PUMP output tags for PCnew and RD. In addition, CSRs can be defined where different actions can occur in response to writing a specific CSR. For example, the rule cache miss handler code can write/insert a new rule into the PUMP's rule cache by writing to a specific CSR. The specific CSR defined may vary depending on the embodiment.

Referring to FIG. 25 , an example of a CSR that may be defined and used in an embodiment according to the techniques herein is illustrated. The table 900 has a first column 902 of the CSR address in hexadecimal, a second column of authority 904, a third column 906 indicating the CSR name, and a fourth column 908 containing the description of the CSR. include Each line of table 900 may identify information about a different defined CSR. The different CSRs in table 900 are described in more detail elsewhere herein with respect to additional features that may also be included in embodiments.

Rows 901a through 901c identify CSRs with special tag values used to tag code and/or instructions by PUMP. In at least one embodiment, the sboottag CSR defined by entry 901a may include a first initial or starting tag value used in the system. The aforementioned start tag value may be referred to as a bootstrap tag value. In one aspect, a bootstrap tag value can be characterized as a “seed” from which all other tags can be derived or based. Thus, the bootstrap tag can be used as a starting point for creating all other tags in one embodiment. In a manner similar to the initial loading of the starting location of bootstrap code in an operating system, hardware may be used to initialize CSR 901a with a specific predefined tag value used as a bootstrap tag. If the bootstrap tag is read as part of booting the system according to the techniques herein, the sboottag CSR may be cleared. For example, a privileged portion of the operating system code may include instructions that invoke a rule that performs initial tag propagation using the bootstrap tag value. The use of bootstrap tags and tag generation and propagation are further described elsewhere in this specification. Row 901b identifies a CSR containing a tag value used to tag data from a public untrusted source as described elsewhere herein. For row 901c, identifies a CSR that contains a default tag value that can be used as the default tag value when tagging data and/or instructions.

Rows 901d and 901e respectively represent addresses and data to write to the opgroup/don't care table (e.g., elsewhere herein including the opgroup and care/don't care bits for the opcode). Also referred to as a mapping or translation table). A write to the CSR indicated by row 901e triggers a write to the opgroup/care table. Row 901f identifies a CSR that can be written to flush the PUMP rules cache. Rows 901g through 901m identify CSRs that provide tag input for the current instruction to the PUMP and rules cache miss handlers. Rows 901j through 901m each represent a different operand tag for the operand of the current instruction being processed, and by causing a rule cache miss, an instruction can have up to four such operands (three of the four operands are registers (CSRs 901j through 901l)). and the 4th operand is a memory location with the tag stored in the CSR indicated by row 901m. Row 901n is the extended opcode of the current instruction as described elsewhere herein. When using the func12 field, identifies the CSR that holds the extended opcode bit. Row 901o represents the CSR indicating which sub-instruction of the word is the currently referenced instruction. As discussed elsewhere in this specification, A single tagged word may be 64 bits and each instruction may be 32 bits, so that two instructions may be included in a single tagged word CSR indicated by row 901o indicates which of the two instructions is a PUMP Rows 901p-901q contain the new PC's PUMP output tag (e.g., the new PC tag for the next instruction) and RD (destination register, address for the result of the current instruction), respectively. A write to the CSR indicated by row 901q causes a rule to be written to the PUMP rules cache (e.g., matching the current instruction that triggered the PUMP rule cache miss). Identifies the tagmod for the PUMP operation, which is described in more detail elsewhere in this specification.

In at least one embodiment, one or more tables (eg, an opgroup/care table) used to store opgroup and care/don't care bits may be populated by writing to the CSR sopgrpvalue denoted 901e, where In , the contents of the aforementioned CSR 901e are written to the address stored in the sopgrpaddr CSR indicated by 901d. Rules may be written to or installed in the PUMP rule cache in response to writing to the srtag CSR definition defined by entry 901q. The written rule specifies the opcode (or more specifically the opgroup for the opcode) and the tag value for the current instruction as input to PUMP via the PUMP CSR (e.g., based on PUMP CSR inputs 901g through 901o). It is a rule to

To allow tagging and tag protection for CSR operations, a dataflow allows CSR tags to be input to and output from the PUMP. According to the RISC-V architecture, there are read and write instructions that read from and write to the CSR, respectively. For a CSR instruction with a PUMP, the R2tag input to the PUMP is the current CSR tag. A CSR read/write instruction (eg csrrc, csrrci, csrrs, csrrsi, csrrw, csrrwi) writes two inputs: (1) RD and (2) the CSR referenced by the instruction. In this case, the PUMP output R tag (or destination's RD tag) specifies the CSR tag output by PUMP and copies the CSRtag directly to the register destination tag:

With respect to the permissions indicated by column 904, the CSR mtagmode defined by row 901r is accessible for read/write by code running at the machine or M-mode level. The remaining CSRs defined by rows 901a through 901q are accessible for read/write by code executing at least at the supervisor or S-mode level. Accordingly, the permissions indicated in column 904 for the various CSRs indicate the minimum RISC-V permission level of executable code for the code to access a particular CSR. Embodiments may assign different RISC-V privilege levels with the CSRs used in the embodiments, as shown in example 900 .

Embodiments according to the techniques herein may define multiple tag modes that affect tag propagation performed by PUMP. The current tag mode is identified by the current point in time value stored in CSR mtagmode as defined by row 901r. In at least one embodiment, tag mode may be used in combination with RISC-V defined permissions (e.g., M, H, S, and U modes above) to define the CSR protection model used in connection with PUMP. .

To allow for configurable placement of rule cache miss handlers, a protection model that further extends RISC-V rights can be used. Instead of defining the PUMP CSR access entirely according to the privilege level, the CSR access can be further defined for the current tag mode in combination with the RISC-V privilege level. Thus, in at least one embodiment consistent with the techniques herein, whether executable code is allowed to access a CSR depends on the CSR's minimum RISC-V privilege level, the current tag mode, and the executable code's current RISC-V privilege level. can be dependent Tag mode is discussed in more detail below.

Referring to FIG. 26 , an example of a tag mode that may be used in an embodiment according to the technology herein is illustrated. Table 910 includes the following columns—mtagmode bit encoding 912, operation 914, and tag result 916. Each row of table 910 represents information about different possible tag modes. When the tag mode is 000, indicated by 911a, the PUMP is off and not in use and does not generate any tag results. When the tag mode is 010, PUMP writes a default tag (eg Rtag to destination or result register or memory location) to all results.

With respect to lines 911c through 911f, the different tag modes that can be specified for engaging or disengaging PUMP when the code is running at different RISC-V privilege levels are indicated. When a PUMP is associated, a PUMP can be characterized as being active, operable, and providing protection when code is executed so that the rules of its policy are enforced during code execution. In contrast, when a PUMP is disassociated, it may be characterized as inactive, inoperable, and providing no protection when code is executed and the rules of its policy are not enforced during code execution. When a PUMP is disassociated, the tag is instead of having the tag propagated based on evaluation of a rule with a tag value that matches the tag value of the current instruction. Can be propagated using one or more default tag propagation rules. Whether a PUMP is associated or unassociated may depend on the particular assumed level of trust due to code running at different RISC-V privilege levels and the level of protection desired.

Regarding tag modes 911c to 911f, except for the mtagmode CSR indicated by 901r, all PUMP CSRs in example 900 may only be accessible when the PUMP is disassociated. That is, the PUMP CSR of example 900, except for the mtagmode CSR indicated by 901r, can only access code executable in the current RISC-V's operational rights or modes that are more privileged than the highest PUMP rights indicated by tag mode. However (e.g., the highest priority authority indicated by 911c is U mode, the highest priority authority indicated by 911d is S mode, and the highest priority authority indicated by 911e is is H mode, and the highest priority authority indicated by 911f is M mode).

When the tag mode is 100 as indicated by 911c, the PUMP is unassociated and does not operate when the RISC-V privilege level is higher than U-mode or indicates a more elevated privilege level. Thus, tag mode 911c is enforced only in conjunction with PUMP and its rules providing protection when the code is running in U-mode, and thereby at a higher privilege level than U-mode (e.g., S, M or H mode) indicates that the code running is reliable. As indicated by 911c, when the tag mode is 100 and the RISC-V protection level of the executable code is S, M, or H mode, the PUMP is not associated and its CSR is for code that runs only in S, M, or H mode. can access (eg CSR cannot access code running in U-mode).

When the tag mode is 101 as indicated by 911d, the PUMP is disassociated and does not operate when the RISC-V permission level indicates a permission level higher than or elevated above the S-mode. Thus, tag mode 911d enforces PUMP and its rules providing protection only when the code is running in S-mode and U-mode, and thereby at a higher privilege level than S-mode (e.g., Indicates that code running in M or H mode) is reliable. As indicated by 911d, when the tag mode is 101 and the RISC-V protection level of the executable code is M or H mode, the PUMP is disassociated and its CSR can access code that runs only in M or H mode (For example, the CSR has no access to code running in S or U mode).

When the tag mode is 110 as indicated by 911e, the PUMP is disassociated and does not operate when the RISC-V permission level indicates a higher or more elevated permission level than the H-mode. Thus, tag mode 911e is only associated and enforced when code is executed in H-mode, S-mode, and U-mode, and thereby at a higher privilege level than H-mode (e.g., in M-mode). Indicates that the code running on is trustworthy. As indicated by 911e, when the tag mode is 110 and the RISC-V protection level executing code is M mode, the PUMP is disconnected and its CSR can access code running only in M mode (e.g. For example, a CSR cannot access code running in U, H or S mode).

When the tag mode is 111 as indicated by 911f, PUMP is always associated and operates for all RISC-V privilege levels of M, H, S and U. Thus, tag mode 911f indicates that PUMP and its rules providing protection are enforced in conjunction when the code is executed in any of M-mode, H-mode, S-mode and U-mode, whereby the code indicates inherently unreliable. For tag mode = 111 as indicated by 911f, the PUMP is never disassociated and its CSR cannot access any executable code.

With respect to the tag mode indicated by rows 911c through 911f, when the current RISC-V privilege level executing the code is higher than the highest associated PUMP level indicated by the tag mode, the PUMP may be disassociated and the tag Can be propagated using one or more default tag propagation rules.

When the tag mode has an encoding of 000, as indicated by row 911a (indicating that PUMP is off), or when the tag mode is of 010, as indicated by row 911b (indicating write default mode) With encoding, all CSRs in table 900 are accessible only by code running in M mode.

Thus, in at least one embodiment consistent with the techniques herein, whether executable code is to be able to access a CSR is subject to the CSR's minimum RISC-V privileges (as specified in column 904 of table 900). level, the current tag mode, and the current RISC-V privilege level of the executable code. For example, in a RISC-V architecture that does not take tag mode into account, code running in U mode can use any CSR defined at (900) due to the minimum privilege level indicated by (904) for all such CSRs. can't access However, regardless of tag mode, at least code running with privileges in H-mode can access all CSRs in (900) except for (901r) and code running in M mode has access to all CSRs in (900). can access Now consider determining the CSR access to the CSR of 900 according to the minimum RISC-V permission and tag mode of 904 . For example, consider code section A that runs at H-level. Code portion A can access CSRs 901a through 901q (of table 900) when the tag mode is 100, as indicated by 911c, or when the tag mode is 101, as indicated by 911d. there is. However, code portion B running in S mode may not be able to access CSRs 901a through 901q because it does not have the minimum privilege level specified by the CSR privilege level defined for that CSR. Thus, for example, code portion A may be a cache miss handler in one embodiment running at the H-level using the CSR defined in table 900. As a second example, assume that the minimum RISC-V authority defined for CSRs 901a to 901q is SRW (indicating S mode as the minimum authority level to access these CSRs). Code portion A executing in H mode can access CSRs 901a through 901q when the tag mode is 100 as in 911c and when the tag mode is 101 as in 911d, and in S mode Code portion B that is executed can access CSRs 901a through 901q when the tag mode is 100 as in 911c. Thus, code part A or B may be the code of the cache miss handler.

In at least one embodiment, the off tag mode of 911a may be the current tag mode when the PUMP is off, for example during an appropriate portion of the boot up process. When initializing a memory location to have the same default tag (e.g., indicated by CSR 901c), the default tag mode of 911b may be the current tag mode. In general, 4 privileged modes have been specified in the RISC-V architecture, but embodiments have a first privileged level representing the user mode or unprivileged mode and a second privileged level (e.g., similar to the kernel mode of a UNIX-based operating system). ) may alternatively use a different number of privileged modes representing elevated or privileged execution modes. In such an embodiment, PUMP can be associated to execute policies when executing code in a user or unprivileged mode, and PUMP can unassociate when executing code in a second elevated privileged mode (e.g., PUMP protection off or rule not enforced). In this way, embodiments may disassociate PUMP when executing trusted or elevated rights code such as a miss handler to store new rules in the PUMP rule cache.

As mentioned above, embodiments may use default propagation rules, e.g., when a PUMP is disassociated and/or when a rule specifies don't care for PUMP outputs newPCtag and Rtag (e.g. For example, such a don't care value can be indicated by the care vector for a particular opcode of the current instruction), and can decide to output the PUMP outputs newPCtag and Rtag. In one embodiment, the following may indicate the logic implemented in the default propagation rules used.

* newPCtag is the PCtag for default propagation.

* Rtag is RS1tag for CSR read and write operations; RS2tag (CSRtag) is assigned to RDtag.

- Allows tags to swap along with data values

- RDtag <-- RS2tag <-- Original CSRtag

- CSRtag <-- Rtag <-- original RS1tag

** Rtag is RS2tag (CSRtag) for CSRR?I, CSRRS, and CSRRC.

- CSRtag does not change

- RDtag <-- RS2tag <-- Original CSRtag

- CSRtag <-- Rtag <-- original RS2tag <-- original CSRtag

* Rtag is PCtag for JAL and JALR instructions (this is for return address). Rtag is a PCtag for AUIPC commands. In RISC-V, the add upper immediate to PC (AUIPC) instruction is used to build PC-relative addresses and uses a U-type format. AUIPC forms a 32-bit offset from the 20-bit U-immediate, fills the least significant 12 bits with zeros, adds this offset to PC, then places the result in register rd.

* Rtag is a CItag for LUI commands. In RISC-V, load upper immediate (LUI) instructions are used to construct 32-bit constants and use a U-type format. The LUI places the U-immediate value in the upper 20 bits of the destination register RD and fills the lower 12 bits with zeros.

* Rtag is RS1tag for non-memory, non-CSR, non-JAL(R)/AUIPC/LUI operations.

** Rtag is RS2tag for memory write operations.

* Rtag is Mtag for memory load operation.

In at least one embodiment of the techniques herein based on the RISC-V architecture, a new PUMP miss trap may be defined for rule cache miss occurrences. A PUMP miss trap may have a lower priority than a virtual memory fault or an illegal instruction.

In at least one embodiment according to the techniques herein using a RISC-V architecture, strict separation and isolation between data and metadata is maintained where separation and isolation exists between tag metadata processing and normal instruction processing. It can be. Thus, a separate domain of execution may be maintained between metadata rule processing and normal or typical program instruction execution. Metadata processing performed using PUMP may be performed on tags associated with commands and data executing code. A PUMP rule cache miss triggers a trap that transfers control to a rule cache miss handler that creates or retrieves a rule matching the current instruction and stores the rule in the PUMP rule cache. Information can be passed between the execution domains mentioned above using CSR. When switching from the instruction execution domain of an executing program to the metadata rules processing domain (e.g. when a rules cache miss handler is triggered via a rules cache miss trap), tags and other information related to the instruction (causing the trap) are It is provided as an input to the PUMP and also as an input to the miss handler using the CSR. In a similar fashion, when control transfers from the metadata rule processing domain to the instruction execution domain of the executing program (e.g., when returning from a rules cache miss handler after processing a rules cache miss trap), the PUMP output uses the CSR. and the content of the CSR is then stored in the corresponding mapped register of the instruction execution domain. Consistent with the discussion herein, an instruction that does not map to a rule (e.g., no rule matching the instruction is placed in the cache, and the cache miss handler determines that no such matching rule exists for the current instruction) Indicates that the rule is not allowed to run, and that a trap or other event is triggered accordingly. For example, the processor may suspend execution of current program code.

In this way, there can be strict separation between the aforementioned domains and associated data paths, even though the same RISC-V processor and memory can be used in both domains. Using the techniques herein, any instruction that executes code cannot read or write metadata tags or rules. All metadata conversion, including tagging commands and data, can be performed through PUMP. Similarly, rule insertion into the PUMP cache can only be performed by the metadata subsystem's rules cache miss handler. Regarding the processing performed by the metadata subsystem or processing system, metadata tags of executable code are placed in the PUMP CSR and become "data" inputs by the metadata system and act on them (e.g., pointers are refers to the metadata memory space). The metadata subsystem reads the PUMP input for processing according to the rules through the PUMP input CSR. If the command can proceed through the rule, PUMP writes the tag result (eg for PC new and R tag) to the defined PUMP output CSR. Rule insertion into the rules cache may be triggered in response to writing a specific CSR (eg, the srtag CSR of 901q). In this way, all tag updates are performed via PUMP's rules and controlled by the metadata subsystem. Only the metadata subsystem can insert rules into the PUMP cache via a cache miss handler that is called when a rule cache miss occurs. Additionally, in at least one embodiment described herein that uses a RISC-V architecture, the foregoing separation between metadata processing and normal instruction processing is referred to as a "RISC-V user-level ISA" and a "RISC-V authoritative ISA". It can be maintained without adding any new instructions other than the instructions of Consistent with discussion elsewhere herein, embodiments in accordance with the techniques herein maintain a strict separation and isolation between data and metadata, thereby allowing between tag-based metadata processing and normal instruction processing. A separation of may exist. In at least one embodiment, this separation may be maintained by having a separate physical metadata processing subsystem with a separate processor and separate memory. Thus, the first processor and first memory may be used when processing instructions of an executing program, and the second processor and second memory may be used in conjunction with performing metadata processing, for example when executing code of a rule cache miss handler. It can be included in the metadata processing subsystem.

Referring to FIG. 27 , an example 1000 of components that may be included in an embodiment consistent with the techniques herein is shown. Example 1000 includes a first subsystem or processor 1002 used in connection with normal processing for an executable program and metadata processing subsystem or processor 1004 . The first subsystem 1002 may be characterized as a program execution subsystem used in connection with normal program execution. Subsystem 1002 is a processor that includes components used in connection with executing program code and using data, such code and data described herein for use with metadata processing subsystem 1004. Include tags as described elsewhere. Subsystem 1002 includes a memory 1008a, an instruction or I-store 1008b, an arithmetic and logic unit (ALU) 1008d and a program counter (PC) 1008e. It should be noted that PUMP 1003 may be used in connection with the execution of code in subsystem 1002 but may be considered part of metadata processing subsystem 1004 . All code and data in subsystem 1002 may be tagged as indicated generally by tag 1002a associated with data 1002b, and 1002a and 1002b may be stored in memory 1008a. . Similarly, element 1001a represents a tag of an instruction in PC 1008e, 1001b represents a tag of instruction 1008b, 1001c represents a tag of memory location 1008a, and 1001d represents a register. Indicates the tag of (1008c).

The metadata processing subsystem 1004 is a processor (also referred to as a metadata processor) that includes components used in connection with metadata rule processing using tags of the current instruction and associated data provided as input to PUMP 1003. PUMP 1003 may be as described elsewhere herein and includes a rules cache. For example, in at least one embodiment, PUMP 1003 may include the components shown in FIG. 22 . More detailed descriptions and examples of the components of PUMP 1003, associated PUMP CSRs used for PUMP inputs and outputs, and associated logic that may be included in at least one embodiment in accordance with the techniques herein are provided below and elsewhere herein. described in more detail elsewhere. Subsystem 1004 is a separate processor used for metadata processing and includes components similar to those of subsystem 1002 . Subsystem 1004 includes memory 1006a, I-store 1006b, register file 1006b and ALU 1006d. Memory 1006a may contain metadata structures used in connection with metadata rule processing. For example, memory 1006a may contain a structure or data pointed to by a tag that is a pointer. Examples of pointer tags and structures/data they point to are described herein, for example, in the context of CFI policies. I-store 1006b and memory 1006a may contain instructions or code such as a miss handler that performs metadata processing. Because the metadata processor 1004 only performs metadata processing (e.g., based on tags and rules), the metadata processor 1004 is used in connection with program execution, such as data memory 1008a ( 1002) do not need access to other components. Subsystem 1004 includes its own components, such as a separate memory 1006a, and does not need to store metadata processing code and data in subsystem 1002. Rather, all information, such as tags of the current instruction that may be used by PUMP 1003, is provided as input to metadata processing subsystem 1004 (eg, PUMP input 1007).

Example 1000 illustrates an alternative embodiment having a separate metadata processing subsystem 1004 rather than performing metadata processing on the same subsystem used for normal program execution as described elsewhere herein. do. For example, instead of having a separate metadata processor or subsystem 1004, an embodiment may include only PUMP 1003 and subsystem 1002. In such an embodiment with a single processor, the CSR may be used to pass information between metadata processing and normal processing modes of running user programs, as described herein, thereby providing isolation and separation. In such an embodiment having a single processor instead of a separate metadata processor, the miss handler's code may be stored in a single memory in such a way that the code is protected. For example, without a separate metadata processor or subsystem, the miss handler's code may be protected using tags as described elsewhere herein to limit access, or may not be addressable by user code. may be mapped to a portion of memory that is not

Further details regarding PUMP I/O (input/output) are now described. The PUMP I/O described below may use a separate processor or subsystem as in 1000 as well as an embodiment of PUMP that may use the same processor or subsystem for normal code execution, for example. It should be noted that this applies to Additionally, the PUMP I/O described below can be used with embodiments based on the RISC-V architecture and can be generalized for use with other processor architectures.

Referring to FIG. 28 , an example 1010 summarizing PUMP I/O in an embodiment according to the techniques herein is shown. As described elsewhere herein, eg with respect to FIGS. 1 and 24 , PUMP operates in stages 5 and 6 . The PUMP input is used to find a matching rule (if any) in the PUMP's rule cache for the current instruction, in conjunction with normal PUMP validation (eg, verifying that the current instruction can use policy rules). Normal PUMP verification can occur for all instructions, such as some in stage 5 as described elsewhere in this specification with a 6 stage pipeline. Additionally, PUMP inputs may be used in connection with controlling rule insertion into the rules cache, which may occur, for example, in stage 6 of a six stage pipeline. The PUMP I/O associated with normal PUMP verification is represented by inputs and outputs in a vertical direction from top (input 1012) to bottom (output 1014). The PUMP I/O associated with controlling the insertion of rules into the PUMP rule cache is represented in example 1010 by horizontal inputs and outputs from left (input 1016) to right (output 1018). Also, as described in more detail elsewhere, element 1012 represents additional inputs that may also be used in conjunction with rule insertion.

First, consider the PUMP I/O associated with normal PUMP verification processing. The PUMP input 1012 is a PC tag, CI tag, instruction operand tag (e.g., OP1 tag, OP2 tag or CSR tag (for CSR-based instructions in RISC-V), OP3 tag, (memory for memory instruction). Mtag for location (note that Mtag can also be referred to herein as MR tag for memory instruction), opcode information (e.g. op group represented by Opgrp input, extended opcodes in RISC-V) for funct12 (funct7) input, a subinstr input that provides an indicator that its instruction is the current instruction in an instruction word containing multiple instructions as in examples 200 and 220) and a care input bit. Opgrp may be the opgroup for the current instruction, and as described elsewhere herein, Opgrp may be the output of a previous stage (e.g., stage 3 or stage 4). Funct 12 (funct 7) The PUMP input may be the extra opcode bits, if any, for those RISC-V opcodes that use the extra bits of the instruction word (e.g., example 400). PUMP output 1014 is Rtag (e.g., the tag to the instruction result register or destination memory location), PC new tag (indicating the propagated tag placed on the PC used for the next instruction), and misses in stage 6. and an indicator 1014a indicating whether there was a PUMP rule cache miss that would result in a trap to the handler.

The care bit 1012a may indicate which PUMP inputs 1012 and which PUMP outputs 1014 are cared for/not cared for (eg, ignored) for a particular instruction. The care bit for PUMP input may include a care bit for funct12 and a second care bit for funct7. As described elsewhere herein, both of the foregoing care bits indicate whether the particular opcode of the current instruction contains any bits for the extended 12 opcode bit portion for RISC-V instructions (e.g., (404a) of Example 400). If both funct12 and funct7 care bits are "don't care", then all 12 bits of the extended 12 opcode bit part are masked-out. If funct7 indicates "care", all lower 5 bits of the extended 12 opcode bit part are masked. If funct12 indicates "care", there is no masking for the extended 12 opcode bit part.

Now consider the PUMP I/O associated with controlling rule insertion into the PUMP rule cache. PUMP input 1016 may be used in combination with input 1012 in connection with PUMP cache rule insertion. PUMP input 1016 includes Op1 data (output from metadata processor or subsystem), instructions (from stage 6), and tag mode (output from metadata processor or subsystem) and permissions (RISC-V permissions). priv) to indicate. The tag mode and priv inputs of 1016 are used by the metadata processor or subsystem so that code, such as a miss handler or other code running on the metadata processor, can be used on various inputs (e.g., input 1012). has sufficient rights to access the CSR described below and elsewhere in this specification, which provides the metadata processor. Rdata 1018 is the input to the metadata processor or subsystem for use in stage 6 (eg, cache miss handler processing input). Op1 data, R data, and other items of example 1010 are described in more detail in the following paragraphs and figures.

Thus, in general, in example 1010, element 1012 represents input to a processor (e.g., a non-metadata processor or subsystem such as 1002) executing PUMP and user code, and element 1014 ) represents the output generated by the metadata processor, element 1016 represents the output generated by the metadata processor input to the PUMP, and element 1018 represents the input to the metadata processor.

Referring to FIG. 29 , an example 1020 summarizing I/O in relation to an opgroup/care table (eg, element 422 of example 420) in an embodiment according to the techniques herein is illustrated. do. As described elsewhere in this specification, the opgroup/care table can be used for each instruction to look up and output the opgroup and care bits for the opcode of the current instruction. This first flow of I/O is illustrated at 1020 by inputs and outputs in a vertical direction from the top (input 1022) to the bottom (output 1024). As described elsewhere herein, input 1022 is an opcode (e.g., as described with respect to the example in the opcode portion of example 420) that uses an index into the opcode/care table or its may be part Input 1022 may be from stage 3. Output 1024 may be the opgroup (opgrp) and care bits for a particular opcode. Outputs 1024 are the inputs to stage 5 (e.g., the two PUMP inputs opgrp and care contained in 1012).

The second flow of I/O is shown at 1020 by inputs and outputs in a horizontal direction from left (input 1026) to right (output 1028). The second flow of I/O at 1020 is an example of processing performed in connection with controlling the selection of the PUMP output Rdata 1028 input to the metadata processor or stage 6. Input 1026 is as described above with respect to 1016 . Output 1028 is as described above with respect to 1018.

Referring to FIG. 30 , an example 1030 abstractly illustrating processing performed by PUMP in an embodiment according to the description herein is shown. Example 1030 provides a PUMP control 1031 corresponding to the PUMP control for rule insertion described above with respect to horizontal PUMP I/O flows (e.g., elements 1012, 1016, and 1018) in example 1010. include Example 1030 includes masking 1032, hashing 1034, rules cache lookup 1036, and output tag selection 1038, which in example 1010 includes the vertical PUMP I/O flow (eg For example, it corresponds to the normal PUMP verify path I/O flow performed for each instruction as described above with respect to elements 1012 and 1014). Masking 1032 indicates applying the care bit of 1012 to mask unused PUMP inputs of 1012 . Hash 1034 represents the calculation of the hash used during the rules cache lookup indicated by 1036. Components that may be used to implement the logic indicated by 1032, 1034 and 1036 in one embodiment are shown and described with respect to FIG. Output tag selection 1038 selects the PUMP output (Rtag and PC new tag) included in 1014 based on the care vector bits (care included in input 1012) and the htagmode CSR (indicating the current tag mode). indicates

Referring to FIG. 31 , an example 1040 illustrating components that may be used to implement the logic of the output tag selection 1038 of a PUMP in one embodiment consistent with the techniques herein is shown. Example 1040 includes multiplexers (MUX) 1043a - 1043b. In general, MUX 1043a may be used to select the last tag value for PCnew tag 1043 as an output by PUMP (e.g., PCnew tag of 1014), and MUX 1043b may be used by PUMP It can be used to select the final tag value for Rtag 1047 as an output (e.g. Rtag in 1014). Element 1042 represents an input used as a selector for MUX 1043a. Input 1042 is PCnew tag 1043, which is used to select either 1041a or 1041b. Input 1042 may include the PCnew tag care bit (e.g., from the care bit of 1012) logically ANDed (&&) with the associated (a boolean indicating whether the PUMP is associated). Element 1043 represents an input used as a selector for MUX 1043b. Input 1043 is used to select one of the inputs indicated by (1045a-1045b) as Rtag 1047. Input 1043 may include the Rtag care bit (e.g., from the care bit of 1012) logically ANDed ($$) with engaged. Thus, in general, the care bits included in PUMP inputs 1012 identify which PUMP inputs don't care (masked) and which PUMP outputs (Rtag and PCnew tags) don't care (masked). do. Also, outputs 1043 and 1047 are treated with a "don't care" value when PUMP is de-associated because the processor is running at a higher privilege level than the current tagmode specifies as the threshold for PUMP operation.

Element 1049 indicates how the boolean engaged is determined as a function of the current RISC-V authority and the current tagmode. Element 1049 includes a logical expression using standard notation known in the art, whereby "A == B" represents a logical check for equality between A and B, and "A &&B" represents a logical AND operation between A and B , and “A || B” represents a logical exclusive OR operation between A and B.

Elements 1041a and 1045a represent inputs to 1043a, outputs from rules cache lookup 1036. PC tag 1041b is a PC tag included in PUMP input 1012. Other inputs 1041b are typically a number of other inputs that can be selected as possibly the last Rtag 1047 output by the PUMP. For example, in one embodiment, other inputs 1041b may include M tag, PC tag, CI tag, OP1 tag, OP2 tag, OP3 tag and possibly others depending on the instruction. The specific Rtag output 1047 may vary depending on the specific RISC-V instruction/opcode.

The following may summarize specific values for Rtag 1047 and PCnew tag 1043 generated as PUMP output values in one embodiment. It should be noted that the following indicates the specific R tag output values when the RISC-V instructions are different. Accordingly, the specific R tag value output as the final PUMP R tag value may change depending on the instruction using such PUMP output in connection with subsequent metadata processing.

1. PCtag does not change when output care bit is off for Pc new tag.

2. Rtag is Op1tag for CSRRW operation.

3. Rtag is Op2tag (CSRtag) for CSRR?I, CSRRS, and CSRRC operations.

4. Rtag is the PCtag for JAL and JALR instructions.

5. Rtag is the PCtag for the AUIPC command.

6. Rtag is the CItag for the LUI command.

7. Rtag is an Op1tag for non-memory, non-CSR, non-JAL(R)/AUIPC/LUI operations when the output care bit is off (indicating care for Rtag).

8. Rtag is the Op2tag for memory write operations when the output care bit is off.

9. Rtag is the Mtag for the memory load operation when the output care bit is off.

Referring to FIG. 32 , an example 1050 of components that may be used to control PUMP I/O in an embodiment consistent with the techniques herein is shown. In general, referring back to example 1030, the components of 1050 may logically include another layer on top of 1032 (eg, interfacing with the components of FIG. 22). Elements M1 to M14 represent multiplexers used to select the various inputs. Element 1052 generally represents the input opcodes from 1012 for the current instruction: PC tag, CI tag, Op1 tag, Op2 tag, Op3 tag, and M tag. Element 1056 generally refers to a row of registers used to store selected outputs of multiplexers M1-M7. In one embodiment based on the RISC-V architecture, each box in row 1056 may be a register, particularly elsewhere herein (e.g., example 900 representing a CSR that may be used in one embodiment). ) may be a CSR containing a specific value as described in

It should be noted that element 1052 of example 1050 does not include all of the inputs of 1012. For example, the subinstr inputs of funct12 (funct7) and (1012) are not shown in example 1050 for simplicity. However, those skilled in the art know that the input funct12(funct7) and subinstr from (1012) can also be included in (1052). More generally, inputs 1052 may apply to specific inputs for metadata rule processing that may be used in an embodiment.

Input 1052 can simply be passed as output 1054 when PUMP is performing processing for normal PUMP verification (eg, verifying that the current command can use policy rules). Output 1054 in this case passes to the PUMP as an input (or more generally to a metadata processor or subsystem) as an input to the component of FIG. 22 for metadata processing. In accordance with normal PUMP validation, the PUMP may generate output 1014 (e.g., if a matching rule for the current instruction is found in the rules cache, generate Rtag and PC new tag, else cache miss 1014a) occurs).

When a rule cache miss occurs, as a first step, the current values from 1052 for the current instruction are loaded into registers G1 through G7 at 1056. Thus, (G1 through G7) contains a snapshot of the opcode and tag values for the current instruction that caused the rule cache miss, and those values are now one or more desired values of (G1 through G7) as needed to make such processing happen. It can be used in conjunction with subsequent processing by cache miss handlers that read values.

Thus, in the second step, the cache miss handler executes, reads as input values from (G1 to G7), and generates a new rule for the current instruction. Multiplexer M16 is configured so that selected outputs from M10 can be executed on the same processor as executing program code (e.g., or otherwise executed on a separate metadata processor as in example 1000). ) can be used to control the selection of the various possible inputs from (G1 to G7) represented by R data 1053 for processing by the cache miss handler. Given inputs (G1 through G7) for the current instruction causing the rule cache miss, the cache miss handler performs processing to determine a new rule to be inserted into the cache. The cache miss handler generates the outputs R tag and PC new tag for the new rule just determined and writes Rtag to Rtag CSR (G8) and PC new tag to PC new CSR (G9). In example 1050, Op1 data 1051 represents outputs such as outputs generated by the metadata processor for new rules (Rtag and PC new tag), which outputs are CSRs (G8 and G9) as described. is stored in

At this time, the values of the CSRs (G1 to G9) are tag values of the new rule generated by the cache miss handler and can be inserted/written into the rule cache as a new rule in the third step. In at least one embodiment using the techniques herein in conjunction with a RISC-V architecture, a write to the R tag CSR indicated by G8 adds a new rule (e.g., the contents of CSRs (G1 through G9)) to the rules cache. trigger to write to Regarding rule insertion, CSRs (G1-G7) are provided as outputs 1052 and CSRs (G8 and G9) are provided to the PUMP as outputs 1055 for storage in the rules cache. More specifically, in one embodiment, outputs 1052 and 1055 may be provided to the component of FIG. 22 for rule insertion.

In a simple case, the embodiment satisfies the current rule miss by writing the contents of the CSR (G1 to G9) for the new rule into the PUMP rule cache as just described (e.g., via outputs 1052 and 1055). You can insert one new rule that does In this embodiment, the multiplexers M1 to M7 are not needed because the Op1 data 1051 output by the metadata rule processor executing the cache miss handler only generates the R tag and PC new tag for the new rule. However, embodiments also enable prefetching multiple rules or inserting multiple rules into the rule cache. For example, in the event of a rule cache miss, the cache miss handler can determine multiple rules to be written/inserted into the rules cache instead of one new rule for the current instruction. In this case, Op1 data 1051 includes additional new values for opcode, PCtag, CItag, Op1tag, Op2tag, Op3tag and Mtag (written in CSR (G1 to G7)) as well as (written in CSR (G8 and G9) In this case, multiplexers M1 to M7 each select the new values from Op1 data 1051 as inputs to CSRs G1 to G7. can be used to do

In general, Op1 data 1051 represents the output from the metadata processor to the PUMP, and R data 1053 represents the output from the PUMP to the metadata processor. Element 1052 also ensures that the value of element 1054 is equal to the value as in 1052 when performing normal PUMP verification (e.g., verifying that the current instruction is capable of using policy rules). Represents input to the PUMP from a processor executing user code (e.g., as part of normal instruction processing).

Referring to FIG. 33 , an example 1060 illustrating a PUMP processing stage combined with a 6 stage processor pipeline in an embodiment in accordance with the techniques herein with a RISC-V architecture with branch prediction is provided. is shown Example 1060 shows a six stage pipeline, where stage 1 includes fetching the next instruction to be executed (e.g., storing the fetched instruction in I cache 1063a) and branch prediction, and stage 2 denotes the decode instruction stage, stage 3 involves obtaining a value from a register (e.g. register read) and obtaining branch resolution for the current instruction, and stage 4 is executing an instruction (e.g. , executes high-speed ALU operations and initiates multi-step operations such as floating point (FP), integer multiplication and division), stage 5 includes receiving responses to multi-stage operations, and stage 6 includes receiving responses to multi-stage operations. This includes committing the instruction (e.g., storing the result to destination and data cache 1063b as indicated by 1069) and handling exceptions, traps and interrupts. Also shown in example 1060 is a PUMP processing step. Element 1062 indicates that an opgrp/care table lookup may be performed in stage 3, with output 1062a being provided as input to PUMP hash 1064 in stage 4. Other inputs to the PUMP hash 1064 include Mtag 1061 (e.g., the tag of a memory location that is an operand to the current instruction) and another tag value 1062b, whereby inputs 1061 and 1062a-1062b ) is used to determine the output 1064a indicating the cache address or location of the PUMP rules cache 1066. Examples of other tag values 1062b of instruction operands, PC, current instruction, etc. are described elsewhere herein and may be used in connection with determining a location within rules cache 1066 for the current instruction (eg For example, Figure 22). Element 1068 represents cache rule miss detection based on output 1066a of the PUMP process from stage 5. Output 1066a may include an indicator as to whether there was a rules cache miss for the current instruction. When 1066a reports a potential hit, 1068 determines whether the hit is a true or false hit, turning the false hit into a miss. Element 1066b represents the PUMP output to stage 6 if there was no rule cache miss and there is a rule in the cache matching the current instruction. Output 1066b may include PC new tag and R tag. It should be noted that the PUMP stage of embodiment 1060 can be changed. For example, the opgroup/care lookup 1062 may be performed in stage 4 rather than stage 3 depending on the determination of both the PUMP rule cache location and the lookup done in stage 5 (e.g., depending on the particular PUMP rules cache implementation). can

Regarding non-memory operations, Mtag is not needed as an input to the PUMP stage, and PUMP can continue processing without it. For memory operation instructions, PUMP is disabled until the Mtag is retrieved from memory. Alternatively, embodiments may perform Mtag prediction as described elsewhere herein. Consistent with discussion elsewhere herein, the PC new tag must be provided back to stage 1 as shown and described with respect to FIG. 1 . As long as an instruction is committed, the PC new tag is the appropriate PC tag for the next instruction. If the current instruction does not commit (eg, no rules cache hit), then (by passing back to stage 1) the PC new tag is determined by the rules cache miss handler. When a trap handler is started or a context switch is performed (eg PC restore), the tags are fetched from the saved PC.

As described herein, embodiments may associate a single tag with each word. In at least one embodiment, the word size associated with each tag may be 64 bits. The content of the tagged word may include, for example, instructions or data. In this embodiment, the size of a single instruction. However, embodiments may also support instructions of sizes other than 64 bits. For example, an embodiment may be based on the RISC-V architecture, which is an open source instruction set architecture (ISA) based on built-in reduced instruction set computing (RISC) principles, as described in more detail elsewhere herein. . Embodiments using the RISC-V architecture may include many different sized instructions, such as 64-bit instructions as well as 32-bit instructions, for example. In this case, embodiments consistent with the techniques herein may associate a single tag with a single 64-bit word, and thus a single word may contain one 64-bit instruction or two 32-bit instructions.

Referring to FIG. 34 , an example 200 of a tag that may be associated with a command in an embodiment consistent with the techniques herein is illustrated. Element 201 illustrates the above mentioned case where a single tag 202a is associated with a single instruction 204a. In at least one embodiment, the size of each of 202a and 204a may be a 64-bit word. Element 203 illustrates the alternative mentioned above in which a single tag 202b is associated with two instructions 204b and 204c. In at least one embodiment, the size of 202b may be a 64-bit word, and instructions 204b and 204c may each be 32-bit instructions contained in the same 64-bit instruction word 205 associated with tag 202b. there is. More generally, it should be noted that there may be more than two instructions in a single tagged instruction depending on the instruction size(s) used in the embodiment. As shown by element 203, multiple commands are associated with a single tag if the granularity of the tagging does not match the granularity of the command. In some cases, the same tag 202b may be used for each of the commands 204b and 204c. However, in some cases, the same tag 202b may not be used for each of the commands 204b and 204c. In the following paragraphs, each of a number of instructions, such as 204b and 204c, included in a single instruction associated with a single tagged word may be referred to as a subinstruction.

Accordingly, techniques will now be described that may be used in embodiments involving multiple sub-instructions within the same instruction word, where different tags may be used in connection with each of the plurality of sub-instructions.

Referring to FIG. 35 , an example illustrating commands and tags that may be used in an embodiment according to the techniques herein is shown. Example 220 includes a single 64-bit instruction word 205 comprising two 32-bit sub-instructions 204b and 204c. Tag 202b may be a tag on instruction word 205 as described above in example 200 . In at least one embodiment consistent with the techniques herein, a tag 202b of an instruction word 205 may be a pointer 221 pointing to another memory location 222 that contains a pair of tags, where the pair Includes a tag for each of the sub-instructions 204b-204c of the instruction word 205. In this example 220, tag pair 222 includes 222a representing a first tag, tag1, for sub-instruction 1 (204b), and also includes a second tag, tag2, for sub-instruction 2 (204c). Indicates (222b). In at least one embodiment, each tag 222a-222b of pair 222 may be a non-pointer tag (eg, scalar), used by PUMP for processing as described herein. It may be a pointer tag pointing to another memory location that contains information, or it may otherwise be a more complex structure containing one or more non-pointer fields and/or one or more non-pointer fields. For example, tag1 222a may be a pointer tag for sub-instruction 1 204a, and tag2 222b may be a pointer tag for sub-instruction 2 204b. As shown at 220, element 223a includes tag1 222a pointing to or identifying another memory location 224a containing information used by PUMP to process subinstruction1 204b. element 223b represents tag2 222b pointing to or identifying another memory location 224b containing information used by PUMP to process subinstruction 2 204c. Depending on the embodiment and sub-instructions, each of 224a and 224b may be a non-pointer, may be another pointer pointing to a memory location, or may be a complex structure containing some combination of one or more pointers and one or more points. there is.

In embodiments having multiple sub-instructions within the same instruction word 205, an additional input may be provided to the PUMP indicating which of the sub-instructions contained in the instruction word 205 are being executed at any one time. For example, if there are two sub-instructions 204b-204c in the instruction word 205, the additional input to PUMP is 0 indicating whether sub-instruction 1 204b or sub-instruction 2 204c is executing at a particular point in time. or 1. In at least one embodiment consistent with discussion elsewhere herein based on the RISC-V architecture, recording or storing additional input (indicating which sub-instruction is executing) to the PUMP (as described elsewhere herein) ssuninstr CSR) can be defined. In at least one embodiment, the PUMP may normally receive the aforementioned additional input from the data path (eg, from the code execution domain) without using a CSR. However, on a rule miss, the aforementioned additional input is written to the CSR, allowing the metadata processing domain on which the rule miss handler is executed to obtain the aforementioned additional input (e.g., the CSR value for the aforementioned additional input). is provided to PUMP upon rule insertion).

Further described, embodiments may include sub-instructions that provide transfer of control between two locations in a program. Examples of such sub-instructions may be jumping, branching, returning, or more generally transferring control from a source location in code to a target (eg, sink or destination) location in code. With respect to CFI or control flow integrity described elsewhere herein, it may be desirable to have PUMPs implement the rules of a CFI policy that restrict or control transfers between locations to only locations supported by the program. For example, consider the case where control is transferred from a source location of code with tag T1 to a target location of code with tag T2. The information used by PUMP when enforcing the CFI policy may be a list of valid source locations allowed to transfer control to T2. In an embodiment of the CFI policy, two rules may be used to provide double checks of two instructions or opcodes when transferring control from a source to a target location. Consider the pseudo-code representation of a transfer or call, as shown in example 230 of FIG. 36 . In example 230, a call can be made to transfer control 23a from a source location in routine foo 231 to a target location in routine bar 233. Specifically, control may be transferred 231a from source location X1 232 with tag T1 to target location X2 234 with tag T2. The target location X2 may be the first command in the body 233a of the code of the routine bar. The rules of the CFI policy can be used to check if the transfer from (232) to (234) is allowed or valid. In at least one embodiment, two rules of the CFI policy may be used, each performing a check to ensure the transfer of control from 232 to 234 is valid. The instruction at source position X1 is the branch point or source point from which control transfers to the target. At the source (eg, prior to executing the instruction at source location X1 232), the first rule may be used to mark or set a tag on the PC to indicate the source location. For example, the first rule may indicate the source location by marking or setting the tag of the PC to the address X1. Subsequently (prior to executing the instruction at target location X2 234), a second rule can be used to check if source location X1 is a valid source location that is allowed to transfer control to target location X2.

In at least one embodiment, the check of the second rule is that the PC's marked tag (set by the first rule) identifying the source location 232 (e.g., indicating the source location address X1) is the target location. 234 to determine if it identifies a valid source location to which control can be transferred. In such an embodiment, the second rule may be provided with a defined list representing all valid source locations that are allowed to transfer control to the target location 234 . In at least one embodiment, the defined list may identify valid source locations by address, for example X1 mentioned above.

Referring to FIG. 37 , an example 240 illustrating tags that may be used in connection with sub-instructions of source and target locations in an embodiment consistent with the techniques herein is shown. Example 240 includes element 203 representing a single tag 202b specified for two sub-instructions 204b-201c of a single instruction word, as described above. A tag 202b on an instruction word may point to a tag pair 242 representing two tags 242a-204b, respectively, for two sub-instructions 204b-204c. Each of the two tags 242a-b is generally a pointer to information used by the PUMP rules to validate the CFI with respect to a source or target location according to a particular sub-instruction associated with each of the two tags 242a-242b. can be

Example 240 illustrates a structure in one embodiment where two sub-instructions 204b-204c are target locations. Sub-instruction tag 242a points to the location of structure 245 including source id field 245a and allowed source set field 245b (243a). The source id field 245a may be null when the sub-instruction 204b is not a source location, such as when the sub-instruction 204b is a target location herein. The source set field 245b may be a pointer to a location containing a list structure 247 identifying one or more valid source locations that are allowed to transfer control to a specific target location that includes the sub-instruction 204b. In at least one embodiment, list structure 247 may include a first element indicating the size or number of valid source locations. Accordingly, size 247a of "n" (where n is an integer greater than zero) represents the number of source locations represented by elements 247b through 247n in list 247 . Each of elements 247b through 247n may identify a different valid source location that may transfer control to a target location that includes sub-instruction 204b. In at least one embodiment, each of the allowed sources 247b through n may be a scalar or non-pointer, e.g., the address of one of the valid source locations.

In example 240, elements 243b, 246 and 248 used with sub-instruction 2 204c are similar to elements 243a, 245 and 247 used with sub-instruction 1 204b, respectively. In general, in such an embodiment using the structure of 240, any item that does not exist may be assigned a null or zero value. If instruction word 205 includes a pair of sub-instructions 204b-204c that is not a source or destination location, tag 202b may be null (e.g., otherwise it does not point to structure 242). may identify non-pointers or other pointers). If one of the sub-instructions 204b-204c is neither the previous source location nor the target location, the associated tag at 242 is null. For example, if sub-instruction 204b is neither a source location nor a target location, but sub-instruction 204 is a target, then 242a may be null and 242b may be as shown in example 240. If subinstruction 204b-204c is not a source location, the source id is null (e.g., since 204b-204c in example 240 is a target location, 245a and 236a are both null) . If sub-instructions 204b-204c are not target locations, the allowed source set field pointer is null. For example, if sub-instruction 204b identifies a source location rather than a target location, source id 245a identifies the address of the source location instruction, and 245b will be null.

38 for another example 250 using the structure as described in example 240, the difference being that the first sub-instruction 251a is neither a source location nor a target location, and the second sub-instruction 251a is neither a source location nor a target location. The command 251b is a target location to which control may be transferred from any of the three valid source locations. Elements 251a - 251b may represent two 32-bit sub-instructions contained in a single tagged word with tag 251 . Tag 251 may be a pointer 1228 identifying a location in memory containing structure 252 having tag pairs for sub-instructions 251a-251b. Element 252 may be similar to 242 of example 240. Element 252a may be a tag pointer for sub-instruction 251a, and element 252b may be a tag pointer for sub-instruction 251b. Sub-instruction 251a is neither a source nor a target location, so 252a is null as indicated by 0. Since subinstruction 251b is the target location, 252b is pointer 1238 to structure 254. Element 254 may be similar to 246 of example 240. Element 254a is a source id field (such as 246a), and element 254b is a pointer (address 1248) pointing to an allowed source set structure 256 (similar to 248 of example 240). ) is an allowed source set field (such as (246b)) that contains. Since subinstruction 251b is only a target location and not a source, source id 254a is null. Element 256a may be a size field (such as 248a) indicating the number of valid source locations. Elements 256b through 256d may represent a valid source id, which may be, for example, the address of a valid source location instruction. In this example, 256a indicates that there are three valid source locations with addresses 50bc, 5078, and 5100 stored in entries 256b through 256d, respectively. In connection with the foregoing, it should be noted that generally an instruction can be both a target and a source, so being a target does not mean that the source id is always null. For example, if a command is both a target and a source, the source id will not be null, and the command's tag contains a list of allowable/allowed sources.

The address of the source location, e.g., in entries 256b through 256d, and more generally in any allowed source of the set of allowed sources (e.g., any of 248b through 248n of example 240) is a byte. It should be noted that it can be a level address granularity.

In a manner similar to that just described with respect to multiple instructions (also referred to as sub-instructions) contained in a single tagged word, embodiments may allow access to less than a single tagged data portion of data. For example, embodiments may include instructions that access data at the byte level, with each byte having its associated tag in a manner similar to providing a different tag to each of a number of sub-instructions contained in a single tagged word. It may be desirable to provide byte-level tagging so that it can have . In the following example, it is mentioned providing byte-level tagging, where each of the 8 bytes included in a 64-bit word can have its own associated tag. More generally, however, the techniques herein may be used to provide subword tagging for any number of multiple data items contained in a single tagged word. In this case, the tag associated with the tagged data word may be a pointer to a structure that identifies the byte level tag for the byte of the tagged data word.

Referring to FIG. 39 , an example 260 of byte-level tagging that may be used in an embodiment consistent with the techniques herein is illustrated. Element 262 represents tag 262a associated with tagged 64-bit word 265, where word 265 contains 8 bytes denoted B1 through B8. Tag 262a may be a pointer 261 to a memory location in structure 266 that contains a tag for each byte B1 to B8 of data word 265 . Structure 266 includes a first field 265a, which is a size field indicating the number of entries remaining in the structure. Each subsequent entry in the structure may contain a tag value and may represent one or more bytes of word 265 with that particular tag value. In this example, size 265a is 8, where each of bytes B1-B8 of (265) has a different tag value. Elements 266a through 266h represent tag values for bytes B1 through B8 of word 265, respectively.

Referring to FIG. 40 , a second example 267 of byte-level tagging that may be used in an embodiment consistent with the techniques herein is illustrated. Element 262 represents tag 262a associated with tagged 64-bit word 265, where word 265 contains 8 bytes denoted B1 through B8. Tag 262a may be a pointer 268a to a memory location in structure 268b that contains a tag for each byte B1 to B8 of data word 265 . Structure 268b may include a first field 265b, which is a size field indicating the number of entries remaining in the structure. Accordingly, 265b is similar to 265a in FIG. 39 . Each subsequent entry in structure 268b may contain a tag value and may represent one or more bytes of word 265 with that particular tag value. In this example, the size 265b is 7, representing the 7 subsequent entries 266a through 226f and 268c. Elements 266a through 266f are as described with respect to example 260 of FIG. 39 . Element 268c indicates that tag 7 is a tag for both bytes B7 and B8. Thus, in example 267, since bytes B7 and B8 have the same tag value of tag 7, structure 268b contains one less entry than structure 266 of FIG. 39 . In this way, the structure (e.g., 268b) pointed to by the tag of the data word (e.g., 262a) may have a varying number of entries, depending on the particular byte-level tag, if desired.

It should be noted that the specific level of data access granularity may vary depending on the specific architecture and instruction set in the embodiment. The foregoing may be used to provide byte-level tagging in embodiments that allow byte-level data access. As a variant, embodiments may support data access at different levels of granularity, and the techniques herein may be readily extended to any subword tagging level of granularity.

Similarly, examples 260 and 267 show one example of a data structure that can be used to hold byte level or other subword data tagging. As a variant, an embodiment may use a tree or other hierarchical structure to specify byte level tags for bytes of a single tagged data word. A tree or other hierarchical structure representing byte-level tags may be used to store word-level tags in association with, for example, respective elements 100, 120, 130, and 140 of FIGS. 78-81 described elsewhere herein. may be similar to the hierarchical structure described herein for

Further explained, an embodiment may use a tree structure to represent a byte level tag as in example 270 of FIG. 41 . In example 270, element 262 can represent tag 262a associated with tagged word 265 that includes bytes B1 through B8. Tag 262a may be a pointer or address to a tree structure representing byte level tags for B1 through B8 265 . For example, the tag 262a may indicate the location of the root node 272 of the tree structure. In this example, the tree structure may include a root node 272 of level 1, nodes 274a to 274b of level 2, nodes 276a to 276d of level 3, and nodes 278a to 278h of level 4. Each node in the tree can be associated with a byte range of one or more bytes. The leaves of the tree may represent byte-level tags for bytes B1 through B8. Therefore, a non-leaf node in the tree does not specify a tag value, but rather one or more descendant nodes at one or more lower levels must consult it to determine the byte-level tag for the byte range associated with the non-leaf node. indicates Leaf nodes may represent homogenous or identical tag values for a multi-byte range of (265). Each non-leaf node may include a left pointer pointing to the left child node of the non-leaf node and a right pointer pointing to the right child node of the non-leaf node. Each of the child nodes of the parent node may represent a division of the byte range associated with the parent node.

Example 270 shows a tree structure in which there is no homogeneous byte-level tag and each of the bytes B1 through B8 of 265 has a different tag value. In a manner consistent with discussion elsewhere herein (e.g., elements 100, 120, 130, and 140 of FIGS. 78-81), an embodiment provides that a subtree is a byte associated with a first node as its root. If we have the first node representing the homogeneous tag value for the range, we can omit the descendant nodes from the subtree. For example, for further explanation, reference may be made to FIG. 42 . In example 280, element 262 can represent a tag 262a associated with tagged word 265 that includes bytes B1 through B8, as described above. Tag 262a may be a pointer or address pointing to a tree structure representing byte level tags for B1 through B8 265 . In this example 280, bytes B1 to B8 each have the same tag T1, so the tree structure should contain only the root node 281. Because the byte-level tags for bytes B1 through B8 may be modified or changed over time, the tree structure or other structure pointed to by tag 262a will be updated accordingly to reflect these byte-level tag modifications. can

In an embodiment that provides for byte-level tagging, or more generally subword tagging, within the same data word 265, one or more byte-level tags (corresponding to any one or more of the bytes included in word 265) Additional input indicating what is being referenced may be provided to the PUMP. For example, in byte level tagging where there are 8 bytes (B1 through B8) within a single tagged data word 265, the additional input to the PUMP may be a bitmask of 8 bits, where each of the 8 bits is a byte (B1 through B8). B8) and indicates whether to use a byte level tag for a particular byte of word 265. As a variant, an embodiment may indicate one or more bytes by specifying a start byte and a length or range of bytes such as size (eg, bytes (B4 through B4) by specifying a start byte B4 and indicating a size or length of 5. B8)). In at least one embodiment consistent with discussion elsewhere herein, based on a RISC-V architecture, one or more byte-level tags for one or more bytes (B1 through B8) record additional input indicating that they will be used by the PUMP. Alternatively, a CSR to store may be defined. The additional input may be, for example, a bitmask or other suitable representation identifying a particular byte level tag used by the PUMP. In at least one embodiment, the PUMP may normally receive the aforementioned additional input indicating that any one or more bytes are to be used as input from the data path (eg, from the code execution domain) without using a CSR. However, on rule misses, the aforementioned additional inputs may be written to the CSR so that the metadata processing domain on which the rule miss handler runs can obtain the aforementioned additional inputs (e.g., upon rule insertion, the aforementioned additional inputs CSR value for is provided to PUMP).

As discussed elsewhere in this specification, many instructions at the policy level can be treated in a similar manner. For example, add and subtract instruction opcodes or opcodes can typically treat their metadata the same, so that both opcodes consider the same tag inputs to the PUMP and the same tag outputs propagated by the PUMP, thereby ensuring a specific policy. can behave similarly at the rule level for In such cases, add and subtract opcodes can be grouped together in a single operation group or "opgroup" so that the same set of rules can be used for all opcodes in that opgroup. How opcodes are grouped together is policy-dependent and therefore may differ from policy to policy. In one embodiment, a translation or mapping table may be used that maps specific opcodes to their associated opgroups per policy level. In other words, since mappings can change from policy to policy, a different mapping table can be created for each policy (or multiple policy groups with the same opcode specified in the opgroup mapping).

For a particular opcode, a translation or mapping table can determine the opgroup as mentioned above and may also determine additional information about the particular opcode. This additional information determines which PUMP inputs and PUMP outputs (e.g., input tags and propagated output tags) are actually used as inputs for rule processing, respectively, and can be propagated as relevant outputs of rule processing for a particular opcode. A care/don't care bit vector as also discussed elsewhere herein, which may represent In an embodiment, the don't care bit vector may be determined for any PUMP input or output. In one embodiment, the don't care bit vector may indicate which input tags and output tags are relevant and may also indicate which particular opcode bits are actually used for a particular opcode. It is described in more detail below for the RISC-V architecture and instruction format, but may be used more generally in conjunction with other suitable instruction formats for other architectures. The foregoing conversion or mapping tables, including opgroups and care/don't care bits for particular opcodes (e.g., element 422 of example 420 discussed below), may also be used elsewhere herein for opgroup May also be referred to as the /care table.

RISC-V has different instruction formats, each using a different set of instruction bits for the opcode. Referring to example 400 of FIG. 43 , the bits of an instruction that may be included in different bit encodings for different opcodes in an embodiment using instructions of the RISC-V architecture are shown. In general, RISC-V architectures include multiple instruction formats in which different bits of an instruction can be used as part of opcode encoding. For 32-bit instructions, it can be used to indicate the encoding of opcodes up to a total of 22 bits. Element 404 represents a portion of an instruction in the RISC-V architecture that can be used to indicate the bit encoding for a particular opcode depending on the instruction format. Element 404 includes three fields 404a through 404c of bits that can be used to encode a particular opcode. Element 404a represents a 7-bit first opcode field, opcode A. Element 404b represents a 3-bit second opcode field, funct3. Element 404a represents a 12-bit third opcode field, funct12. Depending on the instruction (eg, system call), the opcode encoding may include up to all 22 of the bits indicated by (404a through 404c). More specifically, in RISC-V, the opcode uses only 7 bits of (404b), only 10 bits of (404b and 404c) (excluding (404a)), or all 22 bits of (404a to 404c). can be encoded. As another variation, an instruction in a RISC-V architecture may have an opcode encoding using a field as indicated by 402 . Element 402 includes two fields 404b and 404c of bits as described above. Also, rather than using all 12 bits of funct12 (404a) in opcode encoding, an instruction can only use 7 of the 12 bits represented by funct7 (402a). Thus, as another possibility, the opcode can have an encoding using fields 402, 404b and 404c as shown by element 402.

44 shows an example 420 illustrating a mapping or conversion table that may be used in an embodiment consistent with the techniques herein. As discussed above, opcode 421 can be provided as an input or index into an opcode mapping table 422 to look up or determine the output 424 mapped to opcode 421 . The mapped outputs 424 may include opgroups of PUMP inputs and outputs for specific opcodes 421 and care/don't care bit vectors. In embodiments based on the RISC architecture and instruction format, an opcode can potentially have an encoding of up to 22 bits. However, due to the large number of entries needed to accommodate a 22-bit opcode, it is unreasonable to use such large 22-bit opcodes as indexes into a table (e.g., a table can create millions of entries for 22-bit opcodes and associated opgroups and opcodes). An entry may be included for each opcode representing care/don't care bit vector information). To reduce the size of table 422 in this embodiment, table 422 may be indexed using only a portion of the 22-bit opcode field. For example, in at least one embodiment, opcode 421 input may be 10 bits of the opcode represented by elements 404b and 404c of example 400. Thus, table 422 can be indexed using the opcode bits of 404b and 404c of the opcode to determine the opcode's opgroup and associated care/don't care bit vectors.

In such an embodiment, the remaining 12 opcode bits of funct12 404a of the instruction may be provided as input to the PUMP, in which the appropriate portion of 404a is masked for the particular opcode. Information on which specific bits of funct12 404a should be masked/unmasked for a specific opcode may be included in the care/don't care bit vector information output from the mapping table 422 lookup for the opcode. . In at least one embodiment based on the RISC-V architecture, the care/don't care bit vector information may indicate one of the following for the 12 opcode bits of funct12 404a for the opcode:

1. Since none of the bits in 404a are used, all 12 bits can be masked.

2. As indicated by 402a, 7 of the 12 bits are used where the least significant 5 bits of 404a (e.g., bits 20-25) are masked; or

3. All 12 bits of 404a are used so there is no masking of the bits of 404a.

Also, in this embodiment, the 12 opcode bits of funct12 404a may be written to or stored in a CSR, such as the sfunct12 CSR described elsewhere herein, provided as a PUMP input in connection with performing an insert into a PUMP. there is. In at least one embodiment, the PUMP may normally receive the aforementioned opcode bits from the data path (eg, from the code execution domain) without using a CSR. However, on a rule miss, the foregoing is written to the CSR so that the metadata processing domain on which the rule miss handler runs can obtain the foregoing as input (e.g., on rule insert, the CSR value is PUMP is provided as an input to).

In at least one embodiment consistent with the techniques herein, multi-user processes may execute using a virtual memory environment in which physical pages are mapped into user process address space. Techniques herein may be used to share physical pages of memory among multiple user processes, in which case the same set of one or more physical pages may be simultaneously mapped into the address space of multiple user processes. In at least one embodiment, tags used by those processes that are allowed to share may be characterized as global tags that have the same value and meaning or interpretation across user process address spaces.

Referring to FIG. 45 , an example 430 illustrating sharing of physical pages between processes in an embodiment consistent with the techniques herein is shown. 430 includes process PI having address space 434 and process P2 having address space 436 . Element 434 may represent a virtual memory process address space or range from 0 to MAX, where MAX represents the maximum virtual memory address used by the PI and 0 represents the minimum virtual address used by the PI. As is known in the art, a physical page of memory 432 is mapped into a virtual address space, such as 434, and the contents of the mapped physical page in this virtual address space are mapped to the virtual address space of such mapped physical page. It can be accessed by the PI using the address. For example, physical page A 432a may be mapped to subrange X1 of the virtual address space of P1. Process P1 can read a data item or instruction from a location in page A 432a, for example, by referencing a particular virtual address in subrange X1.

Similarly, a physical page 432 of memory can be mapped into a virtual address space 436, in which the contents of the mapped physical page are read by P2 using the mapped virtual address of the mapped physical page. can be accessed. For example, physical page A 432a may be mapped to subrange X2 of the virtual address space of P2. Process P2 can read a data item or instruction from a location within page A 432a, for example, by referencing a particular virtual address in subrange X2.

Tag 431 may represent a tag on a memory location in page A 432, in which page this tag may be used by PUMP in connection with the rule processing described herein. Because page A 432 is shared by both PI and P2 via mapping as shown, the same set of tags 431 are also used by PUMP in connection with executing instructions on both P1 and P2. do. In this embodiment, tag 431 may be characterized as a global tag shared by both PI and P2. Also, in at least one embodiment, global tags 431 shared by multiple processes P1 and P2 are interpreted in a similar manner, such as using the same rules and policies. For example, a first tag with a value of 100 can be associated with a first memory location in 432a. The first tag may indicate a value indicating a colorization of the first memory location used in conjunction with a rule of a policy that determines whether a particular executable instruction may perform an operation that references the first memory location or its contents. The first tag may be interpreted as the same color by convention with respect to instruction execution in both P1 and P2. For example, a tagged value of 100 should be interpreted as the same color by the rules relating to both P1 and P2. Also, the same set or instance of policies and rules may be used by PUMP for both P1 and P2.

In such embodiments using global tags on shared memory as described above, it may also be desirable to further differentiate or allow different accesses, authorizations or operations on a per-process basis. For example, suppose page A 432a contains data shared by both P1 and P2. However, even if a global tag is used to tag shared page A 432a, it may be desirable to allow different operations or access to the shared data of 432a per process. For example, process P1 may have write access to page 432a and process P2 may have read-only access to page 432a. However, 432a may be a shared memory page tagged with a global tag. In such an embodiment with a global tag on a shared page, the same set of policies and rules could be used for P1 and P2 where different read and write access capabilities for each process could be differentiated using different tag values on the PC. there is. For example, process P1 may include a first instruction that performs a write to a memory location in 432a and the current PC tag has a value of X. A rule in an access policy may perform the following logic:

If PCtag = X, allow writing

If PCtag = Y, read only

In this case, the PC tag has a value of X, which is interpreted by convention as allowing write access to process P1, so that P1 can execute the first instruction. Process P2 may have a second instruction that likewise performs a write to the memory location in 432a and the current PC tag has a value of Y. In this case, the PC tag has a Y value that is interpreted as not allowing write access by convention, but instead allowing read-only access to process P2, whereby P2 is not allowed to execute the second instruction.

Thus, in at least one embodiment, a PC tag may be used to encode rights, access or authorizations that may vary from process to process, such that a particular allowed right, access or authorization may be represented by a different PC tag value. there is.

Embodiments may specify specific PC tag values to be used for each process in any suitable way. For example, privileged code may execute as part of operating system startup or initialization that initially specifies a PC tag value to be used for a particular process. As a variant, an embodiment may perform a mapping operation as part of mapping shared page A 432a into the process address space. Rules applied by the operating system when performing the mapping may propagate or generate specific PC tags with output indicating desired access, rights or authorizations based on specific processes.

In this way, the same set of rules can be used with shared pages with global tags where the rules encode logic for differences in access, rights or authorization based on PC tags. It should be noted that a PC tag can also be a pointer to a memory location, so that a pointer tag points to a structure that includes different tag values in different policies in the manner described herein with respect to other tags. In this way, the same set of PC tag values can be used to indicate different capabilities of processes that can vary according to policy. For example, a PC tag value of X as described above with P1 may have a primary purpose as described above where there is a memory safety policy or a data access policy for the shared area. The same PC tag value of X may have a second purpose and meaning given by rules of a second, different policy, such as Control Flow Integrity (CFI).

Aspects of CFI policies that may be used in connection with restricting transfer of control based on static definitions of allowable calls, jumps, return points, etc. are described herein. However, an additional aspect or dimension that can be included in a CFI policy relates to the enforcement of dynamic or runtime invocation information, thereby further refining the conditions under which returned control transfers can be made. For further explanation, reference is made to example 500 of FIG. 46 , which includes routines foo 502 , bar 504 , and baz 506 . Routine Foo 502 may contain a call instruction at address X1 that calls routine bar, which results in a runtime transfer 501a of control to bar 504. Routine bar 504 then includes a return instruction that returns 501b control to routine bar to address X2. So X2 represents the return point address or location of the instruction in routine foo following the call from X1 to routine bar. Routine Foo (502) contains a second call instruction at address Y1 that calls routine baz (506), which results in a runtime transfer (501a) of control to baz (506) to baz (506). Routine baz 506 may then include a return instruction that returns control to routine bar to address Y2. Thus, Y2 represents the return point address or location of the instruction in routine foo following the call to routine baz in Y1.

A static CFI policy can direct all potential control flows between any two transfer points without further restricting the transfer or control flow based on, for example, the current runtime stack or call chain that reflects dynamic runtime control flow aspects. can make it possible For example, as shown at 500, if foo 502 can call bar 504, it calls bar on X1 in foo, then the statically allowed control flow from bar to the instruction's address X2 is reversed. there is However, if foo has not been called so far, or has called something else that should return before calling bar , then it should not be able to execute the return link to return to X2. As another example with runtime execution as shown in example 500, a call to Bar 504 via 501a should not be able to return via 501d to Foo 502 at Y2.

Techniques that may be used will now be described in connection with the extension of the rules of the CFI policy to enforce the dynamic CFI return policy that governs return flow path control. In the case of a dynamic CFI return policy that guarantees that a return to a specific return location, such as X2, is valid only when followed by a specific call or call, such as a call to bar at X1, a dynamic CFI return policy can prevent invalid returns. Information may be stored in one or more tags, for example, when a call is made to exclude. As is known in the art, when a call is made using, for example, a jump and link (JAL) instruction of the RISC-V instruction set, the return address is stored in a return address register (RA). The RISC-V instruction set also includes jump and link register (JALR) instructions, which are examples of return instructions. In one aspect, the return address stored in the RA register from the JAL may be characterized by a "capability" to return to that point. In at least one embodiment, JAL commands may be tagged with tags that cause rules to push appropriate tag capabilities to the resulting return address. For example, in the case of using RA as the return address register, the convention is to tag the RA register to contain a valid or suitable return address, and later the address in the RA register can be used as a return point to which control can be transferred. Can be placed on the RA register. In other words, the tag on the RA register provides authorization for the address in the RA to be loaded into the PC and used as the return address to execute the return transfer of control. When loading the RA address into the PC, the RA tag may be stored as a PC tag by the rules of the CFI policy.

Further describing a technique that can be used to restrict control flow on return, an embodiment can code tag each return point (eg X2, Y2) with a dynamic CFI tag such as expect-A. Code tagging each JAL instruction (or calling instruction) also allows the rules to ensure that the JAL instruction returns the return address in the RA register (where the return address is computed by the JAL) to the appropriate dynamic-CFI-return-to-A. return-to-A) tags to evaluate tagging. For each return, such as each JALR instruction using an RA register tagged with a dynamic-CFI-return-to-A tag, a PUMP rule can be performed in conjunction with other static CFI policy rules by adding a tag (dynamic-CFI- Return-to-A) can be propagated to the PC. The rules of the CFI policy may implement logic to check the RA register used in return instructions. It is known that unless the RA register used for return is tagged with the dynamic-CFI-return-to-A tag, the register does not contain a valid return address allowed for use with JALR instructions. At return points (e.g., X2 and Y2), when the rule encounters an expect-A code tag (e.g., as a tag on the instruction of X2), the PC is tagged as dynamic-CFI-return-to-A. and implement logic to clear the dynamic-CFI-return-to-A tag from the PC.

As a result of the above, the code is prevented from returning directly to any return address. Also, if the return address is copied to another location, such as another register, rules may prevent the copied value from retaining the ability to apply returns; This prevents code from making copies in registers of return addresses that could be used to perform multiple returns on the same call. As another result of the above, if a valid return address (properly tagged) on the stack is overwritten with a new address (not properly tagged) and then an attempt is made to return to the new address, the return is prevented.

Embodiments may also include rules that prevent or further restrict the ability to use the dynamic-CFI-return-to-A tag more than once. As a first implementation, an embodiment may use a rule to limit where the return address (stored in the RA register tagged with the dynamic-CFI-return-to-A tag) can be written or copied. For example, an embodiment may use a rule such that only return addresses in properly tagged RA registers write return addresses to the stack within properly code tagged function code. As a second alternative implementation, the embodiment uses a PC state (eg, a PC tag) and an atomic memory operation to make the return address linear (eg, to follow or occur in a call) rules. can include For example, making a call sets the PC tag to indicate a valid-return-address. A rule can only allow a return if the PC tag is set to valid-return-address. When writing the return address to memory, an additional rule may be used to set the PC tag to a no-return-address. When copying the return address to the target register, a rule can be used that the PC tag can be set to no-return-address and the target register is not tagged with a valid-return-address. When an arithmetic operation is performed using the return address from the RA register, a rule may be used that the result is not tagged as a valid-return-address. A rule can be used that only allows the return address to be retrieved from memory using an atomic swap operation with a non-return-address (e.g., if the PC tag is set to valid-return-address).

One embodiment may further define rules providing stack protection policies. In one aspect, a stack protection policy may be considered in part as an extension of one or more other policies, such as memory safety, in which a policy may use tags of both instructions and data for policy enforcement. In the following discussion and elsewhere in this specification, terms such as routine and procedure may be used interchangeably and more generally a callable unit of code that, when called, consequently creates a new stack frame on the call stack. It should be noted that it refers to Other names that may be used for callable units of code might include functions, subroutines, subprograms, methods, etc.

Referring to FIG. 47 , an example 520 illustrating a call stack of a frame for a runtime call in an embodiment consistent with the techniques herein is shown. At 520, assume that routine foo 502 makes a call to G1 and eventually calls G2. Thus, at one point in execution, routine foo is running and makes a first call to routine G1, which then calls routine G2. Element 522 may represent the first call stack frame for routine foo. Element 524 may represent a second call stack frame for routine G1. Element 526 may represent a third call stack frame for routine G2.

Information stored in a runtime call instance or stack frame for a call (e.g., 522, 524, 526) may include, for example, return addresses, data used by that call instance for registers, variables or data items, etc. there is. Elements 522a and 524a may represent the return addresses contained in frame 522 for foo and frame 524 for G1, respectively. One common attack that may be performed, for example, by malicious code may be to modify return addresses such as (522a and 524a) stored in stack 520. Using techniques such as those described herein for dynamic CFI return policies (e.g., as described with respect to FIG. 46 in example 500), an improper or prevent invalid returns. However, it may be desirable to also enforce additional rules that provide stack protection and prevent improper modification of stack storage locations, such as return addresses. Thus, these additional rules for the stack frame protection policy can prevent modification of 522a or 524a and then stop returns using improperly modified return addresses, rather than allowing improper modification of 522a.

As described in more detail below, different levels of stack protection may be provided. In one aspect, stack protection may be determined based on a static procedure (also referred to as a static authorization protection model described elsewhere herein), or may be determined based on a procedure and also a specific procedure (instance authorization protection model described elsewhere herein). Also referred to as) may be determined based on both call instances. Using the statically authorized protection model, the rules of the stack protection policy can provide stack protection based on specific procedures or routines that create frames. For example, instead of the stack containing only a single frame for a single instance of foo as at 520, at this point in time there may be multiple call instances of foo included in the current call chain, so (e.g. , e.g. based on a recursive call to foo) there may be multiple call stack frames in the stack for routine foo. Based on a static routine or procedure, any instance of foo can modify or access information in any call stack frame for an instance of foo. For example, foo instance 1 can have call stack frame 1 and foo instance 2 can have call stack frame 2. Based on the static routine or procedure for stack protection, code in foo instance 1 can access stack frames 1 and 2 and code in foo instance 2 can also access stack frames 1 and 2. In this embodiment, call stack frames for all instances of the same procedure or routine foo may be colored with the same tag. For example, frame 1 for instance 1 of foo and frame 2 for instance 2 of foo are both colored with tag T1 so that the rules of the memory security policy allow the aforementioned stack frame access across different instances of the same routine or procedure. will make

As a finer granularity of stack protection, embodiments may use static routines or procedures as well as rules in stack protection policies that further restrict access to the stack based on specific runtime instances of routines or procedures (e.g., instance Authorization Protection Model). For example, as mentioned above, foo instance 1 can have call stack frame 1 and foo instance 2 can have call stack frame 2. Based on static routines or procedures and also call instances for stack protection, code for foo instance 1 can access stack frame 1 but not stack frame 2, code for foo instance 2 can access stack frame 2 but can't access stack frame 1. In such an embodiment, the call stack frame for each call instance of a procedure or routine may be colored with a different tag. For example, frame 1 for foo instance 1 can be colored with tag T1 and frame 2 for foo instance 2 can be colored with tag T2, so the rules of memory safety policy can be colored based on specific calls and routines or procedures, respectively. This will enable the stack frame access mentioned above.

Embodiments may further provide a finer level of granularity of different regions or portions of the stack for a single procedure call instance, such as by colorizing different objects or data items within a stack frame, each of which color is different (see elsewhere herein). Also referred to as the object protection model described in ). As described elsewhere herein, a stack frame may contain storage for data items or objects used in specific invocations of routines or procedures, where each such data item or object is tagged with a different color. It can be. For example, referring to FIG. 48 , an example 530 depicting a data item 540 with storage allocated by routine or procedure foo and associated tagged memory in stack frame 531 is shown. Element 540 represents variables 540a through 540c with storage allocated to routine foo, and element 531 represents the call stack frame for this particular call instance of routine foo in the call stack. Element 531 includes memory area 532 of variable array 540a, memory area 534 of variable line 540b, and memory area 536 of variable password 540c. Frame 531 also includes a memory area 538 of stored return addresses. Each of the different regions 532, 534, 536 and 538 may be tagged or colored with a different tag as indicated by 533. Each word in region 532 may be tagged with Red1. Each word in area 534 may be tagged with Red2. Each word in area 536 may be tagged with Red3. Each word in region 538 may be tagged with Red4.

As another variation, embodiments may define different trust domains or boundaries for sets of code (eg, routines, procedures, etc.) and provide different levels of protection. For example, not all routines called may have the same trust level. For example, a developer may have a first set of routines written by him and have a high confidence level that the actions performed by the first set of code do not contain malicious code. However, the first set of routines can be called into a library provided by a third party or obtained from the Internet. Libraries can be unreliable. Thus, embodiments may vary the level of protection based on different bodies of code and specific data items used by each body. For example, referring to example 550 of FIG. 49 , routine foo in trusted user code calls routine evil in library and sends an evil pointer to area 534 (data entry line 540b). pointer) as a parameter. In this case, instead of coloring or tagging each region of 531 with a different color, regions 532, 536, and 538 could all be colored the same color, such as Red5, and region 534 a different color, such as Red6. can be tagged with This can be used to further ensure that memory regions 534 accessed by routine malicious are tagged with a different color than other regions 531 as a level of memory safety since routine malicious is considered untrusted code. Additionally, the pointer pointing to the area 534 that was passed in bad faith may be colored or tagged with the same color Red6 as the area 534 . In this way, memory safety policy rules can restrict access to maliciously used memory to memory tagged with Red6.

Whether a particular routine, library, or text or code has a particular confidence level can be determined based on an analysis using one or more criteria and inputs. For example, based on runtime analysis and use of library code, a level of trust can be determined. For example, if a library calls another unknown or untrusted external or third party library, the level of trust may be relatively low. The level of trust for the body of code may be used by the source or location from which the code was obtained. For example, using code from a library obtained from the Internet may be considered unreliable. In contrast, code developed by a particular developer that does not call any untrusted code may have a high level of trust.

The foregoing and other aspects of stack frame and stack protection are described in more detail below.

Regarding stack frames and referring back to example 530, the compiler can create a new stack pointer by adding an integer (the size of the frame) to the old stack pointer. The old stack pointer can be restored by pushing it onto the stack (to the frame) and then reading it back from the stack. The addition to the stack pointer may indicate the total size of a frame containing many independent objects, as described above at 531 for data items 540a-540c. The stack needs space for these 3 data items 540a through 540c, and the compiler can determine the total space needed for data items 540a through 540c. In standard usage, the compiler accesses stores 532, 534, and 536 of these data items 540a through 540c, respectively, by computing addresses from the stack pointer (or frame pointer generated from the stack pointer). Thus, in an embodiment, the compiler, runtime, and calling convention can create and use pointers that point to different regions of the stack call frame by performing simple pointer arithmetic.

The static authorization protection model indicates that authorization for an object belongs to a static code block, such as a routine or procedure that creates a frame. Thus, as discussed elsewhere herein, a procedure foo that creates a frame has an authorization that creates pointers to things within that frame. In the simplest case, the same authorization would give foo access to all frames it created, no matter if the frames were on the stack earlier or later. Static authorization indicates that a tag (e.g., color of a memory cell, colored pointer, code tag that creates a colored pointer (e.g., also referred to as an instruction tag or tag on an instruction) may be pre-allocated at load time. Instance authorization protection provides authorization based on the depth of the function call on the stack Object protection represents protection at the level of objects allocated on the stack as well as at the stack frame. eg arrays, buffers) to other objects on the same frame, which is not achieved using simple stack frame granularity PUMP rules with a static authorization protection model or an instance protection model. Object protection can be applied to both the static authorization protection model and the instance protection model As a variant of object protection, embodiments can also be hierarchical, such as structures containing arrays and multiple different data item sub-objects, such as integers. Hierarchical object protection of objects may be used In at least one embodiment where a first object has a hierarchical object comprising one or more levels of each of one or more sub-objects, a first tag may be created for the first object. Additional sub-object tags can then be created based on the first tag Each sub-object tag can be used to tag a different sub-object A sub-object tag indicates a particular position of a sub-object in a hierarchy can be a value For example, tag T1 can be created for use with a structure that contains 2 arrays as subobjects 2 and 3. A different subobject tag for each of the 2 arrays is created from T1 and the 2 array sub Used to tag objects.

Processing that may be performed with respect to stack memories for different stack operations in embodiments according to the techniques herein will now be described. At startup, the stack memory may have all memory cells marked or tagged using a free-stack frame tag. Consistent with discussion and description elsewhere herein, such tagging may be performed by invoking PUMP rules. It should be noted that initially tagging of stack memory cells with free-stack frame tags cannot be done for the entire stack at once, but instead can be done incrementally in a kernel page fault handler that expands the stack.

For example, in connection with allocating a new stack frame by a compiler, a new frame tag may be created in the newly allocated frame. A pointer to a new frame may be tagged with a new frame tag. For example, an embodiment may tag an instruction that creates a new frame pointer (eg, an add instruction that performs a pointer operation (by adding to the stack pointer)), in which case the tag on the instruction follows a policy rule. to create a new frame tag. Using rules and tag propagation, a special tag can be created for the stack pointer and used to tag the stack pointer. Then, for each frame pointer, a unique frame pointer tag can be derived from the stack pointer special tag, and the frame pointer can be tagged with its own unique frame pointer tag. In such an embodiment, the frame pointer tag may be created from a tagged copy (e.g., add or zero) of the stack pointer.

When a new stack frame is allocated, for example for a new invocation of a routine or procedure, the memory cells of the newly allocated stack frame are used, for example, in a first technique called strict object initialization, or slow object colorization ( may be tagged or colored using a second technique, which may be referred to as lazy object coloring.

Using the first technique of strict object initialization, all free stack frame cells of a newly allocated frame are initially colored or tagged with one or more colors, eg based on the static objects in the frame. This initial colorization may be performed, for example, as part of the initialization process of the newly allocated frame prior to later using the frame to store information about the associated call. Embodiments may add code that triggers rules that perform colorization or tagging of free stack frame cells to one or more intended colors, e.g., based on static objects in the frame. Code tags on instructions can be used to authorize and define the associated memory cell colorization. Subsequent store or read of a frame's colored memory cell may or may not be allowed based on the frame memory cell color, e.g., according to memory safety policy rules (e.g., for memory cells tagged with color C1, the rule is Again, using a pointer with a tag of the same color C1 allows memory operations to access colored memory cell contents, but may not allow memory operations if the pointer is a different color C2). Code tags on instructions can also provide authorization to perform memory operations within a procedure.

With the second technique of slow object colorization, there is no initial colorization of all stack objects as with the strict object initialization technique. Rather, using slow object colorization, a store to a stack memory location tagged as a free stack frame results in triggering a rule that allows the store and also changes the color of the memory location based on the writer. . Reads to stack memory locations that are tagged as free stack frames are uninitialized memory reads and may or may not be allowed depending on whether the policy allows/disallows uninitialized memory reads. When using slow object colorization, the initial block of code that calls the rule that initially globally tags all memory cells in a frame upon creation is not executed. Rather, memory cells are tagged by rules that are invoked in conjunction with store operations.

In at least one embodiment, whether to use strict object initialization or slow object colorization may depend on the desired level of protection and the occurrence of undefendable vulnerabilities.

Code within a routine or procedure that directly accesses data from the stack/frame pointer is code tagged and allowed to do so. Regarding slow object colorization, storing in a memory cell results in colorization of the memory cell based on the writer as described above. For example, referring back to example 530, the store instruction of routine foo with frame 531 may write a value to a memory location in array 532. Indeed, depending on the current stack protection policy, a store instruction may need to have a tag of Red1 in order for it to write to a location in the array 532 of call frames for foo. A first rule in the policy can be triggered to perform this check on the store command. Thus, an embodiment may cause the compiler to trigger the re-1 rule to generate a code sequence that tags a store instruction as Red1. (For example, as a variation on the foregoing, a tag on a memory cell such as Red1 may be related to, but not identical to, a tag on an instruction store or other instruction. For example, a "Red1code" CI tag may refer to this tag as Indicates that an instruction with can access a Red1 tagged memory cell and can create a Red1 tagged memory cell When a store instruction is the current instruction, the above limitation of checking the instruction tag to ensure that the instruction is Red1 is 1 rule can be triggered As an output, the rule can tag a memory location in the array 532 with a Red1 tag.

Code within a procedure that creates a pointer to a particular object tags a taint or sets a pointer to that object. The pointer may be for the procedure's own use in a subsequent instruction and/or passed as an argument to another procedure.

Saving a register value to a frame or restoring a register value from a frame may be based on frame authorization. The memory location(s) of a stack frame that store register values can be treated as unique objects in the stack frame. Instruction tagging provides authorization for those tagged store and load instructions. Using slow object colorization, a store instruction tagged with an authorization to store data in a memory cell also provides an authorization to tag the memory cell based on the writer (eg, a procedure involving the store instruction).

Procedure arguments passed on the stack can be marked with tags that make them accessible to both callers and callees. It should be noted that the return address may be specially tagged (eg, the dynamic CFI return policy described herein with respect to, for example, FIG. 46). Thus, if the return address is stored on the stack (e.g., in the context of nested calls or recursive calls), the tagging of the return address will not allow the store to overwrite the return address on the stack. . When a stack-derived pointer is passed to another frame in conjunction with a call to another procedure, memory accesses performed using the pointer obey the rules of the memory safety policy as described elsewhere in this specification. results in a trigger. An instruction that created a pointer to a memory location may be tagged based on the tag of the particular memory location. A command tag may indicate authorization to access a memory location. Instructions can trigger rules that tag pointers to indicate authorization to access memory locations. For example, a rule may assign a pointer the same tag as a command or a variant based on a command tag. Thus, in one aspect, the instruction that created the pointer also creates the ability to access a memory location through the pointer and shares that functionality through the pointer passed as an argument to the called procedure. Using slow object colorization, the pointer would have to have a tag giving permission to tag the free stack frame cell, which may not be acceptable for heap-memory safe pointers.

On return or other operation that results in removing the frame from the stack (e.g., due to completion of a called routine), the tagged code may clear the frame. A tag on this code provides permission to change all frame object tags associated with this frame to free stack frame cell tags.

Code of a program executed in an embodiment of a computer system according to the descriptions herein may include code for performing exception handling. As is known in the art, exception handling is processing performed in response to an exception indicating the occurrence of an exceptional or exceptional condition requiring special processing performed by an exception handler. Thus, when an exception occurs at the first point in the program, the normal flow of program execution is interrupted and control is transferred to the exception handler. Prior to transferring control to the handler, the current execution state may be stored in a predetermined location. If program execution can be resumed after the exception is handled by the handler, then execution of the program can be resumed (eg, then control can be transferred back to after the first point in the program). For example, a divide-by-zero operation may result in an exception from which program execution can resume after the handler handles the exception. Regarding implementing the exception handler, embodiments may use library routines such as setjump and longjump. For example, setjump and longjump can be standard C library routines setjmp and longjmp respectively defined as follows.

Here setjmp sets up the local jmp_buf buffer and initializes it for the jump. setjmp stores the program's calling environment in the environment buffer specified by the env argument for later use by longjmp. If the return is from a direct call, setjmp returns 0. If the return is from call to longjmp, setjmp returns a non-zero value.

Here longjmp restores the context of the environment buffer env saved by a call to the setjmp routine in the same invocation of the program. Calling longjmp from a nested signal handler is undefined. The value designated as value is passed from longjmp to setjmp. After longjmp completes, program execution continues as if the corresponding call to setjmp had just returned. If the value passed to longjmp is 0, setjmp will act as if it returned 1; Otherwise it will behave as if it returned a value.

So setjmp can be used to save the current state of the program. The state of a program depends, for example, on the contents of memory (ie code, global, heap and stack) and the contents of its registers. The contents of the registers include the stack pointer, frame pointer and program counter. setjmp saves the current state of the program so that longmp can restore the program state, so it returns the running state of the program as it was when setjmp was called. In other words, longjmp() does not return. Rather, when longjmp is called, execution returns or resumes to a particular point indicated by the previously saved program state (as saved by setjmp). Thus, rather than using standard call or return conventions, longjmp() can be used to transfer control from a signal handler back to a stored execution point in the program.

See, for example, FIG. 50 . In example 560, routine main can call routine first 563, and routine first 563 can call routine second 564. As shown, main 562 may include a call to setjmp at point X1 before calling routine first. First setjmp is called at point X1, returns 0 then routine first is called. After longjmp runs, setjmp returns 1. Routine second 564 includes a call to longjmp at point X2 which causes control to transfer to main at location X1 where setjmp was called. Now that setjmp is called again and returns 1, first is not called and control goes to NEXT.

Regarding the stack protection policy, it may be desirable to clear the stack before resuming execution to the point X1 previously saved by settmp. For example, based on the call chain main-first-second above, 3 stack frames could exist in the call stack and in the call chain between the longjmp call and the setjmp call, a process to clear the stack memory associated with the call could be performed. there is. In particular, longjmp's code may include code to clear the stack frames for first (563) and second (564) in this example. Techniques that may be used in connection with performing these stack clearing operations according to a stack protection policy will now be described.

Regarding the stack protection policy when performing a setjmp which saves the program state to stack memory, embodiments tag the current stack pointer memory cell with an identified tag component so that, with respect to subsequent longjmps, the stack has not changed since setjmp. Allow the rule to check that it is not. Data can be stored in a setjmp data structure, jmpbuf, which represents the current program state. The stored data includes a stack pointer, a program counter, a first pointer (tagged as a pointer allowed to point to a memory location tagged with a distinct tagged component (e.g., pointing to the current stack pointer memory cell)) and a second pointer ( tagged as longjmp-clearing-authority-pointer, which provides authorization to perform longjmp processing). In at least one embodiment, the longjmp-clearing-authority-pointer may provide only authorization to clear a tag associated with a frame in a set of procedures that may be called recursively in this procedure.

Regarding the stack protection policy when performing a longjmp, the code can check that the current stack pointer points to a stack location deeper than the stored stack pointer of the set jump structure (e.g., the setjmp data structure, jmpbuf). A rule may be triggered that checks that the memory cell of the set jump structure containing the stored stack pointer (as stored by the set jump) has a tag compatible with the tagged first pointer (of the set jump structure). Code can be executed that clears all stack memory locations between the current stack pointer and the stored stack pointer (from the set jump structure to the one previously saved by the set jump). Such code can perform the clearing using the above-mentioned second pointer tagged as longjmp-clearing-authority-pointer (e.g., the second pointer used to point to the cleared location) that provides the stack clearing authorization. there is. A rule can be triggered by code that performs clearing, in which case the rule checks whether the second pointer is tagged as a longjmp-clearing-authority-pointer. Instructions in longjmp are uniquely tagged so that invoked rules allow uniquely tagged instructions to use a pointer tagged as longjmp-clearing-authority-pointer. Other code not in longjmp cannot use a pointer tagged as longjmp-clearing-authority-pointer (eg, other code is not tagged to allow use of longjmp-clearing-authority-pointer).

In at least one embodiment, tagging of instructions may be performed by causing a compiler to generate a sequence of instructions that invoke rules to perform the desired instruction tagging and/or memory location tagging. For example, in the case of stack memory location tagging, the compiler can generate an instruction sequence with a store instruction that triggers a rule that initializes or resets the tag of the stack location. For tagging instructions, the compiler can generate an instruction sequence with a store instruction that triggers a rule for tagging instructions, where the tag for the instruction can be based on a color associated with a tagged memory location accessed by the instruction. Upon return from a call that has an associated stack frame, code may be added to clear the frame from the stack. When strict object initialization is used and a new frame created in response to a call is created, code can be added to properly tag or color the objects in the new frame.

Referring now to FIGS. 51-53 , different unauthorized or unintentional modifications that may be made to the stack, such as, for example, by malicious code (e.g., referring to an attack via stack modification) Examples of "stack attacks") or unintentional stack modification by non-malicious code (eg, accidental overwriting or buffer overflow) will be described.

51-52 show stack attacks in relation to stack modifications made by code modules such as third party code (e.g., called library routines) that can be taken to prevent stack attacks and can be characterized as an arbitrary attacker model. show action Thus, instances of 570 and 575 may occur, for example, as a result of a third party library routine being called that contains code that performs unauthorized or unintended stack modifications. Stack modifications may also be made by another routine that is further called by the code of the called library routine. Each line of 570 and 575 contains three information streams. In each line 572a through 572h, column 1 identifies an item that prevents exhibiting undesirable runtime execution behavior, column 2 identifies preventive actions that can be taken to avoid the undesired behavior of column 1, and 3 identifies one or more mechanisms that can be used to implement or enforce the preventive measures in column 2. In general, in column 3, alternative mechanisms are listed that can be implemented independently and separately depending on the particular system. For example, a conventional system may use a separate process as a first mechanism, while a second system may alternatively use capabilities, and a second system may optionally use coloring or tagging of specific stack locations. there is.

For further explanation, consistent with discussion elsewhere herein, code such as prolog code that is executed when the call is made writes the return address and register to the stack. Prologue code can tag stack locations with special tags so that code can modify stack locations or invoke rules that generally restrict access to stack locations. For example, the prolog code can perform a memory write/store to store return addresses, registers, etc. in the memory cells of the stack frame. These write/store instructions in the prolog code may invoke a rule to tag the memory cells of the stack frame with a special tag, STACK FRAME TAG, to mark the memory location as special and to limit what code can modify the memory cells. Write/store instructions in the prolog code can also be tagged with the PROLOG STACK TAG tag, which limits the instructions that can perform such tagging. The following is enforced by the rules invoked by the write/store instructions in the prologue code that specifically mark memory locations by tagging the memory cells of the stack frame with a special tag, STACK FRAME TA, and restrict the code from being able to modify the memory cells. Here is an example of the logic to be:

In the rule logic described above, an output tag refers to a tag placed in a stack location.

In a similar manner, other code, such as epilogue code that is called while performing a return, may be allowed to clear the stack or part thereof. The epilog code can be tagged with a special tag called EPILOG STACK TAG (eg, CI tag), and can be authorized through access of a pointer tagged with the special tag STACK FRAME TAG. The epilog code can perform the aforementioned stack clearing operations using write/store operations using a pointer specially tagged with the STACK FRAME TAG. To further constrain performing stack clearing, the epilog code can be tagged as mentioned above. In this embodiment, the write/store instructions use a specially tagged pointer (tagged with STACK FRAME TAG) to invoke a rule implementing the following logic to enforce the policy that stack clearing can only be performed by the epilog code: can do:

Code intended to restore registers and return addresses from the stack may be given permission to read these specially tagged memory cells of the stack. Such authorizations include, for example: tagging code to indicate that the code is allowed to access specially tagged memory cells in the stack (CI tags), tagging the PC to indicate that the code has authorizations or tagging a pointer where the pointer points to a specially tagged memory cell and the tag on the pointer is used by code indicating an access authorization: for example, a read/load instruction Authorization to read stack memory cells tagged with STACK FRAME TAG can be granted. In one embodiment, a read/load command may be authorized to read from a stack memory location by allowing only read/load commands using a specially tagged pointer (tagged with STACK FRAME TAG). The rule logic to read from a specially tagged stack memory location (tagged with STACK FRAME TAG) allowing only read/load instructions using a specially tagged pointer (tagged with STACK FRAME POINTER) could be:

As a variation of the foregoing, a read/load command may be authorized by tagging the pointer used by the read/load command with the special tag STACK FRAME TAG.

The rule logic to read from a stack memory location allowing only read/load instructions using specially tagged instructions (tagged with STACK FRAME INSTRUCTION) could be:

Examples of mechanisms are described in more detail below and elsewhere.

Element 572a identifies an undesirable runtime behavior of the called routine (callee) never returning to the calling routine (caller). To prevent this behavior, a measure taken is to have a time limit associated with each call, in which case the maximum amount of time can be allowed to complete the called routine. After the maximum amount of time has elapsed, runtime execution of the called routine is terminated. Mechanisms for implementing timeouts include either having the called routine in third-party code come from a separate thread enforcing the timeout, or directly limiting the amount of time the called routine uses time- or instruction-bound calls. can include

Element 572b identifies an undesirable runtime behavior of resource exhaustion where the called routine may consume available resources such as memory. To prevent this behavior, the action taken may be to limit the resources made available to the called routine. Mechanisms for implementing timeouts may include having a called routine in third-party code run on a separate thread that enforces a maximum resource limit, or using special instruction-restricted calls to directly limit the amount of resources in a called routine. can include

Element 572c identifies undesirable runtime behavior of a called routine exercising an unexpected authorization, such as by making an expected call to another routine. To prevent this behavior, the action taken may be to limit the authorization of the called routine to the minimum acceptable authorization. Mechanisms to implement this include tagging the PC with the authorization and control capabilities of the callee or called routine, limiting the parts of the file system or other resources accessible to the called routine, and restricting what the called routine can do. This can include limiting what systems are allowed to call.

Element 572d identifies undesirable runtime behavior of the called routine reading items left in registers by other routines subsequently called by the called routine (e.g., mycode calls P1 from the library and P1 calls the routine maliciously, and P1 can read the data left in the register by malicious intent). To prevent this behavior, steps can be taken to clear non-input and non-return registers. Mechanisms to implement this include performing explicit register clears, colorizing parts of the stack, including registers with no returns and no inputs, so that they cannot be read by the called routine, and having a separate process call the called routine. may include doing

Element 572e identifies undesirable runtime behavior of the called routine reading items left on the stack by other routines subsequently called by the called routine (e.g., mycode calls P1 in the library and P1 calls the routine maliciously, and P1 can read the data left on the stack by malicious intent). To prevent this behavior, measures can be taken to make the called stack inaccessible (e.g. the stack area used by other routines called further, such as malicious access to the first called routine, such as P1). impossible). Mechanisms to implement this include using separate stacks (e.g. for the first called routine P1 and additionally called routines), capabilities (e.g. tagging the PC, or allowing access to special stack areas). Restricting the ability or authorization of code allowed to read areas of the stack using specially tagged pointers that have been tagged), colorization (for example, restricting what code can access by tagging data areas of the stack) , and having a separate process call the called routine.

Element 572f identifies undesirable runtime behavior of a called routine that writes over items in the stack prefix (e.g., overwrites the return address area identifying the return address). . A stack prefix can be an area of the stack that contains information needed to return to some previous caller. To prevent this behavior, the action taken is to make the stack prefix inaccessible or writeable to the called routine. Mechanisms to implement this include having the called routine and the user code calling the called routine use separate stacks, using capabilities (e.g. special tagged code or PC tags or specially tagged pointers). using colorization (e.g., tagging data items with stack prefixes with special tags so that called routines cannot access them), and using separate This can include having the process call the called routine.

Element 572g identifies undesirable runtime behavior of the called routine that reads data from the stack prefix. To prevent this behavior, the action taken is to make the stack prefix inaccessible to the called routine using a mechanism similar to that described in 572f.

Element 572h identifies undesirable runtime behavior of a called routine that redirects control flow from the stack prefix, such as by overwriting the pointer to the return address stored in the stack prefix. To prevent this behavior, measures can be taken to protect the return address stored in the stack prefix. In one aspect, the mechanism of 572h is similar to that of 572f since element 572h identifies a particular instance of 572h. Mechanisms to implement this include having the called routine and the user code calling the called routine use separate stacks, using capabilities (e.g. tagging by special tagged code or PC tag or access authorization). using colorization (e.g., a memory location on the stack prefix that contains the return address so that the called routine cannot access it); with a special tag), and having a separate process call the called routine.

Fig. 53 illustrates actions that can be taken to prevent stack attacks in the context of an arbitrary input attacker model.

Element 581a identifies undesirable runtime behavior of executing code that rewrites unintended items within the current frame of an executing routine. To prevent this behavior, the action taken may be to maintain object integrity. Mechanisms to implement this can be accessed (e.g., through a capability with specially tagged code or through a capability with code provided authorization via a PC tag or via a specially tagged return pointer tagged by an access authorization). This may include using a capability by the object (e.g., tagging an object's memory location) or using a color by the object (e.g., tagging an object's memory location).

Element 581b identifies undesirable runtime behavior of reading items in the current frame of an executing routine. To prevent this behavior, the action taken may be to maintain object integrity. Mechanisms to implement this can be accessed (e.g., capabilities with specially tagged code or capabilities with code provided authorization via a PC tag or via a specially tagged return pointer tagged by an access authorization). This may include using a capability by an object) or using a color by an object (eg, tagging an object's memory address with an object specific tag).

Element 581c identifies an undesired runtime behavior of executing code (with the current frame) rewriting an unintended item in a preceding frame (eg, of another routine that called the executable code). To prevent this behavior, measures taken may be to isolate or isolate the stack frame. Mechanisms to implement this can be accessed (e.g., capabilities with specially tagged code or capabilities with code provided authorization via a PC tag or via a specially tagged return pointer tagged by an access authorization). This may include using a frame-by-frame capability) or using a frame-by-color (e.g., tagging an object's memory location).

Element 581d identifies undesirable runtime behavior of executing code (with the current frame) reading an item from a preceding frame (eg, of another routine that called the executable code). To prevent this behavior, measures taken may be to isolate or isolate the stack frame. Mechanisms to implement this may include using per-frame capabilities or per-frame colors as described in element 581c.

Element 581e identifies undesirable runtime behavior of executing code (with the current frame) reading remaining items on the stack by other routines called by the currently executing code. A precautionary measure is to make the called stack of the called routine inaccessible to currently executing code. Mechanisms to implement this may include using separate processes, separate stacks, capabilities, and colorizations in a manner similar to that described with respect to (572g).

Element 581f identifies undesirable runtime behavior of executing code (with the current frame) that modifies the return pointer (eg, the location in the stack that contains the return address within the routine that called the executable code). A precautionary measure is to protect the return pointer or location in the stack, including the return pointer. A mechanism to implement this may include using capabilities and colorization in a manner similar to that described with respect to (572g).

Embodiments consistent with the techniques herein may use the PUMP rule metadata processing system as part of another hybrid system to learn and validate new rule sets. For example, the PUMP rule metadata processing system can be used to learn allowed control flows (eg, via logging) and determine the rules for an executing program and effective control transfers allowed accordingly. The rules and allowed effective control transfers may then be used as the effective control transfer rules and their set of enforced CFI policies for the executed program.

Further describing learning rules and transfer of control for the program's CFI policy, a first training or learning step may be performed. In this first step, the program is executed using a training version of the CFI policy that has no rules for all tagged control points (eg branch or transfer of source and target) and control transfer instructions. Thus, whenever there is a transfer of control, such as a branch or jump instruction, there is a PUMP rules cache miss that causes control to transfer to the cache miss handler in the PUMP rules metadata system. The cache miss handler can perform processing to log information about the control transfer. Logged information may include, for example, a previous source location and a previous target location. Other information may also include, for example, the calling procedure or routine to which the transfer was made (eg, including the source location) and the called procedure or routine to which control was transferred (eg, including the target location). can More specifically, in the learning or training phase, the first time a particular control transfer occurs, the cache miss handler computes a new rule in the learned rule set for the particular control transfer from the source to the target. Subsequent run-time transfers of control from the same source to the same target use this calculated rule. In this way, if a program is assumed to be bug-free and a non-attacking program (not malicious code) and all control paths are executed while the program is running, the logged set of control transfers is the set of learned rules set at the end of program execution. As indicated by , indicates all valid or permissible transfers of control to this particular program. Thus, the learned rule set may represent the initial or first rule set of the CFI policy for the program.

A process may be performed to verify the learned rule set representing the CFI policy for the program. Verification may include ensuring that none of these rules allow for an invalid control transfer. Verification of the learned rule set may be performed in any suitable manner. For example, an embodiment may run an analysis tool that validates each rule. The tool verifies that each rule corresponds to the allowed transfer by examining, for example, binary or object code, symbol tables, and original source code. Further clarification, validation may check that the binary code with all control points (e.g. branch or transfer of source and target) is tagged. In this way, the tagged binaries or source code represent a valid set of all potential source and target locations, thus providing a set of potential sources and targets that can actually be used at runtime transfer of control. Any run-time transfer of logged control MUST only be made from a source to a target if the source and target are each included in a valid set. For example, the tagged binary or source code may contain locations A1, A2, A3 and A4. Any logged transfer of control must include the source of A1, A2, A3 or A4 and the target of A1, A2, A3 or A4. If the logged run-time control transfer indicated by rule 1 is from A1 to B7, since B7 should not be the target of the control transfer (e.g. B7 is statically tagged as A1, A2 A3 and A4 consistently) The first rule may not be valid because it is not included in the determined set of possible control points). In one aspect, a learned rule set can be characterized as a candidate rule set that can be further reduced through rule elimination as a result of validation processing.

Any rules in the learned set or the initial set of rules required by the CFI policy for a validated program may be used as the validated rule set included in the enforced CFI policy for the program.

Referring to FIG. 54 , an example is shown summarizing the just-described processing that may be performed by embodiments in accordance with the techniques herein for learning, validating, and using policy rules. At 602, the program can initially run without any CFI policy rules, so that each new transfer of control will cause a rule cache miss and trigger a cache miss handler to find new rules for control transfers encountered at runtime. to create A new rule may identify transfer of control from the source and target and may be included in the first set of learned rules 604 . At the end of program execution, the first set of learned rules 604 includes rules for each of the different control transfers generated at runtime. The second set of learned rules can then be verified in the process of 606 to ensure that each rule represents a valid control transfer. The processing of 606 may use tools such as those described above for automated rule validation, and may also include other processing. For example, the validation process of 606 may include presenting to the user the rules that have been validated by the tool for further confirmation that the transfer of control is valid. A second set of validation rules 608 may be created as a result of rule validation processing 606 . As a result, the second set of validated rules 608 can be used by the PUMP system as the CFI policy enforced when running the program at a second point in time 610 .

Thus, as discussed above, the first program execution at 602 can be used to determine a valid set of transfers of control for the program. However, it may not be reasonable to assume that this single program execution executes all control paths, and thus the control transfer identified at 608 may appear less than all possible valid control transfers. In this case, processing as described above with respect to 610 may be performed using the proven CFI policy rule set. During runtime, if a control transfer occurs that results in a rule cache miss (e.g., indicating an unexpected control transfer with no rules at 608), at runtime, e.g., the binary code An additional check can be performed verifying the transfer of control as described above (using a set of possible control points tagged with or annotated in the source program). If the transfer of control is determined to be invalid, a fault or exception may be triggered.

Alternatively, if a control transfer causes a rule cache miss, thereby indicating an unexpected run-time control transfer, the cache miss handler may log the unexpected transfer rule for later validation and may also indicate that the unexpected transfer of control is in effect. It can be continued with additional or different policies. For example, if the control transfer is invalid, the transfer can be considered untrusted, so the policy can be modified to reflect a higher level of protection due to the untrusted nature of the invalid control transfer. For example, an unexpected transfer could transfer control to a library routine. Library routines can be executed using policies that reflect a higher level of protection and less trust than those in force prior to unexpected transfers. If control transfer is proven, the first stack protection policy may be in effect at a first point in time prior to the unexpected control transfer and the second stack protection policy may be in effect after the unexpected control transfer. The first stack protection policy may enforce static procedure authorization. The first protection policy may not include any colorization at the object level as described elsewhere herein with the object protection model. After an unexpected control transfer, the second stack protection policy in effect may provide stack protection according to the object protection model described elsewhere herein with strict object colorization. Thus, when an unexpected transfer of control occurs, the executing code can use the more restrictive second stack protection policy, which provides a stricter and finer level of granularity of stack protection. Additionally, once an unexpected transfer of control occurs, program execution may continue with a lowered priority.

55 and 56, flow diagrams 620 and 630 of processing steps that may be performed in embodiments according to the techniques herein using an effective rule set, such as the rules of the CFI Policy for Programs described above. ) is shown. Flow diagram 620 describes a first set of processing steps that may be performed in connection with an unexpected transfer of control that does not have a rule in an executable program's CFI policy. Flow diagram 631 describes a second set of processing steps that may be performed in connection with unexpected control transfers that do not have rules in the CFI policy of the executable program.

Referring to flowchart 620, at step 622, the program may be executed using a set of validated rules. At step 624 during program execution, a runtime transfer of control is performed. At step 626, it is determined if there are rule cache misses indicating that the transfer was unexpected. In particular, if a rule exists in the second set of asserted rules for run-time transfer of control, control transfer is expected, in which case step 626 evaluates to no, and processing continues to step 628, where A transfer of control is performed at , and the program continues to run.

If step 626 evaluates to yes (eg, cache miss indicating unexpected control transfer), then processing continues to step 632 where runtime verification processing is performed for the unexpected control transfer. In particular, the miss handler can perform processing that attempts to prove an unexpected transfer. An example of a rule validation process is determining if the runtime source and target locations are included in the aforementioned set of potential control transfer points that can be determined using tagged binary code, the original source program and symbol tables, etc. can include At step 634, the attestation process of step 632 determines whether the unexpected transfer of control is valid. If step 634 evaluates to yes, processing continues to step 636 where the new rule is added to the second set to be used as the CFI policy for the program and processing of the program continues. If step 634 evaluates to no, program execution may be terminated, for example by triggering a trap.

Referring to flowchart 631 , steps 622 , 624 , 626 and 628 are as described with respect to flowchart 620 . If step 626 evaluates to yes, control proceeds to step 639 where the unexpected control transfer can be recorded (eg, the candidate rule for the unexpected control transfer is recorded). At step 639, the program may continue execution even when the transfer of control is unexpected. However, at step 639, program execution continues using, for example, one or more restrictive policy sets, reduced execution priority, etc., as noted above.

As noted above, the processing described above may similarly be performed with respect to other policies such as taint tracking. For example, for taint tracking, a first learning or training step can be executed to have a cache miss handler "log" each cache miss, thereby learning the rules of the policy through program execution. As described herein, taint tracking can include tagging data based on code that creates or accesses it (eg, using CIs described elsewhere herein). One reason to taint data based on code or source is to ensure that the program is properly embedded and does not perform unwanted or improper data accesses. For example, a rule could be used to ensure that data tainted by a JPEG decoder never enters a password database, or to ensure that credit card data, social security numbers, or other personal information is only accessed by a specific set of one or more restricted applications. there is. When determining the taint tracking policy, cache handler misses the first time the cache handler sees a particular data flow (e.g., which routine in a program routine accesses which data, which user input is written to which database, etc.). Processing for the learning or training phase can be performed without executing taint tracking rules on the test data that triggers and writes the rules. In a manner similar to that described above for CFI policies, at the end of the first learning phase test run, there is a set of learned rules that are applied to protect the program during operation. Attestation processing of learned rule sets may be performed using the tools mentioned above for CFI learned rule sets or other suitable means. Such attestation processing for taint tracking may include ensuring that each data flow or access is appropriate.

Also, in a manner similar to that described with respect to flowcharts 620 and 631, an asserted rule set can be created with the PUMP system handling the handling of any data access for which a cache miss handler does not have a corresponding rule in the asserted set. can be used Similar to the processing of flow diagram 620, the cache miss handler then also performs runtime validation processing (e.g., similar to step 632) to determine if the candidate rule for the data access or data flow is valid. and program execution may continue (similar to steps 634 and 636) or not continue (similar to step 638, for example). Alternatively, similar to the processing of flow diagram 631, the cache miss handler records candidate rules for unexpected data accesses or data flows that may be proven offline (e.g., not during runtime), and yes Program execution may continue (e.g., similar to step 639) using a more restrictive policy, lowered priority, etc.

The example above describes the binary learning process in general. Embodiments consistent with techniques herein may further support the use of statistics when making decisions about whether to allow an event (eg, control transfer or data access). In at least one embodiment, a counter may be added to each rule to count the number of uses of each rule during program execution. When rules are evicted from the PUMP cache, processing may add accumulated rule usage to a global software count that can be used to provide additional statistics about rule usage. Coefficients can also be used to cause something to occur a limited number of times. For example, with respect to a tain tracking rule that tracks the flow of data from a source to a target, a limited threshold amount of data (e.g., read from a specific database by a specific program) X amount of data) may be acceptable. Once that threshold amount has been transferred, no further data may be transferred between the source and target until the corresponding candidate rule has been successfully validated. When a limited use case has a threshold amount, the PUMP system (e.g., a miss handler) allows an instruction without rules to occur a slightly limited number of times. The aggregation or counting applied to the threshold may be performed in other ways. For example, consider an unexpected transfer of control. If not aggregated, the cache miss handler may not allow the same unexpected control transfer to occur more than 5 times for which the rule is not validated. For example, a program may allow up to 100 unexpected control transfers, if aggregated over all unexpected transfers of control for a program. This can be useful, for example, for cases where unexpected transfers of control or unexpected data access may be allowed in a single instance to occur. For example, a single query that examines data from a particular source may be acceptable. However, if more than a threshold number of queries are performed for a data source (eg, a specific database), the program must be flagged or stopped.

More general statistical cases can be used to learn the range of normal behavior. For example, the program can be run in a learning phase to determine the relative usage of the different rules of the policy (eg, the percentage usage of each rule). For example, the relative use of each rule invoked for run-time control transfer can be recorded. Ideally, such runs can be performed on programs using many different data sets to learn what can be considered average or normal program behavior. Rule learning and validation can then produce a set of rules for a proven control transfer (as described above) and additionally a percentage representing the relative usage of each proven rule. Both the proven rule and the associated usage rate can be used as enforced policy rules during subsequent processing. When the policy is enforced during subsequent program execution, the PUMP system can check that the current rule usage does not match the expected rate. Embodiments may include, for example, a maximum expected use or range of rules whereby a control transfer invoking a rule that exceeds the maximum may be flagged. For example, programs that call certain control transfer rules that exceed the maximum may be flagged for further inspection or analysis. Using these mechanisms, program runtime behavior can be monitored to create firewall rules, similar to how network behavior is monitored. Statistical learning algorithms can be used to learn normal case versus attack behavior by capturing rule usage and possibly other standard runtime characteristics such as main memory traffic and cache miss rate. In an embodiment that applies a limited-use threshold as described above, if a program exhibits unusual run-time behavior or otherwise could be considered unreliable, the usage limit may be greatly reduced or otherwise set to zero. Alternatively, if the program exhibits normal runtime behavior or can otherwise be considered trusted, the usage limit can be set or increased much higher than in untrusted scenarios.

The above technique can be used to determine the effective rule set of a policy, such as the effective control transfers reflected in the rules of a CFI policy, without the compiler outputting any additional information. Thus, embodiments in accordance with the techniques herein may have two versions of each policy, one used for the learning phase and the other used for subsequent enforcement. The learning phase can be used in an autodiagnostic mode to discover allowable data accesses or flows for taint tracking, transfer of control for CFI policies, and so on.

Examples of architectures that may be used in embodiments according to the techniques herein using a RISC-V processor will now be described. Also described below are techniques that may be used in connection with performing a processor-based mediated data transfer between an untagged data source and a tagged data source used by a processor. . These technologies tag external, untrusted data that the processor may bring into the system for use, and also remove tags from tagged data used within the system to make untagged data available for use outside the system. do.

Referring to FIG. 57 , an example of a component that may be used in an embodiment consistent with the techniques herein for mediating tagged and untagged data is shown. Example 700 is a RISC-V CPU 702, PUMP 704, L1 data cache 706, L1 instruction cache 708, interconnect fabric 710 used internally within the system for tagged data transfer. , a boot ROM 712a, a DRAM controller (ctrl) 712b, and an external DRAM 712c for storing tagged data. In addition, an additional tag 714a and a validate drop tag 714b, which are hardware components, transfer external untagged data from the untagged memory 716 for use by the processor 702 and Interconnect fabric 715 used to transfer untagged data to untagged memory 716 is included. It should be noted that other sources 701 of external untagged data, other than untagged memory 716 , may be coupled to untagged fabric 715 . For example, element 701 may include untagged data stored in flash memory, untagged data accessible from a network, and the like. A DRAM controller (ctrl) 712b is a controller used to read data from the DRAM 712c and write data to the DRAM 712c. The boot ROM 712a may include boot code used to boot the system.

Example 700 shows a separate tagged fabric 710 and an untagged fabric between which a processor 702 is used to move data. Additional tag 714a accepts untagged data as input and indicates that this data is public (which may be used outside the system described herein) and (source may be unknown or is otherwise known from a trusted source). tag the data with a tag that indicates unreliability (because it is not In at least one embodiment, untagged data in untagged memory 716 may be received by 714a. Untagged data received from 716 may be encrypted so that additional tag 714a may attach an untrusted tag to the received encrypted data. The received data may be encrypted using asymmetric encryption, such as public key encryption using a public-private key pair or other suitable encryption techniques known in the art. Received data may be stored in encrypted form. As is known in the art, for an owner's public-private key pair, the private key is only released to the owner while the public key is made public and is used by others. A third party can use the owner's public key to encrypt information sent to the owner. The owner can then use his private key (which he does not share with anyone else) to decrypt the received encrypted information. In a similar manner, the owner can encrypt information using his/her private key, and the encrypted information is transmitted to a third party who uses the owner's public key to decrypt the encrypted information.

Validate drop tag 714b may receive the tagged encrypted data and remove the tag to produce untagged encrypted data that is exported to untagged memory 716 . Such untagged encrypted data stored in memory 716 can be stored in other systems and processors that do not use tags and do not use the associated metadata rule processing, for example, as done using PUMP as described herein. can be used

In at least one embodiment, the untagged data received at 714a may be encrypted as noted above and may also be signed to provide integrity of the data. In addition, signatures can be used to verify received data items (e.g., to ensure that the original sender that signed them has not been modified since sending them, and that the data was sent by the sender signing the data) for authentication and data integrity. can guarantee For example, an owner can hash a message to create a hash value or "digest" and then encrypt the digest with the owner's private key to create a digital signature. Owners can send messages and signatures to third parties. Third parties can use signatures to verify received data. First, the third party can use the owner's public key to decrypt the message. A signature can be verified by computing a hash or digest of the decrypted message, decrypting the signature with the owner's/signer's public key to obtain the expected digest or hash, and comparing the computed digest to the decrypted expected digest or hash. there is. A matching digest verifies that the message the owner signed has not been modified.

In operation, an instruction, such as a load instruction, may reference data stored in untagged memory 716, which is then passed to data cache 706 for use in instruction execution. For this load instruction, data may be passed from 716 through 715 for processing by 714a outputting the tagged data (tagged as untrusted and public). The tagged data output by 714a is stored in the L1 data cache 706 for processing. In a similar manner, a store instruction may store data from data cache 706 to a location within untagged memory 716 . For this store instruction, data can be passed from 706 through 710 to validating drop tag 714b which outputs untagged data.

Code may run on processor 702 to retrieve untagged data from 716 into the system and store it on, for example, DRAM 712c. The logic of the code to fetch untagged data can be represented as follows:

1. The tagged data output by the add-on tag 714a may be stored in an untrusted buffer (tagged as public, untrusted).

2. The tagged data stored in the unreliable buffer is decoded and stored in the decode buffer. Thus, the decode buffer contains decrypted data that is tagged as public and untrustworthy.

3. Perform validation processing to ensure that the decode buffer contains valid and uncorrupted data. This attestation process may use digital signatures as described elsewhere herein and known in the art.

4. If the decode buffer contains attestation data, the second part of the trusted code may be executed to convert the data in the decode buffer that is tagged as public and untrusted to data that is tagged as trusted. A trusted piece of code may contain one or more instructions that, when executed, invoke a rule to re-tag the data in the decode buffer as trusted, public. Re-tagged data now tagged as trusted, public may be stored in a trusted buffer located in external DRAM 712c.

Trusted code may contain memory instructions tagged with special instruction tags that, when executed, give authority to invoke rules that re-tag referenced memory locations. For example, trusted code could include special tag store instructions that store data tagged as public, untrusted (in an untrusted buffer) with a new tag as public, trusted, in a destination memory location (trusted buffer). there is. The aforementioned store of trust command may be specially tagged by the loader, for example.

We can represent the logic of the trusted code to re-tag data from public, untrusted to public, trusted as follows:

*

where N is the length of the unreliable buffer and temp is the temporary buffer used to perform re-tagging. The first command, temp = *untrusted buffer [i], may generate a load command that loads the first element of the untrusted buffer from the untagged memory 716 into a temporary buffer. The second command, trusted buffer [i] = temp, may be a store command for storing data tagged as open and unreliable in a temporary buffer into a new tag of open and trusted in a trusted buffer [i]. Thus, the second instruction is a specially tagged instruction as noted above to cause the authorization to re-tag the data from untrusted to trusted.

In a similar manner, when the tagged data in 712c is exported or stored to untagged memory 716 (or any untagged memory source 701), the code encrypts the data item to create a signature. Executed by processor 702, the encrypted data item and signature may be forwarded to 714b, where they are stripped, then transmitted via 715 and stored at 716.

As a variation of example 700, memories 716 and 712c may be unified and also interconnect fabrics 710 and 715 may be unified. In such an embodiment, the address range that untagged memory source 701 is allowed to access may be limited. For example, see example 720 of FIG. 58 . Example 720 includes components similar to those numbered as in 700, with components 714a-714b, 715 and 716 removed and memory 712c storing untrusted, publicly tagged data. The difference is that it includes a portion U 722 representing the area of memory 712c used to Untagged memory sources 701, such as unreliable DMAs and I/O subsystems, may be limited to using the lower 16 or 256 MB of memory 722. In one embodiment, data stored in U 722 cannot be explicitly tagged, rather all data stored in U having an address within this limited range may be implicitly tagged and treated as public and untrustworthy. As a variant, an embodiment may pre-tag portion U 722 with a persistent tag representing untrusted public data and the aforementioned associated persistent metadata tag cannot be modified. A rule may prevent the processor from storing other data to area U 722 . For example, unreliable DMA operations performed by the DMA included in 701 may be limited to writing to area U 722.

Embodiments that must execute unported I/O handling code can run on a dedicated I/O processor on the untrusted side of the component. For example, see example 730 of FIG. 59 . Example 730 includes components similar to those numbered as in 700, with the difference that components 732, 732a and 732b are added. Element 732 is an additional RISC-V processor that runs without PUMP and metadata rule processing. Element 732a represents a data cache for second processor 732 and element 732b represents an instruction cache for second processor 732 . Data cache 732 may be coupled to untagged interconnect fabric 715 .

As described in more detail elsewhere herein, separate I/O PUMPs are untagged data sources (e.g., 701, 716) and tagged memory 712c used by processor 702. It can be used as another alternative mediating between them.

Referring to FIG. 60 , used in connection with the techniques herein to arbitrate between an untagged data source (eg, 701 , 716 ) and a tagged memory 712c used by the processor 702 Other embodiments of components that may be included in the system are shown. Example 740 includes components similar to example 700, with the difference that components 714a-b are removed and replaced with intern 742 and extern 744. In this embodiment, intern 742 and exton 744 may be hardware components that perform the processing described above. In particular, intern 742 may include hardware that processes received untagged data and outputs attested data items that are tagged as reliable, public. Data items that are tagged as trusted and public can be passed to fabric 710 for storage in data cache 706 used by processor 702 in connection with execution of instructions. Interns 742 may include hardware that performs attestation processing of untagged encrypted data and, assuming successful attestation, may further tag received untagged data as trusted, public. Exturn 744 may include hardware that processes tagged unencrypted data and outputs signed encrypted data items. If the signed encrypted data item is to be used by another processor that does not perform metadata rule processing as described herein, Exton may remove the tag prior to encryption.

In the simplest case, the hardware of intern 742 and extern 744 can host a single public-private key set, and signing and encryption are also performed using the single key set. The key set may be encoded in the hardware used by 741 and 744. In yet another variation, the hardware of intern 742 and exton 744 may host multiple sets of public-private keys, and signing and encryption may also be performed using multiple sets of keys, each set with a different public-private key. (including pairs) is performed using one of the Multiple key sets may be encoded in the hardware used by 742 and 744. The clear data included with the incoming untagged data informs the intern unit 742 which set of keys to use. Accordingly, intern 742 can select a desired key set by performing a lookup in a hardware data store (eg, associative memory) containing multiple key sets. Each of multiple sets of keys may be associated with a different tag, and therefore, a particular set of keys indicated by clear data also dictates a particular tag that the tagged data will contain. In this way, the tag of the tagged data item output by 742 indicates that the data item is public and also indicates that the data item was encrypted/decrypted using a particular key set of multiple keys. In embodiments with multiple key sets, exturn 744 can inspect the tags to determine which particular key of the multiple key set is being used in connection with encrypting and signing data items. Thus, the intern unit 742 process requires that portions of the code, such as the trusted code portion discussed above, have the ability to tag data, by providing an isolated hardware component that performs tagging and verifying received untagged data. Let there be no

Referring again to Figures 1 and 24, the input to PUMP 10 at stage 5 includes a tag as described elsewhere herein. If an instruction contains a memory location as an operand of the instruction, acquiring the memory input and associated tag, the MR tag (sometimes referred to herein as Mtag), causes an extra pipeline stall, and thus the stage At 5, PUMP 10 cannot proceed until it has all inputs including MR tags. Rather than waiting to retrieve the actual MR tag value read from memory, an expected or predicted value that can be used to determine the tag value (e.g. destination register or memory location, if any) for the result of an instruction that is an R tag. A process of determining an MR tag can be performed according to the techniques herein. In this embodiment, the final check is the action where the predicted MR tag was retrieved from memory for the instruction's operand. It may be performed in stage 6, writeback or commit stage to determine if it matches the MR tag (see for example element 22 of FIG. 1 and final stage 6 of FIG. 24). The aforementioned selection and use of predicted MR tags to determine Rtags for instructions that have memory locations as operands may be referred to as Rtag prediction accelerator optimization.

Referring to FIG. 61 , an example 800 illustrating components of an embodiment in accordance with the techniques herein for Rtag prediction accelerator optimization is shown. Example 800 corresponds to PUMP 10 at stage 5 as described elsewhere herein with additional features for performing Rtag prediction accelerator optimization (e.g., FIGS. 1 and 24). PUMP 802. PUMP 802 includes as an input an MR tag 804a as well as other PUMP inputs 804 as described elsewhere herein. PUMP 802 also includes other inputs, That is, the prediction selector mode (which indicates whether the PUMP 802 is running in normal processing mode (non-prediction mode in which MR tag prediction processing is not performed) or otherwise in prediction mode (in which MR tag prediction processing is performed). 804 b) In at least one embodiment, the prediction mode selector 804 b may be 0 indicating a normal processing mode for a PUMP for which a predicted MR tag value is not determined, or a predicted MR tag value is determined. may also be 1, indicating the prediction mode for the PUMP to be 1. When the prediction mode selector is 1, the PUMP 802 may run in a prediction mode in which the MR tag 804a input may be masked or ignored, and the PUMP 802 produces as output a predicted MR tag 805c When the prediction mode selector is 0, the PUMP 802 can run in normal processing mode as described elsewhere herein, in which mode the MR tag 804a is an input to PUMP 802 and no output 805c is generated.

As shown in example 800, additional outputs of PUMP 802 at stage 5 include R tag 805a and PC new tag 805b. When using a predicted MR tag, a rule for the predicted MR tag can be determined, in which case the rule specifies an associated tag for the R tag. When operating in predictive mode, the predicted MR tag 805c is an additional input to stage 6 808 of the pipeline. Element 808 may represent a commit or writeback stage (eg, FIGS. 1 and 24 ) as described elsewhere herein. Accordingly, element 808a may represent other stage 6 inputs than 805a-805c, as generally described elsewhere herein.

At stage 6 808, additional processing 808b may be performed when PUMP 802 is operating in a predictive mode. Element 808b indicates that a check may be performed in step 6 808 comparing the predicted MR tag to the action MR tag obtained from memory for the instruction's operand. In other words, 808b evaluates whether PUMP 802 correctly predicted the MR tag value by determining whether the predicted MR tag matches the MR tag obtained from memory. If the predicted MR tag does not match the MR tag obtained from memory, a false rule is triggered and used by the PUMP 802 to determine the R tag 805a as the erroneously predicted MR tag. The correct rule must now be selected (according to the actual MR tag) and used to determine the modified R tag. Therefore, if the predicted MR tag does not match the MR tag, a rule cache miss is determined and cache miss processing is performed. Consistent with the discussion elsewhere herein, cache miss processing may include processing using MR tags to select and evaluate the correct rule.

Load/Read and Store/Write instructions are examples of instructions in embodiments that may include memory locations as operands that benefit from the use of predicted MR tags. The other input 804 to the PUMP includes another or remaining set of input tags in addition to the MR tag 804a. For example, one embodiment shown with respect to FIG. 23 may have 5 input tags - PC tag, CI tag, OP1 tag, OP2 tag and MR tag - and 2 output tags - PC new and R tags. Therefore, the remaining input tag set (excluding MR tag) includes 4 tags: PC tag, CI tag, OP1 tag, and OP2 tag. Determining the predicted MR tag or instruction may include determining one or more rule sets having tag values that match 4 tags (eg, for PC tag, CI tag, OP1 tag, OP2 tag) of the instruction. can In some cases, only one rule may contain matching tag values for 4 input tags. In this case, the single matching rule also specifies a value to the MR tag that can be used as the predicted MR tag 805c. In addition, the rule can be evaluated using the 4-input tag and the predicted MR tag to further determine the R tag 805a.

For example, consider a memory safety policy with typical load and store operations. A load operation may load data from a source memory location using a pointer, and the first rule indicates that the tag or color on the source memory location must match the tag or color of the pointer. A store operation may use a pointer to store data in a target memory location, and the second rule indicates that the tag or color on the target memory location must match the tag or color of the pointer. In the case of a load command, the first rule may be the only rule having a tag value that matches 4 input tags for the PC tag, CI tag, OP1 tag, and OP2 tag of the load command. The MR tag of rule 1 can be used as the predicted MR tag 805c. Also, the R tag of the first rule can be determined using the 4 input tag set and the predicted MR tag. Similarly, for a store instruction, the second rule may be the only rule with a tag value matching the 4 input tags for the PC tag, CI tag, OP1 tag, and OP2 tag of the store instruction. The MR tag of the second rule may be used as the predicted MR tag 805c. Also, the R tag of the second rule can be determined using the 4 input tag set and the predicted MR tag.

In another instance, the policy's rule set with tags matching the input tags for the instruction's PC tag, CI tag, OP1 tag, and OP2 tag may be used as the predicted MR tag 805c. It can include multiple matching rules, with each matching rule identifying a tag. Embodiments may use any suitable technique for selecting one of a number of acceptable MR tags to use as a predicted MR tag. For example, an embodiment may select an MR tag from a set of allowable MR tags that is most common or likely to occur. The most probable MR tag may be based on previous observations or rule profiling. Alternatively, an embodiment may set the predicted MR tag to the previous or most recent MR tag. In the worst case, if the predicted MR tag does not match the actual MR tag once received, cache miss handling is performed as described herein to use the actual MR tag along with the other input tags of the instruction to determine the correct rule. can

In at least one embodiment, a class of rules may be created for memory operations that are used when a PUMP operates in predictive mode. A rule class may be referred to as a class of "predict memory tag" rules. For the "predict memory tag" rule, the MR tag 804a is not used as an input to PUMP 802, and thus is not used in connection with the various lookups performed by PUMP. For example, a care/don't care bit vector for a "memory tag prediction" rule could treat an MR tag as a don't care. Also, the "memory tag prediction" rule can omit the MR tag as an input, and instead specify a predicted MR tag as an output. As described above, if there are multiple matching normal rules that match a particular set of input tags for PC tag, CI tag, OP1 tag, and OP2 tag, then a single "memory tag prediction" rule corresponding to the matching set of rules. can specify a predicted MR tag as an output that is the most common or expected MR tag. In one embodiment, a single “memory tag prediction” rule corresponding to the set of matching rules may specify the last or previous MR tag received by PUMP 802 as a predicted MR tag.

The policy logic may decide whether to insert or use the "memory tag prediction" rule. Embodiments may maintain 2 versions of each policy, a first version containing the policy "memory tag prediction" rules for use when operating in predictive mode and a second version operating in normal processing mode or non-predictive mode. Contains normal or non-predictive policy rules to use when If the check performed at 808b in stage 6 fails for a given instruction when using the "memory tag prediction" rule, the cache miss handling is performed using the normal rule set (e.g., the second version of the rules described above). Processing for determining matching rules for commands may be performed.

In embodiments using a RISC-V processor and architecture, the prediction mode selector 804b may have a corresponding PUMP CSR. The use of CSR in embodiments using the RISC-V architecture is described in more detail elsewhere herein.

Referring to FIG. 62 , a flowchart of processing steps that may be performed in an embodiment consistent with the teachings herein is shown. Flow diagram 840 summarizes processing as described above with respect to example 800 . As noted above, PUMP 802 shown in example 800 represents a PUMP at stage 5 providing input to stage 6 of the processor pipeline. In at least one embodiment, steps 842, 844, 846, 848, and 852 of flowchart 840 may represent the processing steps performed in stage 5 and the specific policy rules used, as described above, implemented within PUMP. , steps 854, 856 and 858 may be performed in stage 6 described above.

At step 842, a determination is made as to whether the prediction mode is on/enabled indicating that the PUMP is operating in a prediction mode using the "memory tag prediction" rule. If step 842 evaluates to no, control passes to step 846 where the PUMP operates in normal or non-predictive mode using normal rules. If step 842 evaluates to yes, control passes to step 844 where a determination is made as to whether the current instruction is a memory input operating instruction. If step 842 evaluates to no, control passes to step 846. If step 844 evaluates to yes, control proceeds to step 848 where the PUMP operates in a predictive mode using the "predicted memory tag" rule. At step 848, a “predicted memory tag” rule that matches the instruction may be determined. At step 852, the R tag for the current instruction may be determined using the matching “predicted memory tag” rule from step 848. In step 854, a determination is made as to whether the predicted MR tag matches the actual MR tag. If step 854 evaluates to no, control passes to step 856 to perform rule cache miss handling by invoking the rule miss handler. If step 856 evaluates to yes, control passes to step 858 where the R tag is used as the R tag PUMP output when it is determined that there is a rule containing the predicted MR tag.

As a variation of example 800, reference is made to FIG. 63 showing the components of an embodiment that includes a PUMP 802 running in a normal non-prediction mode and a second PUMP 822 running in a prediction mode. In this example, a PUMP 822 operating in prediction mode may also be referred to as an MR tagged prediction PUMP where prediction mode selector 822b is always ON (eg, 1). Similarly, for PUMP 802, prediction mode selector 804b may also be OFF (eg, 0). MR Tag Prediction PUMP 822 can only use “memory tag prediction” rules and PUMP 802 can only use normal or non-predictive versions of policy rules. In this embodiment, PUMPs 802 and 822 may operate in parallel in stage 5. Element 828 may represent a component associated with stage 5 and 6 processing and MR tag prediction PUMP 822 . Element 829 may represent a component associated with stage 5 and 6 processing and PUMP 802 operating in normal mode. At 829, the PUMP 802 output is as with respect to example 800, with the difference that the predicted MR tag 805c is no longer output by the PUMP 802. Also, stage 6 808 does not perform check 808b. Element 828 may include components that perform processing in a manner similar to example 800, with the difference that MR tag prediction PUMP 822 uses only the "memory tag prediction" rules as noted above.

Stage 6 808 is modified to receive PUMP outputs Rtag 805a and PCnewtag 805b from MR tag prediction PUMP 822 and output Rtag 805d and PCnew tag 805e from PUMP 802. Also, in stage 6, a selection is made between Rtags 805a and 805d and also between PCnew tags 805c and 805e based on whether the predicted MR tag matches the actual MR tag (as indicated by 808a). selection is made in If there is a match between the predicted MRtag and the actual MRtag (e.g., 808a evaluates to 1 or true), then the tag from the predicted PUMP 822 (e.g., Rtag 805a and PCnew tag 805b) is used, and tags from the unpredicted PUMP 822 (e.g., Rtag 805d and PCnew tag 805e) are discarded. For example, if (808a) evaluates to 0 or false), tags 805a through 805c from predicted PUMPs 822 are discarded, and tags 805d through 805e from unpredicted PUMPs 802 are discarded. ) is used The unpredicted PUMP 802 provides its outputs 805d through 805e later than the outputs 805a through 805c of the predicted PUMP 822, so the PUMP from stage 5 for PCnewtag and MRtag A pause is introduced in stage 6 waiting for the aforementioned stage 6 input when the output is needed for processing as input to stage 6. The unpredicted PUMP 802 may experience a PUMP rule cache miss when it is selected, in which case , which is treated like a typical rules cache miss as described elsewhere in this disclosure.

Referring to stage 6 808, elements 850 and 852 represent multiplexers. Element 808a may represent a selector used to select an input from each of 850 and 852 based on the logical result of whether the predicted MRtag matches the MRtag. If the foregoing two tag values match, Rtag 805a is selected as input to 850, which serves as the selected Rtag 850a representing the final Rtag output of stage 6; Otherwise, if the above two tag values do not match, Rtag 805d is selected as input to 850 provided as selected Rtag 850a. Also, if the values of the two aforementioned tags match, PCnew tag 805b is selected as input to 852, which is presented as selected PCnew tag 852a representing the final PCnew tag output of stage 6; Otherwise, if the values of the two tags described above do not match, PCnew tag 805e is selected as input to 852, which is provided as the selected PCnew tag 852a.

Techniques for using coloring allocated memory that may be used in embodiments according to the techniques herein will now be described.

A user program, for example a user program coded in the C programming language, may contain calls to routines used in connection with memory allocation and deallocation. For example, malloc and free are routines in the C standard library and can be linked into an executable file of a user program. Thus, malloc and free run as routines in the user process address space, along with other user code that can call malloc and free. malloc is called for dynamic memory allocation, which allocates blocks of memory used by executing code. In at least one embodiment, malloc may have an input specific to the call indicating the size of the block of memory to be allocated, such that malloc returns a pointer to the allocated memory block. The program uses the pointer returned by malloc to access the allocated block of memory. In at least one embodiment, free is called to free or deallocate memory previously allocated by malloc. When a block of memory allocated using malloc is no longer needed, the pointer (returned by malloc) can be passed as an input argument to free, and thus free frees the memory (located at the address indicated by the pointer). Deallocate it so that it can be used for other purposes. In embodiments according to the techniques herein, user code running on a processor may make such calls to call malloc and free or other routines or functions that similarly perform memory allocation and deallocation. Routines such as malloc and free that perform dynamic memory allocation can use memory management metadata about allocated memory. In the following paragraphs, such metadata used for memory management may be referred to as malloc metadata, and is distinct and is also tag-based metadata described herein, including other metadata pointed to by tags and pointer tags (e.g. For example, tag-based metadata is not accessible to running user code and is processed by a metadata processor or subsystem as described elsewhere herein with respect to example 1000). The malloc metadata may include, for example, information about the allocated memory block, such as the size of the allocated memory block, and a pointer pointing to a portion of the malloc metadata for the subsequently allocated memory block.

Referring to Fig. 64, an example illustrating memory allocation, eg, in conjunction with malloc, is shown. In example 1100, the program makes a first call to malloc to allocate a first block of memory of the requested size. In response, malloc may allocate a block of memory 1102b of the requested size and return a pointer P1 indicating the starting address for block 1102b of memory. The user program can then store data in and read data from the allocated memory block 1102b using pointer P1 or another address based on an offset from P1. Also for dynamic memory management, malloc may allocate its own store 1102a of malloc metadata for each allocated memory block. Element 1102a represents a portion of memory allocated and used by malloc to store malloc metadata for allocated memory block 1102b. In a similar manner, the user program can then perform a second call to malloc to allocate a second block of memory. Element 1104a represents the portion of memory allocated by malloc in response to this second call, and 1104a is used to store malloc metadata. Element 1104b represents a second block of memory, where P2 is a pointer returned to the user program to access the second block of memory. In a similar manner, the user program can then perform a third call to malloc to allocate a third block of memory. Element 1106a represents the portion of memory allocated by malloc in response to this third call, and 1106a is used to store malloc metadata. Element 1106b represents an allocated third memory block, where P2 is a pointer returned to the user program to access the third memory block.

After the allocated memory block 1102b, such as 1102b, is no longer needed by the executing code, the code performs a call to free to free the memory block 1102b so that the memory block 1102b ) is deallocated and can be used for other purposes. When making such a call to free, a pointer (P1) can be returned. In a similar manner, when memory blocks 1104b through 1104c are no longer needed, a call to free can be made to specify pointers P2 and P3, respectively.

Because the address of the portion of memory 1102a holding malloc metadata is mapped into the address space of the executing code, through a pointer such as P1 returned to the executing user code by malloc, the user code may accidentally or intentionally You can access malloc metadata. For example, user code may assign the address of memory portion 1102a to another pointer P4 (e.g., P4 = P1-2) and then read or write to the memory location identified by pointer P4. can Thus, user code can, for example, overwrite the malloc metadata stored at 1102a and read the malloc metadata stored at 1102a. In this way, performing a write to the memory location at the address identified by P4 may corrupt the malloc metadata portion 1102a. More generally, the foregoing may be performed by user code with respect to any of the malloc metadata portions 1102a, 1104a, and 1106a.

Regarding call to free, user code can use malloc to specify a pointer corresponding to the starting address of an allocated memory block previously allocated. For example, user code may perform a call to free specifying the aforementioned pointer P4 as an argument other than P1, P2 or P3. For example, assume that malloc allocates a block of X bytes (e.g., X is a non-zero integer) for each malloc metadata portion 1102a to 1102c in conjunction with a call to malloc. The routine free will perform processing assuming that the memory locations from the first address P4-X to the second address P4-1 represent start and end addresses over the malloc metadata portion, such as 1102a, respectively. can In this case, the processing performed by free may be, for example, using a corrupted malloc metadata portion 1102a resulting in unexpected runtime performance and/or dynamic memory management errors.

Embodiments may use the techniques described herein to protect the malloc metadata portions 1102a, 1104a, and 1106a to avoid tampering through overwrites performed by other running code, such as user code. Such techniques may tag code and/or data with specific colors or tags and enforce rules that allow only desired access and operations as described elsewhere herein.

65, in at least one embodiment, the portion of memory used by malloc and free may be colored or tagged with a first tag used by metadata processing as described herein, (malloc Other portions of memory used by user code (as allocated by ) may be colored or tagged with a different second tag used for metadata processing as described herein. In example 1100, the data portion used by malloc and free (including malloc metadata) may be marked or tagged red, and the user data portion (a block of memory allocated by malloc for use by user code). may be marked as blue or tagged. An embodiment may have at least one tag or color reserved exclusively for use when colorizing or tagging memory locations used by malloc and free. In this example, red is a reserved color used to tag memory locations used by malloc and free. As described elsewhere herein, embodiments may also reserve one or more colors or tags for executing user code. In at least one embodiment, all memory allocated for use by a user program may be tagged with the same color. As a variant, an embodiment may use a different tag for each call to malloc, and thus a different color for each separate block of memory allocated. In this example 1110, to simplify the explanation, only the single color blue is used to tag all memory blocks allocated by malloc for user programs.

Element 1111 may represent a tag specific to a corresponding memory location 1113 . Elements 1112a, 1114a, and 1116a represent tags for malloc metadata portions 1102a, 1104a, and 1106a, respectively. Elements 1112b, 1114b and 1116b respectively represent tags for memory blocks 1102b, 1104b and 1106b allocated by malloc for use by user code via calls made to malloc as described above.

Elements 1112a, 1114a, and 1116a indicate that each memory location at 1102a, 1104a, and 1106a, respectively, is tagged red. Elements 1112b, 1114b and 1116b respectively indicate that the respective memory location of 1102b, 1104b and 1106b is tagged blue.

In general, an embodiment may colorize a block of memory at 1113 with a tag indicated at 1111, and may also use instruction tagging, colored pointers, or combinations of the foregoing in connection with triggering rules that enforce memory safety policies. can be used, whereby only malloc and free can access the malloc metadata areas 1102a, 1104a and 1106a and user code cannot access them.

In a first embodiment, the code of malloc and free may be tagged (eg, instruction tagged) with a special instruction tag (eg, CI tag) by the loader, for example. Both malloc and free can be tagged with the same unique or special instruction tag (e.g. malloc and free are tagged with the same CI tag of tmem), or they can be tagged with their own unique or special instruction tag (e.g. For example, malloc code is tagged as tmalloc and free code is tagged as tfree). Malloc's code, when executed, may include a store instruction that triggers a rule to perform colorization as in example 110. Free's code, when executed, deletes the malloc metadata portion (e.g., 1102a, 1104a, and 1106a) or previously malloced memory by re-tagging each memory cell of the block or malloc metadata portion with an F tag to indicate that it is free memory. It may include store commands that trigger rules to reinitialize or deallocate blocks (eg, 1102b, 1104b, and 1106b). Also, in a first embodiment, the memory safety policy may include rules triggered by the execution of specific instructions, such as load and store instructions, whereby the rules are instructions tagged with the above-mentioned special instruction tag(s). allows only 1) access to malloc metadata portions 1102a, 1104a and 1106a and 2) to perform memory block colorization as in example 110. These rules generally check CI tags to colorize memory cells in any of the metadata portions of (1102a, 1104a, and 1106a) or that each instruction accessing that memory cell has a special instruction tag indicating malloc or free. guarantee

In a second embodiment, rather than using special instruction tags, embodiments may use colored pointers with rules of memory safety policy triggered by execution of specific instructions, such as load and store instructions. The loader can tag pointers to malloc and free that refer to malloc metadata portions 1102a, 1104a and 1106a colored red. Malloc's code, when executed, may include a store instruction that triggers a rule to perform colorization as in example 110. Free's code, when executed, removes the malloc metadata portions (e.g., 1102a, 1104a, and 1106a) or previously allocated memory blocks (e.g., 1102b, 1104b and 1106b) may include store commands that trigger rules to reinitialize or deallocate. The memory safety policy may include rules that are triggered by the execution of specific instructions, such as load and store instructions, whereby the rules refer to memory cells using red colored pointers in the malloc metadata portion (1102a). , 1104a and 1106a). This rule generally checks the MR tag so that a memory instruction accessing a memory cell in any metadata portion of (1102a, 1104a, and 1106a) uses a pointer with a first color that matches the second color of the memory cell. guarantee that

In a third embodiment, as described above, both special command tags and colored pointers may be used in combination. The following are examples of commands and rules that may be used in such a third embodiment. Consistent with other discussions herein, the following examples are used to tag the destination register or memory location where the result of the current instruction is stored: PC (program counter), CI (current instruction), OP1 (current instruction's operand) 1), OP2 (operand 2 of current instruction), 5 input tags for metadata processing for MR (memory location referenced in current instruction, if any) and PCnew (new PC tag for next PC in next instruction) and R (tag for the result of the current instruction) Use a rule based on two propagated or generated tags for the instruction. Also, "-" indicates don't care about tags. In this embodiment, the loader can tag instructions in malloc with the special tag tmalloc and instructions in free with the special tag tfiree. Colored pointers can be created using the triggered rules mentioned below.

In the context of malloc, the processing of metadata rules triggered by executing malloc's code portion is a pointer to a newly allocated memory block, such as 1102b, via the first rule called as a result of a store instruction in malloc's code portion. You can create tags for For example, the malloc C code could be "P1 = next free", where next free is a pointer to the next free memory location at (1113), and the store instruction could be "move R1, R2", where Register R1 is the source register containing the address of the next free, and register R2 is the destination register, which is the pointer P1. Register R1 can be OP1 (with an OP1 tag), and register R2 can be a result or destination register (with an R tag propagated or generated as a result of a fired rule). The code portion of malloc is also an instruction tagged with a special tag, tmalloc, and may include an instruction indicating that the instruction is included in the malloc code, for example, an instruction such as the move instruction described above. In at least one embodiment, the loader may tag instructions in malloc with a special code tag, tmalloc. The first rule may tag the pointer P1 pointing to the allocated memory block 1102b with the tag blue. The first rule triggered as a result of the move command in malloc may be:

The above rule only fires when the CI tag is tmalloc and so on move commands tagged with malloc. Assuming that the pointer used by malloc is P1, mv rule 1A above would tag the tag P1 stored in register R2 as a tag or color blue, so that it is a blue memory location (i.e. a memory location tagged with a blue tag). indicates that it is a pointer pointing to .

The blue tagged pointer P1 can be used with another second store instruction of malloc to write allocated memory block 1102b with 0 or some other initial value for each word to allocated memory block 1102b. For example, "*P1=0" can be included in malloc C code that generates "Store R3, (R2)", where R3 is the source register operand OP1 containing zero, and R2 is the address P1. It is the OP2 register that contains. In such a store instruction, "(R2)" is the operand MR and also indicates the memory location that is the target or destination of the store instruction. Additionally, store instructions above malloc may also be tagged as tmalloc and may result in triggering a second special store rule as follows:

Before returning the tagged pointer P1 to the user code that called malloc,

Store rule 2A above only fires when the CI tag is tmalloc, when a pointer or address in R2 (representing P1) is tagged blue, and when the memory location MR pointed to by P1 has an F tag. Assume that the aforementioned memory location *P1 is tagged with "F" prior to colorizing the memory location as blue. In this example, F represents a free memory location. The MR tag for the resulting memory location shows a blue tag for the memory location.

Thus, malloc can contain code that results in triggering the second rule mentioned above for each memory location in the block of memory being allocated.

malloc generates code that triggers additional rules described below (e.g., similar to move (mv) rule 1A and store rule 2A above) for use in initializing the malloc metadata portions 1102a, 1104a, and 1106a. can also contain For example, the malloc C code may be "(P1 - 2) = MD area", where the MD area is a pointer to the malloc metadata area 1102a and the move command may be "move R7, R8"; Here, register R7 is a source register containing addresses "P1 - 2", and register R8 is a destination register, which is a pointer MD area. A rule triggered by the move command above could be:

tagging the MD area pointer as red,

malloc stores tags 1112a, 1114a, and 1116a for malloc metadata portions 1102a, 1104a, and 1104c, respectively, to tag each memory location of the malloc metadata portion (store 2A rule above). (similar to) may also contain code that triggers storage rule 2B. For example, assume that size is an integer representing the size of the malloced memory block 1102b and "*(P1-2)=size" is included in the malloc C code resulting in "Store R6, (R7)"; , where R6 is the source register operand OP1 containing the size value, and R7 is the OP2 register containing the address P1. In this store instruction, "(R7-2)" is the operand MR, and also indicates the memory location in MR 1102a that is the target or destination of the store instruction. Store rule 2B could be:

This is to perform a store if the store instruction is tagged tmalloc, if the R7 register containing address P1 is tagged red, and if the MR operand is tagged as F. Embodiments may also include the above-mentioned store rule 2D, which is a variation of the above-mentioned store 2B rule, whereby the store 2D rule may be used when updating of metadata values is desired.

At a later point in time, such as when freeing or deallocating block 1102b, colored blue, the free is the memory location of a previously allocated memory block (e.g., a memory block allocated for user code use). You can include code such as "*P=0" which will trigger store rule 3 mentioned below to re-tag. The loader can colorize or tag free instructions with tfree. Routine free may contain the C code statement "*P=0" resulting in "Store R4, (R1)", where R4 is the source register operand OP1 containing zero, and R1 is the address of the memory location to be initialized. is the OP2 register containing "(R1)" denotes the memory operand MR with R1 containing an address pointing to a memory location. Store rule 3 could be:

Thus, free can contain code that causes the third rule mentioned above to be triggered for each memory location in a memory block being deallocated, where the memory block is (e.g., to store data other than malloc metadata). used) previously allocated using malloc for use by user code. Store rule 3 checks to ensure that CI tag = t is free and both the memory location and the pointer pointing to it are the same color, blue.

It should be noted that an MR tag of "blue" could be any color previously used by malloc to color a generally allocated user memory block.

Free's code may also contain code that triggers move(mv) rule 1C and store rule 4 described below in relation to re-tagging each memory location in the malloc metadata part, such as 1112a. Free's code may contain code that triggers move(mv) rule 1C mentioned below, similar to move(mv) rule 1B above. The move(mv) rule 1C could be:

This may be tagging the red pointer for use by the free in conjunction with re-tagging using store rule 4.

Store rule 4 below (similar to store rule 3 above) is for re-tagging each memory portion of the metadata portion, e.g., for metadata portions 1102a, 1104a, and 1106a, re-tagging 1112a, 1114a, 1116a) may be triggered. Store rule 4 could be:

It performs a store if the store instruction is tagged tfree, and if the MR operand uses a pointer tagged red. The memory location is tagged with "F" to indicate that it is now free.

In a fourth embodiment, PC tagging reads data from the malloc metadata portions 1102a, 1104a, and 1106a and writes data to the malloc metadata portions 1102a, 1104a, and 1106a, and another code is used in the aforementioned metadata portion. can be used to prepare malloc and free to provide malloc and free with sufficient privileges, access, or authorizations to preclude access to . PC tagging is described elsewhere herein, for example, with respect to example 430 of providing different rights, access or authorizations on a per-process basis using different PC tag values. In a similar manner, special or unique PC tag values may be used to provide malloc and free with authorization to perform load and store operations with respect to malloc metadata portions 1102a, 1104a, and 1106a. More specifically, malloc can contain instructions tagged as tmalloc (eg CI tag=tmalloc when the instruction is executed). malloc may also contain code that, when executed, triggers the application of rules that propagate or create specific PC tags as output indicating rights or authorizations to access malloc metadata portions 1102a, 1104a, and 1106a. malloc may include the first instruction INS1 as follows:

where R2 is the address of the malloc metadata portion, such as address P6 in area 1102a, and (R2) represents the memory location with address P6 in 1102a colored red. When executed, the command INS1 described above may create a PCnew with a tag value equal to X1, where X1 represents the permission required to access 1102a. In this case, the rule triggered for the first command INS1 above may be as follows:

This colorizes R2 red and also sets PC to X1 to indicate a read/write access to the memory location with the address stored in R2 (e.g. address P6). Malloc will then include a second instruction INS2 called “store R3, (R2)” which stores the value from register R3 (e.g., OP1) to a memory location with address P6 (P6 is stored in R2). can The rule triggered for the second command INS2 above may be as follows:

Here PCnew is cleared or reset to PCdefault, which is the default PC tag that does not indicate permission to access the malloc metadata portion 1102a. Thus, in this particular example, the first ADD instruction triggers a rule granting malloc read/write access or authorization to 1102a. After the second malloc instruction above, which performs the write, is executed, the propagated PC tag removes the permission or authorization for read/write access to 1102a from malloc. As a variant, an embodiment may include a version of malloc with a prologue containing an instruction that triggers a rule that grants malloc read/write access to 1102a by creating a PCnew tag of X1 (e.g. For example, the prolog contains the Add command INS1 which triggers the rule mentioned above). On malloc's exit before returning, an epilog may be executed containing instructions that, when executed, trigger rules that remove read/write access to malloc by creating a PCnew tag of PCdefault (e.g. contains the store command INS2 that triggers).

In a similar manner, free may contain instructions that invoke rules that generate or propagate a PCnew tag value to give free access to 1102a. Applied rules may propagate or generate specific PC tags as output indicating desired access, rights or authorizations based on a particular process, such that certain allowed rights, accesses or authorizations may be represented by different PC tag values. .

It should be noted that the foregoing illustrates a single color blue for all malloced memory blocks and a single color red for all malloc metadata parts. More generally, as described elsewhere in this specification, malloc may be given an authorization to create an infinite number of new colors that may be needed to color other parts of heap memory. As discussed elsewhere herein, for example, malloc may initially be given one or more pre-determined sets of colors or tags, and then generate the necessary tags from the initial pre-determined sets. For example, the initial predetermined set of mallocs may contain yellow or Y and red or R. For a running process, for each call to malloc it creates a new Y-based tag (e.g. Y1, Y2, Y3, . . . ) to be used by user code (e.g. malloc metadata store other than) can allocate a new memory block. Thus, a different Y-based tag can be used to color each allocated memory block 1102b, 1104b, and 1106b (e.g., 1102b is colored Y1, 1104b is colored Y2, (1106b) is colored Y3). malloc may create a new R-based tag (e.g. R1, R2, R3,...) for each different piece of malloc metadata created for each call to malloc. Thus, R-based tags can be used to color malloc metadata portions 1102a, 1104a, and 1106a with different R-based tags, respectively (e.g., 1102a is colored R1, 1104a is colored R2 is colored with , and (1106a) is colored with R3). The current or last R-based tag and the current or last Y-based tag used by malloc can be stored as state information via rules that are triggered when executing the malloc instruction. For example, malloc may contain an instruction that triggers a rule to store the last Y-based tag Y9 as the tag of the first memory location. Y9 can be generated as Rtag. Subsequent instructions may refer back to the same first memory location tagged with Y9, the last Y-based tag stored, in which case subsequent instructions: 1) create a new tag Y10 based on the last Y-based tag Y9; and 2) Trigger a rule that stores tag Y10 as a tag in the first memory location. Y10 can be generated as Rtag. A rule triggered by a subsequent instruction may direct Rtag to be determined, for example, MRtag +1, where MRtag is Y9 for the subsequent instruction.

A technique will now be described that can be used as an optimization in connection with metadata processing using hardware accelerated miss handling. In general, some policies used in the embodiments herein may cause frequent rule cache misses and cache miss handlers for such policies may take many cycles to execute. In some policies, the relationship between the various rule inputs can be somewhat simpler in that the relationship between the various rule inputs logically determines the outcome or outcome and so can be quickly hardwired and resolved using dedicated hardware.

As a result, these policies implemented using hardware (HW) rule cache miss handlers can be resolved in a much shorter amount of time than others that do not use such hardware acceleration. In such embodiments, policy components such as cache miss handlers for one or more selected policies may be implemented in dedicated hardware. Accordingly, embodiments in accordance with the techniques herein may use such hardware-assisted policies with software-defined policy components alone or in conjunction with software-defined policy components using software rule cache miss handlers.

As an example, consider a memory-safe policy using memory-safe colorization. Memory cells and pointers may be colored, such as in connection with memory safety policies described elsewhere herein, such that the rule invoked with respect to load and store operations is that the pointer color matches the color of the memory cell. Only references are permitted. For example, a rule triggered on a load instruction has the policy that the pointer color (eg, of a register tag whose register is an operand such as OP1) is equal to the memory cell color (eg, a memory location tag such as Mtag). can be used to enforce The memory safety policy can thus challenge capacity by filling the PUMP rule cache with many different specific rules that simply capture the same color relationship for many colors, thereby increasing the rate of capacity misses. In some embodiments described herein that do not preload the rule cache, a forced rule cache miss is required to insert all of these rules one by one. Because memory safety policy rules can typically be triggered in conjunction with running user code, memory safety policy rules can be supported using HW rule cache miss handlers rather than software rule cache miss handlers.

In such an embodiment, the HW rule cache miss handler may generate or compute a new rule inserted into the cache when a rule cache miss occurs. For example, a miss handler for memory safety can be implemented using hardware as a HW rules cache miss handler that compares OP1tag to Mtag for load instructions. If OP1tag equals Mtag, the HW rule cache miss handler can create a new rule with Rtag assigned to Mtag. For example, if the pointer PTR is red and the memory cell pointed to by the PTR is red, the command that invokes the rule is allowed and the resulting tag Rtag must be red. To generate the above as a new rule to be inserted into the rule cache, the HW cache miss handler can first compare OP1tag with Mtag. If they do not match, a rule violation has occurred and the instruction is disallowed (eg, causes the processor to stop executing). If the HW rules cache miss handler determines that OP1tag is equal to Mtag, then the HW rules cache miss handler determines opcode=load, OP1tag=red, Mtag=red, and Rtag=red (all other tag inputs and outputs in the rule don't care may be generated as an output of the hardware, and the generated rule may then be inserted into the rule cache.

Referring to FIG. 66 , an example illustrating a cache miss handler implemented in hardware in an embodiment according to the techniques herein is shown. Example 1300 shows input 1302a being entered into PUMP rule cache 1302 (e.g., FIG. 22) to perform a lookup to determine if a rule matching input 1302a is in the cache ( 1301). If there is a match, the output 1302b is determined based on the rules stored in the cache. Consistent with discussion elsewhere herein, input 1302a may include an opcode and an input tag - PCtag, CItag, OP1tag, OP2tag, Mtag. Output 1302b may include the rule's output tags, such as PCnew tag and Rtag. With respect to an embodiment according to the description herein of implementing a cache miss handler in software, when a rule cache miss occurs, the software cache miss handler may be called, whereby the code of the miss handler is executed to determine the current rule cache miss. A new rule can be calculated for input 1302a that causes The cache miss handler first determines whether the input matches an acceptable rule (e.g., in the case of a memory safe load rule, whether OP1tag equals Mtag), and if so, calculates the output for the particular input 1302a ( eg, Rtag to Mtag), thereby creating a rule for input 1302a. A new rule (based on the combination of the input 1302a and the computed output of the miss handler) is inserted into the rule cache. Consistent with what has been discussed elsewhere herein, new rules may include opcodes, input tags - PCtag, CItag, OP1tag, OP2tag, Mtag - and output tags - PCnewtag, Rtag.

Element 1303 illustrates a HW rules cache miss handler 1304 that may be used in embodiments according to the techniques herein rather than a software rule cache miss handler. In such an embodiment, the HW rule cache miss handler 1304 may be implemented using dedicated hardware including, for example, gate level logic and other hardware components. In this embodiment, the HW miss handler 1304 can take the same inputs 1302a as the PUMP rules cache 1302 and use its hardware to generate the same outputs 1302b to be output to the PUMP rules cache. Consequently, as mentioned above, new rules can be formed by combining opcodes, input tags and output tags. The new rules may then be stored in the PUMP rule cache (eg, FIG. 22).

In at least one embodiment, the HW rule cache miss handler for memory safety policies can simply copy from Mtag to Rtag to load rules into cache and perform PUMP rule insertions immediately (e.g. gate level logic). using) can be implemented in hardware as described above. In this simple case, you don't need to reference memory and perform all data structure operations in memory.

Additionally, in at least one embodiment, memory security may implement a tag on a memory cell as a pair of tags: (1) a memory-cell color tag, and (2) a pointer-on-pointer color tag within a memory cell. Memory-safe acceleration may include a dedicated cache that combines the Mtag and OP2tag into a new Rtag on the store and extracts the pointer-tag from the Mtag pair and places it in the Rtag for the load. A simpler dedicated software handler can be used for such cache misses. Although the foregoing has been described in terms of a single (non-composite) policy such as memory safety, the same general techniques can be applied to components of a composite policy on UCP.

Embodiments may also perform hardware acceleration using HW rule cache miss handlers for a limited common subset of rules, such as rules expected to be commonly referenced. For example, in memory safety, the rules for load/store and propagation during arithmetic are the most standard and stylized. There are other unusual rules for initially colorizing a memory area and putting the memory area back to free. These rare rules may be implemented using the typical rule miss handlers described herein rather than being implemented with hardware support.

In at least one embodiment, the HW rules cache miss handler may directly implement the mapping function as gate-level logic. For example, these gate-level logic circuits can map input tags to output tags for rules such as mapping Mtag to Rtag for the store instruction rule of a memory safety policy. As another example, a HW rule cache miss handler for a control flow integrity (CFI) policy uses gate-level logic to tag a control flow target or destination to a set of allowed callers (e.g., a specific tagged control flow target or destination). source location or address that is allowed to transfer control to . As another example, the stack protection policy may encode the stack-frame-code tags and associated stack-frame-memory-cell tags in a way that allows hardware that one derives from the other (e.g., they are only may differ by only a few bits, which could be arranged even if the tag was a pointer by allocating the stack-frame-code tag pointer and the stack-frame-memory-cell tag pointer together); As a result, the HW rule cache miss handler enforcing the stack protection policy can either determine which tag to create (in the case of creating a tag from a stack pointer) or request a memory reference within such code (in the case of a read or write). There will be.

As a variant for using the HW rule cache miss handler to compute or determine new rules to be inserted into the PUMP rule cache, an embodiment is such that one or more rules are fully instantiated and enforced in hardware and so are not stored in the PUMP rule cache. You can actually hardwire the logic of one or more policy rules. For example, instead of using a HW rule cache miss handler and a PUMP rule cache for the policy, an embodiment encodes and enforces the rules of the policy (e.g., rules of the policy implemented in hardware such as gate level logic and circuitry). hardware can be used. In such an embodiment using both the PUMP rule cache and HW specific rules, a rule lookup of both the PUMP rule cache and HW specific rules may be performed. In this case, a miss handler (eg, HW rule cache miss handler or software miss handler) may be called to determine/calculate a new rule according to not finding a rule for a specific entry in the PUMP rule cache or HW specific rule.

Composite policies present additional challenges and opportunities. Consistent with discussion elsewhere herein, a composite policy includes multiple policies that are concurrently enforced for an instruction. The challenge is that a composite policy must address several different policy components. The overall resolution order of a composite policy can be supported by hardware using a HW rule cache miss handler with a data cache, a UCP cache (per policy component of the composite policy) and a CTAG cache for all different policy components of the composite policy. Being able is an opportunity. From previous experience, a common challenge is that when allocating memory new (eg, using malloc), and thus tagging the new memory with a color, a forced rule cache miss is caused. In this case, it is possible that the memory safety policy component needs new rules, but the other components already have their rules in the UCP cache. Using hardware acceleration through HW rule cache miss handlers for top-level composite policy and memory-safe color matching, memory rule resolution can be implemented in hardware instead of requiring hundreds or thousands of cycles to resolve rules executing software-based miss handler code. It can be achieved with a small finite state machine that runs on and consults caches (e.g. data cache, UCP cache and CTAG cache).

In at least one embodiment, the UCP cache can be decomposed by component policy, and everything that creates a complex set of tag results to be fed back into the CTAG cache can be resolved in parallel. If all policies can be resolved by the UCP cache or by simple hardware rules such as those for memory safety, the total time to look up the UCP cache will be the total time of a single policy rather than proportional to the number of policies. This works perfectly if the number of component policies is fixed and matches the hardware provided. Nonetheless, a slight variation is to simply distribute the component policy across a fixed number of available UCP caches, so the number of in-order UCP cache solutions is just the ratio of the number of component tags to the number of physical UCP caches.

Referring to FIG. 67 , an example 1310 illustrating the use of a HW Rule Cache Miss Handler in conjunction with a composite policy that may be used in embodiments consistent with the techniques herein is shown. In this particular example, the 3 policies include a composite policy, such that all 3 policies are enforced concurrently for the same instruction, but more generally a composite policy includes any number of policies, but is not limited to three. Elements 1314a through 1314c are HW rule cache miss handlers for the 3 policies including the composite policy. Input 1312 may be provided to each of HW rule cache miss handlers 1314a through 1314c that determine or compute rule outputs 1316a through 1316c, respectively, for a particular policy (e.g., HW rule cache miss handler 1314a ) determines output 1316b containing Rtag and PCnew tag for policy A; HW rules cache miss handler 1314b determines output 1316b containing Rtag and PCnew tag for policy B). As a result, outputs 1316a through 1316c can be combined into a single composite result 1318 representing the composite Rtag and PCnew tag for the three policies. Combining the outputs 1316a - 1316c to determine the composite result 1318 can also be implemented using hardware or software. The new rule is inserted into the cache, where the new rule is an input (eg, input for a specific instruction that triggers rule miss processing) with a composite result 1318 (eg, a composite value for Rtag and PCnew tag). opcode and input tags).

Also, although not shown in example 1310, an embodiment may use a UCP cache and a CTAG cache in combination with HW rule cache miss handlers 1314a to 1314c in an embodiment according to the techniques herein. As described elsewhere herein (e.g., with respect to FIGS. 21, 23, and 24), policies A, B, and C each have their own UCP cache caching the most recent policy result tag. (e.g., the UCP cache for policy A stores the result tag recently computed by miss handler 1314a based on the combination of the instruction's opcode and input tag - PCnewtag and Rtag results). As described elsewhere herein (e.g., with respect to FIGS. 21, 23, and 24), a CTAG cache is an individual Rtag that may be output from multiple composite policies, such as policies A, B, and C. You can store composite results of Rtags for specific combinations of values. The CTAG cache may also store composite results of PCnewtag for specific combinations of individual PCnew tag values that may be output from multiple composite policies, such as policies A, B, and C. Thus, the hardware generating composite result 1318 from outputs 1316a - 1316c can use information from the CTAG cache to determine composite result 1318 . Additionally, the HW rule cache miss handlers 1314a - 1314c may also have as input information from the UCP cache for policies A, B and C.

As an alternative to having HW rule cache miss handlers for all 3 policies in a composite policy, as in example 310, an embodiment may provide a HW rule cache for one or more, but less than all of those policies that contain the composite policy. You can optionally choose to implement a miss handler. In such an embodiment, a portion of the rules cache miss handler may be implemented in hardware, and the remainder of the rule cache miss handler in the composite policy may be implemented in software as described elsewhere herein.

It should be noted that some policies as described herein may assign a new tag, such as in connection with a memory safety policy, for example. In at least one embodiment, a HW rules cache miss handler for a policy such as memory safety that can allocate a new tag is a FIFO-based cache of new tag values that the HW-based handler can use (e.g., a newly allocated tag cache of tags that can be used as values are generated. If the assigned tag is a pointer representing an address, the cache contains the address or pointer instead of the tag value. In this way, the HW rules cache miss handler can perform the allocation simply by reading the top entry from the FIFO based cache. Periodically, a software handler may run in the metadata processing domain to repopulate the FIFO-based cache with new tags available for allocation.

Embodiments are described herein where there is complete and strict separation between metadata processing domains and "normal" code processing in user code or execution domains. As a variant, an embodiment may take a more relaxed approach and still not allow modification or writing of information by user code or execution domains to metadata processing domains, but passing information/values by metadata domains to user code. Or you can extend the strict isolation model described above to allow returns to the execution domain.

We now describe techniques that may be included in at least one embodiment where a metadata processing domain may take advantage of the more relaxed approach described above to return a value that may be used or referenced by code executing in a normal code processing or execution domain. (e.g., metadata processing returns input values to normal or user code execution domains). For example, as described elsewhere herein, an embodiment may use malloc and free routines, which allow the code of malloc and free to, when executed, perform the processing of accessing malloc metadata. It has code tagged with command tags that provide unique functionality needed to trigger rules that allow malloc and free to function, create new color tags, tag user data areas with these new color tags, etc. . The foregoing is to provide those privileges or functions that are uniquely assigned to malloc and free, excluding other code, such as user code. Code where malloc and free now do their own processing, and the loader specially tags the malloc and free codes with special code tag(s) to uniquely identify them as belonging to malloc and free with special execute rights. Consider an embodiment in which tagging is used. In such an embodiment, the user code making the call to free may, for example, case provide a pointer PTR1 that is corrupted or does not point to the beginning of a previously allocated storage area that is otherwise being deallocated. According to free, PTR1 can be assumed to point to the first location of the user data area previously allocated by malloc. free, for example, stored in a predetermined location for the user data area to which malloc metadata is allocated, e.g., in advance for the user data area and associated memory location of the memory heap described with reference to FIGS. 64 and 65 The determined structure can be inferred.

Now, a technique that may be used in an embodiment that causes a PUMP to return a value to a code execution domain will be described.

Referring to example 1200 of FIG. 68 , elements 1111 and 1113 described with respect to example 1110 of FIG. 65 , further annotated with pointers PTR1 and PTR2 discussed below, are shown. Assume that user code calls free with PTR1 with the intention of deallocating memory block 1102b. P1 can represent a pointer or address expected by free. However, in this example, PTR1 could indicate a corrupted or invalid address that would normally indicate an address other than P1 (e.g., PTR1 could identify a location in memory 1102b or that does not even point to a heap). address). Although PTR1 is corrupt or otherwise does not point to the correct memory location P1, free can perform processing using PTR1 to access malloc metadata using relative addressing to PTR1, where malloc metadata is It is assumed to exist in its predefined structure, format or layout. For example, the malloc metadata area used by free can be estimated to be located right before the allocated user data portion as shown in FIGS. 64 and 65 . In this case, free's code determines that the malloc metadata it processes to deallocate a particular block of memory is located at a particular offset OFF1 before PTR1 based on a predetermined layout. For example, referring to FIG. 68, free can be estimated by user code as PTR1=P1 where PTR1 can be provided to call to free. free can use relative addressing as described above based on a predefined data layout that malloc metadata 1102a corresponding to memory block 1102b to be deallocated must start at a memory location with address PTR2=PTR1-OFF1. can In this example, PTR1 is not equal to P1, and PTR1 points to somewhere in the actually allocated memory block 1102b such that the address calculation PTR2=PTR1-OFF1 also exists in the user allocated memory block 1102b (PTR2 is free indicates the expected starting point of the associated malloc metadata used by .

In such a case where PTR1 provided by the user code on the call to free does not point to the expected location P1 and so PTR2 indicates the assumed starting point of the malloc metadata used by free, free's code (discovered by PUMP) Data stored in memory block 1102b may be incorrectly accessed using data such as malloc metadata that triggers a violation, interrupt, or trap (which may be due to rule violations or other code execution error conditions during execution of free). . Thus, the execution of code running in the user process space or domain may be interrupted due to the aforementioned violation during execution of the routine free as invoked in call to free using PTR1 from user code. Rather than having routine free cause user code to crash, it may be desirable to have free's code query PUMP, or more generally, have metadata processing return a value. The return value could be, for example, a Boolean indicating whether the color associated with PTR2 (used to access malloc metadata by the free code) actually points to a valid or expected malloc metadata area. Using such a returned PUMP value or metadata processing value allows free to perform different conditional processing based on whether the color associated with the memory location at address PTR2 represents a valid malloc metadata color, such as red. Routine free can perform some recovery or other action if PTR2 identifies an invalid malloc metadata area as determined by the color of PTR2. This action may be preferable to halting user code due to rule violations, traps, interrupts, or other execution errors.

In at least one embodiment using the RISC-V instruction set, to implement the return of metadata processing values, a new instruction gmd (get-metadata-info) may be added to the RISC-V instruction set as follows: :

where R1 contains the result value returned from PUMP or metadata processing;

R2 contains address PTR2 tagged with the color of the memory location having address PTR2;

R3 is tagged with a valid color as expected for a valid malloc metadata area.

Thus, R2 and R3 can be registers that are input or source operands, and R1 can be a register that contains the result or output. In this particular example, R3tag can be red and R2tag can be blue, representing the color of a valid malloc metadata region. The rule invoked by the new instruction may output a return value in this example as a boolean indicating whether R2tag=R3tag, where the aforementioned boolean result is stored in register R1 accessible to free contained in the address space of user executable code. It may be a return value output by metadata rule processing (eg, PUMP output). Consistent with discussion elsewhere herein, it should be noted that R1 may be tagged with Rtag as the result tag.

The following describes the logic processing that can be performed by free code using a C-like pseudo code description with PTR1, PTR2 and OFF1 as described above:

In the logic processing above, IS_RED can check to see if PTR2 is color RED.

The recovery process performed by the code in the else block mentioned above may attempt to find the starting point of a valid malloc metadata area, for example, by searching backwards or forwards from PTR2. The code in the else block mentioned above can cause user code to exit in a more defined and expected way, eg with a runtime error message/condition indicating invalid colored pointer PTR2.

The new commands Get metadata info R1, R2, R3 may be included in the commands generated as a result of compiling and linking the code of the free routine written in C to perform the logic processing mentioned above, for example. Embodiments may wish to control or restrict what particular code portions may be allowed to execute these new instructions. PUMP rules can be used to mediate or restrict when these new instructions can be allowed to be executed by certain routines. For example, free or malloc code may be allowed to execute the new Get metadata info command, but user code may not. Any suitable technique, some of which is described herein, may be used to provide routine free with the necessary privileges or authorizations to execute a new instruction that returns a PUMP value. For example, free's code can be tagged with a special instruction tag indicating that free is allowed to execute new instructions. For example, the loader can tag new instructions that appear in free code with the special tag NI. Rules can be used to arbitrate or restrict code with an NI instruction tag (CI tag) from being allowed to call a new instruction.

Referring to FIG. 69 , an example 1210 illustrating the inputs and outputs of metadata rule processing in an embodiment consistent with the techniques herein is shown. Element 1212 may generally represent metadata processing as described herein. Inputs 1212a to metadata processing may include, for example, various tag and opcode information as described herein. Output 1214 generated by metadata processing 1212 may include Rtag 1214a and PCtag 1214b as described elsewhere herein. Metadata processing may also generate a new output, which is return value 1214c. The return value 1214c may be placed in a register, such as R1 indicated above, with the new instruction in the user process space/set of registers accessible to code execution. Consistent with description elsewhere herein, 1214a and 1214b represent results (e.g., result registers or memory locations) and tags placed on the PC, respectively; Not accessible to space/code execution. It should be noted that whether metadata processing returns return value 1214c may be conditional on a particular instruction or opcode. For example, as described elsewhere herein, the metadata processing outputs associated with FIGS. 27-33 based on opcodes using multiplexers that enable/disable the output of return values 1214c. can be filtered as described above. Value 1214c in this example represents the logical result of whether R2tag=R3tag when opcode is the value of the new instruction. Otherwise, if the opcode does not represent a new instruction opcode, a default value may be conditionally returned by metadata processing as return value 1214c.

Referring to FIG. 70 , when a value is returned to the user execution domain by metadata processing, for example, when executing a new instruction included in the code of free as described above, in an embodiment according to the technology herein, An example 1220 illustrating possible components and processes is shown. For simplicity of illustration, example 1220 shows the logic and components of the metadata processing used only for the destination or result register R1 and the associated result register for this new return value. Element 1222a may represent a PUMP input (eg, a tag such as R2tag and R3tag, opcode in this example), generally as described elsewhere herein for metadata processing. The PUMP 1222 may include a rule for checking whether the code tag is NI for a new instruction, and a logic result indicating whether R2tag=R3tag (e.g., in this example, OP1 representing the first input source operand R2 and Outputs OP2) representing the second input source operand R3. The rule outputs the aforementioned logic result 1221a. Element 1225 can represent a multiplexer having an opcode used as selector 1225a for multiplexer 1225. When the opcode of the current command indicates a specific opcode for the new command Get metadata info, 1225a selects 1221a to be output as return value 1214c. Otherwise, if the opcode is not the opcode of the new instruction, 1225a will select the default return value 1222a as the return value 1214c. Return value 1214c is the PUMP output stored in destination register RD 1228 (e.g., 1214c returns the contents stored in register RD stored in D1 1228b and accessible to code running in the user process address space). indicate). Since RD 1228 is a result register, the rule could also be to tag RD with Rtag (e.g., Rtag is stored in tag portion T1 1228a, where T1 is the tag word of the RD register). In at least one embodiment, Rtag may be a special tag SPEC1 indicating that RD contains the output of a new instruction. As described elsewhere herein where the tag input to the rule is (PCtag, CItag, OP1tag, OP2tag, MR tag) and the rule output is (PCtag, Rtag) and the third output is NEWOUT indicating the new return value 1214c. symbolic Based on the logic, the rule can be expressed as:

More generally, the foregoing use of a new instruction may, in embodiments consistent with the techniques herein, indicate (e.g., with NI) a special can be used to return a value that is any suitable and desired value that can be tagged as

Alternative embodiments may avoid adding new instructions. This can be done by code tagging an existing instruction to control this behavior and setting the care bit to select the output value in this case. Another alternative could be to add a value-output-care bit that is also the output of the PUMP so that the rule can decide when the value output should flow to the RD value result. This second case allows opcodes to behave normally when not tagged and exhibit this special behavior only when given an appropriate code tag.

Techniques that may be used to ensure that a particular sequence of instructions are executed atomically, either as a single unit or as a complete sequence, in a particular order from the first instruction to the last instruction in the sequence will now be described. Further, this technique ensures that control does not transfer to the sequence of instructions other than the first instruction in the sequence and does not transfer or end the sequence except through the last specified instruction in the sequence. For example, consider the simple instruction sequence of FIG. 71.

In example 1400, a sequence of two instructions 1402 and 1404 is shown. The first instruction 1402 reads the contents from a memory location (the address of the memory location is stored in R2) or loads it into R1. The second instruction writes or stores zero (0) to the same memory location (which has the address stored in R2). This sequence of instructions can be provided to ensure that a value read from a memory location (with the address specified in R2) is used only once, so that the previous value is immediately after the value is read from memory. It is erased from the memory location or zeroed out. Thus, a zero output of a memory location must be performed by the second instruction 1404 in the sequence, as the next instruction in the sequence after the first instruction 1402 reading a value from the memory location.

In at least one embodiment consistent with the techniques herein using a RISC architecture, rules may be used to enforce the aforementioned linearity and atomicity of data items in the instruction sequence of 1400. In such an embodiment, a PC tag (PCnew tag) may be updated to convey the state of the sequence of the expected next instruction in the sequence. In at least one embodiment, one solution is to tag instruction 1402 with a CI to denote it as a linear read instruction. Also, (R2), which represents a memory location with an address stored in R2, is entered and tagged as a linear variable with unique metadata id X1 (e.g., X1 uniquely identifies this linear variable from all other linear variables). It can be. The first rule can be triggered as a result of the first instruction 1402 . The first rule may indicate that only instructions tagged as linear reads are allowed to read from linear variables. Also, the resulting PCnew tag may be clear-linear-variable-Xl-next indicating that the next instruction to be executed should clear linear variable X1. The second rule can be triggered as a result of executing the second instruction 1404, where the value of the operand, zero (written to the memory location), represents a special value used to initialize or clear the memory location. It is tagged with the special EMPTY tag. Also, a memory location is required such that the linear variable X1 represents the particular tagged linear variable from the immediately preceding instruction 1402 . (1402) If the next second instruction does anything other than write the EMPTY value into the linear variable X1, a trap is generated. Thus, the second rule at 1400 enforces the desired contiguous and atomicity of the sequence of instructions.

More specifically, assume that the first instruction 1402 is a load instruction that loads the contents into R1 from a memory location whose address is stored in R2. The load command could be:

Also assume that the second instruction 1404 is a move instruction that moves a zero (0) to the memory location having the address stored in R2. A move command could be:

*

According to conventions mentioned elsewhere in this specification, rules may be defined in terms of opcodes, input tags - PCtag, CItag, OP1tag, OP2tag, Mtag - and output tags - PCtag, Rtag. Based on the above rule convention, for the first load instruction, OP1 is R1, OP2 is R2, and (R2) is the memory location tagged as Mtag. The first rule triggered by the first load instruction may be:

Based on the above rule convention, for the second store instruction, OP1 is 0, OP2 is R2, and (R2) is the memory location tagged as Mtag. The second rule triggered by the second move command may be:

This example shows how to use tags and rules to ensure indivisibility of specific instruction sequences. Those skilled in the art will readily appreciate that this general technique can be applied to many other scenarios where it is desirable to enforce that data can only be accessed in specific ways as part of specific instruction sequences. A person skilled in the art can also readily appreciate that this technique can be employed in any case where strict enforcement of a sequence of instructions is required. As mentioned above, a common technique is to check the new PC from instruction N in the sequence (e.g., PCnew tag) as a PC tag in a rule triggered by the next instruction N+1 in the glued sequence. This includes being tagged with a special tag that

Techniques that may be performed as part of an operation to boot or start up a system in embodiments according to the techniques herein based on the RISC-V architecture will now be described. The following paragraphs may refer to various CSRs described elsewhere herein, such as with respect to example 900 in which a CSR may be used in connection with a metadata processing domain.

As described elsewhere herein, a bootstrap tag can be a value that is hardwired or stored in a specific ROM location. As part of booting the system, a segment of bootstrapping code may be executed that generally performs initialization including initializing different CSRs, memory, and the like. As part of initialization, this process also initially tags the memory location with a default tag value derived from the initial bootstrap tag. In at least one embodiment, a CSR such as a boottag CSR (e.g., a sboottag CSR as in example 900) is a special boottrap used as an initial "seed" tag from which all other tags in the system are derived. Can be initialized with tags. Other code entities, such as loaders, have their instructions specially tagged (eg, CI tags are set to special instruction tags) to perform actions that other code that does not have a special instruction tag are not allowed to do. You can specify a loader as having specific privileges or authorizations. The foregoing can be enforced using a rule triggered by the loader's code that checks the CI tag to ensure that the CI tag is a special tag in order for the triggered rule to perform the desired tag action. Thus, for example, the special CI tags used to tag the loader's instructions may be generated or derived from bootstrap tags as a result of special rules triggered by executing code as part of the startup process. In general, when a piece of code or stored instructions is tagged, rules can be triggered by execution of that tagged code to generate more desired tags and also place so-generated tags into the code and data. The foregoing and other aspects are described in more detail.

At start-up or boot-up of the system, for example, the tagmode stored in the tagmode CSR (eg, 901r of example 900) may be initially off (eg, 911a of example 910). . The bootstrap ROM program can be executed by first directly setting the default tag CSR (e.g., 901c of example 900) to a special default tag value. The bootstrap program can then set the tagmode CSR to a mode in which the metadata processing domain can write the default tag stored in the default tag CSR to all results. In other words, while in defaulttag tag mode (e.g., 911b of example 900), the PUMP output Rtag is always the default tag value.

Subsequently, after the memory location has been initialized and tagged with a default tag, a process may be performed to generate an initial set of tags that will be used for further generating or deriving all other subsequent tags (e.g., the initial set may be one in an infinite fashion). can be further used to derive occurrences of tags above). This process may include executing a sequence of commands or code segments that trigger rules to create an initial set of tags. In this case, the tag mode can be set to an appropriate tag mode level to associate PUMP with during execution of the code segment. For example, if the boot code is running in hypervisor mode, it is set to x110, as indicated by 911e, or to x111, as indicated by 911f, to engage PUMP during execution of the code segment; This allows rules to be triggered and enforced as a result of code segment instructions.

It should be noted that processing to verify or verify the code segment may be performed prior to executing the above-mentioned code segment. For example, in at least one embodiment, the code segments noted above are decrypted and verified prior to execution (e.g., using a digital signature) to ensure that the code segments have not been altered or modified. may be stored in an encrypted form, verified or validated.

Further explaining, the bootstrap program may be included in the above mentioned Code Segment 4 instructions executed while PUMP is engaged to generate an initial set of tags:

In instruction 1 above, R1 is a general purpose register. Command 1 reads the boottag CSR and passes both the value stored in the boottag CSR and the tag stored in the boottag CSR to R1. The boottag CSR was set to hold certain tags during processor reset or by privileged mode writing of the CSR including its own tag. Reading from the boottag CSR may also clear the boottag CSR so it is not possible to retrieve it after the initial search during boot.

" 형태의 위의 명령어 2 내지 4를 형성하는 각각의 가산 명령어에서, Rn은 Add의 결과를 저장할 타깃 또는 결과 레지스터를 나타내며, Ry는 또한 레지스터 또는 소스 오퍼랜드를 나타낸다. 전술한 코드 세그먼트의 명령어 2는 제 1 태그로부터 제 2 태그를 발생하고 제 2 태그를 R2가 가리키는 메모리 위치에 배치하는 제 2 규칙을 트리거할 수 있다. 전술한 코드 세그먼트의 명령어 3은 제 2 태그로부터 제 3 태그를 더 발생하고 제 3 태그를 R3가 가리키는 메모리 위치에 배치하는 제 3 규칙을 트리거할 수 있다. 전술한 코드 세그먼트의 명령어 4는 제 3 태그로부터 제 4 태그를 더 발생하고 제 4 태그를 R4가 가리키는 메모리 위치에 배치하는 제 4 규칙을 트리거할 수 있다. 이러한 방식으로, 전술한 코드 세그먼트는 태그 값으로서 레지스터에 저장된 4 태그의 초기 세트를 발생하는데 사용될 수 있다. 전술한 일반적인 기술은 임의의 원하는 수의 초기 세트의 태그를 발생하는 유사한 방식으로 더 확장될 수 있다."

In each add instruction forming above instructions 2 through 4 of the form, Rn denotes the target or result register in which to store the result of Add, and Ry also denotes the register or source operand. Instruction 2 of the preceding code segment may trigger a second rule that generates a second tag from the first tag and places the second tag in the memory location pointed to by R2 Instruction 3 of the preceding code segment further generates a third tag from the second tag; can trigger rule 3 which places a 3rd tag at the memory location pointed to by R3 Instruction 4 of the preceding code segment generates a further 4th tag from 3rd tag and places the 4th tag at the memory location pointed to by R4 In this way, the code segment described above can be used to generate an initial set of 4 tags stored in registers as tag values The general technique described above can be used to generate any desired number of initial sets It can be further extended in a similar way to generate tags of

Generally, when generating an initial set of tags, in at least one embodiment, the number of specific tags in the initial set may be a predefined number. Each special tag can be generated as a result of a different unique rule triggered when executing a command. Each instruction, such as the code segment above, can result in a cache miss, so the cache miss handler can be executed to compute an Rtag as part of the rule output for that particular instruction, where Rtag is one of the initial set of tags. In a similar way to the instructions in the code segments above, different code sequences can be executed at different times to generate additional tags using one of the initial set of tags. Thus, each tag in the initial set may represent a tag generator that is used to further generate other tag sequences. In the above example, the Add command can be used to generate the next tag generator that can be used to generate another full sequence of tags. As discussed below, an initial set of tag generators (additional tag generators themselves used as starting points for generating other sequences) are distinguished from regular or non-generated tags that can no longer be used as generators for generating other tag sequences. It can be. Thus, a specific command such as ADD can be used to trigger rule and miss processing to generate a set or sequence of tag generators. This can be contrasted with other commands, such as MOVE, which can trigger rules and miss handling that result in non-occurring tags in sequence. In conjunction with code such as malloc, the ADD instruction can similarly be used to generate a new application tag color generator used to generate a sequence of different colors for a first application (e.g., a new application tag color generator may be APP1 used to generate a sequence of different colors RED-APP1, BLUE-APP1, GREEN-APP1, etc. for the application). The tagged ADD instruction can then be used to obtain the next tag in a specific application specific sequence, such as one of RED-APP1-gen, BLUE-APP1-gen or GREEN-APP1-gen. The tagged MOVE command can then be used to generate the actual color RED-APP1, BLUE-APP1 or GREEN-APP1 from RED-APP1-gen, BLUE-APP1-gen or GREEN-APP1-gen respectively (where RED-APP1 , BLUE-APP1, GREEN-APP1 cannot be used to further generate additional tag sequences).

The bootstrap program's code segments that run while the PUMP is engaged, when executed, tag kernel code/instructions and additionally tag other code modules or entities with any desired special instruction tags so that these specially tagged codes have the desired privileges or You can also include additional code to trigger rules that allow you to have authorization. For example, a code segment may contain instructions that trigger a rule that causes such code to perform privileged tagging operations by tagging loader code and tagging the code of routines malloc and free with special instruction tags that extend privileges or authorizations. can Special code tags generate additional desired tags and also trigger rules that appropriately tag additional code and/or data with generalized tags, in a manner similar to that mentioned above using predetermined code sequences/instruction sets. , can be generated from an initial set of tags.

In at least one embodiment, additional countermeasures or techniques may be taken with respect to portions of the code segments noted above. For example, the 4 instructions mentioned above used to generate the initial set of tags are a "glue" policy that enforces sequentiality and atomicity, such as described elsewhere herein (example 400). may be included in the first command sequence using the rule of

After the code segments mentioned above are executed to generate the initial set of tags and further special tag the kernel code and any other desired instructions, control can be transferred to additional boot code. In at least one embodiment based on the RISC-V architecture, additional boot code may be executed at the hypervisor privilege level. This additional boot code may include, for example, instructions that trigger the loading of the initial rule set into the PUMP. Once boot is complete, the PUMP tag mode indicated by the tagmode CSR may be set to a level suitable for associating PUMP with respect to user code, such as running at a user privilege level (e.g., in example 910). As in 911c, the PUMP is associated and set to U (user) mode or tag mode indicating that it operates only at privilege level).

Referring to FIG. 72 , a flowchart of processing steps that may be performed in an embodiment consistent with the teachings herein is shown. Flow diagram 1600 summarizes the process described above. At step 1602, the tagmode is set to an off state where the tagmode CSR indicates a PUMP off state as described elsewhere herein with respect to 911a of example 910. At step 1604, the boottag CSR is initialized with a special bootstrap tag. At step 1606, execution of the bootstrap program begins. At step 1608, the bootstrap program may set the defaultatg CSR as the default tag. At step 1610, the tagmode CSR can be modified to a mode that writes the default tag to all results (eg, each Rtag=default tag while in this tag mode). At step 1612, an instruction that triggers a rule to initialize a memory location and tag the memory location with a default tag may be executed. At step 1614, the tagmode CSR may be changed to a mode that associates the PUMP during execution of the subsequent code segment at step 1616. At step 1616, the subsequent code segment is executed in conjunction with the PUMP. A code segment generates an initial set of tags, clears the boottag CSR, tags the kernel code, and tags additional code segments with special tags to give those tagged code the extended capabilities, authorizations, and privileges rules as desired. Contains commands that trigger At step 1618, control can be transferred to additional boot code that is executed. When the boot process is complete, the system is now ready to execute user code with PUMP associated and in an operational state for user code execution.

Now, in more detail how to generate tags from bootstrap tags. A tag generation process starting with a bootstrap tag may be called a tag tree or tree of life. More generally, the tag generation process forms a hierarchical structure as shown in example 1620 of FIG. 73 .

Example 1620 shows boottag 1621 as the origin of the tag generation process. Elements 1621a through 1621d may represent an initial set of tags generated, for example, as described above. In this example, the initial set of tags 1621a through 1621d may include an initial OS special instruction tag 1621a used to further generate a sequence 1622 of an infinite number of special instruction tags, followed by an infinite number of special instruction tags. may be applied to 1623 to tag different code or instructions of module 1624. From the initial OS special command tag 1621a, additional tags 1622 can be created for the different modules to be tagged. For example, a first OS special instruction tag 1622a is generated for malloc and applied to malloc (1623a), so that the instructions in malloc are tagged with special instruction tag 1622a (1624a). In this way, the malloc code has a special code that identifies malloc as the tag generator (e.g., indicating that the malloc code has the authority to generate more new tags and tag other memory cells with more newly generated tags). Can be tagged with command tags.

In this example of malloc, 1621b may be the initial malloc tag used to generate more malloc tag generator application tags 1626, one per user application, since an instance of malloc is included in each user application. The present invention seeks to authorize each such malloc instance in each user application to generate a different colored tag included in 1625.

In general, example 1620 shows initial tag sets 1621a through 1621d for special instruction tag 1621a, Malloc 1621b, CFI 1621c, and Taint 162d. Thus, each of the tags 1621a to 1621d in the vertical display of tags in the first row (other than boottag 1621) represents a different initial tag used to create the infinite tag sequence. For example, value 1621a is used to further derive or generate an infinite number of special command tags 1622. Value 1621b is used to further derive or generate an infinite number of values 1626. Each instance of 1626 can be further used as a generator of another infinite sequence of tags for each application. For example, 1626a represents a generator value used to further generate another infinite sequence 1629 of different colors used for a single application app1. In a similar manner, each different generator value of 1626 can be used to generate an infinite number of more colors for each application.

Value 1621c can be used as a generator to generate an infinite number of further values 1627. Element 1627 is similar to 1626 in that it represents authority or functionality to further generate another infinite sequence each time CFI tag generator n occurs for a particular application or app N. For example, 1627a represents a generator value used to further generate another infinite sequence 1630 of different colors used for a single application app1. In a similar manner, each different generator value of 1627 can be used to generate an infinite number of more colors for each application.

Value 162d can be used as a generator to generate an infinite number of further values 1628. Element 1628 represents a permission or function to further generate another infinite sequence whenever tag generator n for a particular application or app N occurs. For example, 1628a represents a generator value used to further generate another infinite sequence 1631 of different colors used for a single application app1. In a similar manner, each different generator value 1628 can be used to generate an infinite number of more colors for each application.

As shown, the sequences or subtrees of CFI and Taint, respectively, from (1621c to 1621d) are similar to the Malloc subtree starting from (1621b). In example 1620, nxtTag or TInxtTag is used to indicate the next element of the generated infinite sequence, and getTag is used to extract the next tag from the sequence member. In general, getTag can be used to indicate retrieving the tag itself to use, not the tag generator. If a usable tag is provided to a particular code segment and is expected to be used, the present invention does not wish to also endow the code segment with the ability to generate the tag. For example, you want to provide each application with a Malloc tag generator for that application (e.g., App1ColorTagX), but you do not want to provide an application with the ability to generate Malloc tag generators for other applications. So, getTag changes the type from generator to instance. The difference between nxtTag and TInxtTag is that nxtTag can be used without "tagged instructions", whereas TInxtTag can only be used with properly tagged instructions.

The Malloc Application Tag sequence 1626 allows the operating system or loader to generate a color tag generator for each application. For example, element 1626a represents an application-specific color tag generator value used to generate tags of application color sequence 1629. Within the application, the AppYColorTag sequence 1629 causes malloc to generate permissions for each color. That color right can be used to: color cells for allocated memory, color pointers for allocations (eg, when free is called) and make cells of that color free. The use of color, for example with malloc and free, is described elsewhere in this specification.

In this way, different tags can be reserved for different uses. From the initially tagged kernel instructions as mentioned above, kernel code can be executed further tagging other code parts with different capabilities or authorizations. For example, the operating system's kernel code may further tag other code entities, such as loaders, with special privileges, giving the loader the ability to further tag other code and data, generate additional tag generators, and the like. can When loading a user program containing malloc, the loader may further tag the malloc code with special instruction tag(s) to mark it as malloc code providing the ability to further generate other tags used to color different memory regions. there is. Thus, certain instruction tags placed in the loader's code provide the loader with a set of privileges. Placing a second, different instruction tag on the malloc code gives the malloc code a different set of privileges. Generally, when performing tag firing of a sequence, the current tag in the sequence is stored as state information that is referenced and used in connection with firing the next tag in the sequence. As described herein, this state information about the current tag in the sequence can be stored and used in the metadata processing domain. Current tags, or more generally metadata processing state information, can be saved and restored as a result of rule processing and cache miss processing. A current tag in a sequence, such as the last color assigned for use in a particular application, can be stored as a tag on a memory location designated as the current state of the sequence. When an application's new next color needs to be allocated, malloc's code triggers a rule to retrieve the last allocated color for the application and uses the last allocated color to determine the next color in the application-specific color sequence. In general, generating a unique sequence of tags may involve the execution of a command that triggers a rule to:

1. Store/hold sequence state in the tagged portion of an atom (eg register, memory location);

2. Execute a command that triggers a rule to fire the next tag in the sequence using the archived/saved sequence state; and

3. Save/keep the next tag of the sequence (generated from 2) in the tag part of the atom where the next tag is now the updated current state of the sequence.

Referring back to example 1620, the loader may use malloc to allocate a particular one of the malloc tag generator application tags of 1626 for each application. The loader can execute code that triggers a rule to generate the next malloc tag generator tag, e.g., 1626a, and then store this tag as state information by tagging a memory location. Subsequently, on the first call to malloc by the application, the malloc code triggering the rule is executed, retrieves the archived malloc tag generator tag, uses the archived tag to generate the application's first color, then writes the stored state. You can update and save the first color as the last or newest color created for the application. On the second call to malloc by the application, the malloc code that triggers the rule is executed, retrieves the previously stored primary color, uses the stored primary color to generate the application's secondary color, and then The state information can be updated so that the second color can now be stored as the last or newest color generated for the application. In a similar manner, other subsequent calls to malloc may trigger other rules to assign additional colors based on state information maintained for the application (eg, most recently assigned color).

Aspects of direct memory access (DMA) architectures that may be included in embodiments according to the techniques herein will now be described. In general, the following paragraphs describe I accessing data stored in memory of a second interconnect fabric using untagged data by intervening DMAs issued from sources such as untrusted devices connected to the first interconnect fabric using untagged data. The use of /O PUMP is explained.

Referring to FIG. 74 , examples of components that may be included in embodiments described herein are shown. Example 1500 includes similarly numbered components to components in example 700 and other examples (eg, FIGS. 57-60 ) described elsewhere herein. Example 1500 also includes I/O PUMP 1502 and an additional actor, a DMA request source or initiator (which can issue DMA requests to access data stored in memory 712c). 1504a to 1504c). Example 1500 includes Ethernet DMA device A 1504a, Ethernet DMA device B 1504b and a universal asynchronous receiver/transmitter (UART) or serial communication device (universal asynchronous receiver/transmitter) connected to untagged fabric 715. 1504c). A DMA request to read or write data may originate from one of the devices 1504a - 1504c. This request is forwarded to I/O PUMP 1502, which performs processing to determine if the DMA request is allowed, and if so, allows the request to proceed. Accordingly, I/O PUMP 1502 may be characterized as arbitrating DMA requests received over untagged fabric 715, so the general assumption is that a device connected to 715 issuing such a DMA request that it can be unreliable.

In at least one embodiment, I/O PUMP 1502 may be an instantiation of a PUMP as described herein (eg, FIG. 22 ), the difference being that the rules enforced are DMA accesses to memory 1712c. It is a rule of the DMA policy that controls The use of the I/O PUMP 1502 described above is consistent with a general architecture that ensures that all instructions involving memory operations are mediated by rules. If autonomous DMA devices 1504a through 1504c allow direct, unmediated access to memory, DMA devices 1504a through 1504c may break the invariant and safety characteristics enforced by the rules. Consequently, to allow DMA, embodiments consistent with the techniques herein may also enforce rules regarding DMA access to memory 712c. Similar to PUMP, which enforces rules for processor instructions, I/O PUMP 1502 enforces rules necessary for memory loads and stores in DMA devices such as 1504a through 1504c. Normally, the I/O PUMP arbitrates all loads and stores. In at least one embodiment described herein based on the RISC-V architecture, the I/O PUMP uses CSR and in a manner similar to that described elsewhere herein with respect to PUMPs used in the RISC-V architecture. to handle rule cache misses. I/O PUMP 1502 has a set of CSRs similar to PUMPs, but accesses them via memory mapped addresses. For example, access to the I/O PUMP CSR described in the next paragraph with respect to example 1520 may be tagged protected using a rule. A rule cache miss encountered when trying to find a rule in the I/O PUMP may trigger an interrupt to be serviced by the processor RISC-V CPU 702. The I/O PUMP uses the same rule resolution process as processor 702, but there is a single DMA policy containing only the rules for DMA loads and stores trying to access data in memory 712c. The I/O PUMP atomically writes to memory 712c (eg, writes tags and values in a single atomic operation). However, in some embodiments, the complete process from reading the Mtag to writing the Mtag (e.g., performing a tag check or verifying and writing) may not be used atomically with the standard store. can

I/O PUMP 1502 is a rules cache for SDMP. I/O PUMP provides a mapping between a set of tags involved in a DMA operation and an operation result. In at least one embodiment, I/O PUMP runs independently of processor 702. Since the I/O PUMP 1502 is a cache, it will generate a miss when it has not seen the input set before (forced) or cannot hold to the rules (capacity or possibly conflict). This results in rules cache misses associated with I/O PUMPs in a manner similar to rule cache misses as described herein for PUMPs. A miss involving the I/O PUMP rules cache 1502 - equivalent to a missed trap by the service processor 702 - generates an interrupt that is handled in software by the rules cache miss handler system. On rule misses relating to I/O PUMP 1502, the input is executed via the I/OPUMP CSR described below (e.g., example 1520) (e.g., on code of processor 702 in the metadata processing domain). ) is passed to the miss handler, and the rule insert is provided back to the I/O PUMP via CSR. An I/OPUMP miss causes the I/O PUMP to be disabled until serviced by the processor 702. In at least one embodiment, the disabled state of the I/O PUMP means that all DMA transfers that the I/O PUMP mediate are suspended until the I/O PUMP miss is serviced.

Consistent with the discussion of PUMP elsewhere in this specification, an I/O PUMP input is an opgroup (opgrp), a DMA command, and a tag for its operand (e.g., PCtag, CI tag, OP1 tag, OP2 tag, Mtag (sometimes referred to herein as MRtag) The I/O PUMP output may include Rtag and PCnew tags (the tag for the PC of the next instruction) as described herein I/O PUMP and In relation to this, these inputs and outputs may have different meanings and values as follows in one embodiment.

The following are I/O PUMP inputs in one embodiment:

1. Opgrp - Currently there are two: load and store

2. PCTag - Status of DMA I/O devices (similar to PCtag for code)

3. CItag - A tag that identifies a DMA IO device (similar to a command tag in a designated code area)

4. OP1tag - always assumed to be "public, untrusted" (not physically represented in IOPUMP cache, but used in rules)

5. OP2tag - same as OP1tag

6. Mtag - tag on memory input to DMA operation

7. byteenable - which bytes are being read/written?

Following are the I/O PUMP outputs in one embodiment:

8. Rtag - tag on memory result for store

10. PCnew tag - state of DMA I/O device after this operation

In an I/O PUMP, there may be no programmable opgroup mapping table (e.g., YES 420). Rather, the opgroups that the I/O PUMP uses to find rules may be fixed opcodes representing a single opgroup for DMA load and DMA store operations. In at least one embodiment, there is no care masking for I/O PUMP.

When there is a rule cache miss with respect to PUMP, e.g., as described herein in FIG. 22, the processor 702 expects to automatically reissue the instruction that caused the miss after the corresponding rule has been inserted into the PUMP rule cache. It can be. As a result, rule injection expects to simply place the rule into the PUMP cache and issue the command again to get the tagged result. However, the behavior according to the DMA operation is different from the previous one. DMA operations are interrupted and are not expected to require retry operations. To support this DMA operation, rule insertion for I/O PUMP can be handled differently. In particular, once an I/O PUMP has failed due to a miss, processing holds pending DMA operations and causes processor 702 to wait (e.g., to calculate the output tags Rtag and PCnew tag for the new rule). (assuming it is allowed) supplies a missing output tag for the rule. When an output is supplied, in addition to triggering a rule write into the IOPUMP, the output is forwarded to the DMA pipeline as if it came from an I/O PUMP (e.g., described with respect to example 1540 below); So the operation can continue without forcing the I/O PUMP to reissue the operation. Rule violations can be handled by providing the specified disabled-DMA-device tag to the updated PCtag, PCnew tag, which means the operation is disallowed and no further DMA from that particular DMA device 1504a through 1504c is allowed until the PCtag is reset. It will signal that the action will not be allowed. In general, a device tag for a particular DMA device issuing a DMA operation or DMA request, e.g., one of 1504a through 1504c, is a device tag that uniquely identifies the issuing DMA device (e.g., the source of the DMA request). It may be a specific value of the CI and a specific value of the PC tag indicating the current state of the PC tag DMA device. In at least one embodiment, the PC tag may be set to a specific value at which point it disables further processing of DMA requests from the specific DMA device identified by the CI tag.

Referring to FIG. 75, a table of CSRs that may be used by an I/O PUMP in an embodiment according to the technology herein is shown. The table 1520 includes an address column 1524 (indicating the memory mapped address of the CSR), a name column 1526, and a description column 1528. Each row of table 1520 corresponds to one of the defined CSRs used by the I/O PUMP. Row 1522a indicates that the CSR transaction id has address 0x00. A write to transaction id CSR increments the current transaction id stored (eg, to prefetch), and a read from transaction id CSR returns the current transaction id stored in transaction id CSR. Row 1522b indicates that the CSR opgrp has an address of 0x01. The opgrp CSR contains the opgroup for the current DMA instruction and is used as input to the rule miss handler in case of a rule miss. Row 1522c indicates that CSR byteenable has address 0x02. A byteenable CSR indicates which bytes of the word affect the DMA operation and are used as inputs to the rule miss handler on rule misses. Consistent with other discussions herein, this allows policies to provide byte-level protection; A triggered rule may check if the bytes of data requested by the DMA are allowed to be accessed by the particular DMA device initiating the request, for example by specially tagging a portion of memory that is accessible to a different DMA device. Row 1522d indicates that the CSR pctag has address 0x03. The pctag CSR contains the PC tag for the current DMA instruction and is used as input to the rule miss handler on rule misses. Row 1522e indicates that CSR citag has address 0x04. The citag CSR contains the CI tag for the current DMA command and is used as input to the rule miss handler in case of a rule miss. Row 1522f indicates that the CSR mtag has address 0x07. The mtag CSR contains the M tag for the current DMA command and is used as input to the rule miss handler on rule misses. Line 1522g indicates that CSR newpctag has address 0x08. The newpctag CSR contains the PC new tag that is placed on the PC after the completion of the current DMA instruction (e.g., the output of PUMP and cache miss handling). Line 1522h indicates that the CSR rtag has address 0x09. The rtag CSR contains the tag placed on the memory result of the current DMA instruction (e.g., the output of PUMP and cache miss handling). Row 1522i indicates that the CSR commit has address 0x0A. Writing to the commit CSR causes a comparison of the value written to the commit CSR with the current transaction id (stored in the transaction id CSR). If the two above match, the match triggers a write of the rule to the I/O PUMP. The written rules include the opcode for the current DMA instruction and tag inputs and outputs (as determined by miss processing). Row 1522j indicates that the CSR status has address 0x0E. The status CSR contains a value indicating the status of the I/O PUMP. For example, in one embodiment as described herein, the status CSR may indicate whether the I/O PUMP is enabled or disabled. This may be disabled in case of a PUMP I/O rule cache miss as described elsewhere herein. Row 1522k indicates that the CSR flush has an 0x0F address. The flush CSR, when written, triggers a flush of the I/O PUMP (eg, flushes or clears rules from the I/O PUMP cache).

In at least one embodiment, if bit 0 of the status CSR is 1, it means I/O PUMP is disabled, otherwise, if bit 0 has a value of 0, it means I/O PUMP is disabled. . A PUMP I/O miss disables the pump. Bit 1 of the Status CSR indicates whether the PUMP has failed and is waiting for service (e.g. Bit1=1 means I/O PUMP Fault/Cache Miss and Waiting for Service). Bit 2 of the Status CSR indicates whether an I/O PUMP rule miss is currently being resolved by the rule cache miss handler, and if the transaction id matches, it will provide the inserted result directly to the pending miss operation. All of the aforementioned bits of the status CSR are reset by a commit operation (success or failure) (e.g., bit 0 = enabled, bit 1 = no fault, bit 2 = no pending misses). Writing to the state CSR may also be performed to reset the aforementioned bits, eg as needed to initially enable the I/O PUMP at startup. A reset of the state CSR for a failed write allows the DMA device to retry the operation and trigger the fault again.

A load/store memory operation into an I/O PUMP CSR by processor 702 must be tagged with an iopump CI tag. There must be a policy rule in place that restricts actions to commands with the iopump CI tag. Individual I/O PUMP CSRs do not have tags.

Each device 1504a - 1504c on the untagged or untrusted fabric 715 can be configured with its tag presented as a device tag when the processor performs a load or store to the device (e.g., device 1534b) where the tag is stored in the register file described below and specified as a CI tag when the particular device performs a DMA load or store). This allows fine-grained control over which codes and authorizations can directly access which devices. All load to and store devices are given the same tag, and the tag does not change with load and store operations. The specific device tags associated with and identifying each device 1504a - 1504c may be stored in a device register file. The specific device tags specified for devices 1504a through 1504c can only be changed by modifying the device register file. The device register file may indicate for each device 1504a - c a unique target device id (used to identify devices on untagged or untrusted fabric 715) and a target device specific tag for the unique target device id. . In at least one embodiment, the device register file itself can be accessed as a device on untrusted fabric 715 using its own device tag. To bootstrap the use of the device register file, the device tag register file's own tag (stored in the device register file) may be written to the file before PUMP is enabled during startup. For example, a self tag in the device tag register file may be written to the file as part of the boot process while PUMP is off (eg, tagmode indicated by 911a of example 910). The CI tag of the command can identify the target ID of the DMA target device performing the load or store command, and in the above command the CI tag is used in rules triggered by those load and store operations to determine the target ID of the specified DMA device. You can restrict (eg allow or disallow) certain load or store operations. Also, if a particular DMA device performs a disallowed load and/or store operation, the state associated with the particular DMA device is modified to be disabled, allowing further requests (e.g., DMA loads and stores) to be ignored.

As mentioned above, a DMA device that initiates or is the source of a DMA request or command may have an associated state indicated by the PCtag of the DMA device. In particular, a unique PCtag can be used to indicate a disabled state for allowed DMA operations from a DMA device (identified by the CI tag). A disabled initiator may reject its DMA request upon initiation of a DMA or Trustbridge pipeline described below (e.g., examples 1530 and 1540).

It should be noted that embodiments may have a single I/O PUMP to arbitrate all DMA traffic, an I/O PUMP per DMA engine, or multiple I/O PUMPs to arbitrate DMA traffic for multiple DMA engines. Example 1510 shows a single I/O PUMP to a single DMA engine (eg, single memory 712c). As in example 1500, the use of a single I/O PUMP may be a bottleneck, so embodiments may choose to have multiple I/O PUMPs arbitrate I/O traffic. In such an embodiment where there are multiple I/O PUMPs, each can be independently enabled or disabled so that a first portion of one or more of the multiple I/O PUMPs is disabled (due to an I/O PUMP miss). Even if enabled, the remaining second portion of the multiple I/O PUMP may be disabled to continue servicing DMA requests.

In at least one embodiment, different DMA devices acting as initiators or sources of DMA operations may each be allowed to access only specified portions of memory 712c. The different portions of memory 712c accessible via DMA may each be tagged with separate tags. For example, device 1504a can access a first address range of memory 712c and device 1504b can access another second address range of memory 712c. A memory location 712c corresponding to the first range may be tagged with a first tag, and a memory location 712c corresponding to a second range may be tagged with a second tag. In this way, a rule can be used that enforces or restricts device 1504a's access to memory locations within a first range and device 1504b's access to memory locations within a second range. As a variant, different tags may be associated with the type of access allowed (eg read only, write only read and write). In a similar manner, in an embodiment with multiple DMA engines accessing the same memory 712c, the different portions of a single memory 712c accessible exclusively to each DMA engine may be uniquely tagged, so the rule is Enforces and limits each DMA engine's access to a specified address range of memory locations.

Referring to FIG. 76 , in an embodiment according to the techniques herein, a trusted fabric 1532 (e.g., corresponding to tagged interconnect fabric 710) and an untrusted fabric 1536 (e.g., corresponding to tagged interconnect fabric 710) An example depicting data flow between interconnect fabrics (corresponding to unmodified interconnect fabric 715) is shown. Element 1534 generally represents processing performed by I/O PUMP 1534a in connection with DMA arbitration between 1532 and 1536. Element 1534 may represent a trust bridge or DMA pipeline 1534c performed to verify and service DMA operations as part of DMA arbitration. Element 1538a may represent an output channel from untrusted fabric 1536 (e.g., to DMA devices 1504a-1504c of example 1500). Element 1538b may represent an input channel to untrusted fabric 1536 (eg, from one of devices 1504a - 1504c ). Typically, I/O PUMP 1534a needs to verify that the tag on the target memory allows the requested DMA access by issuing a read request during DMA read and write operations. The I/O PUMP will have to buffer the request and perform master control of the tagged communication operation (as described between processing stages in example 1540 below).

Element 1537 represents a value provided as input to load (or retrieve) the I/O PUMP CSR as described in example 1520. In addition, the device state information of the different DMA device initiators is PCtag (e.g., the state of the DMA device, such as whether requests from this DMA device are disabled) and (e.g., 1504c)) of the DMA device initiator's CItag (eg, the unique identifier of the DMA device) may be stored in untrusted fabric device register file 1534b. An entry in the device register file 1534b for the particular DMA device performing the DMA load or store may provide the CItag and PCtag values for the current DMA load or store. Element 1535a indicates the channel used for the device on untrusted fabric 1536 making the 1534 arbitrated DMA processing request of 1534. Element 1535b may represent a channel used to return the result of 1534's arbitrated DMA request to untrusted fabric 1536.

Elements 1531a-1531b represent channels for forwarding DMA requests from the untrusted fabric 1536 to the trusted fabric 1532 (through the DMA arbitration process at (1534)). In particular, channel 1531a is for forwarding initial tag read (unvalidated) DMA requests to trusted fabric 1532, and channel 1531b is for forwarding final writes of data using updated tags. This is the second channel for The use of two channels may become more apparent when considering further discussion regarding DMA or Trustbridge pipelines described below with respect to example 1540. Element 1531c represents a channel from the trusted fabric 1531c to the untrusted fabric through the DMA arbitration process 1534.

In one embodiment, element 1534 may represent a DMA processing pipeline as shown in example 1540 of FIG. 77 . Example 1540 illustrates DMA operations performed by DMA devices 1504a through 1504c from untrusted or untagged fabrics (e.g., 1506 of example 1500, 1536 of example 1530). Represents a 4 stage processing pipeline for servicing. Elements 1542, 1544, 1546 and 1548 may represent rules triggered as a result of the DMA request. Element 1545 represents, for example, an I/O PUMP as described in connection with other figures (e.g., 1502 of 1500). Element 1543 represents a stage of the DMW processing pipeline. In the first stage 1541a, a DMA request is received from the untrusted fabric, and the unsubstantiated request follows the rules of the second memory fetch stage 1541b to obtain the requested DMA data and its associated tag from the memory 712c. (1542). The tag information fetched from memory for the DMA requested data is provided as input to the third verification stage 1541c where a lookup is performed in the I/O PUMP cache 1545 for the rule corresponding to the current DMA request. If no rules are found on the I/O PUMP, then I/O PUMP processing may be stopped and disabled at stage 1541c, but a DMA miss handler may be executed on processor 702 to output Rtag and PCnew tags for the DMA request. Calculate or otherwise determine that the current DMA request is disallowed (thus triggering a fault or trap). Assuming the rule for the current DMA request is found in the I/O PUMP, it is determined that the DMA request is allowed to execute. If the DMA request is a write request, the write data of the DMA request along with its tag information is written back to the memory 712c at stage 4 (1541d). For a DMA write operation, once the write is complete, a response 1548a can be provided to the untrusted fabric (and then to the DMA device that initiated the DMA request). For a DMA read operation, a response 1546a is returned to the untrusted fabric (and then to the DMA device that initiated the DMA request), in which case the response includes the requested data fetched in stage 2 1541b.

Element 1542 passes requests from the untrusted fabric during stage 2 1541 b while memory fetches are being performed (at stage 3 1541 c) and passes the I/O request to I/O PUMP 1545 (at stage 3 1541 c). It may indicate rules for passing information (from stage 1 1541a). Element 1544 gathers tag responses from the trusted fabric, formulates the actual rules input to the I/O PUMP, and transfers information from stage 1541b to writeback stage 154dd to be merged with the output of the I/O PUMP. can indicate the propagation rule.

As a variation of the foregoing embodiment, reference is made to example 1500 again. In at least one embodiment, rather than storing rules in an I/O PUMP cache as described above, an I/O PUMP may be implemented as a hardwired I/O PUMP, in which the rules are fixed. It can be implemented using dedicated hardware, such as hardwired logic gates to implement a set of I/O PUMP load and store rules.

As another variation, the I/O PUMP could alternatively be defined as a programmable cache in another embodiment as described with respect to example 1500, the difference being that as a rules cache, the I/O PUMP has finite capacity. and is populated with a fixed set of rules that are all stored in the I/O PUMP cache. In this latter embodiment, there is never a rule cache miss for an I/O PUMP since the I/O PUMP can be filled with the complete set of all DMA rules. Thus, there is absolutely no need to service I/O PUMP rule cache misses.

Techniques that may be used in connection with initializing, setting, or resetting a tag that may be associated with a memory location will now be described. Consistent with other descriptions herein, tags used in connection with such techniques may be non-pointer tags (a non-pointer tag is an actual tag value for an associated memory location) or a pointer tag (a pointer tag is a pointer or actual tag value or is the address of another memory location that contains values). For example, a pointer tag associated with a memory location may be used in conjunction with a composite tag where a pointer identifies an address in memory that contains multiple tag values, eg for multiple composite policies implemented in parallel. As described elsewhere herein, exemplary composite policies that may be supported in parallel include the memory safety policy and the CFI (Control Flow Integrity) policy described herein.

Processing performed in relation to memory safety and stack policies may include, for example, setting or initializing a number of tags associated with memory locations to specific values. For example, when the allocation of a memory area can be associated with a particular color, for example, each tag associated with a memory location within the area must be initialized to have a particular color value. As another example, when putting a memory area back, for example freeing a memory area, all memory locations in the free or unallocated area may be initialized with a specific tag value representing the free or unallocated memory location.

The processing performed to initialize or reset the tags of all memory locations within the region can consume an unacceptable amount of time, and becomes especially unacceptable as the size of the memory region to be tagged increases. Accordingly, techniques for efficiently initializing or setting (tagging) a tag of a memory location are described in the following paragraphs. In at least one embodiment, tag initialization or setup may be performed, for example, in connection with allocating an area of memory or freeing a memory area. These techniques described herein are scalable for use with large memory areas. Although these techniques are illustrated below with respect to tags in memory locations, more generally, these techniques may be used in connection with initializing, setting, or resetting values associated with data items or entities, respectively.

In at least one embodiment, tags of memory regions and associated memory locations may be represented in a hierarchical structure or arrangement in which the leaves of the hierarchy represent tags to memory locations. For explanatory purposes, the following discussion refers to a tree as a hierarchical structure. More generally, however, any suitable hierarchical structure may be used to represent the address space associated with a region of memory locations.

As an extreme example, in one embodiment, the leaves of a tree or hierarchy may represent individual words in memory and hold tags. However, if an entire subtree is homogeneously tagged with the same tag value, the techniques herein may simply store the tag value at a particular node and associated level within the tree without further indicating any descendant nodes of the subtree. In this case, the node's tag value specifies the tag value for a number of memory locations in a specific region (eg, contiguous or contiguous range of memory addresses). In this way, if there are large areas that are homogeneously tagged, storage can be saved in storing the tagged values. In the worst-case scenario where there are no homogeneous tag values (e.g., two memory locations with consecutive addresses do not have the same tag value), each leaf of the tree corresponds to a single memory location, such as a single word within a region. Indicates the tag value.

In such a hierarchical structure, such as a tree as described in the next paragraph, a process of re-tagging or initializing a power-of-two memory region can be performed by simply writing one node back into the tree. For non-power-of-two regions, processing is performed to divide the region into a minimum set of power-of-two regions (e.g., at most 2*log ₂ (region size) of such a region in the minimum set). It can be. When a tag of a particular word or memory location is needed (eg, when reading a tag for an associated memory location), a process of determining the tag using the tree may be performed. In at least one embodiment described below, a hierarchy of cache memories may be used at different levels of the tree. The tag value may be provided by the cache associated with the highest level of the tree that has the cache hit relative to the desired memory location (eg, performing a cache lookup of the tag value for the address of the desired memory location). Regarding the processing performed to write or modify a tag value associated with a memory location, the processing is a single representation representing a subtree or multiple writes (e.g., 2*log ₂ (region size) log write). It may include performing an entry. Such multiple writing may be performed, for example, in response to modifying or setting a tag of a first memory location included in a homogenously tagged first memory area prior to modifying or setting a tag value. In this case, setting or changing the tag value causes the first memory area to no longer be tagged as homogeneous, and accordingly, the hierarchical structure representing the tag value for the first memory area is Update the subtree to further decompose.

Referring to FIG. 78 , an example of a hierarchical structure that may be used to represent a tag value for an address space corresponding to a memory area in an embodiment according to the technology herein is shown. Example 100 shows a tree as a hierarchical structure used to represent a memory region containing 8 memory locations for simplicity of illustration. More generally, the techniques herein can be applied to any number of levels, any suitable number of nodes at each level, any suitable number of child nodes per parent node, and any suitable number of nodes at each level. It can be used to represent tag values for any address space or region of memory using an appropriate hierarchy.

Example 100 shows a binary tree representation of tag values for 8 memory locations, including addresses 0-7. The tree in this example may contain up to four levels of nodes, depending on which, if any, of the eight memory locations are tagged homogeneously using the same subtree of structure 100 . In this example, the entire memory region of 8 memory locations can be repeatedly partitioned into two smaller memory regions squared, each such division of the smaller memory region corresponding to a different level of nodes in the tree. For example, level 1 (104) contains node A1 corresponding to the entire address space 0 to 7 which is divided into two smaller regions each represented by the nodes (nodes B1 and B2) in level 2 (106). do. Level 2 (106) includes node B1 associated with addresses 0-3 and node B2 associated with addresses 4-7.

Each of the nodes B1 and B2 at level 2 (106) can be further divided into two smaller regions each represented by a node at level 3 (108). Node B1 and its associated address ranges 0 to 3 are divided into two regions represented by nodes C1 and C2, where C1 is associated with address range 0-1 and C2 is associated with address range 2-3. Similarly, node B2 and its associated address ranges 4 to 7 are divided into two regions represented by nodes C3 and C4, where C3 is associated with address ranges 4-5 and C4 is associated with address ranges 6-7. .

Each of the nodes C1 to C4 in level 3 (108) can be further divided into two smaller regions each represented by a node in level 4 (110). In this example, the nodes at level 4 each represent a tag value for a single word or memory location. Node C1 and its associated address range 0-1 are divided into two regions represented by nodes D1 and D2, where D1 is associated with address 0 and D2 is associated with address 1. Node C2 and its associated address ranges 2-3 are divided into two regions represented by nodes D3 and D4, where D3 is associated with address 2 and D4 is associated with address 3. Node C3 and its associated address ranges 4-5 are divided into two regions represented by nodes D5 and D6, where D5 is associated with address 4 and D6 is associated with address 5. Node C4 and its associated address ranges 6-7 are divided into two regions represented by nodes D7 and D8, where D7 is associated with address 6 and D8 is associated with address 7.

All nodes (A1, B1-B2, C1 to C4, and D1 to D8) may represent the maximum number of possible nodes that may exist in the hierarchical representation of tag values for a region of 8 memory locations. However, as described below in more detail, specific nodes included in the tree representing tag values stored in memory locations 0 to 7 may vary depending on specific tag values and homogeneous and non-homogeneous tag regions represented at various points in time. . The levels of the hierarchy may be ranked from the highest level corresponding to the root or level 1 (104) node to the lowest level corresponding to the lowest level 4 (110) node.

For a first example in connection with the description herein, reference is made to 120 of FIG. 79 . In this first example, all memory locations associated with nodes at a particular level of hierarchy 120 have the same tag value T1, thus representing a subtree of homogenously tagged memory locations, and nodes at a particular level are all Having the tag value of that memory location, no further descendant nodes in the subtree need be referenced to determine the tag value for any of the homogenously tagged memory locations. For example, if all memory locations 0 to 7 contain the same tag value T1 with respect to initializing a memory region with the same tag, then the tag value T1 for memory locations 0 to 7 is (e.g., "by node A1" tag=T1") may be stored at node A1. In at least one embodiment, it is no longer necessary to store additional tag values for other nodes in the tree because the tag values for the entire region for addresses 0 through 7 are represented by a single node A1. In this case, element 122 represents a single node that may be included in a hierarchical representation of tag values stored in memory locations having addresses 0 through 7, and the remaining nodes B1, B2, C1 through C4, and D1 through D8 are hierarchical. may be omitted from the expression

In the second example, reference is made to 130 in FIG. 80 . In this second example, assume that memory locations 0 to 3 have the same first tag value T1 and memory locations 4 to 7 have the same second tag value T2 (the first and second tag values are different ). In this case, node A1 is an indication that node A1 does not specify homogeneous tags for memory locations 0-7 and that the tag values for memory locations 0-7 are specified by nodes at one or more lower levels of the hierarchy. (e.g., indicated by the "TAG VALUE = NO TAG VALUE" indication by node A1). At level 2 of the hierarchy, a first tag value T1 may be stored in node B1 (represented by node B1 by the "TAG VALUE=T1" indication), and a second tag value T2 may be stored in node B2 (node B1). marked "TAG VALUE=T2" by B2). The subtree B1, C1, C2, D1 through D4, rooted at B1, represents a set of homogeneously tagged memory locations 0 through 3. The subtree B2, C3, C4, D5 through D8, rooted at B2, represents another set of homogeneously tagged memory locations 4 through 7. In at least one embodiment, there is no longer a need to store additional tag values for other nodes in the tree at levels 3 and 4 (e.g., nodes C1 to C4 for level 3 and nodes D1 to D8 for level 4). is absent, because tag values for the entire area for addresses 0 to 7 are represented by nodes B1 and B2 at level 2. In this case, element 132 represents a node that may be included in the hierarchical representation of tag values stored in memory locations using addresses 0 to 7, and the remaining nodes (C1 to C4 and D1 to D8) may be omitted from the hierarchical representation. can

At a first point, all tags have the same tag value, so the tag hierarchy can be as described with respect to example 120 with only a single node 122 . At a second time point that follows, tag values for addresses 0 to 3 may be modified to the same first tag value T1 and addresses 4 to 7 may be modified to the same second tag value T2. As a result of the tag modification described above, two additional nodes B1 and B2 as described above in example 130 may be added to the hierarchy. At a third time point that follows, now assume that the tag values for addresses 0 through 3 remain the same as in example 130. However, the tag values for addresses 4 through 7 can be modified as described below with respect to FIG. 81, whereby (C4 and D5-D6) are added to the tag hierarchy.

In the third example, reference is made to 140 in FIG. 81 . In this third example, assume that memory locations 0 through 3 have the same first tag value T1 as described above (where the first tag value T1 is the node B1 and the subtrees B1, C1, C2, D1 through D4), B1 of the subtree represents a homogenously tagged set of memory locations 0 to 3. In addition, memory locations 4-5 each contain a different tag value, where memory location 4 has a tag value T3. , memory location 5 has a tag value T4, and memory locations 6-7 are homogeneously tagged and contain the same tag value T5 In this case, nodes A1, B2 and C3, consistent with the above description, have: Each particular node may include an indicator that does not specify a tag value (eg, TAG=NO TAG), such that nodes at one or more lower levels in the hierarchy may have specific memory associated with nodes A1, B2, and C3. Specifies a tag value for a location, eg, node C3 corresponding to memory location 4-5, whereby node C3 does not specify a tag value, so that a node at one or more lower levels in the hierarchy has memory location 4-5 node D5 at level 4 may specify a tag value T3 for memory location 4 (e.g., by node D5 the TAG=T3 indicator). and node D6 at level 4 may specify a tag value T4 for memory locations 6-7 (e.g., the TAG=T4 indicator by node D6. Node C4 corresponding to memory locations 6-7). can specify the tag value T5 as a homogenous tag value common to memory locations 6-7 (e.g. by node C4 the TAG=T5 indicator), no need to store additional tag values at nodes D7 and D8. indicates that there is no (e.g., descendant nodes D7 and D8 of C4 no longer need to be examined.) In this case, element 142 is a hierarchical hierarchy of tag values stored in memory locations with addresses 0 through 7. in the expression Indicates nodes that may be included, and the remaining nodes (C1-C2, D1 to D4, and D7 to D8) may be omitted from the hierarchical representation.

The foregoing examples of 120, 130 and 140 represent a hierarchical representation of tag values for memory regions for addresses or memory locations 0 through 7 at different points in time because tag values associated with memory locations may change over time. can In a similar way to adding a node to a hierarchy as described above, a node can be removed from a hierarchy as needed (e.g., a node's descendants will be modified so that all subtrees of the existing node have the same tag value). If they all have the same tag value, all descendant nodes can be removed from the hierarchy and the node can be used as the only node in the subtree to represent a single homogeneous tag value of the node and its descendants).

In at least one embodiment, when a first node in a level of the tree specifies a value for one or more memory locations associated with the first node, there is no need to indicate further descendant nodes of the first node (e.g., There is no need to further indicate subtree nodes other than the first node). For further explanation, reference is made to the first example mentioned above in (120) of FIG. 79 in which only the tag value of node A1 is needed to indicate a single homogenous tag value for memory areas 0 to 7. [0053] For further explanation, reference is made to the above-mentioned third example 140 of Figure 81 in which an embodiment may not further represent nodes C1-C2, D1-D4, and D7-D8. In this way, using this hierarchical representation of memory locations and associated tag values can save storage in terms of tag values for memory locations. In other words, in at least one embodiment, rather than always assigning and storing individual tag values for each memory location, a single tag value within a hierarchy represents a homogenous tag value for multiple memory locations with contiguous or contiguous addresses. A storage device may be allocated. Referring to the first example mentioned at 120, rather than allocating storage for 8 tag values for memory locations 0 through 7, each containing the same tag value, storing a single tag value for node A1 Memory can be allocated for

In the worst-case scenario, assuming that there are no homogenously tagged memory locations in the memory regions with addresses 0-7, the entire node hierarchy structure of FIG. 78 is used to represent the tag values stored at addresses 0-7. For example, each leaf of the hierarchy may represent a different word of memory. Thus, the lowest level 4 (110) of the hierarchy may represent tag values for address spaces 0 through 7.

Referring again to Figure 78, assume that there is an 8-bit address space used to represent the addresses of memory locations 0-7. In at least one embodiment, the entire 8-bit address space may be divided into different memory regions each containing 8 memory locations, each different memory region having a tag value represented by a different instance of the tag value hierarchy. can Therefore, for the memory area of addresses 0 to 7 just described, the most significant or top 5 bits are all = 0, and the addresses 0 to 7 can be expressed in the remaining 3 bits. Therefore, the most significant or top 5 bits = 0 can be used to indicate the memory area of addresses 0 to 7. In such an embodiment, each memory area of the 8 memory locations may have a separate tag value hierarchy shown in FIG. 78 representing, for example, the tag value of a particular memory area. In this example, each of the different memory regions representing a different range of 8 addresses or memory locations can be distinguished by examining the top 5 bits of the 8-bit address of the memory location.

In at least one embodiment according to the techniques herein, a series of tag cache memories may be used in which the number of tag caches may correspond to the number of levels in the hierarchy of nodes representing tag values. Continuing the example discussed above and referring back to 100 of FIG. 78 , each instance of the tag hierarchy for a memory area of 8 memory locations has 4 levels. In this case, an embodiment may use four tag cache memories 152, 154, 156, and 158 as shown in example 150 of FIG. 82 to store tags for memory locations. In general, each of the four tag cache memories 152, 154, 156 and 158 are associated with a different level in the tag value hierarchy and may store information about each node in the associated different level of the tag value hierarchy. For example, the tag level cache 152 contains information about the root of the tag value hierarchy for each level 1 104 node or memory region (in this particular example, a memory region of 8 memory locations, as noted above). can do. The tag level cache 154 may include information about the level 2 106 node of the tag value hierarchy for each memory region. The tag level cache 156 may include information about the level 3 108 node of the tag value hierarchy for each memory region. The tag level cache 158 may contain information about the level 4 108 node of the tag value hierarchy for each memory region. The lowest or lowest level in the hierarchy, level 4 110 in this example, may correspond to a cache line for a memory location that may be stored in a data cache (e.g., as indicated by element 20 in FIG. 1). (L1-D$)). Embodiments may have level 4 158 of the tag cache and have metadata tags that may be separately stored in cache lines of the data cache in addition to metadata tags that may be separately stored in cache lines of the data cache. can Each of the node's caches 152, 154, 156 and 158 has an associated representation in main memory.

With respect to the embodiments described herein having an 8-bit address space, the most significant or most significant 5 bits 152a of the address of a memory location are used by the level 1 cache 152 to allow the cache 152 to access the memory location's address. Can be used to search for any level 1 node. The topmost or most significant 6 bits 154a of the memory location's address may be used by the level 2 cache 154 to retrieve whether the cache 154 contains any level 2 nodes for the address of the memory location. The topmost or most significant 7 bits 156a of the address of the memory location may be used by the level 3 cache 156 to retrieve whether the cache 156 contains any level 3 nodes for the address of the memory location. Eight bits 154a of the memory location's address may be used by the level 4 cache 158 to retrieve whether the cache 158 contains any level 4 nodes for the memory location's address.

For a particular address, each cache associated with a level other than the lowest level can return:

1) a tag value for a particular address (this indicates that there is a homogeneous tag value for multiple addresses at that level);

2) an indicator that the cache does not specify a tag value for a particular address, and that a cache at a lower level in the hierarchy does not need to be referenced to obtain a tag value for a particular address (this particular level is does not specify a homogenous tag value); or

3) Null or a second indicator indicating that there is no cache location in the specific level cache containing node or tag information corresponding to the specific address. A second indicator also indicates that no caches in the lower but not lower level caches contain node or tag information for the address. This is explained in detail below.

Consistent with the discussion above, the indicator returned in item 2) could be a “NO TAG” indicator associated with the nodes shown in examples 120, 130 and 140, for example. For example, referring to example 130 of FIG. 80, assume that a process of determining a tag for memory location 5 is performed. In this case, the level 1 cache 152 may return a NO TAG indicator indicating that the tag value for memory location 5 is specified by one of the other lower level caches 154, 156 or 158. The level 2 cache 154 may return the tag value T2 for memory location 5, which illustrates returned cache item 1) above. To illustrate returned item 3) above where the second indicator is returned, consider a level 3 cache 156. Level 3 cache 156 may not contain any node information corresponding to memory location 5 (e.g., no cache location contains associated node or tag information), so this level 3 cache A second indicator described in 3) above indicating that there is no node information for memory location 5 may be returned. In such an embodiment, processing may generally use the tag value returned from the highest tag level cache. For example, referring to example 130 with respect to memory location 5, level 2 cache 154 is the top level tag cache that returns the tag value for memory location 5.

For the contents of a memory location stored in the L1 (level 1) data cache, the cached information may include the current tag value and the level of the tag cache hierarchy at which the tag value is defined. Referring back to the above example for memory location 5 using layer 130 of FIG. 80, if the contents of memory location 5 are also stored in the data cache, then the data cache may contain the tag value T2 and also the current The tag value T2 may include information defined by a level 2 node (eg, B2) having node information stored in the level 2 cache 154. Thus, example 150 illustrates a four tag cache in a tag cache hierarchy in which tag values can be stored, and a tagged data cache (e.g., L1 data cache) separate from any tag information stored in the tag cache hierarchy. additionally included.

In an embodiment according to the techniques herein, a process performed by PUMP to resolve or determine a tag value for a specific memory location having a specific address may be performed. When performing the process of obtaining the tag value and content for a particular memory location, there may be a data cache hit where the memory cache content and its tag are stored in the data cache. When a data cache hit to a memory location occurs, processing is performed that references the stored level of the tag cache hierarchy that defines the tag value for that memory location, so that the first cached tag value obtained from the tag caching level is returned to the data cache. Matching with the second tag value of the memory location stored in may be guaranteed. If the two do not match, this indicates that the second cache tag value stored in the data cache is in a suspended state, has passed its expiration date, and has been modified. In this case, if the second cache tag value for the memory location stored in the data cache and the first tag value obtained from the tag cache for the memory location do not match (eg, to match those stored in the tag cache layer), data A process may be performed that includes updating a second cache tag value for a memory location stored in the cache. In at least one embodiment, when a memory location has its data and so its tag is cached in the data cache, information in the data cache for a tag in the memory location that includes the level of the tag cache hierarchy at which the tag is defined may be tracked. can Storing levels in the aforementioned cache tag hierarchy (rather than having to reference all tag level caches or otherwise find the hierarchy of existing nodes in a downward search from the root or top of the hierarchy towards a leaf node, for example) The level may be the optimal one that can be used to easily access tag values from the tag hierarchy. Thus, if a data cache hit occurs and the value of the tag stored in the data cache for the memory location does not match the value of the tag stored in the tag layer for the memory location, the process is to update the value of the tag stored in the data cache and the memory location. It may further include updating hierarchical level information stored in the data cache regarding the location's tag as defined in the tag hierarchy. The processing performed by PUMP to resolve or determine the tag value for the memory location can then be restarted.

If a data cache miss occurs for a memory location (eg, the memory location contents and tags are not found in the data cache), then the tag value is returned to a tag value at a level in the tag cache (eg, other than the lowest tag cache level). A process of parallelly performing tag cache lookup for the . For example, lookups for tag values for memory locations can be performed in parallel by referencing four caches 152, 154, 156, and 158 for levels 1, 2, 3, and 4 of the tag cache, respectively. As discussed above, the tag values returned by the top-level tag caches 152, 154, 156 and 158 are used as the tag values for memory locations. Also note that in a properly represented tagged value hierarchy, only one of (152, 154, 156 and 158) can return a tagged value for a memory location. In at least one embodiment, caches 152, 154, 156, and 158 may be indexed to allow parallel access.

Embodiments may also not perform parallel searches or lookups to find tags of a particular memory location with respect to all four tag caches 152, 154, 156 and 158. As a variant, an embodiment may traverse the tag cache of the hierarchy downward from the root node level (level 1) towards the leaf nodes (eg, level 4). In the case of a tag cache miss at level N, the tree or hierarchy can be traversed by inserting nodes into different levels of the tag cache for specific memory accesses. Regarding level cache misses for parallel lookup of the tag cache, embodiments may only choose to insert a node into the level cache when a tag is present. Therefore, since some level caches provide tags, it is not necessary for all other level caches to have NO TAG entries.

As discussed elsewhere herein, the tag of a memory location may be modified. In response to modifying the tag of the memory location, processing may be performed to properly update the hierarchy that specifies the tag value for the memory location. Such an update may include invalidating any one or more levels of the hierarchy that are no longer homogenous. Further, accordingly, a process of appropriately updating the cache level may be performed, for example, as shown in example 150 of FIG. 82 .

When performing an operation to set or initialize a tag of a memory location, such processing may include a PUMP check for validity of performing the desired operation. For example, consider the case of re-tagging all memory locations within a memory region with a new tag. The processing may include obtaining the current tag values of all memory locations in the region and checking the validity of the retags through PUMP processing. If permitted, the process may include clearing the tag of the memory location within the region and, if permitted, then updating the tag value for the memory location within the region. Consistent with the discussion above, updating, modifying, or setting a tag of a memory region means modifying the hierarchy and associated nodes to reflect tag values for different memory locations within the memory region (e.g., prior to modification, homogenous and After modification, it may include decomposing parts of the non-homogeneous region, so that there may be additional child or descendant nodes added to reflect the tag value modification(s).

In at least one embodiment, the hierarchical representation of tag values for memory regions may be a tree. For example, the tree can be a binary tree where each node has 0, 1 or 2 children. As a variant, the hierarchical representation may be a tree but not a binary tree. For example, each node in the tree may be allowed to have any suitable number of child nodes up to a specified maximum. A hierarchical representation may include any suitable number of levels, nodes at each level, children per parent node, and the like. As is known in the art, there are trade-offs between various parameters of a hierarchical representation, such as depth or number of levels and number of children per node/parent node at each level. For example, the greater the number of nodes in each level, the fewer the number of levels and thus the amount of time/levels to be referenced when determining a tag value for a memory location. However, in this case, more writing must be performed to clear the area.

Now, in relation to the CFI policy in an embodiment according to the technology herein, a technology that can be performed by a rule triggered as a result of a loader code will be described. To enforce CFI policies using metadata processing rules that access tag information, information related to permissible control flows must be passed to the metadata processing domain. To this end, embodiments according to the techniques herein may use the approaches described in the following paragraphs. In general, the transfer of control is from a branch source to a target or destination. With respect to an allowable control flow, for a particular control flow target or destination, a set of sources from which transfer of control to a particular control flow target or destination is permitted can be identified. A set of sources for each possible control flow target can be passed to the metadata processing domain, such as stored metadata tag information, and then executed in user code (e.g., code execution domain or non-metadata processing domain). code) may be used by the rules of the CFI Policy in connection with the enforcement of the CFI Policy during run-time execution of the CFI Policy.

The processing performed may include uniquely tagging each source and then tagging each target with a set of permissible sources (eg, addresses of sources) that are allowed to transfer control to that particular target. For example, see FIG. 83. In example 1700, element 1701 may represent a code portion of instructions of an application running in a code execution or non-metadata processing domain. Elements 1702a and 1704a through 1704c represent the locations of instructions in the code portion. Element 1702a represents control flow target A. Elements 1704a through 1704c represent control flow sources that are allowed to transfer control to target A1 1702a. This transfer of control from each of these 1704a through 1704c is indicated by the JMP (jump) A instruction. Element 1706 represents the set of permissible sources that are allowed to transfer control to target A. D7 represents the unique source tag of instruction 1704a. C3 represents the unique source tag of instruction 1704b. E8 represents the unique source tag of instruction 1704c. As shown by 1710, JMP (jump) instructions 1704a through 1704c are tagged as D7, C3, and E8, respectively. Also, as shown at 1710, instructions 1704a through 1704c are stored at addresses 1020, 1028, and 1034, respectively. Target location A has address 800. In this case, the set of allowable sources or addresses of source instructions allowed to transfer control to target A may be the set {1020, 1028, 1034} denoted by 1706. Accordingly, set 1706 is an example of permissible control flow information that must be passed to the permissible metadata processing domain, where such permissible control flow information is included in the tag metadata for use by the rules of the CFI Policy. stored as In at least one embodiment consistent with the techniques herein, the loader's code collects control flow information needed by the metadata processing domain to enforce the CFI policy for the application code portion (1701). You can trigger rules that perform processing. The loader code executes in conjunction with loading the application (e.g., loading executable code required by the application), so the loader code executes to load the application (metadata during execution of the application). The processing triggers rules that perform the processing necessary to collect control flow information (which is later used to enforce CFI policies).

In at least one embodiment, consistent with description elsewhere herein, execution of kernel code, when executed, is used to tag sources (generating source tags D7, C3, and E8, for example). You can trigger a rule tagging the loader's code with a special instruction tag that enables the loader's tagged instruction to trigger a rule that fires a sequence of tags (each tag in the sequence is unique). For example, reference is made to FIG. 84 which includes logic processing performed by a rule triggered as a result of executing the code of the loader. Logic processing is described at 1720 using C-like pseudocode descriptions such processing can be performed for each control flow target, such as A 1702a. At step 1721, the source set is initialized to an empty set. In step 1722, steps 1723, 1724 and 1725 may be performed for each source allowed to transfer control to the target. At step 1723, t is assigned the newly assigned CFI source tag. In step 1724, the source location (of the instruction transferring control to the target) is tagged with the newly assigned tag t created in step 1723. At step 1725, the source set is updated to also include tag t. In one aspect, the operation of step 1725 is performed on each iteration of the loop process starting at 1722, as performed for each source, the set of sources acceptable to the target for which the union operation is performed at 1725. It can be characterized as forming a union. Step 1726 tags or marks the target as a source set.

Element 1723 may be the following instruction included in loader code that triggers a rule to generate or assign a new CFI source tag:

Here, an ADD instruction (such as ADDI in the RISC-V instruction set) is tagged by the kernel code with a special CI tag of CFI-alloc-tag that marks it as an acceptable tag generator instruction. In at least one embodiment, a different sequence of source tags may be generated for each application by a loader in association with a CFI policy (e.g., in example 1620, the loader may generate a set of CFI source tags for an application). A different sequence of CFI tags 1630 can be used as a unique sequence, and the sequence of CFI tags in this application can be generated from a specific one of the CFI Tag Generator App-n tags in 1627). CFI-alloc-tag is a CI tag placed in the loader ADD instruction above indicating that the ADD instruction may allocate or generate the next tag in the application-specific CFI sequence. The CFI-alloc-tag may be one of the special command types of 1624 as described with respect to example 1620. The ADD instruction above indicates that the tag on R1 holds the state of the CFI sequence whose state could be the last tag of a previously created sequence. Executing the above ADD command triggers a rule that generates the next new tag in the CFI sequence and updates the tag on R1 with the newly generated tag. Using rule conventions as described elsewhere herein, it can be indicated that the following ADD rule is a rule triggered by the ADD command above:

This ensures that the CI tag for the ADDI command is a CFI-alloc-tag. In these ADD rules, t1 represents the previous tag in the sequence (saved as the current state of the application's CFI tag sequence) that is used to generate the next tag in the sequence, t1next, where the next t1next is the value for the destination or result register (RD). stored as tags. The aforementioned tag of the CFI sequence, t1next, may be used as a unique CFI source tag placed at the source point.

Element 1724 may be an instruction in the loader code, such as the ST (store) instruction below used to trigger a rule to tag a source location with a unique CFI source tag:

where R3 is a pointer pointing to the control flow source location of the user program code being tagged (e.g., 1704a of example 1700), and the tag on R1 is the unique CFI source tag to be placed at the source location. The ST instruction above can also be tagged with a special CI tag such as CI-LDR indicating that the ST instruction is included in the loader code triggering rule ST below:

where CI tag=CI-LDR, t1 is the CFI source tag currently stored as a tag on R1, and codetag is the instruction tag on the source location at address R3 (e.g. ensure that the source location is currently tagged as code is a tag that does). As a result, destination R3 is tagged with t1, a unique CFI source tag.

Element 1725 represents an acceptable source location from which control can be transferred to the target address of the source (e.g., R3 currently points to, where R3 contains the address of the source), such as in the ADD instruction below. An instruction in the loader code used to trigger a rule that adds to the cumulative set of CFI source tags may be:

Here, the tag on R2 points to a memory location representing the cumulative set of acceptable source locations. The above ADD instruction may be tagged with a special CFI UNION instruction tag to indicate that this ADD instruction performs a union operation of CFI sources and the union is stored as a tag on R2. As a result of the ADD command above, the following rules for ADD can be triggered:

This checks to ensure that the CI tag is a CFI UNION, tset is the target set, and tsrc is the source tag. This rule creates a new CFI set, tunion, indicating the addition of tsrc to tset.

Element 1726 can be an instruction in loader code, used to trigger a rule tagging a target with a union or accumulated list of allowable source locations that can transfer control to the target, such as the ST instruction below:

R17 may be the register containing the address of the target location, and R2 may be the register tagged as the union of the currently accumulated set of allowable source locations as mentioned above (e.g., the tag on R2 is the address represents the set of allowable source locations for the target location included in R17). The above ST instruction may be tagged with the special instruction tag CFI MARK TARGET, which marks this instruction as a special instruction allowed to tag the target location prior to control (e.g., triggering a rule that performs the processing of 1720). In a similar manner to other code tags on load code instructions, these STORE instructions 1726 in loader code may be tagged by kernel code). As a result of the STORE command above for (1726), the following ST rules may be triggered:

This triggers when the CI tag is CFI MARK TARGET, the target (pointed by R17, where R17 contains the target address) is tagged with a code tag representing the instruction, and places a tset annotation on the target.

Other tag structures or layouts that may be defined for use with a source, target, and set of permissible source locations are described elsewhere herein, as well as in any other suitable structure definition (e.g., any instruction Examples (240, 250, 260, 240, 250, 260, 267, 270 and 280)).

Thus, the processing steps described above, e.g., in example 1720, when such loader code is executed, the rules that cause the steps in example 1720 to be performed by the metadata processing domain in an embodiment consistent with the description herein. This can be done by properly tagging the loader's code to be triggered. It should be noted that the foregoing sequence of commands and rules invoked as a result of commands are only one example of commands and rules that may be used in an embodiment using the techniques herein. For example, an embodiment may include instructions other than ADD in the loader code that trigger a rule (eg, element 1725) to perform processing as described above.

In the foregoing description, certain terminology has been used for brevity, clarity, and understanding. As these terms are used for descriptive purposes and are intended to be interpreted broadly, no unnecessary limitations beyond the requirements of the prior art are implied. Moreover, the descriptions and illustrations of preferred embodiments of the present disclosure are examples, and the present disclosure is not limited to the exact details shown or described.

Various aspects of the techniques described herein may be performed by executing code stored on any one or more different forms of computer readable media. Computer readable media includes different forms of volatile (eg, RAM) and nonvolatile (eg, ROM, flash memory, magnetic or optical disks, or tape) storage that may be removable or non-removable. can do.

Although the invention has been disclosed in connection with the various embodiments shown and described in detail, modifications and improvements of the invention will be readily apparent to those skilled in the art. Accordingly, the spirit and scope of the present invention should be limited only by the following claims.

PUMP programming

Hardware-assisted micro-policies for security

summary

Extensive security policies are formulated as rules for ISA-level metadata and can be efficiently enforced in programmable hardware. We detail a programming model for such policies, based on the Programmable Unit for Metadata Processing (PUMP) architecture, which supports flexible rule evaluation on uninterpreted metadata along with key computations. We demonstrate the generality of the model by implementing different sets of safety and security policies of varying complexity in four specific domains - spatial and temporal memory safety, taint tracking, control flow integrity and primitive typing. We characterize the performance of these policies, alone or in combination, for a simple RISC ISA. The average runtime overhead for most policies is only 8%. This shows that the PUMP model can achieve flexibility and adaptability of software execution with the performance of dedicated hardware.

1. Introduction

It is all too easy for an attacker to subvert the programs in the tent. Modern processors designed to be tolerant of the intended high-level semantics of the operations they perform are in conflict in this context, a legacy of a technology era in which transistors are expensive and the primary design goal was run-time performance. As computer systems take on increasingly critical tasks, system security finally becomes a key design target. At the same time, processors are now small compared to just plain system-on-chip dies, making it feasible and inexpensive to augment them with security-enhancing hardware. For tomorrow's computers, to adequately protect the privacy and integrity of the data they manage, we must radically reconfigure our entire computing stack with security mechanisms consistent with modern threats and hardware costs.

This security literature provides extensive runtime policies that can reduce vulnerabilities due to malicious and erroneous code. These policies often encode high-level language abstractions (this is an array of digits, this is a code pointer, ...) or user-level security invariants (this string comes from the network) into the program's data and metadata annotations on the code. High-level semantics or policies are enforced by propagating this metadata as computation proceeds and dynamically checking for violations at appropriate points. We call these low-level, fine-grained enforcement mechanisms micro-policies (or, informally, just "policies").

A software realization of the micro-policy can define arbitrary metadata and arbitrary powerful computation beyond these. Software implementation facilitates rapid deployment of new policies, but can be prohibitively expensive (1.5x to 10x) in terms of runtime and energy cost [42], resulting in unfavorable security performance trade-offs. Simple micro-policies can be supported in hardware with low overhead [41,?]; However, hardware customized to support a single policy can take years to deploy and is slow to adapt. Today's dynamic cyberattack environment requires mechanisms to support a rapid, on-the-ground response to evolving threats.

The desire for greater flexibility has fueled many recent efforts to make policy enforcement hardware more programmable [18, 45, 19, 13] (see §5). Here, we consider a design called PUMP [7], “Programmable Unit for Metadata Processing”, which allows a wide range of low-level runtime policies to be defined in terms of fine-grained instruction computation on arbitrary metadata. At the hardware level, every word of data is associated with a word-sized metadata tag. These tags are not interpreted by hardware; In software, tags can be mapped to informational representations such as type, source, classification level, or authenticity of the data to which the information is attached. Tags can refer to data structures of arbitrary size and complexity, including tuples of metadata, that are large enough to represent pointers, allowing multiple orthogonal policies to be enforced in parallel. A program counter is tagged to support historical tracking of a program's control state; Program code is tagged to support policies regarding code provenance, control flow, and compartmentalization. The processor core is augmented with a rule cache that enables high-performance rule analysis in parallel with instruction execution, and a special mode of operation for rapid context switching to policy processing code when a lookup misses in this cache. This allows PUMP to easily enforce a wide range of low-level policies through the expressiveness and adaptability of software and the capabilities of hardware.

One goal of this paper is to show both the usefulness of PUMP-like tagging and rule handling for real threats and the ease of writing policies in the form of rules. We do this by detailing how PUMPs can be programmed to support a diverse collection of low-level security and safety policies. We have four families of policies (all of which are in the literature): (i) primitive types that enforce a weak form of type safety; (ii) user-after-free errors for spatial and temporal memory safety, caching bounds, and heap-allocated data; (iii) control flow integrity (CFI) to prevent code-reuse attacks [2]; (iv) present detailed implementation and evaluation of taint tracing, where a taint may indicate a data source or component that may have contributed to a given piece of data; Many of these policies are beyond what current systems can efficiently support in software. Finally, we show how these policies can be applied simultaneously. Since these policies have been well studied in the existing literature, we do not focus primarily on the security assurances these policies provide, but rather explore how policies can be expressed as rules and enforced using PUMP. We use instruction trace simulations to predict the runtime impact of these policies on the SPEC CPU2006 Benchmark Suite when PUMPs are attached to simple sequential RISC processors (Alpha [1]). We show that PUMP can support policies of a wide range of complexity and quantify their performance impact. This range exemplifies the ability to improve policy as a threat evolves and how this evolution can affect performance.

This paper is an expanded, enriched, and refocused version of [7], a short paper to be presented at a workshop later this summer. The previous paper focuses on direct hardware integration of PUMP into RISC processors, establishes reasonable performance for most benchmarks, and identifies areas for improvement. In this work, we avoid the microarchitectural considerations well described in [7], and instead focus on the evaluation of the programming model and much more detailed description and policy itself. We also explain how the PUMP software service protects itself from abuse. The performance we report can be attributed to (i) the use of opgroups (§2), (ii) a more accurate estimate of the miss cost (§3) and (iii) a reduction in DRAM accesses by using pointer tags only when needed (§4). [7] is improved due to

In summary, the main contributions of this work are (i) a programming model and supporting interface model (§ and §3) to concisely and accurately describe the policies supported by this architecture; (ii) detailed examples of policy encoding and construction using four different classes of well-studied policies; (iii) quantification of requirements, complexity and performance for these policies (§4). In §5 and §, we discuss related and future work. Some additional material is available anonymously at http://git.io/8K7IKA. These materials include: [7] an anonymized version and the source code of our experiment, an appendix with a complete definition of the policy studied.

2. POLICY PROGRAMMING MODEL

A PUMP policy consists of a collection of rules that manipulate these tags along with a set of tag values to implement any desired tracking and enforcement mechanism. Rules come in two forms, depending on whether we are talking about the software layer of the system (symbolic rules) or the hardware layer (concrete rules).

example. To illustrate the operation of PUMP, consider a simple example policy for limiting return points during program execution. The motivation for this policy comes from a class of attacks known as return-oriented programming (ROP) [39], in which an attacker identifies a set of "gadgets" in the binary executable of the program under attack and uses them assemble complex malicious behavior by building appropriate sequences of stack frames, each containing a return address pointing to some gadget; A buffer overflow or other vulnerability is then exploited to overwrite the top of the stack with the desired sequence, causing the snippets to be executed in sequence.

One simple way to limit ROP attacks is to limit the targets of return instructions to well-defined return points. We can do this using PUMP by tagging the tagging command, which is a valid return point, as a metadata tag target. Whenever we issue a return instruction, we check to set a metadata tag on the PC to indicate that a return has just occurred. On the next instruction, we are notified that the PC tag is checked, verify that the tag on the current instruction is the target, otherwise signal a security violation. We'll show later in this section that by making the metadata richer, we can control exactly which return commands can return to which return points. By making this richer, we can implement full-fledged CFI checking [2] (see §4. 3).

symbolic rules. From the perspective of the policy designer and the software portion of the PUMP, policies are concisely described using symbolic rules written in a small domain-specific language. Each symbolic rule has the following form:

This rule is the instruction opcode along with the metadata tag on the program counter (PC), the current instruction (CI), up to two operands (OP1, OP2) from the register file, and the memory location referenced by the instruction (MR), if any. It is said to match on a set (opgroup) of . The rule matches all relevant tag expressions and guard? Apply if the predicate holds. In this case, the right side determines how to update the tag on the PC (PC') and the result of the operation (R'). Because in most policies there will be many opcodes with the same rules, we use opgroups instead of opcodes. We write "-" to indicate input or output fields that are ignored ("wild cards"). guard? When the condition is true, we delete it.

(나머지 모두) - 으로 분할하며; 가능한 태그 값은 check, target 및

이다. PC는 항상 check 또는

로 태깅될 것이며, 각 명령어는 target 또는

로 태깅될 것이다. (명령어 태그는 신뢰성 있는 로더에 의해 공급된다; §참조). 상징적 규칙은 다음과 같다: For the simple ROP policy just outlined, we divide the opcodes into two opgroups - return (which contains only a single opcode) and

(all others) split by -; Possible tag values are check, target and

am. PC always check or

will be tagged with , and each command can be a target or

will be tagged with (The instruction tag is supplied by the trusted loader; see §). The symbolic rules are:

은 허용되지 않는다). 우리는 상징적 규칙이 겹치지 않는다고 가정한다.According to Rule 1, when the current action is return (and the PC is not already tagged check), we change the tag on the PC to check. When we execute an instruction with a PC tagged check (rule 2), we check if the instruction tag, CI, is the target; If so, we allow the action and clear the tag on the PC. If the current action is not return and the PC tag is 1, then we just proceed (rule 3). Rule 4 handles the special case where the valid target of a return is the return itself. If none of the rules apply, the action is disallowed (e.g. configuration PC=check and CI=

is not allowed). We assume that symbolic rules do not overlap.

Next, consider a more sophisticated variant of this policy, in which we ensure that every return not only reaches some valid return target, but also targets a code point that can actually be called. This policy assumes that the compiler has complete knowledge of the return points and, for each return point, can analyze which call site it is likely to return to. Using this information, we can attach a unique tag to each return and each potential return target. When return is encountered, PUMP copies the tag on the instruction to the PC (rule 1' and 4') (instead of the normal tag check). In the next step, it is checked if the actual return point is among the expected points - i.e. if return from PC to CI is allowed (rules 2' and 4').

In these rules, we use X (the set of code location identifier pairs provided by the compiler) to indicate the indirect control flow allowed through returns in code. As can be seen here, expressions describing tags within symbolic rules are not limited to constant values: we can write more general expressions that concisely describe large sets of tags.

specific rules. Symbolic rules can succinctly encode various metadata tracking mechanisms. However, at the hardware level, we need tuned rule expressions for efficient interpretation to avoid slowing down the underlying calculations. To do this, we introduce a low-level rule format called concrete rules. Intuitively, each symbolic rule for a given policy can be extended to an equivalent set of concrete rules. However, since a single symbolic rule can usually generate an infinite number of concrete rules, we do this laboriously slowly, creating concrete rules as needed while the system is running.

The PUMP hardware contains a cache of specific rules that can be referenced in parallel with the processor's ALU operation. When an instruction is issued, the rules cache performs an associative match of tags from the current machine state (current PC tag, tag on the operand of the current instruction, etc.) for all specific rules in the cache. If a match is found, the cache returns a new tag for the PC and a tag for the result of the instruction. Otherwise, the processor clears the fault in the rule miss handler - a software routine that consults the symbolic rule in the policy and determines whether the faulty machine state should be allowed to proceed; If so, it generates the appropriate specific rule, installs it in the cache, and restarts the instruction that led to the fault. Otherwise, call the appropriate security fault handler. The general format of a specific rule is:

Here input and output fields are fixed tags. "Guard?" It should be noted that the fields in the symbolic rule format are not needed, since the miss handler checks the corresponding condition before adding any concrete rules to the cache.

opgroup에 대한 규칙은 OP1, OP2 및 MR 입력에 매칭시킬 필요가 없으며, R' 결과를 생성할 필요가 없다. 미사용 입력 필드의 모든 가능한 값에 대해 구체적 규칙을 생성하지 않기 위해, 우리는 각 opgroup 및 입력 필드에 대해 don't-care 비트를 포함하는 비트 벡터를 정의하는데, 이것은 대응하는 태그가 규칙 캐시 룩업에 실제로 사용되는지를 결정한다. 유사하게, don't-care 벡터는 디폴트 태그가 리턴된 미사용 출력을 마킹한다(아래에서는 이것을 위해

를 사용한다). One convenient encoding trick greatly reduces the number of concrete rules. We observe that it is very common for all symbolic rules for a given opgroup to mark certain inputs or outputs as "wildcards". For example, in the ROP policy, return and

Rules for opgroup need not match the OP1, OP2 and MR inputs, and do not need to produce R' results. To avoid generating concrete rules for every possible value of an unused input field, we define a bit vector containing a don't-care bit for each opgroup and input field, which means that the corresponding tag is not included in the rule cache lookup. determine if it is actually used. Similarly, the don't-care vector marks unused output for which a default tag is returned (see below for this

use).

opgroup이 OP1, OP2, MR 및 R1'에 대해don't-care 비트 세트를 갖기 때문에, 컴파일러가 t1으로 태깅된 리턴 명령어가 코드의 유일한 리턴임을 알고 있고 t2 및 t3로 태깅된 리턴 타겟에만 리턴할 수 있다면, 규칙 2'는 단지 두 개의 구체적 규칙만 갖는다.For example, for a ROP policy:

Because the opgroup has the don't-care bit set for OP1, OP2, MR, and R1', the compiler knows that the return instruction tagged t1 is the only return in the code and will only return to the return targets tagged t2 and t3. If possible, rule 2' has only two specific rules.

로 마스킹되었다. 다른 한편, 상징적 규칙 3'은 네 개의 구체적 규칙에 대응한다:The "don't-care" position is

was masked with On the other hand, symbolic rule 3' corresponds to four concrete rules:

에 대한 "don't-care" 위치가 아니기 때문에 (규칙 3''은 CI를 와일드카드로서 마킹하지만, 규칙 2'는 그렇지 않으며 두 규칙은 모두 동일한 opcode에 관한 규칙임), 우리는 각각의 가능한 값마다 각기 취할 수 상이한 구체적 규칙을 얻는다 -

및 모든 식별자(이 예에서는 단지 t1, t2 및 t3).CI is

Since it is not a "don't-care" position for (rule 3'' marks the CI as a wildcard, rule 2' does not, and both rules are about the same opcode), we consider each possible Each value gets different concrete rules that can be taken -

and all identifiers (in this example only t1, t2 and t3).

)만 사용하지만, 다른 정책은 더 많이 필요할 수 있는데; 예를 들면, 프리미티브 타입 정책(§4.1)은 열 개를 사용한다.The mapping from opcodes to opgroups and don't-care vectors is programmable. A ROP policy consists of two opgroups (return and

), but other policies may require more; For example, the primitive type policy (§4.1) uses ten.

structured tags. For policies with richer metadata tags than ROPs, the conversion from symbolic rules to concrete rules follows the same general lines, but the details are a bit more complicated. For example, the taint tracking policy (§4.4} uses tags as pointers to memory data structures, each of which represents a data source or system component that may have contributed to a given fragment's data. ) describes a set of taints of arbitrary size A symbolic rule for the load opgroup says that the taints on the loaded value must be the union of the instruction itself, the target address of the load, and the taints on memory at that address:

로 태깅된 값이고; (ii) tci가 집합{TA, TB}을 나타내는 데이터 구조체(이를 테면, 테인트 id의 어레이)를 가리키고; (iii) tp가 {TC, TD}의 표현을 가리키고; 및 (iv)

가 비어 있는 세트를 가리킨다고 가정해 본다. 또한, 이전에 테인트 {TA, TB, TC, TD}가 발생하지 않았다고 - 즉, 우리가 로드의 결과를 테인트하는데 사용해야 하는 세트를 나타내는 데이터 구조체가 현재 메모리에 없다고 - 가정한다. 이 경우, 규칙 캐시 룩업은 미스일 것이고 실행은 규칙 미스 핸들러에 결함을 일으킬 것이며, 이것은 적절한 구체적 규칙을 발생하고 이를 캐시에 설치할 것이며, 아마도 다른 규칙을 없애버려 공간을 만들 것이다. 이렇게 하면 (예를 들어, 어드레스 tnew에서) 새로운 메모리를 할당해야 하고, 이를 초기화하여 {TA, TB, TC, TD}를 표현해 주어야 한다. 그러면 발생된 구체적 규칙은 다음과 같을 것이다:At any moment, (i) the next instruction to be executed has Id r0 r1 and its tag is tci, register r0 contains a vertically tagged pointer p, and the memory at address p is

is the value tagged with ; (ii) tci points to a data structure representing the set {TA, TB} (eg, an array of taint ids); (iii) tp points to the expression {TC, TD}; and (iv)

Suppose that points to an empty set. We also assume that no taints {TA, TB, TC, TD} have occurred before - i.e. there is currently no data structure in memory representing the set that we should use to taint the result of the load. In this case, the rule cache lookup will miss and execution will fault the rule miss handler, which will generate the appropriate specific rule and install it into the cache, possibly discarding other rules to make room. In this case, new memory must be allocated (eg, at address tnew), and it must be initialized to represent {TA, TB, TC, TD}. Then the specific rules generated would be:

After the instruction restarts, the next cache lookup will succeed, and the value loaded into r1 will be tagged with tnew.

To reduce the number of distinct tags (and thus reduce the burden on the rules cache), metadata structures are stored internally as primitives, and sharing is fully exploited since tags are immutable (e.g. elements of a set are Given in the default order, the sets are succinctly expressed as sharing a common subset of prefixes). When no longer needed, these structures can be returned (eg by garbage collection).

)이고, t는 테인트 태그(테인트들의 세트를 가리키는 포인터)이다. 캐시 룩업 프로세스는 정확히 동일하지만, 미스가 발생할 때, 미스 핸들러는 튜플의 컴포넌트를 추출하고 상징적 규칙들 세트 모두를 평가하는 루틴으로 디스패치한다. 정책 모두가 적용되는 규칙이 있는 경우에만 동작이 허용되고; 이 경우 결과적인 태그는 두 서브-정책으로부터 생긴 결과를 포함하는 쌍을 가리키는 포인터이다.compound policy. Taking it a step further, we can enforce multiple orthogonal policies simultaneously by having a tag be a pointer to a tuple of tags from multiple component policies. (In general, the multiple policies may not be orthogonal; we return to this point in §6.) For example, to construct the first ROP policy with the taint tracking policy we just sketched, we would We will put each tag as a pointer to a representation of the tuple {r, f}, where r is a ROP tag (code location identifier or

), and t is a taint tag (a pointer to a set of taints). The cache lookup process is exactly the same, but when a miss occurs, the miss handler extracts the tuple's components and dispatches them to a routine that evaluates the full set of symbolic rules. An action is allowed only if there is a rule that all of the policies apply to; The resulting tag in this case is a pointer to a pair containing the result from the two sub-policies.

Command Modifiers and Temporary Rules. Some policies (e.g. memory safety) require that new tags be generated dynamically. One way to achieve this effect is to use a tag on a command such as move as a modifier to pass a request for a new tag to the policy management system.

According to this, a move command tagged with tpolicygen is interpreted as a request to generate a new tag. The resulting tnewtag is the unique tag associated with the specified policy. The tag tpolicygen on the command is also used as an authorization or capability for these service requests; Without that tag, it is impossible to call; The trusted loader ensures that only specially designated areas of code (eg the malloc routine in the memory safety policy in §4.2) are annotated with these tags. A "1" represents a temporary rule whose results are not permanently stored in the hardware rule cache (since it changes on every call).

Code to initialize tags may need to ignore the "normal state" rule. For example, in memory safety policy, malloc must initialize the tags of newly allocated memory areas. The standard rule is that a pointer can only be written to a memory area that is properly tagged to match the pointer. However, malloc must allow us to override this rule while writing the newly created tags to each word in the new region. We do this by giving the store operation a special modifier tag (used only by malloc):

3. Policy system and protection

The policy system exists as a separate memory area within each user process. The policy system includes data structures representing miss handlers, policy rules, and metadata tags of policies. Placing the policy system in the process minimizes the intrusions of the existing Unix process model and facilitates lightweight transitions between the policy system and user code. The policy system is isolated from user code using the mechanisms described below.

Metadata Threat Model. Obviously, the protection provided by PUMP is useless if an attacker can rewrite the metadata tag or change its interpretation. Our system is designed to prevent such attacks. We trust the kernel, the loader and (for some policies) the compiler. Specifically, depending on the compiler, we assign initial tags to words and, if necessary, pass rules to the policy system. We assume that the loader will preserve the tags provided by the compiler, and that the path from the compiler to the loader is protected from tempering, for example using cryptographic signatures. We assume a standard Unix-style kernel that sets up an initial memory image for each process. (It may be possible to eliminate some of these assumptions using micro-policies, further reducing the size of the TCB - §6.) We assume that the rules-cache-miss-handling software is implemented correctly. It is small and therefore a good target for formal verification; A recent work [8] shows the feasibility of a programming model similar to PUMP.

Our main concern is to prevent user code running in a process from violating the protection provided by the process' policy. User code must (i) not be able to directly manipulate tags - all tag changes must be performed in accordance with currently applicable policy rules; (ii) must not be able to manipulate data structures and code used by the miss handler; (iii) It must not be possible to insert rules directly into the hardware rule cache.

addressing. To prevent direct manipulation of tags by user code, tags attached to all 64b words cannot be separately processed by themselves. In particular, it is impossible to specify an address corresponding to only a tag or a portion of a tag in order to read or write a tag. All user-accessible commands operate on (data, tag) pairs as atomic units - the standard ALU, which operates on the value part, and the PUMP, which operates on the tag part.

Miss handler architecture. The policy system is only activated on a PUMP cache miss. To isolate the policy system and user code, we add a miss (miss handler) operating mode to the processor; We also extend the integer register file with 16 additional registers available only for miss handlers, to avoid saving and restoring registers. PCs of fault-inducing instructions, rule inputs (opgroups and tags), and rule outputs appear as registers while in miss handler mode. We also add a miss-handler-return instruction that installs the specific rule into the cache and returns it to user code.

Normal behavior of PUMP is released while the processor is in miss-handler mode. Instead, a single hardwired rule applies: all commands and data touched by a miss handler must be tagged with a predefined miss-handler tag distinct from the tag used by any policy. This ensures isolation between the miss handler code and the data and user code in the same address space. User code cannot touch or execute policy system data or code, and miss handlers cannot accidentally touch user data and code. Because the miss-handler-return command can only be issued in miss-handler mode, user code is prevented from inserting rules into the PUMP.

4. Policy and experimentation

In this section, we show how to use PUMP to implement four policy groups that enforce various sets of security invariants. For each family, we first sketch a threat model. Then we describe policies and response rules that mitigate this. Using the example from the public vulnerability suite [10], we show how each policy catches typical attacks. Most importantly, we describe the load each policy places on the system. We close by comparing similar policies from the literature.

To evaluate the policy load, we use 28 C, C++ and Fortran applications [25] from the SPEC CPU2006 benchmark suite, and simulate them in the gem5 simulation environment [9] against 64-bit Alpha ISA [1] ( We exclude the tonto and xalancbmk benchmarks where gem5 fails). The gem5 simulation does not directly model PUMP; Rather, it creates an instruction trace that runs through a separate PUMP simulator.

Figure 1:

This step-by-step simulation suffices for the policy described here, because when a policy violation occurs, execution is only aborted if it affects the computation. We simulate a 4096-entry pre-miss-handler rule cache.

The abstract programming model described in §2 does not place any restrictions on the number of unique tags, the number of specific rules, or the size of data structures used to represent metadata at the software level. To understand how PUMP is actually performed, a number of issues must be considered. How many policies, applications, and datasets do you actually create given unique metadata tags? With the O opgroup and T tags, in theory a program could need O*T ⁵ concrete rules, but how much in a typical case? How does the total number of metadata tags and the size of the metadata representation affect performance? How much locality is tagging and controlling usage? How much does a specific rule resolution decision cost, and how much does a rule cache miss affect performance? Does performance degrade appropriately as tags, rules, metadata size, or rule resolution time increase5?

참조). Runtime overhead(런타임 오버헤드)는 PUMP가 없는 베이스라인 Alpha와 비교하여 정책을 실행하는 애플리케이션의 벽시간(wall-clock) 런타임의 비율이다. 아무 정책도 사용되지 않더라도 태그 및 PUMP의 하드웨어 구조체의 추가 때문에 몇몇 런타임 오버헤드가 존재한다. 특히, 태그가 늘어난 프로세서상의 L1 캐시는 더 큰 태깅된 워드 폭을 수용하면서 동일한 사이클 시간을 달성하기 위해 PUMP없는 베이스라인 Alpha 유효 용량의 절반이다. 이로 인해 태그가 늘어난 프로세서의 L1 미스 레이트는 더 높아진다. 이러한 오버헤드는 제 1 열(

)에 담겨 있는데, 이 열에서 모든 태그는 디폴트이고, 단일 규칙이 존재하며, 미스 핸들러는 결코 효과적으로 호출되지 않는다.To begin understanding these results, we measure several characteristics other than runtime overhead for each policy - see Figure 1. Tag usage shows that the tag is not used by any rules within the policy. Opgroups is the minimum number of opgroups required to acquire a policy; The fewer opgroups we use, the greater the compression we get for a specific rule and hence the greater the effective PUMP capacity. Symbolic rules are the number of symbolic rules we have written to express our policy. Initial tags is the number of tags in the initial memory image before starting execution. More tags are dynamically allocated during execution (dyn.alloc.tags). Policies such as tracking taints will also create tags representing unions of taint sets, and compound policies will form tuples of individual policy tags. Final tags identifies the number of tags present at the end of the billion instruction simulation period; This gives some sense of policy complexity and can be used to infer the rate of tag generation. Concrete rules, this is the number of unique concrete rules generated during the simulation period, characterizing the number of forced misses required to resolve symbolic rules into concrete rules, and the actual forced miss rate. Metadata structure, this is the average size of a word in the data structure pointed to by each tag, showing a value with infinite metadata. Metadata space, this is the number of words required for all data structures holding policy-related information pointed to by a metadata tag, and is characterized by a memory overhead that exceeds the tag itself. Policy-depend instrs is the total number of instructions required for the code to translate symbolic rules into concrete rules; This is useful for understanding the complexity of policies. Policy-depend instrs (dynamic) are the average number of policy-dependent instructions executed to resolve from symbolic rules to concrete rules; This represents the runtime complexity of the miss handler for each policy. The impact of the policy-dependent part depends on the complexity of the rule, the metadata data structure, the locality of the metadata data structure, and the need to assign a new result tag. The policy-independent part of the miss handler requires only a few dozen instructions (Fig. 1 column

reference). Runtime overhead is the ratio of the wall-clock runtime of the application executing the policy compared to baseline Alpha without PUMP. Even if no policy is used, there is some runtime overhead due to the addition of tags and hardware structures of PUMP. Specifically, the L1 cache on a tagged processor is half the effective capacity of the baseline Alpha without PUMP to achieve the same cycle time while accommodating the larger tagged word width. This results in a higher L1 miss rate for processors with increased tags. This overhead is the first column (

), in which all tags are default, there is a single rule, and the miss handler is never effectively called.

를 초과하는 런타임 오버헤드를 그래프로 도시한다.*Average figures in Figure 1 are inevitable simplifications for brevity. Benchmarks show varying results. The results are shown in Figures 3-6 using boxplots to show the distribution of properties across applications on the SPEC CPU2006 benchmark set. Figure 6 is

Graph the runtime overhead exceeding .

We only measure runtime performance to the exclusion of other non-trivial costs. In particular, in a blank implementation, adding a word-sized tag to every word in cache and memory imposes at least 2x area overhead. Adding the impact of the PUMP cache and the impact of larger memory, the energy overhead is multiplied by 4x. We are optimistic that with careful optimization we can reduce these numbers to around 30% range and 50% energy, or even lower; We are working to substantiate this claim.

4.1 Primitive Types

threat model. Data misinterpretation is a common way to cause a processor to perform unintended actions. Here we are interested in a form of low-level type confusion in which the code executing on behalf of the other party may try to use an arbitrary data value as a pointer or execute a word as an instruction. We enforce that data cannot be executed and code cannot be created or modified at runtime (see also §4.3).

Policies and Rules. In policy (C), we use tags to separate instructions (tagged insn), addresses (addr) and all other data (other). Commands cannot be created or modified, only commands can be executed. Only addresses can be used as memory access instructions. Other type tags are used as catch-calls for words that are not commands or addresses. The following rule verifies (for example) that insn is actually tagged before nop is executed:

(5)

(5)

Address arithmetic is allowed - for example, when one of the arguments to be added is an address, the result is an address:

(6)

(6)

Also we enforce that load and store instructions only dereference pointers and do not read or write instructions:

(7)

(7)

(8)

(8)

To prevent attacks where the return address is overwritten (eg via stack smashing), we consider an extended policy (D) that adds a fourth tag (retaddr) to the return address. We use this to tag the call's return address (rule 9). In Alpha ISA, a call puts the return address into reg26, while a return transfers control to an address in this register (the register is flushed onto the stack on another call). Rule 10 checks whether the value in reg26 is the entered retaddr when the return instruction is executed.

(9)

(9)

(10)

(10)

An instrumented compiler can infer these type tags and apply them to the initial binary memory image - every issued instruction has a tagged insn, and a pointer to stack-allocated memory has a tagged addr. have, others are tagged otherwise; Words in which new addr is typed occur through dynamic address assignment. However, currently we do not have such a compiler, so we use other methods to infer these tags for simulation and analysis. First, we tag every instruction in the binary executable file insn. To infer which words addr should be tagged with, we use post mortem analysis of the execution trace to track when and where each register is loaded and which is later used as a pointer operand pointing to a load or store. Everything else is tagged otherwise. This method of acquiring the initial tag allows us to measure the runtime impact of typing policies on the SPEC benchmark. However, with this setup we can't make any claims about whether our typing policy is good enough to accommodate all benchmarks without raising unnecessary alerts. This is caused by the tight compiler integration required for typing and does not occur with the other policies we present below.

protection demo. We use an instance of CWE-843 (type confusion) [30] where the programmer typecasts an integer to a function pointer and later calls this function. This translates into loading an immediate value tagged with something else into a register, and jumping to the address pointed to by that register at a later time. Using policy (C), we can catch the fault-inducing instruction since the policy only allows indirect jumps to values tagged with addr.

characteristic. Policies (C) and (D) do not generate new tags. (C) can be encoded with 15 symbolic rules making only 17 concrete rules, whereas (D) requires 16 symbolic rules and 19 concrete rules. Because the total number of rules is small, we show only a negligible runtime overhead (less than 0.01%) compared to the policy (A) without a miss-handler. Thus, PUMP provides a simple, hardwired type of tagging capability without having to bake policy into hardware.

Related Works. One of the first uses of tags in computer architecture was to distinguish the type of word within a machine [34, 23]. Symbolics L1SP Machines [31] allocated 2 to 8b for tagging out of 36b primitive words to distinguish a set of primitive types including instructions, different flavors of pointers, integers, floating point and uninitialized values. ; Berkeley SPUR [43] used the 6b object type tag.

4.2 Spatial and Temporal Memory Safety

threat model. The following policy groups target memory safety of heap-allocated data, preventing an attacker from referencing beyond an object's bounds (spatial violation), referencing via a pointer after the region is freed, or Prevent exploitation of programming errors such as freeing invalid pointers (temporal violations). This includes classic heap-based attacks such as heap smashing and point forging. The policy we study here protects only heap-allocated data, which tells how calls to malloc and free set up and free memory regions; We do not deal with stack allocation or unboxed data structures. These can in principle be handled assuming some compiler support (see [32]).

Policies and Rules. Intuitively, for each new allocation, we create a new block id, so-called c (for "color"), and (in memset-like fashion) write c as a tag on each memory location of the newly created memory block. do. The pointer to the new block is also tagged c. Later, when we dereference the pointer, we check that the tag is the same as the tag on the memory cell it points to. When a block is freed , the tags on every cell of the block are changed to a constant F indicating that it is free memory.

를 사용하고, 태그에 대해 컬러 c 또는

중 하나인 t를 기입한다. 우리는 하나의 부가적인 세부 사항을 처리한다 - 메모리 셀은 포인터를 포함할 수 있다. 그러므로 메모리 내의 워드는 두 개의 태그와 연관되어야 한다. 우리는 이것을 각 메모리 셀상의 태그를 쌍(c, t)을 가리키는 포인터로 만들어서 처리하며, 여기서 c는 이 셀이 할당된 메모리 블록의 id이고, t는 셀에 저장된 워드상의 태그이다. 로드 및 스토어에 대한 규칙은 각 메모리 액세스가 유효한지를 (즉, 액세스된 셀이 이 포인터가 가리키는 블록 내에 있는지를) 체크하는 것과 함께, 이들 쌍을 패킹 및 언패킹하는 일을 처리한다.We add additional tags for non-pointers

, and color c or

Enter one of them, t. We take care of one additional detail - memory cells can contain pointers. Therefore, a word in memory must be associated with two tags. We do this by making the tag on each memory cell a pointer to the pair (c, t), where c is the id of the memory block to which this cell is allocated, and t is the tag on the word stored in the cell. The rules for load and store handle packing and unpacking these pairs, along with checking that each memory access is valid (i.e., that the cell accessed is within the block pointed to by this pointer).

(11)

(11)

(12)

(12)

Address arithmetic operations preserve pointer tags:

(13)

(13)

로 설정한다.To maintain the immutability that tags on pointers only occur by assignment, operations that create data from scratch (such as loading constants) do not trigger tags.

set to

We can augment malloc and free tagging memory regions by using the instruction modifiers and temporary rules described at the end of §2. In malloc, we generate a new tag for a pointer to a new area via a temporary rule. Then we use the newly tagged pointer to write zeros to all words within the allocated area using special store rules before returning the tagged pointer.

(14)

(14)

Conversely, free uses a modified store instruction to re-tag the region as unallocated before returning it to the free list:

(15)

(15)

We implemented several variations of this policy to account for performance/security trade-offs. In the first (E), we assign a single color to all memory regions allocated by a given source module. This sandboxing policy provides per-module isolation within a process, similar to software-based fault isolation [46]. In the following variant, we use different numbers of colors to tag regions returned by successive calls to malloc - just in a single color (F) - which provides the weakest form of spatial and temporal memory safety. provided, it only distinguishes allocated from unallocated memory - up to 8 (G) and 32 (H) colors. Increasing the number of colors reduces the aliasing effect caused by color reuse. Finally, we implement a precise full-memory safety policy (I), using the entire 64-bit tag space required for color.

protection demo. We use two attacks from the Juliet family [10]. The first attack is the case of CWE-416 (Use After Free) [28], in which case the application uses policy (I) to catch an attempt to load from a memory location tagged F. The second attack is an example of CWE-122 (Heap-Based Buffer Overflow) [27] where a buffer is allocated and later written to beyond its bounds (using strcpy), thus overwriting the valid area. Using (I), PUMP aborts the instruction attempting to put a letter into the memory location of the tagged F.

characteristic. Sandboxing (E) and low color count policies (F), (G) and (H) assign only a few tags and create only a small number of rules (less than 600 for 32 colors). These add no runtime overhead - the rules all fit into the cache. Full memory safety (I) is more expensive: it allocates one tag per memory allocation, and for this a new rule must be added to the cache. This means more trips through the miss handler and, in some benchmarks, the specific rule set is larger than the cache. Nonetheless, the rule locality is high (see Figure 7), and the average runtime overhead is only 13%. We can witness a maximum overhead of around 130% for GemsFDTD.

Related Works. Clause et al. [16] first demonstrated spatial and temporal memory protection using metadata tainting. Deng et al. [19, 20] supported such tainting with hardware tag management. HardBound [21] is an approach to spatial memory safety that places boundary information in shadow space to maintain data structure layout compatibility between monitored and unmonitored code. HardBound's runtime overhead is 10 to 20%. Watchdog [32] is a follow-up to HardBound that additionally prevents temporal violations by generating a unique identifier for each assignment; The average runtime overhead is 24%. SoftBound [33], like HardBound, is a software approach that provides spatial memory safety for C, but at the cost of runtime overhead (67% in SPEC and Olden benchmarks). Baggy Bounds [3] also targets only space violations and achieves 60% runtime overhead in SPEC2000.

4.3 Control-flow integrity

threat model. This policy group targets code-reuse attacks. We make the standard assumption [2] that an attacker cannot execute data or inject or modify code. (We can enforce this assumption using the primitive type policy in §1, just as we do in §5 with our written policy). Instead, attackers attempt to string existing code snippets (gadgets) together in order to induce malicious behavior.

Policies and Rules. A common element of all code-reuse attacks is the introduction of control flows that do not exist in the original binary. We implement a family of CFI policies that validate each indirect control flow (calculated jump) against the program's control flow graph. Because the code is fixed, there is no need to dynamically check direct jumps [2]. First we implement the low-level CFI policies of [2, 51] (J), (K) and (L). (J) tags all indirect call, indirect jump and return instructions and their potential targets with a single tag {f}. When we execute an instruction that is the source of the indirect control flow, we transfer this tag to the PC.

(16)

(16)

All other instructions are tagged with Ø. Whenever a PC is tagged with {f}, the current instruction must have the same tag:

(17)

(17)

Policy (K) further separates and traces the control flow resulting from returns (these tags contain r) from indirect calls and jumps (these tags contain c). It uses many tags (Ø, {r}, {c} and {r, c}). Policy (L) extends to (K) with two additional tags ({p} and {p, c}) to return to authorized code (these tags contain p), so that critical code Enables additional protection against snippets [51].

As seen in Goktas et al. [22], these loose CFI policies do not provide sufficient protection against sophisticated code-reuse attacks. We also implemented a set of fine-grained CFI policies, described by Goktas et al as “ideal CFI”. We use two orthogonal policies: PUMP JOP (M), which precisely tracks the association between indirect jumps and calls and their targets; and §2 (rule 1'-4'), we first introduce a PUMP ROP (M) that performs the same on return. We finally merge these two policies into PUMP CFI (O) - a single policy accurately tracks and verifies all indirect control flows. In all these policies, it is assumed that the compiler or linker computes a sound overapproximation of the indirect control flow and tag instructions.

protection demo. We tested these policies against a specially crafted program consisting of a single call to a "harmless" function. The code also contains "bad" functions that are never called, mimicking dormant gadgets that are not part of the execution path and can be exploited to cause unintended behavior. To simulate a return-oriented attack, a series of assemblies of harmless functions overwrites the stack pointer with the bad function's address, tricking execution into returning to the bad function. Policy (N) detects this simulated attack by indicating that the bad return is not in a valid control flow set.

characteristic. Each of the above CFI policies can be encoded very concisely with only 2 to 4 symbolic rules. The simpler policies (J), (K) and (L) also require very few tags and specific rules. As shown in Figure 1, the largest of these (L) uses 6 constant tags and requires 21 or fewer specific rules. Because of this small working set size, these policies incur no runtime overhead than empty policies. Applying the stronger CFI policies (M), (N), and (O) to the SPEC benchmark generates up to thousands of specific rules for these policies, which are fully contained in the 4096 entry, pre-miss-handler PUMP cache. That's right. As a result, we get the ideal added protection without additional runtime overhead. A complete CFI(O) policy requires an average of 28K words to store the control flow graph for the application (for this simulation, we extract this from an instruction trace generated by gem5; in practice this never worked in our simulation). (requires more space than indicated to contain allowed control flow paths that are not allowed).

Related Works. CFI [2] provides an attractive defense against common code-reuse attacks, but has often been considered too expensive. A recent work [51] demonstrated a low-overhead CFI scheme that provides branch target checking and uses a randomizing "springboard" as an additional defense against successfully constructing gadgets. However, this work is not a specific return point with a specific target as policies (N), (M) and (O) do, but similar to the single-target examples in Rules 1 to 4 from §2, the permitted It only sanctions call and return targets, leaving them vulnerable to attack; Nor does it deal with CFI in procedures as our (M) and (O) do.

4.4 Taint Tracking

threat model. This policy covers cases where an attacker enters malformed data into a program that does not sanitize input, which results in unintended or malicious behavior (e.g. SQL or OS command injection).

Policies and Rules. Taint tracking mitigates this threat by detecting when untrusted data can flow into sensitive behavior. PUMP facilitates fine-grained taint tracking using an infinite number of sources, separate taints per source, and multiple taints on each piece of data, where each tag can be a pointer to a set of source ids. let it be A taint on a value is the union of taints on a value used to compute it. Typical taint propagation rules include:

(18)

(18)

(19)

(19)

(20)

(20)

*All policies we study use the same set of symbolic rules, differing only in the number and source of initial taints. We introduce taints in two different ways: by input sources (P and Q) and by code domains ((R), (S) and (T)). In (P), we use a single taint for all input sources (i.e., for SPEC programs, standard I/O streams and input files). This is similar to most previous work [41] where the single-bit taint t simply indicates whether any data from an untrusted source was used to compute the value tagged with t. Policy (Q) extends (P) by assigning each input stream a unique taint id; There is no limit on the number of streams. Tainting by program code protects against untrusted libraries and buggy components. We change the granularity by using a unique taint for (i) each library (R), (ii) each included header file (S), or (iii) each function in the code (T). These policies require the compiler to tag instructions with associated taint identifiers. Finally, we combine (Q) and (R) to create policy (U).

protection demo. We can consider the case of CWE-78 (OS Command Injection) [29], where the user is only allowed to parameterize the arguments of the Is command passed to the system system call. A malicious user adds a parameter string starting with a command termination character along with an arbitrary command. This converts data tagged as "untrusted" and passed as an argument to the execve system call into post-sanitized data. Using policy (U), PUMP aborts execution when it sees that it is about to combine unreliability with a system-call taint.

characteristic. All these policies use the same 8 symbolic rules defined in terms of 7 opgroups. The first two (P and Q) use the input stream as a taint source. For (Q), across all SPEC programs, we only see 2 sources on average, and we only need 10 and 14 specific rules. As a result, these policies do not incur appreciable runtime overhead. For policies (R) to (U), we see a larger set of tasks.

Tainting by function experimentation (T) deliberately pushes the mechanism to extremes, providing more fine-grained tagging than would be useful in practice. A large number of taints results in more degrees of rules than the PUMP cache can hold at one time. Also, the tag-processing overhead is large (4110 instructions). These factors result in an average runtime overhead of 314%. This shows that the PUMP mechanism can strain under complex policies but still support them. Per-file taints (S) also achieve runtime overhead as low as 9%, as they are finer-grained than likely useful, the rule set is smaller, and miss handler resolution is tighter.

Policies (R) and (Q) in which we assign taints to the entire library represent a more reasonable usage. Here, the average runtime overhead is indistinguishable from the no-miss-handler case. This shows that PUMP can also express and support much richer models (compared to previous studies using 1b-taints or 4b-taints), essentially without additional runtime overhead. Not only that, but across these various taint cases, the final tag is only 2 to 3X times the initial and dynamically allocated tag; This shows that while we create a set of non-singleton tags, we know nothing close to the theoretical worst-case power-of-effect.

Related Works. Vulnerabilities addressed using taint tracking include format string attacks [48, 17, 41, 18, 12], cross-site scripting [48, 18, 12], and memory exploitation. exploits [48, 17, 41, 14, 18, 36, 12], code injection [48, 17, 18, 12] and others [49, 18]. Most of the existing works focus on software technologies in which programs are instrumented. Typically, these techniques introduce significant runtime overhead (often 2x or more, some up to 20x), in addition to other handicaps (e.g. handling of race conditions in dynamic binary translations [15]). .

Hardware approaches such as DIFT [41], Minos [17], and SIFT [35] use a single taint bit. Raksha - both on-core [18] and dedicated coprocessor [26] variants - supports up to four concurrent policies using 4-bit tags. In contrast, we allow arbitrary sets of taints corresponding to multiple trusted sources, possibly with different levels of trustworthiness. A more flexible tagging scheme is discussed in §5.

4.5 Composite Policy

Each of these policies is potentially useful, but it would be a shame if you had to choose only one policy to enforce at a time - choosing between protecting against buffer overflows or command injection vulnerabilities, for example. Instead, we generally want protection by writing multiple policies. In fact, some of our individual policies require mutual protection that protects against all threats (CFI relies on type protection to ensure that data cannot be executed and code cannot be created or modified).

Composite potentially increases the number of tags and the number of rules created, which significantly degrades performance. To characterize the effect of the combination, we implement two composite policies. First we implement a fairly small one based on the simplest instance of each of the four protection classes: 3 primitive types (C), simple memory safety (F), CCFIR (L) and single-bit input-taint (P). . Second, we use more complex and stronger protections, which are a composite of 4 primitive types (D), total spatial and temporal memory safety (I), PUMP CFI (O), stream input taint-specific and library-specific complex (U). implement

characteristic. A simple compound policy (V) is suitable for caching and has the same performance as the constituents policy. For larger compound policies (W), the number of instructions needed to resolve rules in the miss handler increases significantly, going from 38 to 710, since all policies have to be resolved. The increase in the final tag is only a factor of 2.5x, suggesting that there is some product set effect from the composite tag, but very little in the worst case scenario. Also, specific rules only increase about 3x with more tag sets and additional opgroups. The combination of a larger specific rule set (now much larger than the PUMP cache capacity) and increased miss handler cost results in an average overhead of 38%, with the worst-case overhead being as high as 280% (GemsFDTD). This demonstrates that PUMP can handle the larger number of rules that compositing results in at the expense of performance impact. For many applications, the overhead is insignificant, but in some cases it becomes excessive. This, together with the taint by function experimentation (T), points to the need for additional software and microarchitectural optimizations to reduce the miss handler service time to obtain reasonable performance on rich complexes such as this, which is the focus of our ongoing research.

4.6 Discussion

The total number of rules does not fully account for the locality of the rules and consequently the effective working set size. Figure 7 shows the cumulative distribution function (CDF) of the number of unique rules used within a million instruction sequence within a billion instruction simulation for the gcc benchmark. This shows that the overall memory safe (I) has a very dense working set (mostly less than 3000); This is important because the number of specific rules in a non-composite policy is at most. This locality helps explain why the performance overhead is low despite having a much larger rule set. A composite CFI (O) has a larger working set, but the composite rule set fits completely in the 4096 entry cache, so there are no exits.

Previous works have used ingenious schemes to succinctly express or approximate safety and security policies (eg [42]), but these are often compromises to the intended policy and can trade complexity for brevity. We show that it is possible to include rich metadata that more fully and more naturally accommodates the requirements of a security policy with little or no added runtime overhead. Instead of imposing fixed boundaries on metadata representation and policy complexity, PUMP moderately degrades performance. This allows policies to make more data available where needed without affecting performance and size in the normal case. Even complex policies can be easily expressed and enforced, further enabling incremental granularity and performance tuning of policies.

4.7 Other micro-policies

We envision that our programming model can encode a number of different policies. Information-flow control (e.g., [6, 37, 40, 24, 8]) is richer than the simple taint tracking model here, but tracking the implicit flow is a RIFLE-style binary translation ) [44] or by use of some supported PC tags from the compiler. Micro-policies can support lightweight access control and segmentation [47]. Tags can be used to identify non-forgeable resources [50]. Unique generated tokens can play a key role in sealing and guaranteeing data, which in turn can be used for powerful abstractions - ensuring that data is only created and destroyed by authorized code components. Micro-policy rules can enforce data immutability such as immutability and linearity. Micro-policies will support concurrency as out-of-band for synchronization primitives such as data or full/empty bits of futures (e.g., [5]) or as a condition to detect race conditions on locks. can (eg, [38, 52]). System designers can apply specific micro-policies to existing code without having to audit or rewrite every line.

5. Related Works

Our example policies and related works are covered in §4. Here we discuss more generally related works on hardware tag checking and propagation. With a few exceptions noted below, most previous works use a small set of tag bits with hard-wired or very restrictive policies (see Figure 2). The first wave of taint hardware used hard-wired taint propagation logic to support a single tail bit appended to each word. Modern systems have the ability to handle multiple independent taint tags (e.g. [18]), multi-bit tags (e.g. [45]) and more flexible policies (e.g. [19]). Added Being the only design to support more than one policy at a time, Raksha supported up to four taint-tracking policies [18].

Previous systems closest to us are Aries [11], FleX1Taint [45], Log-Based Architecture (LBA) [13], and Harmoni [20], all of which propose programmable rule caches backed by software handlers. Only FleX1Taint and LBA specify specific exemplary security policies using a programmable rules cache. In all cases except LBA, the rules cache bases the two inputs on the operation's two operands and produces a single output, whereas the PUMP potentially takes five inputs and produces two outputs: Figure 1 shows these tags It summarizes how sources and destinations are used in our security policy.

Figure 2: Hardware Tagging Approach

LBAs potentially have multiple inputs, but do not handle metadata generation in hardware. Some of LBA's innovations (e.g., limiting general propagation tracking to unary inheritance tracking, including abandonment of taint combinations) led to the abandonment of the generality provided by our solution particularly quickly. Even with these limited policies, LBAs have ~50% runtime overhead compared to the 8% average overhead of most single policies. The policies we demonstrate here are richer than those supported by FleXiTaint because of the extra tag inputs and outputs and richer tag metadata.

6. Future research

The PUMP design offers an attractive combination of flexibility and performance, supporting a diverse collection of low-level, fine-grained security policies with a single policy performance comparable to dedicated mechanisms in most cases, while degrading moderately in most cases as rule complexity increases. support richer and more complex policies that To understand this design space more thoroughly, many issues need further investigation. First, if we have a running hardware implementation, we will need to integrate the PUMP hardware and low-level software with the host operating system and software toolchain (eg compiler, linker and loader). Second, we wonder if the mechanism provided by PUMP can be used to protect its own software constructs. We believe that by implementing a "compartmentalization" micro-policy using PUMP and using it to protect the miss-handler code, we can replace the special miss-handler mode of operation. Finally, we find it easy to assemble an orthogonal set of policies, where the protection afforded by each policy is completely independent of the other policies. However, policies often interact: for example, an information-flow policy may require placing a tag in a new area allocated by a memory safety policy. Policy construction needs more research in terms of representation and efficient hardware support.

Figure 3: Distribution of initial tags

Figure 4: Distribution of final tags

Figure 5: Distribution of specific rules

Figure 6: Distribution of runtime overhead (of policy A above)

Figure 7: CDF of working set size for gcc

7. References

[I] Alpha Architecture Handbook. Digital Equipment Corporation, 1992.

[2] M. Abadi, M. Budiu, LJ Erlingsson, and J. Ligatti. Control-flow integrity. In Proc. ACM CCS, pages 340-353, 2005.

[3] P. Akritidis, M. Costa, M. Castro, and S. Hand. Baggy bounds checking: an efficient and backwards-compatible defense against out-of-bounds errors. In Proc. USENIX Security, pages 51-66, 2009.

[4] D. Arora, S. Ravi, A. Raghunathan, and N. K. Jha. Architectural support for run-time validation of program data properties. IEEE Trans. VLSI Sys., 15(5):546-559, May 2007.

[5] Arvind, R. S. Nikhil, and K. K. Pingali. l-structures: Data structures for parallel computing. In Proc. Wkshp on Graph Reduction (Springer- Verlag LNCS 279), Sept. 1986.

[6] T. H. Austin and C. Flanagan. Efficient purely-dynamic information flow analysis. In Workshop on Programming

Languages and Analysis for Security (PLAS), PLAS, pages 1 13- 124. ACM, 2009.

[7] (authors removed for anonymity). PUMP - A Programmable Unit for Metadata Processing, 2014. To appear.

[8] A. Azevedo de Amorim, N. Collins, A. DeHon, D. Demange, C. Hrij:cu, D. Pichardie, B. C. Pierce, R. Pollack, and A. Tolmach. A verified information-flow architecture. In POPL, pages 165-178. ACM, Jan. 2014.

[9] N. Binkert, B. Beckmann, G. Black, S. K. Reinhardt, A. Saidi, A. Basu, J. Hestness, D. R. Hower, T. Krishna, S. Sardashti, R. Sen, K. Sewell, M. Shoaib, N. Vaish, M. D. Hill, and D. A. Wood. The gem5 simulator.

SIGARCH Comput. Archil News, 39(2): 1-7, Aug. 201 1.

[10] T. Boland and P. E. Black. Juliet 1.1 C/C++ and Java test suite.

Computer, pages 88-90, 2012.

[11] J. Brown and T. F. Knight, Jr. A minimally trusted computing base for dynamically ensuring secure information flow. Technical Report 5, MIT CSAIL, November 2001, Aries Memo No. 15.

[12] H. Chen, X. Wu, L. Yuan, B. Zang, P.-c. Yew, and F. T. Chong. From Speculation to Security: Practical and Efficient Information Flow Tracking Using Speculative Hardware. In

Proc. ISCA, pages 401-412, 2008.

[13] S. Chen, M. Kozuch, T. Strigkos, B. Falsafi, P. B. Gibbons, T. C.

Mowry, V. Ramachandran, O. Ruwase, M. P. Ryan, and E. Vlachos.

Flexible Hardware Acceleration for Instruction-Grain Program Monitoring. In Proc. ISCA, pages 377-388, 2008.

[14] S. Chen, J. Xu, N. Nakka, Z. Kalbarczyk, and R. Iyer. Defeating memory corruption attacks via pointer taintedness detection. In Proc. IEEE DSN, pages 378-387, 2005.

[15] J. Chung, M. Dalton, H. Kannan, and C. Kozyrakis. Thread-safe dynamic binary translation using transactional memory. In HPCA, pages 279-289. IEEE, 2008.

[16] J. A. Clause, I. Doudalis, A. Orso, and M. Prvulovic. Effective memory protection using dynamic tainting. In Proc. ASE, pages 284-292. ACM, 2007.

[17] J. R. Crandall and F. T. Chong. Minos: Control data attack prevention orthogonal to memory model. In Proc. IEEE MICRO, pages 221-232, 2004.

[18] M. Dalton, H. Kannan, and C. Kozyrakis. Raksha: a flexible information flow architecture for software security. In Proc. ISCA, pages 482-493, 2007.

[19] D. Y. Deng, D. Lo, G. Malysa, S. Schneider, and G. E. Suh. Flexible and Efficient Instruction-Grained Run-Time Monitoring Using On-Chip Reconfigurable Fabric. In Proc. IEEE MICRO, pages 137-148, 2010.

[20] D. Y. Deng and G. E. Suh. High-performance parallel accelerator for flexible and efficient run-time monitoring. In Proc. IEEE DSN, pages 1-12, 2012.

[21] J. Devietti, C. Blundell, M. M. K. Martin, and S. Zdancewic.

HardBound: Architectural support for spatial safety of the C programming language. In S. J. Eggers and J. R. Lams, editors, ASPLOS, pages 103-1 14. ACM, 2008.

[22] E. Goktap, E. Athanasopoulos, H. Bos, and G. Portokalidis. Out Of Control: Overcoming Control-Flow Integrity. In Proc. IEEE S&P, 2014. [23] C. J. Haley, S. M. Luera, M. D. Schanken, and W. B. Geer. Final evaluation report unsys a series mcp/as release 3.7. Technical Report CSC-EPL-871003, Library No. S-228,515, National Computer Security Center, Fort Meade, MD, August 5 1987.

[24] D. Hedin and A. Sabelfeld. Information-flow security for a core of JavaScript. In 25th IEEE Computer Security Foundations Symposium (CSF), CSF, pages 3-18. IEEE, 2012.

[25] J. L. Henning. SPEC CPU2006 benchmark descriptions. SIGARCH Comput. Archil News, 34(4):1-17, Sept. 2006.

[26] H. Kannan, M. Dalton, and C. Kozyrakis. Decoupling Dynamic Information Flow Tracking with a Dedicated Coprocessor. In Proc. IEEE

DSN, pages 105-1 14, 2009.

[27] MITER Corp. CWE-122: Heap-based buffer overflow. [28] MITER Corp. CWE-416: Use after free.

[29] MITER Corp. CWE-78: Improper neutralization of special elements used in an OS command (OS command injection).

[30] MITER Corp. CWE-843: Access of resource using incompatible type (type confusion).

[31] D. A. Moon. Architecture of the Symbolics 3600. In Proc. ISCA, pages 76-83, Los Alamitos, CA, USA, 1985. IEEE Computer Society. [32] S. Nagarakatte, M. M. K. Martin, and S. Zdancewic. Hardware-Enforced Comprehensive Memory Safety. IEEE Micro, 33(3):38-47, May-June 2013.

[33] S. Nagarakatte, J. Zhao, M. M. K. Martin, and S. Zdancewic. SoftBound: highly compatible and complete spatial memory safety for C. In Proc. PLDI, pages 245-258. ACM, 2009.

[34] E. I. Organick. Computer System Organization: The B5700/B6700

Series. Academic Press, 1973.

[35] M. Ozsoy, D. Ponomarev, N. B. Abu-Ghazaleh, and T. Suit SIFT: a low-overhead dynamic information flow tracking architecture for SMT processors. In Conf. Computing Frontiers, page 37, 201 1.

[36] F. Qin, C. Wang, Z. Li, H. Kim, Y. Zhou, and Y. Wu. LIFT: A low-overhead practical information flow tracking system for detecting security attacks. In Proc. IEEE MICRO, pages 135-148, 2006.

[37] A. Russo and A. Sabelfeld. Dynamic vs. static flow-sensitive security analysis. In Proc. CSF, pages 186-199, 2010.

[38] S. Savage, M. Burrows, G. Nelson, P. Sobalvarro, and T. Anderson. Eraser: A dynamic race detector for multi-threaded programs. ACM Trans. Comp. Sys. , 15(4), 1997.

[39] H. Shacham. The Geometry of Innocent Flesh on the Bone: Return- into-libc without Function Calls (on the x86). In Proc. ACM CCS, pages 552-561, Oct. 2007.

[40] D. Stefan, A. Russo, J. C. Mitchell, and D. Mazieres. Flexible dynamic information flow control in Haskell. In 4th Symposium on Haskell, pages 95- 106. ACM, 2011.

[41] G. E. Suh, J. W. Lee, D. Zhang, and S. Devadas. Secure Program Execution via Dynamic Information Flow Tracking. In Proc. ASPLOS, pages 85-96, 2004.

[42] L. Szekeres, M. Payer, T. Wei, and D. Song. SoK: Eternal war in memory. In Proc. IEEE S&P, pages 48-62, 2013.

[43] G. S. Taylor, P. N. Hilfinger, J. R. Larus, D. A. Patterson, and B. G.

Zorn. Evaluation of the SPUR lisp architecture. In Proc. ISCA, pages 444-452, 1986.

[44] N. Vachharajani, M. J. Bridges, J. Chang, R. Rangan, G. Ottoni, J. A. Blome, G. A. Reis, M. Vachharajani, and D. I. August. RIFLE: An architectural framework for user-centric information-flow security. In Proc. IEEE MICRO, 2004.

[45] G. Venkataramani, I. Doudalis, Y. Solihin, and M. Prvulovic. FlexiTaint: A programmable accelerator for dynamic taint propagation. In Proc. HPCA, pages 173-184, Feb. 2008.

[46] R. Wahbe, S. Lucco, T. E. Anderson, and S. L. Graham. Efficient software-based fault isolation. In SOSP, pages 203-216, 1993.

[47] E. Witchel, J. Cates, and K. Asanovi c. ondrian memory protection. In Proc. ASPLOS, pages 304-316, New York, NY, USA, 2002. ACM.

[48] W. Xu, S. Bhatkar, and R. Sekar. Taint-enhanced policy enforcement: a practical approach to defeat a wide range of attacks. In Proc. USENIX Security, Berkeley, CA, USA, 2006.

[49] H. Yin, D. X. Song, M. Egele, C. Kruegel, and E. Kirda. Panorama: capturing system-wide information flow for malware detection and analysis. In Proc. CCS, pages 1 16-127. ACM, 2007.

[50] N. Zeldovich, H. Kannan, M. Dalton, and C. Kozyrakis. Hardware enforcement of application security policies using tagged memory. In Proceedings of the 8th USENIX conference on Operating systems design and implementation, OSDI, pages 225-240. USENIX Association, 2008.

[51] C. Zhang, T. Wei, Z. Chen, L. Duan, L. Szekeres, S. McCamant, D. Song, and W. Zou. Practical Control Flow Integrity & Randomization for Binary Executables. In Proc. IEEE S&P, 2013.

[52] P. Zhou, R. Teodorescu, and Y. Zhou. HARD: Hardware-assisted lockset-based race recording. In Proc. HPCA, 2007.

8. Symbolic rules

8.1 Primitive Types

Alternate rules for checking return addresses

8.2 Memory Safety

을 가정하는데, 이는 힙을 가리키는 포인터가 아닌 모든 데이터에 태깅하는데 사용된다. 레지스터에 대한 태그는 컬러 또는

(t로 작성됨)이다. 메모리에 대한 태그는 컬러와 컬러 또는

((c1, t2)로 작성됨) 또는 F (할당되지 않음)의 쌍이다. 힙은 처음에 모두 F로 태깅된다. 마지막으로 명령어상의 태그는 세트: {tmalloc, tmal loci nit, tfreeinit, tsomething}로부터 작성된다.N-colorize with N=2 ⁶⁴ -k for full memory safety. We write color in c, and use it to tag a pointer to the heap. We have special tags that are different in color

, which is used to tag all data that is not a pointer to the heap. Tags for registers can be colored or

(written as t). Tags for memory are color and color or

A pair of (written as (c1, t2)) or F (unassigned). Heaps are initially tagged with all F's. Finally, the tag on the command is created from the set: {tmalloc, tmal loci nit, tfreeinit, tsomething}.

8.3 CFI

8.3.1 CFI-1ID [2]

We use 2 tags written as sets: ø and {f}. The tag {f} is used to tag all indirect control flows as well as all their potential destinations. The tag ø is used for everything else.

8.3.2 CFI-2ID [2]

In this policy, r is used to mark returns and potential targets of returns, and c is used for indirect calls and jumps and potential targets of jumps. Since these two cases can overlap, we are using 4 tags written as sets: ø{r}, {c} and {r, c}.

8.3.3 CCFIR [51]

r is return-id, c is cal1-id, and p is return-into-privileged-code-id. Set: Assume 6 tags written in ø, {r}, {p}, {c}, {r, c} and {p, c}.

8.3.4 CFI-ROP

이다.We assume an allowed control-flow graph χ containing pairs of return IDs and possible destination IDs. We write the id below as ci or pc. tag is a valid ID or

am.

8.3.5 CFI-JOP

Assume an allowed control-flow graph, X.

8.3.6 Complete CFI

We assume an allowed control-flow graph x.

8.4 Taint Tracking

8.5 Subword Operation

The above rules we used in our experiments do not take subword operations into account. To properly support subword operations, we would have had to split the load and store opgroups into two opgroups for word operations (wload and wstore) and two opgroups for byte operations (bload and bstore).

The rules for any policies that explicitly talk about loads or stores should be changed (simple types, memory safety, and taint tracking). Here's how to change a simple type policy (without the retaddr variant) (the w opgroup corresponds to the previous rule).

Here is the b rule for memory safety.

Here is the bstore rule for taint tracking.

Claims (13)

As a method for performing metadata rule-based mediated data transfer,
issuing a first direct memory access command from a first device, wherein the first direct memory access command accesses first data stored in a first memory location having a first metadata tag, the first memory location having a first metadata tag; contained in a first memory coupled to one interconnect fabric, the first device being an untrusted device and coupled to a second interconnect fabric; and
performing processing to arbitrate the first direct memory access command issued from the second interconnect fabric to the first interconnect fabric;
The processing is:
Whether to allow execution of the first direct memory access instruction using a first rules cache containing metadata rules for the direct memory access instruction and according to one or more metadata tags used in the first direct memory access instruction. determining, wherein the first rule cache contains metadata rules for direct memory access instructions used to define allowed direct memory access operations;
A method for performing metadata rule-based moderated data transfer. According to claim 1,
Further comprising performing, in a metadata processing domain using metadata rules of a second rule cache, metadata processing to determine whether to allow execution of a second instruction in a code execution domain isolated from the metadata processing domain. And, the second command is included in user code executed on a processor of the code execution domain.
Methods for Performing Metadata Rules-Based Moderated Data Transfer According to claim 2,
The processing is:
determining whether a rule exists in a first rule cache for the first direct memory access instruction according to the one or more metadata tags used in the first direct memory access instruction;
in response to determining that no rule exists in the first rule cache for the first direct memory access instruction, performing rule cache miss processing in the metadata processing domain;
The step of performing rule cache miss processing in the metadata processing domain;
determining whether execution of the first direct memory access instruction is permitted;
in response to determining that the first direct memory access instruction is allowed, generating a new rule for the first direct memory access instruction; and
inserting the new rule into the first rule cache;
Methods for Performing Metadata Rules-Based Moderated Data Transfer According to claim 1,
wherein the first instruction performs an operation comprising one of reading from and writing to the first memory location;
Methods for Performing Metadata Rules-Based Moderated Data Transfer According to claim 1,
The second interconnect fabric includes a plurality of untrusted devices including the first device, and a direct memory access command issued by the plurality of devices is an untrusted request to access a memory location of the first memory. ,
Methods for Performing Metadata Rules-Based Moderated Data Transfer According to claim 1,
The processing is:
obtaining the first metadata tag for the first memory location from the first memory;
providing the first metadata tag as a first metadata tag of the one or more metadata tags used to determine whether to allow execution of the first direct memory access instruction;
Methods for Performing Metadata Rules-Based Moderated Data Transfer According to claim 6,
The one or more metadata tags used to determine whether to allow execution of the first direct memory access command include the first metadata tag and additionally indicate a device identifier that uniquely identifies the first device. 1 contains a plurality of metadata tags, including the current instruction metadata tag for the direct memory access instruction,
Methods for Performing Metadata Rules-Based Moderated Data Transfer According to claim 7,
wherein the plurality of metadata tags further comprises a program counter metadata tag indicating a current state of the first device and indicating whether direct memory access instructions from the first device are enabled or disabled.
Methods for Performing Metadata Rules-Based Moderated Data Transfer According to claim 8,
wherein the plurality of metadata tags further comprises a byte enable metadata tag identifying which of the one or more bytes of the first memory location is being accessed by the first direct memory access instruction.
Methods for Performing Metadata Rules-Based Moderated Data Transfer According to claim 9,
The plurality of metadata tags used to determine whether to allow execution of the first direct memory access instruction are provided as inputs to the first rule cache in a first set of registers, and a second set of registers are provided as inputs to the first rule cache. which stores the output of the cache,
Methods for Performing Metadata Rules-Based Moderated Data Transfer According to claim 10,
The second set of registers includes a first output register containing a next tag of a program counter for a next instruction, the next tag indicating the state of the first device after performing the first direct memory access instruction. ,
Methods for Performing Metadata Rules-Based Moderated Data Transfer According to claim 11,
wherein the second set of registers comprises a second output register containing a tag placed on a memory result if the first direct memory access instruction is a store or write to the first memory location.
A method for performing metadata rule-based moderated data transfer. According to claim 3,
A current transaction identifier is stored in a transaction identifier register, and a write to the commit register results in a comparison between the current contents of the commit register and the transaction identifier register, whereby the current contents of the commit register are changed to the transaction identifier. in response to determining that it matches the current contents of the identifier register, the new rule is written to the first rule cache.
A method for performing metadata rule-based moderated data transfer.

Images