KR20250100654A - Region identifier based on instruction fetch address - Google Patents

Abstract

A device (100) comprising: an instruction fetch circuit (105) responsive to an instruction fetch address to fetch an instruction associated with the instruction fetch address; a processing circuit (125) responsive to the instruction to perform an operation that varies depending on the target memory address, if the instruction includes a request specifying a target memory address and the request specifying the target memory address is permitted; and a memory security circuit (135), wherein if the instruction includes the request specifying the target memory address, the memory security circuit is configured to: determine a current region identifier based on a predetermined slice of the instruction fetch address; identify, based on the current region identifier, authorization information for a request issued in response to an instruction associated with the current region identifier; determine, based on the authorization information, whether the request is prohibited; and in response to a determination that the request is prohibited, issue a response to the processing circuit indicating that the request is prohibited.

Description

Region identifier based on instruction fetch address

This technology relates to the field of data processing.

In a data processing system, instructions may be executed that include accessing data or instructions within memory. For example, some instructions may include requests to read or write to locations within memory, while other instructions may include requests to execute instructions stored at locations within memory. It may be useful to be able to define permissions for such access.

In a first example of the present technology, the following is provided: As a device:

An instruction fetch circuit responsive to an instruction fetch address for fetching an instruction associated with the instruction fetch address;

A processing circuitry that responds to the command to perform an operation that depends on the target memory address, if the command includes a request specifying a target memory address, and the request specifying the target memory address is permitted; and

A memory security circuit comprising:

Based on a predetermined slice of the above instruction fetch address, determine the current region identifier;

Based on the current realm identifier, identify authorization information for a request issued in response to a command associated with the current realm identifier;

Based on the above authority information, determine whether the request is prohibited;

In response to a determination that the request is prohibited, the processing circuitry is configured to issue a response indicating that the request is prohibited.

As another example, the following is provided: As a method:

In response to the instruction fetch address, a step of fetching an instruction associated with the instruction fetch address; and

If the above command includes a request specifying a target memory address:

In response to the above command, if the request specifying the target memory address is allowed, performing an operation that varies depending on the target memory address; and

A step of determining a current region identifier based on a predetermined slice of the above instruction fetch address;

A step of identifying authorization information for a request issued in response to a command associated with the current area identifier, based on the current area identifier;

A step of determining whether the request is prohibited based on the above authority information; and

In response to a determination that the request is prohibited, the method comprises the step of issuing a response indicating that the request is prohibited.

In another example, the following is provided: A computer program, which, when run on a computer, causes the computer to:

Instruction fetch program logic responsive to an instruction fetch address to fetch an instruction associated with the instruction fetch address;

A processing program logic responsive to the command to perform a request indicating the target memory location, if the command includes a request specifying a target memory address, and the request specifying the target memory address is allowed; and

Provides memory security program logic, wherein when the command includes the request specifying the target memory address, the memory security program logic:

Based on a predetermined slice of the above instruction fetch address, determine the current region identifier;

Based on the current realm identifier, identify authorization information for a request issued in response to a command associated with the current realm identifier;

Based on the above authority information, determine whether the request is prohibited;

In response to a determination that the request is prohibited, the processing program logic is configured to issue a response indicating that the request is prohibited.

In another example, a computer-readable storage medium is provided for storing the aforementioned computer program. The computer-readable storage medium may be a transitory storage medium or a non-transitory storage medium.

Additional aspects, features and advantages of the present technology will become apparent from the following description, which should be read in connection with the accompanying drawings, in which:
Figure 1 schematically illustrates a data processing device;
Figures 2a and 2b illustrate examples of permissions defined for specific address spaces.
Figures 3a and 3b illustrate examples of how instructions in different code regions can be executed.
Figures 4 to 6 illustrate various examples of determining a space region identifier (SRegionID) based on an instruction fetch address.
Figure 7 illustrates an example of how to define read, write, and execute permissions in a permission table.
Figure 8 illustrates an example of circuitry that can be used to identify and access one or more authorization tables.
FIG. 9 is a flowchart illustrating an example of a method that may be performed in response to a memory access request being issued.
Figure 10 is a flow diagram illustrating an example of how a data processing unit may react to the execution of some branch instructions.
Figure 11 illustrates an example simulator implementation that may be used.

Before discussing exemplary implementations with reference to the attached drawings, a description of the following exemplary implementations and associated advantages is provided.

According to one exemplary configuration, a device is provided that includes instruction fetch circuitry responsive to an instruction fetch address to fetch an instruction associated with the instruction fetch address. For example, the instruction fetch circuitry may fetch an instruction from a memory location indicated by the instruction fetch address (which may be, for example, a virtual address or a physical address). In a particular example, the instruction fetch address may be a program counter (PC) address associated with the instruction.

The device also includes processing circuitry that, if the instruction includes a request specifying a target memory address, performs an action that depends on the target memory address, if the request specifying the target memory address is permitted. For example, a load or store instruction specifying a target memory request may include a request to read from or write to a target memory location associated with the target memory address, while a branch instruction (which may in some examples be a function call or function return instruction) specifying a target memory address may include a request for execution to branch to an instruction stored at the target memory location. However, it should be understood that other types of instructions (other than load, store and branch instructions) may also include such requests.

It may be useful to provide mechanisms to protect data and instructions stored in memory from read and write accesses issued by code regions within a process that are not permitted to access such data/instructions, and to prevent branching of execution to specific regions of code. One way to do this is to define permissions that vary based on the target memory address, which can be defined in tables such as page tables. However, these permissions do not take into account the source of the request, and they do not define which process or part of a process is permitted to access/branch to which location in memory. Thus, unless the permissions in the page table are updated, all instructions have the same access rights to a given memory page. Updating these permissions can incur significant latency, since it requires access to memory, and thus such updates can only be performed between processes, in which case, within any one process (or application), all code in that application typically has the same privilege to read/write/execute data/instructions from any given memory location.

Another approach might be to additionally include a "privilege overlay" or "privilege key" mechanism that can dynamically revoke certain privileges based on the programming of CPU registers that revoke or modify certain privileges. For example, if privileges are defined in a page table (e.g.), there might be a number of bits in the "overlay index" of the page table entry. Thus, each page of memory would be annotated with a "key", and there would be a programmable "overlay interpretation" register that could subtract privileges. For example, the overlay interpretation register might indicate a change such as "remove write access from page with index 2", or "toggle index 3 from writable to executable".

However, these approaches also provide only a temporal view of permission: none of the approaches defined above considers the source of an access request (i.e., the instruction containing the request), because permission is determined solely by "what was last written to the configuration registers?", not by "what code is currently executing?". As a result, since permission is derived from the current values of registers and what is currently stored in page table entries, a loss of control flow integrity may (for example) lead to a loss of integrity of other parts of memory (e.g., a branch of execution to an unexpected location without updating the overlay interpreter registers or page table entries, where the expected path of program flow to reach that location must involve updates to the overlay interpreter registers or page table entries).

To address these issues, the present technique provides a mechanism by which permissions are defined code-space (e.g., depending on the source of a memory access request) rather than merely code-temporally (e.g., depending on when the request was issued).

In particular, the device of the present technology includes memory security circuitry for determining a current region identifier (also referred to as "RegionID") based on a predetermined slice of an instruction fetch address, when the instruction includes a request specifying a target memory address. Thus, the RegionID depends on the source of the request (e.g., the instruction) rather than solely on the target of the request (e.g., the target memory address - it will be appreciated that permissions for a particular RegionID may vary depending on the target of the memory access). The memory security circuitry is configured to identify, based on the current region identifier, permissions information for a request issued in response to an instruction associated with the current region identifier, and to determine, based on the permissions information, whether the request is forbidden. The memory security circuitry is further configured to issue, in response to a determination that the request is forbidden, a response to the processing circuitry indicating that the request is forbidden.

The RegionID is determined based on the instruction fetch address for the instruction requested to access/branch to the memory location identified by the target memory address (and optionally also based on other factors). Thus, since the authorization information is looked up based on the RegionID, the memory security circuitry determines whether the request is prohibited based on the source of the request. This allows the memory security circuitry to enforce fine-grained authorization that varies based on the specific location within the process/application where the request is issued, and to maintain the integrity of code regions even if there is a loss of control flow integrity. Furthermore, determining the RegionID based on a slice of the instruction fetch address provides a simple, low-cost mechanism for determining the RegionID, which may avoid the need to implement expensive/high-latency table lookups based on the instruction fetch address, for example. Note that even if the authorization information indicates that the request is permitted, the access request may still ultimately be denied, for example, if it fails any other checks performed by the device.

The present technology also provides a mechanism for defining different privileges for different instructions, which may be, for example, different parts of a single process or application (e.g., because privileges may vary based on the source of the request, rather than solely on the target of the request or the value of a configuration register that must be updated to update the permission set). Thus, the present technology may be useful in applications and operating system (OS) kernels, for example, for hardening core security components of software. In an OS kernel, this mechanism may be used, for example, to harden kernel memory management code and structures against accidental or malicious tampering by other kernel components. It may also be used to sandbox kernel drivers without the performance overhead of delegating such components to a separate process. The same benefits apply within applications: for example, protecting memory allocation library code/structures, and/or dynamic linker code/structures from tampering by the rest of the application. It may also provide benefits to applications that include a sandboxed environment or a Just-In-Time (JIT) environment for handling untrusted input.

In some examples, the memory security circuitry is configured to determine whether the request is forbidden based on page table access permission information derived from a page table entry associated with the target memory address. In such examples, the memory security circuitry is configured to, in response to a determination that the request is forbidden based on at least one of the permission information and the page table permission information, issue a response indicating that the request is forbidden.

While defining permissions based on the source of a request is advantageous for the reasons presented above, the technique can be particularly effective if such permissions are provided in addition to page table access permissions defined in page tables that depend on the target memory address specified by the request. In such an example, if the permissions defined with respect to a RegionID are different from the permissions defined based on the page table entry for the target memory address, the memory security circuitry is configured to treat the more restrictive permissions as correct (e.g., by issuing a response indicating that the request is forbidden if one or both of the sets of permissions indicate that the request is forbidden).

In some examples, the memory security circuitry is configured to determine a source region identifier corresponding to a region of memory storing an instruction based on a predetermined slice of an instruction fetch address, and to determine a current region identifier based on dependency on the source region identifier.

As explained above, the current region identifier depends on the instruction fetch address. In this example, this dependency is expressed by the source region identifier (also called the space region identifier (SRegionID)), which corresponds to the region of memory that stores the instruction (and thus the region of the address space that contains the instruction fetch address).

In some examples, the processing circuitry responds to a return-space-identifier instruction that determines the current source region identifier and identifies a destination register to store the current source region identifier in the destination register.

This provides a mechanism by which, for example, a shared library can identify the code region from which it was called (branched). Note that the return-space-identifier instruction may be a dedicated instruction, or a modification of an existing instruction - for example, the current source region identifier may be stored in a system register field, and the return-space-identifier instruction may be an instruction to read that field in a system register.

In some examples, the device includes a register for storing a current time identifier, wherein the memory security circuitry is configured to determine a current region identifier that varies based on a source region identifier and a current time identifier, wherein the current time identifier is looked up independently of an instruction fetch address. In such examples, the processing circuitry is responsive to detecting an instruction having a given source region identifier that is different from a source region identifier associated with a previous instruction to set the current time identifier to a predetermined value.

In addition to a spatial component (e.g., a source region identifier), in this example the current region identifier also has a temporal component (e.g., based on the current temporal region identifier, TRegionID), which is forced to a predetermined value (e.g., it may be 0) in response to a change in the source region identifier. This approach provides additional security against loss of control flow integrity, since branching to different regions of the code forces the temporary region identifier to a predetermined value, which may be associated with a predetermined set of permissions (e.g., a set of permissions).

In some examples, the device includes a configuration register for storing slice identification information indicating a predetermined slice of an instruction fetch address.

The bits of the instruction fetch address used as the predetermined slice may, in some instances, be hardwired (e.g., not software configurable). However, in this example, the predetermined slice is identified by slice identification information stored in a configuration register. This configuration register is accessible to software, allowing the slice identification information to be configured by software.

The way in which the slice identification information is represented is not particularly limited. For example, it may be represented as an indication of the first and last bit positions (i.e., the most significant and least significant bit positions) of the instruction fetch address to be used as the predetermined slice (e.g., if bits (44:38) of the instruction fetch address are to be used, the slice identification information may identify bit positions (44 and 38)). Alternatively, the configuration register may store an indication of either the first or last bit positions of the slice and the number of bits in the slice (e.g., in an example in which bits (44:38) are used, either bit position (44) or bit position (38) may be identified and the number of bits in the slice may be represented as 7).

In some examples, the memory security circuitry responds to a determination that an additional slice of the instruction fetch address has a value other than a predetermined value to determine that the source region identifier is a default source region identifier.

It may be useful to identify an additional slice of the instruction fetch address, and use this to provide additional information about the source region identifier. For example, if this additional slice holds a particular value (or a value other than some predetermined value), it may be determined that the default source region identifier will be used. This provides additional flexibility in which regions of memory are associated with which source region identifiers. For example, this approach could be used to require that region identification only occur for certain larger regions of the address space, allowing (for example) an application to operate in an "ambient" address space from which multiple regions are partitioned (for example, having a default source region identifier of 0). This allows a small set of regions of the address space to be selected for sandboxing within the process/application, but the bulk of the address space is reserved for arbitrary, less-trusted components in the application. Using an additional slice as a mask to provide this peripheral address space has only a small hardware cost, since it is a simple mask that can be applied in the front-end of the microarchitecture, meaning that the rest of the device (e.g. the CPU pipeline) can be informed of the source region identifier in advance.

In the above examples, the manner in which a predetermined slice of an instruction is used to determine a source region identifier is not particularly restricted. However, in certain instances, the predetermined slice may be used directly as a source region identifier. This provides an approach that requires less complex circuitry than, for example, alternative approaches in which the predetermined slice is used to indirectly determine the identifier (e.g., by applying some function to the predetermined slice, or by querying a storage structure to determine the source region identifier using the predetermined slice). However, a disadvantage of directly using a predetermined slice as a source region identifier may be that it provides less flexibility in which region or memory is assigned to which source region identifier.

In some examples, the instruction fetch address includes a virtual address, the instruction fetch circuitry is configured to fetch an instruction depending on a given portion of the instruction fetch address, the given portion of the instruction fetch address indicating a location in memory where the instruction is stored, and wherein the given portion of the instruction fetch address and the predetermined slice of the instruction fetch address overlap by at least one bit.

In some architectures, a process can use a virtual address to refer to a location in memory, which can be translated into a physical address that identifies the location in memory. This allows, for example, multiple different virtual address spaces to be defined, each with its own unique mapping to a physical address space. For example, different processes can have different virtual address spaces.

This can lead to a situation where multiple different virtual addresses are mapped onto the same physical address - for example, if multiple different processes with different virtual address spaces want to access a given instruction within a shared library of code, each may use a different virtual address to reference that instruction. This is called aliasing. However, aliasing can impact the performance of the device - for example, entries in the translation lookaside buffer or instruction cache may be indexed and/or tagged by virtual address, meaning that each aliased virtual address maps to a different entry. This can result in multiple copies of the same instruction/translation being stored in separate entries in the cache/TLB, taking up space that could otherwise be used to store other instructions.

This problem can be addressed by disallowing aliasing - for example, by requiring that a given portion of an instruction fetch address be the same for each virtual address mapping to a particular physical address. However, it may be useful to maintain some information in a given portion that indicates which process/section of code a particular instance of an aliasing virtual address originates from. To address this, the inventors of the present technology propose that one or more bits of a given portion (used to identify the corresponding physical address) overlap one or more bits of a predetermined slice (used to determine the source region identifier). These bits may be different for the aliasing virtual address, for example, while the other bits of the given portion remain the same. This allows a cache-like structure to be looked up based on a given portion excluding the overlapping bits, so that only one copy of an instruction from a given physical address is stored in the cache, while still maintaining the information to distinguish the aliasing address.

In some examples, the memory security circuitry is configured to determine whether a request is forbidden based on privilege information that identifies at least one of the following:

ㆍ Read access rights;

ㆍ Record access rights;

ㆍ Authority to perform branching; and

ㆍ Permission to perform a branch without storing the return address.

Thus, the access permission information can indicate any combination of read, write and execute instructions, and can additionally indicate when a branch needs to be performed as a function call (saving the return address).

In some examples, the memory security circuitry is configured to determine a destination region identifier based on a target memory address. In these examples, the memory security circuitry includes table access circuitry that queries a privilege table within the memory based on the current region identifier and the destination region identifier, the privilege table defining privilege information. Furthermore, in these examples, the table access circuitry is configured to support at least one encoding of the privilege table in which different privilege information is defined for different combinations of different destination region identifiers and current region identifiers.

In this example, the permission table can be considered a two-dimensional table in that it is queried based on both the current region identifier (which is determined based on the instruction fetch address) and the destination region identifier (which is determined based on the target memory address). This allows permission information to be defined for a number of different combinations of the current region identifier and the target region identifier, to determine whether the currently executing piece of code is allowed to access/branch to a particular memory location indicated by the target memory address of the request. This allows for certain sections of code to be allowed or denied access to certain sections of memory.

In some examples, the memory security circuitry includes table access circuitry for accessing a permission table defining permission information within the memory, and the device includes a table identification register for storing address information indicating a location of the permission table within the memory.

For example, the address information may be the base address of a table in memory. The table access circuitry uses the address information to locate the table in memory.

In some examples, the device is arranged to operate at one of a plurality of privilege levels, and the device includes a plurality of registers, each of which is configured to store address information indicating a location of a corresponding privilege table in memory. In such examples, the device also includes a register selection circuit that selects one of the plurality of registers as a privilege table identification register based on a current privilege level.

In this example, a separate permission table can be defined for each privilege level. For example, there could be one register for the kernel and one for user space. This allows, for example, more restrictive permissions to be defined when the device is operating at a lower privilege level.

In some examples, the memory security circuitry includes table access circuitry for accessing a privilege table defining privilege information within the memory, the device includes a register storing a current set of privileges representing privilege information defined in the privilege table for a current region identifier, and the table access circuitry is responsive to a determination that the current region identifier has changed to a new region identifier to query the privilege table and the register for the identifier, based on the new region identifier, for an updated set of privileges to be stored.

Therefore, the permission information associated with the current realm identifier can be loaded into a register so that it can be accessed with reduced latency, in this example. Then, whenever the current realm identifier changes, the permission information in the register can be replaced with the updated permission set associated with the new realm identifier.

The format of the register is not particularly limited, but the register may include, for example, a field for each of a plurality of target region identifiers, and each field may store corresponding permission information (e.g., bits for indicating respective permissions, such as a read bit, a write bit, and an execute bit).

In some examples, the memory security circuitry includes table access circuitry for accessing a privilege table defining privilege information within the memory, and the device includes a cache for storing a subset of the privileges defined in the privilege table. In these examples, the device is configured to operate in one of a plurality of contexts, each of which is associated with a context identifier, and the cache includes a plurality of entries, each of which is associated with a corresponding context identifier.

Thus, in this example, some of the entitlement information may be cached, so that future accesses to the entitlement information can be performed with reduced latency, thus improving performance. Additionally, associating each entry with a context identifier (for example, this could be a combination of a virtual machine identifier (VMID) and an address space identifier (ASID)) improves performance, since the cache does not need to be flushed on context switch, and cached data may still be available for later access.

In some examples, the device includes a plurality of registers, each register storing, for each of a plurality of current realm identifiers, a set of permissions representing permissions information for that current realm identifier.

These registers may be provided in place of, or in addition to, the permission table in memory. Adding additional registers may increase the circuit area occupied by the device, but may be advantageous because such registers may be accessed with reduced latency (thus improving the performance of the device).

As in the example above, the format of the register is not particularly limited, but each register may include, for example, a field for each of a plurality of target area identifiers, each field storing corresponding access permission information.

The techniques discussed above may be implemented in a hardware device having circuit hardware implementing the instruction fetch circuitry, processing circuitry, and memory security circuitry described above. However, in another example, the same techniques may be implemented in a computer program (e.g., an architecture simulator or model) that may be provided to control a host data processing device to provide an instruction execution environment for executing instructions from target code. Such instructions may, in some specific examples, include any of a return-space-identifier instruction, a time-identifier update instruction, a branch-and-change-time-identifier instruction, and a branch-and-maintain-time-identifier instruction.

The computer program may include instruction fetch program logic for fetching instructions of target code, and processing program logic for controlling a host data processing device to perform data processing in response to the instructions. Accordingly, the instruction fetch program logic emulates the function of the instruction fetch circuitry of the hardware device as described above, and the processing program logic emulates the processing circuitry.

Additionally, in some examples, some or all of the registers described above may be emulated, and in particular, the program may include register maintenance program logic that maintains data structures (either within memory of the host device or within architectural registers) that represent (emulate) architectural registers of the instruction set architecture being simulated by the program. The emulated registers may include any of the plurality of registers described in some examples above.

Thus, such a simulator computer program can provide, to the target code running on the simulator computer program, an instruction execution environment similar to that provided by an actual hardware device capable of directly executing the target instruction set, even if the host computer running the simulator computer program may not have the actual hardware providing such features. This can be useful for executing code written for one instruction set architecture on a host platform that does not actually support that architecture. Additionally, the simulator can be useful during the development of software for a new version of an instruction set architecture, while the software development is being done in parallel with the development of a hardware device supporting the new architecture. This allows software development to begin before the hardware device supporting the new architecture is available, since the software can be developed and tested on the simulator.

Specific embodiments will now be described with reference to the drawings.

FIG. 1 schematically illustrates a data processing device (100) in which an example of the present technology may be implemented. As depicted in the drawing, the data processing device (100) includes instruction fetch circuitry (105) for fetching instructions from memory (optionally via one or more caches). The fetch circuitry (105) fetches instructions from a memory location identified by an instruction fetch address (e.g., these may be memory addresses defining locations within memory where instructions are stored) or from one or more intervening caches (not shown). In the example of FIG. 1, the instruction fetch address of the next instruction to be fetched by the instruction fetch circuitry (105) is stored in a program counter (PC) register (110), which is one of a set of registers (115) provided in this example. The PC register (110) identifies the next instruction to be fetched, and is thus incremented each time an instruction is fetched (so that the instruction points to the next instruction in program order). The register file (115) also includes another register, which in this example includes a time domain identifier register (130) that stores a time domain identifier (TRegionID). This will be described in more detail below.

The instruction fetch circuit (105) decodes the instruction and provides the instruction to the instruction decode circuit (120), which issues a control signal to the processing circuit (125) to control the processing circuit (125) to execute the decoded instruction. The processing circuit (125) executes the decoded instruction by referring to data stored in the register (115) (for example, the processing circuit can read an operand for a data processing operation from the register and store a result of the data processing operation in the register).

The processing circuitry (125) may also, in response to some instructions, issue a memory access request to access data or instructions stored in memory. For example, the processing circuitry (125) may issue a memory access request to a memory controller (not shown) to load data from memory to a register or to store data from a register to memory. The processing circuitry (125) may also, in response to a control flow instruction, such as a branch instruction, update a value stored in the PC register (110) to change the flow of instructions to be fetched by the instruction fetch circuitry (105).

In this example, the data processing device also includes memory security circuitry (135), which will be described in more detail below.

In many modern hardware and software architectures, read and write permissions to load or store data to/from specific regions of memory, and execution permissions to fetch instructions from specific regions of memory, are controlled by permissions described in page tables (e.g., multi-level page tables) programmed by the operating system and stored in memory. For example, a memory controller or memory management unit (which controls access to memory in response to memory access requests, including requests to load/store data and requests to fetch instructions) may include page table walk circuitry to access a page table and identify permissions for a specific access request. In particular, the page table is queried based on the target memory address of the access request (e.g., the address of the data or instruction to be accessed) to identify the associated permissions. Thus, these access permissions are defined based on the target of the access request, not on the instruction with which the access request is issued.

Within a process (or application), all code in that application, in a typical data processing device, has equal privileges to read/write/execute any memory in the address space - for example, different instructions within a given process typically have the same privileges. As described above, some architectures additionally include a "privilege overlay" or "privilege key" mechanism that allows certain privileges to be dynamically revoked based on the programming of CPU registers that cause certain privileges to be revoked or modified - for example, page table entries may be annotated with such overlay bits/keys, and the programming of CPU registers may indicate that a given privilege should be revoked for any page associated with a particular key value (e.g., "revoke read access to privilege key 2"). This allows for modification of access privileges defined in the page table, but only provides a temporal view of the privileges. The inventors of the present technology have recognized that this can cause potential problems, for example, in cases where there is a loss of control flow integrity (e.g., control flow is allowed to branch to an unexpected region of code).

Figures 2 and 3 are helpful in explaining how this issue may arise. In particular, Figures 2a and 2b illustrate examples of permissions that may be defined for a particular address space (200). As illustrated, different portions of code (“Code 1,” “Code 2,” “Code 3”) and different data (“Data A,” “Data B”) may be stored in different areas of the address space. Each of these different areas may have different read/write access permissions, which may further vary depending on the code being executed at any particular point in time. For example, as illustrated in Figure 2a, an instruction fetched from code area 1 (Code 1) may have read (R) and write (W) access (e.g., permissions to load and store data) to data area A (Data A), but may not have access to data stored in data area B (Data B). Meanwhile, code area 3 (code 3) can have read-only (RO) access to data area A and read and write access to data area B.

Similarly, as illustrated in FIG. 2b, each code region may have different execution access permissions (e.g., defining whether instructions from a given code portion are allowed to branch to instructions in different code portions). For example, in this example, instructions from code region 1 are allowed to branch to instructions in code region 2 and code region 4 (code region 4), whereas instructions from code region 3 are allowed to branch to instructions in code region 2, but not to instructions in code region 4.

It can be expected that the privilege overlay mechanism defined above could be used to exercise such privileges, for example by changing the contents of the overlay interpretation register when switching from one code region to another. However, this mechanism is less effective in cases where there is a loss of control flow integrity, as will be described below with reference to Figures 3a and 3b.

Figures 3a and 3b illustrate examples of how instructions from different code regions may be executed. Figure 3a illustrates an example of the expected instruction flow. As illustrated, prior to transitioning from code region 3 to code region 1, an instruction is executed to update a configuration register, which in combination with the overlay bit updates the access permissions defined by the page table. Following this update, an instruction (instruction C) from code region 1 is executed, causing the processing circuitry to issue an access request to read data from region B. However, the configuration register in combination with the overlay bit and the permissions in the page table indicate that read access to data region B is prohibited, and thus the access request is denied.

However, Fig. 3b illustrates how a loss of control flow integrity can lead to a loss of data integrity. For example, Fig. 3b illustrates a situation that can occur when an instruction from code region 3 unexpectedly branches to an instruction for code region 1. In this case, instruction A branches to instruction C without the configuration register being updated. That is, when instruction C is executed, the permissions defined by the configuration register in combination with the page table remain the same as the permissions for code region 3. Since the instruction from code region 3 is allowed for both read and write accesses to data region A, read accesses to data region B are also allowed. Therefore, a loss of control flow integrity can result in a loss of integrity or confidentiality of data stored in data region B. That is, the integrity/confidentiality of data stored in data region B depends on the control flow integrity being maintained.

The present technique provides a mechanism to address these issues. In particular, the technique defines a source region identifier (also referred to as a space region identifier, SRegionID) that depends on the instruction fetch address of the instruction requesting access to a particular memory location (whether a read, write or execute access). This allows access permission information to be defined based on the source of the access request, rather than just on the destination of the access request and/or the timing of the access request.

For example, FIG. 4 illustrates how a space region identifier (SRegionID) may be determined based on an instruction fetch address (which may be obtained from the PC register). The space region identifier may be determined by the memory security circuitry (135) in response to a memory access request issued by the processing circuitry.

In FIG. 4, a 64-bit instruction fetch address is shown, but it will be appreciated that this is merely an example - the instruction fetch address may vary in size depending on the implementation, but the example shown in FIG. 4 may be better suited to architectures utilizing larger address widths, such as greater than 64 bits. The space region identifier is determined based on a selected portion of the instruction fetch address, and some state (e.g., a register) (400) of the memory security circuitry (135) indicates which bits of the instruction fetch address are to be used - for example, the state (400) of the memory security circuitry may indicate the first and last bit positions of the portion to be used, or the first/last bit positions and the size of the portion. In an alternative example, the portion of the instruction fetch address to be used may be hardwired rather than programmable in a configuration register.

Figure 4 illustrates an example of a typical format for a 64-bit PC at "A". The figure also illustrates three examples (B, C, and D) of portions of an instruction fetch address that would be used as or to derive a space region identifier. In all four examples, the instruction fetch address includes a number of standard/tag bits, and useful VA (virtual address) bits that define the location in memory where the instruction is stored. Examples (B, C, and D) each include a portion (SRegionID) that would be used to derive the space region identifier. It should be noted that while these examples illustrate a virtual instruction fetch address that would be used to determine a space region identifier, a physical address could be used instead.

Example 1 (A) illustrates an example of a typical instruction fetch address. The standard/tag bits occupy bit positions (63:49) of the instruction fetch address, and the remaining bits (48:0) are all useful VA bits.

In the second example (B), the same bits (63:49) are used as the standard/tag bits, but bits (44:38) are used to derive the space area identifier. In this example, an additional constant is defined at bit positions (48:45) that can provide additional information - for example, the memory security circuitry could be arranged to determine whether the default space area identifier should be used when the constant has a particular value. This leaves bits (37:0) to define useful VA bits.

In the third example (C), the same bits (63:49) are reused as standard/tag bits, but bits (48:45) are used to derive the spatial domain identifier. This leaves bits (44:0) to define useful VA bits.

In Example 4 (D), bit positions (63:55) are used to derive the spatial domain identifier, and the number of standard/tag bits is reduced to occupy bit positions (54:49). This leaves bits (48:0) to define useful VA bits.

In all examples (B) through (D), selection of bits of the instruction fetch address is used to determine a spatial region identifier, such that the spatial region identifier depends on the source of the memory access request (e.g., the instruction fetch address of the instruction that issued the memory access request) rather than on the destination of the memory access request (e.g., the target address of the data or instruction to be accessed). The manner in which the selected bits are used to determine the spatial region identifier is not particularly limited. In some examples, the selected bits may be used directly as spatial region identifiers, while in other examples, the selected bits may be mapped to spatial region identifiers by the memory security circuitry in some other manner.

In some instances, the SRegionID portion and the useful VA bits may overlap by a number of bits (e.g., multiple bits are used both to determine the SRegionID and to determine the location in memory where the instruction is stored). As noted above, this may provide a mechanism for distinguishing between aliased virtual addresses in situations where software must keep all other VA bits constant between aliased virtual addresses. Furthermore, in some instances, the useful VA bits may include all of the SRegionID bits.

In some examples, the architecture may support multiple techniques for determining the SRegionID based on the instruction fetch address. For example, more than one of the approaches illustrated in FIG. 4 may be supported - for example, the PC bit register (400) may be configurable to program which bits are to be addressed by the SRegionID slice.

Additionally, additional mechanisms may be supported by the architecture in addition to supporting the use of slices of instruction fetch addresses to determine SRegionIDs. This may provide additional flexibility to chip designers using the architecture. For example, FIG. 5 illustrates another approach to determining a spatial region identifier. In particular, the memory security circuitry (135) illustrated in FIG. 5 includes a set of registers (500) that map different regions (e.g., virtual or physical) of the address space to region identifiers. In the particular example illustrated in FIG. 5, a pair of registers is provided for each of a plurality of spatial region identifiers, the pair including a base address register (505) that identifies a base address of the corresponding region within memory, and a size register (510) that identifies a size of the corresponding region within memory. In this example, the memory security circuitry is arranged to compare all or part of the instruction fetch address to the base address and size indicated by the registers to determine which region the instruction fetch address belongs to. The spatial region identifier is then an identifier corresponding to the corresponding region.

Note that the size of each region may be expressed as, for example, the number of bytes of memory in that region, the number of pages in the memory region, the number of bits in the base address to mask out as part of region identification, or the end address of the region of memory.

FIG. 6 illustrates another additional mechanism that may be supported in the architecture. In this example, the memory security circuitry (135) includes table access circuitry (also referred to as SRegionID table access circuitry, spatial region identifier table access circuitry, or source region identifier table access circuitry) (600). The SRegionID table access circuitry responds to a memory access request to query a table in memory (605) based on the instruction fetch address of the instruction that caused the memory access request to be issued. The table (610) defines a mapping of spatial region identifiers to instruction fetch addresses.

When a table in memory is used to define the mapping of instruction fetch addresses to space region identifiers, as in the example illustrated in FIG. 6, the memory security circuitry may also include one or more caches for caching data from the table in memory.

Therefore, since the space region identifier varies depending on the source of the memory access, it may also be referred to as a source region identifier. Then, a set of memory access permissions (e.g., read/write permissions) may be defined that vary depending on the space region identifier (and optionally may also vary depending on the target address of the memory access). These permissions may be defined in addition to the permissions defined in the page table.

Also, while most of the above discussion focuses on permissions defined for memory accesses (e.g., loading and storing data or instructions from/to memory), execution permissions can also be defined based on their dependence on space-area identifiers - for example, the space-area identifier of a branch instruction could be used to determine whether the branch is permitted.

Access rights may also depend on a time region identifier (TRegionID) that may be stored in a time identifier register (130) as illustrated in FIG. 1. This register may be software accessible, in which case the time region identifier may be updated by instructions executed by the processing circuitry. In a specific example, a region identifier (RegionID) is defined, which is a concatenation of a space region identifier (SRegionID) and a time region identifier (TRegionID).

Figure 7 illustrates an example of a method for defining read, write, and execute permissions based on region identifiers. In this particular example, access permissions for a given memory access request or branch request are defined for each of a plurality of combinations of a current region identifier (e.g., a concatenation of a spatial region identifier of the requesting instruction and a current time region identifier) and a target region identifier (e.g., a concatenation of a spatial region identifier of the target address and a current time identifier). Therefore, the table illustrated in Figure 7 may be considered a two-dimensional (2D) table since it is queried by both the current region identifier and the target region identifier.

In the table, "RW" indicates that read and write accesses are allowed, "RO" indicates that read accesses are allowed but write accesses are not allowed, "X" indicates that branches are allowed, and "XL" indicates that function calls (branches where the return address is stored, e.g., in the link register) are allowed but other kinds of branches are not allowed. A dash "-" indicates that no access is allowed.

A table (which may be referred to as a permission table, for example) may be stored in memory. The table may be a single table, or it may be a multi-level table, for example. In some examples, branch and function call permissions ("X" and "XL") may be defined in separate tables or bitmaps, and the permission table defines only read and write permissions.

FIG. 8 illustrates an example of circuitry that may be used to identify and access one or more privilege tables, such as those illustrated in FIG. 7. In this example, the memory security circuitry (135) includes privilege table access circuitry (800) for accessing a privilege table (805) within the memory (605). The base address of the privilege table is defined in a set of registers (810). In this particular example, it is assumed that the data processing device can operate at any one of three privilege levels, and that a table is defined for each privilege level. Accordingly, registers (815) are provided to store the base address of each table in memory, and the privilege table access circuitry accesses the privilege table based on the base address stored in the registers. The memory security circuitry in this example also includes one or more privilege table caches (820) arranged to cache a subset of the contents of the privilege table. Entries in the privilege table cache may be tagged by a virtual machine identifier (VMID) and an address space identifier (ASID), so that the cache does not need to be flushed on each context switch. Alternatively, the cache can be tagged by some alternative context identifier.

In the example illustrated in FIG. 8, only some of the circuitry that may be present in the memory security circuitry (135) is illustrated. It should be appreciated that the memory security circuitry in this example may also include circuitry such as the SRegionID table access circuitry (600), the SRegionID register (500), or the PC bit register illustrated in other drawings. Additionally, while this example assumes that the data processing device can operate at a number of different privilege levels, this is not required.

FIG. 9 is a flow diagram illustrating an example of a method that may be performed by a data processing device in response to a memory access request being issued. Note that a similar method may also be performed in response to the execution of a branch instruction.

As illustrated in the drawing, the method includes a step (900) of reading a current time region identifier from a TRegionID register, and a step (905) of determining a current space region identifier (SRegionID) based on an instruction fetch address of an instruction whose execution has issued a memory access request. The method also includes a step (910) of determining a target space region identifier (i.e., a space region identifier corresponding to a target of the access request) based on a target address of the memory access request. After determining the current time region identifier and the current space identifier, the method includes a step (915) of determining a current region identifier (RegionID) based on the current space and time region identifiers (e.g., RegionID can be a concatenation of SRegionID and TRegionID as described above). The method also includes a step (920) of determining a target region identifier (RegionID) based on the target space region identifier and the current time region identifier. After determining the current and target area identifiers, the method includes a step (925) of querying a privilege table based on these two identifiers - for example, this may be a query in a table such as that illustrated in FIG. 7.

FIG. 10 is another flowchart illustrating an example of how the data processing unit may react to the execution of a branch instruction in this case. In particular, in some examples, the data processing unit may be arranged to set the time region identifier (SRegionID) to zero (or some other default value) if the execution of the branch instruction causes the space region identifier (SRegionID) to change (e.g., if the branch instruction is associated with one space region identifier and the target of the branch instruction is associated with a different space region identifier). This helps maintain control flow integrity.

In particular, the method illustrated in FIG. 10 includes a step (1000) of determining whether a branch instruction is executed. If it is determined that the branch instruction has been executed, the method includes a step (1005) of determining whether execution of the branch instruction caused a change in a spatial domain identifier. If it is determined that this is the case, the temporal domain identifier is set to 0 (1010).

FIG. 11 illustrates an example simulator implementation that may be used. While the embodiments described above implement the invention in terms of devices and methods for operating specific processing hardware supporting the technology of interest, it is also possible to provide an instruction execution environment implemented through the use of a computer program in accordance with the embodiments described herein. Such computer programs are typically referred to as simulators insofar as they provide a software-based implementation of the hardware architecture. Various simulator computer programs include emulators, virtual machines, models, and binary translators including dynamic binary translators. Typically, the simulator implementation may be executed on a host processor (1330), optionally executing a host operating system (1320) to support the simulator program (1310). In some arrangements, there may be multiple simulation layers between the hardware and the instruction execution environment provided, and/or there may be multiple separate instruction execution environments provided on the same host processor. Historically, a powerful processor has been required to provide a simulator implementation that runs at reasonable speed, but such an approach may be justified in certain circumstances, such as when there is a need to execute code native to another processor for compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment with additional features not supported by the host processor hardware, or may provide an instruction execution environment that is typically associated with a different hardware architecture. An overview of simulation is given in the literature [“Some Efficient Architecture Simulation Techniques”, Robert Bedichek, Winter 1990 USENIX Conference, Pages 53 - 63].

While the embodiments have been described above with reference to specific hardware configurations or features, in the simulated embodiments, equivalent functionality may be provided by suitable software configurations or features. For example, certain circuitry may be implemented as computer program logic in the simulated embodiments. In the example illustrated in FIG. 11 , instruction fetch program logic (1340) is provided, which provides the same functionality as the instruction fetch circuitry of the previous example. In addition, processing program logic (1350) is provided, which provides the same functionality as the processing circuitry described above, and memory security program logic (1360) is provided, which provides the functionality of the memory security circuitry of the above example. Similarly, memory hardware, such as registers or caches, may be implemented as software data structures in the simulated embodiments. In an arrangement where one or more of the hardware elements mentioned in the embodiments described above reside on host hardware (e.g., host processor (1330)), some simulated embodiments may utilize the host hardware, where appropriate.

The simulator program (1310) can be stored in a computer-readable storage medium (which can be a non-transitory medium) and provides a program interface (instruction execution environment) to the target code (1300) (which can include an application, an operating system, and a hypervisor), which is identical to the interface of the hardware architecture modeled by the simulator program (1310). Accordingly, program instructions of the target code (1300), including instructions that require memory access requests to be issued, branch instructions, function call instructions, and function return instructions described above, can be executed within the instruction execution environment using the simulator program (1310), so that a host computer (1330) that does not actually have the hardware features of the device (100) discussed above can emulate such features.

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

Additionally, the phrase "comprising at least one of" in this application is used to mean including any one of the following options or any combination of the following options. For example, "at least one of A; B, and C" is intended to mean A or B or C, or any combination of A, B, and C (e.g., A and B, or A and C, or B and C).

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

Claims (18)

As a device
An instruction fetch circuit responsive to an instruction fetch address for fetching an instruction associated with the instruction fetch address;
A processing circuitry that responds to the command to perform an operation that depends on the target memory address, if the command includes a request specifying a target memory address, and the request specifying the target memory address is permitted; and
A memory security circuit comprising:
Based on a predetermined slice of the above instruction fetch address, determine the current region identifier;
Based on the current realm identifier, identify authorization information for a request issued in response to a command associated with the current realm identifier;
Based on the above authority information, determine whether the request is prohibited;
A device configured to, in response to a determination that said request is prohibited, issue a response to said processing circuitry indicating that said request is prohibited. In the first paragraph,
The above memory security circuitry:
Based on page table access permission information derived from the page table entry associated with the target memory address, determine whether the request is prohibited;
A device configured to issue a response indicating that the request is prohibited in response to a determination that the request is prohibited based on at least one of the above permission information and the page table permission information. In paragraph 1 or 2,
A device wherein the memory security circuitry is configured to determine a source region identifier corresponding to a region of memory storing the instruction based on the predetermined slice of the instruction fetch address, and to determine the current region identifier based on dependence on the source region identifier. In the third paragraph,
A device wherein the processing circuitry responds to a return-space-identifier instruction that determines a current source region identifier and identifies a destination register to store the current source region identifier in the destination register. In clause 3 or 4,
Including a register for storing the current time identifier,
The memory security circuitry is configured to determine the current region identifier, which varies depending on the source region identifier and the current time identifier, wherein the current time identifier is looked up independently of the instruction fetch address;
A device wherein the processing circuitry is responsive to detecting a command having a given source region identifier that is different from the source region identifier associated with a previous command, to set the current time identifier to a predetermined value. In any one of claims 1 to 5,
A device comprising a configuration register for storing slice identification information representing the predetermined slice of the instruction fetch address. In any one of claims 1 to 6,
A device wherein the memory security circuitry is responsive to a determination that an additional slice of the instruction fetch address has a value other than a predetermined value to determine that the source region identifier is a default source region identifier. In any one of claims 1 to 7,
The above instruction fetch address contains a virtual address;
The above instruction fetch circuitry is configured to fetch the instruction depending on a given portion of the instruction fetch address, wherein the given portion of the instruction fetch address represents a location within memory where the instruction is stored;
A device wherein the given portion of the instruction fetch address and the predetermined slice of the instruction fetch address overlap by at least one bit. In any one of claims 1 to 8,
The above memory security circuitry:
Read access rights;
Records access rights;
Authority to perform branching; and
A device configured to determine whether the request is prohibited based on said permission information identifying at least one of the permissions for performing a branch without storing a return address. In any one of claims 1 to 9,
The above memory security circuitry is configured to determine a destination area identifier based on the target memory address;
The above memory security circuitry includes a table access circuitry that looks up a permission table in the memory based on the current area identifier and the destination area identifier, the permission table defining the permission information;
A device wherein the table access circuitry is configured to support at least one encoding of the authority table in which different authority information is defined for different combinations of different destination area identifiers and the current area identifier. In any one of claims 1 to 10,
The above memory security circuitry includes a table access circuitry for accessing a permission table defining the permission information within the memory;
A device, wherein the device includes a table identification register for storing address information indicating the location of the permission table within the memory. In Article 11,
The device is arranged to operate at one of a plurality of privilege levels;
The above device:
A plurality of registers (each configured to store address information indicating the location of a corresponding permission table in memory); and
A device comprising a register selection circuit for selecting one of the plurality of registers as the privilege table identification register based on a current privilege level. In any one of claims 1 to 12,
The above memory security circuitry includes a table access circuitry for accessing a permission table defining the permission information within the memory;
The device comprises a register storing a set of current permissions representing the permission information defined in the permission table for the current area identifier;
The device wherein the table access circuitry is responsive to a determination that the current domain identifier has changed to the new domain identifier to query the permissions table to identify an updated set of permissions to be stored in the register based on the new domain identifier. In any one of claims 1 to 13,
The above memory security circuitry includes a table access circuitry for accessing a permission table defining the permission information within the memory;
The device comprises a cache for storing a subset of the permissions defined in the permission table;
The device is configured to operate in one of a plurality of contexts, each of which is associated with a context identifier;
A device wherein the cache comprises a plurality of entries, each of which is associated with a respective context identifier. In any one of claims 1 to 14,
A device comprising a plurality of registers, each register storing, for each of a plurality of current zone identifiers, a set of permissions representing permissions information for that current zone identifier. As a method,
In response to the instruction fetch address, a step of fetching an instruction associated with the instruction fetch address; and
If the above command includes a request specifying a target memory address:
In response to the above command, if the request specifying the target memory address is allowed, performing an operation that depends on the target memory address;
A step of determining a current region identifier based on a predetermined slice of the above instruction fetch address;
A step of identifying authorization information for a request issued in response to a command associated with the current area identifier, based on the current area identifier;
A step of determining whether the request is prohibited based on the above authority information; and
A method comprising: in response to a determination that the request is prohibited, issuing a response indicating that the request is prohibited. As a computer program, when run on a computer, said computer:
Instruction fetch program logic responsive to an instruction fetch address to fetch an instruction associated with the instruction fetch address;
A processing program logic that responds to the command to perform an operation that depends on the target memory address, if the command includes a request specifying a target memory address, and the request specifying the target memory address is allowed; and
Provides memory security program logic, wherein when the command includes the request specifying the target memory address, the memory security program logic:
Based on a predetermined slice of the above instruction fetch address, determine the current region identifier;
Based on the current realm identifier, identify authorization information for a request issued in response to a command associated with the current realm identifier;
Based on the above authority information, determine whether the request is prohibited;
A computer program configured to, in response to a determination that said request is prohibited, issue a response to said processing program logic indicating that said request is prohibited. A computer-readable storage medium storing the computer program of Article 17.

Images