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

Abstract

An apparatus (100) comprising instruction fetch circuitry (105) responsive to an instruction fetch address to fetch an instruction associated with the instruction fetch address, processing circuitry (125) responsive to the instruction to perform, when the instruction comprises a request specifying a target memory address and the request specifying the target memory address is permitted, an operation dependent on the target memory address, and memory security circuitry (135) to, when the instruction comprises the request specifying the target memory address: determine, based on a predetermined slice of the instruction fetch address, a current region identifier; identify, based on the current region identifier, permissions information for requests issued in response to instructions associated with the current region identifier; determine, based on the permissions information, whether the request is prohibited; and issue, in response to determining that the request is prohibited, a response to the processing circuitry indicating that the request is prohibited.

Description

Region identifier based on instruction fetch address

This technology is related to the field of data processing.

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

In view of the first example of the present technology, a device is provided, which includes: an instruction fetch circuit system, which fetches an instruction associated with an instruction fetch address in response to an instruction fetch address; a processing circuit system, which responds to the instruction and performs an operation depending on the target memory address when the instruction includes a request to specify a target memory address and the request to specify the target memory address is allowed; and a memory security circuit system, which, when the instruction includes the request to specify the target memory address: determines a current region identifier based on a predetermined slice of the instruction fetch address; identifies permission information of a request issued in response to an instruction associated with the current region identifier based on the current region identifier; determines whether to prohibit the request based on the permission information; and In response to determining that the request is prohibited, issuing a response to the processing circuit system indicating that the request is prohibited.

In view of another example, a method is provided, comprising: Responsive to an instruction fetch address, fetching an instruction associated with the instruction fetch address; and When the instruction includes a request specifying a target memory address: Responsive to the instruction, when the request specifying the target memory address is permitted, performing an operation depending on the target memory address; and Determining a current region identifier based on a predetermined slice of the instruction fetch address; Based on the current region identifier, identifying permission information for the request issued in response to the instruction associated with the current region identifier; Determining whether to prohibit the request based on the permission information; and Responsive to determining that the request is prohibited, issuing a response indicating that the request is prohibited.

In view of another example, a computer program is provided that, when executed on a computer, causes the computer to provide: instruction fetch program logic that, in response to an instruction fetch address, fetches an instruction associated with the instruction fetch address; processing circuit logic that, in response to the instruction, executes a request indicating a target memory location when the instruction includes a request to specify a target memory address and the request to specify the target memory address is permitted; and memory security program logic that, when the instruction includes the request to specify the target memory address: determines a current region identifier based on a predetermined slice of the instruction fetch address; Based on the current zone identifier, identifying permission information for a request issued in response to a command associated with the current zone identifier; Determining whether to prohibit the request based on the permission information; and In response to determining that the request is prohibited, issuing a response to the processing program logic indicating that the request is prohibited.

In view of another example, a computer-readable storage medium is provided to store the above-mentioned computer program. The computer-readable storage medium can be a temporary storage medium or a non-temporary storage medium.

Before discussing example implementations with reference to the accompanying drawings, the following description of example implementations and associated advantages is provided.

According to one example configuration, a device is provided that includes an instruction fetch circuit system that, in response to an instruction fetch address, fetches an instruction associated with the instruction fetch address. For example, the instruction fetch circuit system may fetch the instruction from a memory location indicated by the instruction fetch address (e.g., which may be a virtual address or a physical address). In a specific example, the instruction fetch address may be a program counter (PC) address associated with the instruction.

The apparatus also includes a processing circuit system that responds to the instruction and performs an operation depending on the target memory address when the instruction includes a request to specify a target memory address and the request to specify the target memory address is allowed. For example, a load or store instruction that specifies a target memory request may include a request to read or write a target memory location associated with the target memory address, and a branch instruction that specifies a target memory address (which may be a function call or function return instruction in some examples) may include a request to execute a branch to an instruction stored at the target memory location. However, it should be understood that other types of instructions (instructions other than load, store, and branch instructions) may also include such requests.

It may be useful to provide a mechanism to protect data and instructions stored in memory from read and write accesses issued by code areas within a program that is not allowed to access such data/instructions, and to prevent execution from branching to certain code areas. One way to do this may be to define permissions that depend on the target memory address - such permissions may be defined in a table such as a page table. However, such permissions do not take into account the source of the request - the permissions do not define which programs or which parts of programs are allowed to access/branch to which locations in memory. Therefore, unless the permissions in the page table are updated, all instructions have the same access permissions to a given memory page. Updating such permissions can incur significant delays because access to memory is required, and therefore such updates can only be performed between programs, in which case, within any one program (or application), all code in that application generally has equal privileges to read/write/execute data/instructions from any given memory location.

Another approach may be to additionally include a "permission overlay" or "permission key" mechanism that can dynamically revoke certain permissions based on programming of CPU registers to revoke or modify certain permissions. For example, if the permissions are defined in a page table (for example), there may be a number of "overlay index" bits in the page table entry. Each page of memory is thus annotated with a "key", and there is a programmable "overlay interpretation" register that can reduce permissions. For example, the overlay interpretation register may indicate a change such as "remove write access from the page with index 2" or "switch index 3 from writable to executable."

However, even this approach only provides a temporal view of permissions: none of the approaches defined above consider the source of the access request (e.g., the instruction containing the request), because permissions are defined solely from "what was last written to the configuration registers?" rather than "what code is being executed now?" Thus, because permissions are derived from the current values of registers and what is currently stored in page table entries, a control flow integrity compromise can (for example) result in a control flow integrity compromise of other parts of memory (e.g., due to a branch being taken to an unexpected location without the overlay interpret register or page table entry being updated when the expected path of program flow to that location should have involved an update to that location).

To address this problem, the present technology provides a mechanism by which permissions are defined in code-space (e.g., depending on the source of the memory access request) rather than just in code-time (e.g., depending on when the request was issued).

Specifically, an apparatus of the present technology includes a memory security circuit system to determine a current region identifier (also referred to as a "RegionID") based on a predetermined slice of the instruction fetch address when the instruction includes a request that specifies a target memory address. Thus, the RegionID depends on the source of the request (e.g., the instruction) rather than just the target of the request (e.g., the target memory address - although it should be understood that the permissions of a particular RegionID may also depend on the target of the memory access). The memory security circuit system is configured to identify permission information of a request issued in response to an instruction associated with the current region identifier based on the current region identifier, and determine whether to prohibit the request based on the permission information. The memory security circuitry is also configured to, in response to determining that the request is prohibited, issue a response to the processing circuitry indicating that the request is prohibited.

The RegionID is determined based on the instruction fetch address of the instruction requesting access/branch to the memory location identified by the target memory address (and optionally also depending on other factors). Therefore, because the permission information is based on the RegionID lookup, the memory security circuit system determines whether to prohibit the request based on the source of the request. This allows the memory security circuit system to execute fine-grained permissions that depend on specific locations within the program/application represented by the issued request, and maintain the integrity of the code region even if there is a loss of control flow integrity. In addition, slicing based on the instruction fetch address to determine the RegionID provides a simple, low-cost mechanism for determining the RegionID, which avoids the need to, for example, implement an expensive/high latency table lookup based on the instruction fetch address. It should be noted that if the permission information indicates that the request is allowed, the access request may still ultimately be denied, for example if it fails any other checks performed by the device.

The technology also provides a mechanism to define different permissions for different instructions, which may, for example, be different parts of a single program or application (e.g., because permissions depend on the source of the request, rather than just the target of the request, or based on the value in a configuration register that needs to be updated to update the permission set). Therefore, the technology can be useful, for example, in applications and in operating system (OS) kernels to harden core security components of software. In the OS kernel, this mechanism can, for example, be used to harden core memory management code and structures to prevent accidental or malicious tampering by other core components. It can also be used to sandbox core drivers without the performance overhead of delegating such components to discrete processes. Apply the same benefits within the application: for example, by 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 sandbox environments or just-in-time (JIT) environments for handling untrusted input.

In some examples, the memory security circuit system is configured to determine whether to prohibit the request based on the page table access permission information derived from a page table entry associated with the target memory address. In these examples, the memory security circuit system is configured to issue the response indicating that the request is prohibited in response to determining that the request is prohibited based on at least one of the permission information and the page table permission information.

While defining permissions based on the source of the request is advantageous for the reasons set forth above, the present technique may be particularly effective if, in addition to providing page table access permissions defined in the page table, such permissions are provided as a function of the target memory address specified by the request. In such instances, if the permissions defined in relation to the RegionID differ from those defined in the page table entry based on the target memory address, the memory security circuitry is configured to treat the more restrictive permissions as correct (e.g., if one of the one or both sets of permissions indicates that the request is forbidden, by issuing a response that the request is forbidden).

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

As explained above, the current region identifier depends on the instruction fetch address. In this example, this dependency is represented by a source region identifier (also called a space region identifier (SRegionID)), which corresponds to the memory region where the instructions are stored (and therefore corresponds to the address space region containing the instruction fetch address).

In some examples, the processing circuitry determines a current source region identifier in response to a return space identifier instruction identifying a destination register and stores the current source region identifier in the destination register.

This provides, for example, a mechanism by which a common library can identify which code region to call (branch to). It should be noted that the return space identifier instruction may be a dedicated instruction, or it may be 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 that reads that field of the system register.

In some examples, the apparatus includes a register to store a current time identifier, wherein the memory security circuitry is configured to determine the current region identifier as a function of the source region identifier and the current time identifier, the current time identifier being looked up independently of the instruction fetch address. In these examples, the processing circuitry sets the current time identifier to a predetermined value in response to detecting an instruction having a given source region identifier that is different from a source region identifier associated with a previous instruction.

In addition to a spatial component (e.g., a source region identifier), the current region identifier in this example also has a temporal component (e.g., based on a current temporal region identifier TRegionID), and this identifier is forced to a predetermined value (e.g., which may be zero) in response to changes in the source region identifier. This approach provides additional security against control flow integrity compromise because branching to a different code region forces the temporal region identifier to a predetermined value that may, for example, be associated with a set of predetermined permissions.

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

The use of bits of the instruction fetch address for a predetermined slice may be hard-wired in some examples (e.g., not configurable by software). However, in this example, the predetermined slice is identified by slice identification information stored in a configuration register. This configuration register may be made accessible to software, allowing the slice identification information to be configurable by software.

The manner 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 and least significant bit positions) of the instruction fetch address to be used for 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 one of the first or last bit positions of the slice and the number of bits in the slice (e.g., in the example of using bits 44:38, one of bit position 44 or bit position 38 may be identified, and the number of bits in the slice may be indicated as 7).

In some examples, the memory security circuitry determines that the source region identifier is a default source region identifier in response to determining that a further slice of the instruction fetch address has a value different than a predetermined value.

It can be used to identify a further slice of the instruction fetch address, and use this slice to provide additional information about the source area identifier. For example, if this further slice holds a specific value (or a value other than some predetermined value), it can be determined that the default source area identifier is to be used. This provides additional flexibility in which areas of memory are associated with which source area identifiers. For example, this method can be used to require that area identification only occur for specific larger areas of the address space, so that (for example) an application can use "surrounding" address space operations that it slices out several areas of (e.g., with a default source area identifier of zero). This allows a small set of address space areas to be selected for sandboxing within a program/application, while the majority of the address space is used for any less trusted components in the application. Using a further slice as a mask to provide this surrounding address space has only a small hardware cost, since it is a simple mask that can be applied at 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 the source region identifier is determined using the predetermined slice of the instruction is not particularly limited. However, in a specific example, the predetermined slice can be used directly as the source region identifier. This provides a method that requires less complex circuit systems than alternative methods such as (for example) using the predetermined slice to indirectly determine the identifier (for example, by applying some functions to the predetermined slice, or using the predetermined slice to look up a storage structure to determine the source region identifier). However, the disadvantage of using the predetermined slice directly as the source region identifier may be that there is less flexibility in which regions or memories are assigned to which source region identifiers.

In some examples, the instruction fetch address comprises a virtual address, and the instruction fetch circuit system is configured to fetch the 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, 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, programs can reference locations in memory using virtual addresses, which can be translated into physical addresses that identify locations in memory. This can allow, for example, defining multiple different virtual address spaces, each with its own mapping to the physical address space. For example, different programs can have different virtual address spaces.

This can result in a situation where multiple different virtual addresses map to the same physical address, for example, if multiple different programs with different virtual address spaces wish to access a given instruction in a common code library, each may reference the instruction using a different virtual address. This is called aliasing. However, aliasing can affect the performance of the device - for example, entries in a translation lookaside buffer or instruction cache may be indexed and/or tagged by virtual address, meaning that each aliased virtual address will map 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.

One solution to the problem, such as by not allowing aliases - for example, by requiring that a given portion of an instruction fetch address be the same for each virtual address that maps to a particular physical address. However, it may be useful to retain some information in a given portion that indicates which program/segment of the code a particular instance of an aliased virtual address originates from. To address this, the inventors of the present technology propose allowing one or more bits of a given portion (used to identify the corresponding physical address) to overlap with one or more bits of a predetermined slice (used to determine the source region identifier). For example, these bits may be different for an aliased virtual address while other bits in the given portion remain the same. This allows structures such as caches to be searched based on a given portion of the address excluding overlapping bits so that only one copy of the instruction from a given physical address is stored in the cache, while still retaining information to distinguish alias addresses.

In some examples, the memory security circuitry is configured to determine whether to prohibit the request based on the permission information identifying at least one of the following: ●      read access permission; ●      write access permission; ●      permission to execute a branch; and ●      permission to execute a branch without causing a return address to be stored.

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

In some embodiments, the memory security circuitry is configured to determine a destination region identifier based on the target memory address. In these embodiments, the memory security circuitry includes table access circuitry to look up a permission table in memory based on the current region identifier and the destination region identifier, the permission table defining the permission information. Further, in these embodiments, the table access circuitry is configured to support at least one encoding of the permission table, wherein different permission information is defined for different combinations of the current region identifier and different destination region identifiers.

In this example, the permission table can be viewed as a two-dimensional table, where the table is looked up based on both the current region identifier (determined by the instruction fetch address) and the destination region identifier (determined by the target memory address). This allows permission information to be defined for multiple different combinations of the current region identifier and the target region identifier, so that it can be determined whether the currently executing portion of the code is allowed to access/branch to a specific memory location indicated by the requested target memory address. This allows access to a specific memory region to be given to a specific code region or access to a specific memory region to be denied to a specific code region.

In some examples, the memory security circuitry includes table access circuitry to access a permission table in memory that defines the permission information, and the device includes a table identification register to store address information indicating a location of the permission table in memory.

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

In some embodiments, the device is configured to operate in 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 permission table in memory. In these embodiments, the device also includes a register selection circuit system to select one of the plurality of registers as the permission table identification register based on a current privilege level.

In this example, a separate permission table may be defined for each privilege level. For example, there may be one register for the kernel and one register 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 circuit system includes a table access circuit system to access a permission table in memory that defines the permission information, the device includes a register to store a set of current permissions indicating the permission information in the permission table defined in the current zone identifier, and the table access circuit system searches the permission table for an identifier based on the new zone identifier and a set of updated permissions to be stored in the register in response to determining that the current zone identifier has changed to a new zone identifier.

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

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

In some examples, the memory security circuitry includes table access circuitry to access a permission table in memory defining the permission information, and the device includes a cache to store a subset of the permissions defined in the permission table. In these examples, the device is configured to operate in one of a plurality of contexts each associated with a context identifier, and the cache includes a plurality of entries each associated with a corresponding context identifier.

Thus, in this example, some permission information may be cached so that further access to the permission information may be performed with reduced latency, thereby improving performance. Additionally, associating each entry with a context identifier (e.g., this may be a combination of a virtual machine identifier (VMID) and an address space identifier (ASID)) avoids the need to flush cache memory when context switching, thereby improving performance because cached data may still be available for access in the future.

In some examples, the apparatus includes a plurality of registers including a register for each of a plurality of current locale identifiers to store a set of permissions indicating permission information of the current locale identifier.

Such registers may be provided in place of or in addition to a permission table in memory. Although the addition of additional registers may increase the circuit area occupied by the device, such registers may be advantageous because they may reduce latency accesses (thereby allowing improved performance of the device).

As with the above examples, the format of the registers is not particularly limited, but each of the registers may, for example, include a field for each of a plurality of target region identifiers, each field storing corresponding access permission information.

The techniques discussed above may be implemented in a hardware device having circuit hardware that implements 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 provide an instruction execution environment for controlling a host data processing device to provide an execution environment for instructions from target code. In some specific examples, such instructions may include any of a return space identifier instruction, a time identifier update instruction, a branch and change time identifier instruction, and a branch and keep time identifier instruction.

The computer program may include instruction fetcher logic to fetch instructions from the object code, and processor logic to control the host data processing device to perform data processing in response to the instructions. Thus, the instruction fetcher logic emulates the functionality of the instruction fetch circuitry of the hardware device discussed above, and the processor logic emulates the processing circuitry.

Furthermore, in some examples, some or all of the registers described above may be emulated - specifically, the program may include registers maintaining program logic that maintains data structures (in the host device's memory or in the architecture registers) representing (emulating) the instruction set architecture emulated by the program. The emulated registers may include any of the plurality of registers described in some of the above examples.

Thus, such an emulator computer program can present to target code executed on the emulator computer program an instruction execution environment similar to the environment that would be provided by actual hardware devices capable of directly executing the target instruction set, even though there may not be any actual hardware providing such features on the host computer on which the emulator program is being executed. This can be useful for executing code written for an instruction set architecture on a host platform that does not actually support that architecture. Furthermore, an emulator can be useful during the development of software for a new version of an instruction set architecture, while the software development is performed in parallel with the development of hardware devices supporting the new architecture. This allows software to be developed and tested on the emulator, allowing software development to begin before hardware devices supporting the new architecture are available.

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 shown, the data processing device 100 includes an instruction fetch circuit system 105 to fetch instructions from a memory (optionally via one or more cache memories). The fetch circuit system 105 fetches instructions from a memory location identified by an instruction fetch address (e.g., such addresses may be memory addresses defining the location where the instruction is stored in the memory) or from one or more intermediate cache memories (not shown). In the example of FIG. 1 , the instruction fetch address of the next instruction to be fetched by the instruction fetch circuit system 105 is maintained 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 therefore incremented each time an instruction is fetched (so that it points to the next instruction in the program sequence). The register file 115 also includes other registers, including, in this example, a time region identifier register 130 that stores a time region identifier (TRegionID). This will be disclosed in more detail below.

Instruction fetch circuitry 105 provides instructions to instruction decode circuitry 120, which decodes the instructions and issues control signals to processing circuitry 125 to control processing circuitry 125 to execute the decoded instructions. Processing circuitry 125 executes the decoded instructions with reference to data stored in registers 115 (e.g., processing circuitry may read operands for data processing operations from registers and store results of data processing operations in registers).

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

The data processing device in this example also includes a memory security circuit system 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 a particular area of memory and execute permissions to fetch instructions from a particular area of memory are controlled by permissions described in page tables (e.g., multi-level page tables) that are programmed by the operating system and stored in the 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 traversal circuitry to access the page table and identify permissions for a particular access request. Specifically, the page table is looked up 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 relevant permissions. Therefore, such access rights are defined based on the target of the access request rather than on the instructions represented by the issued access request.

In a general data processing device, within any one program (or application), all code in that application has equal privileges to read/write/execute any memory in its address space, e.g., different instructions within a given program generally have the same permissions. As explained above, some architectures additionally include a "permission overlay" or "permission key" mechanism that can dynamically revoke certain permissions based on programming of CPU registers that allow certain permissions to be revoked or modified, e.g., page table entries can be annotated with such overlay bits/keys, and the programming of the CPU registers can indicate (for example) that a given permission should be revoked for any page associated with a certain key value (e.g., "revoke read access for permission key 2"). This allows modification of access permissions defined in the page tables, but only provides a temporal view of the permissions. The inventors of the present technology have recognized that, for example, if there is a loss of control flow integrity (e.g., if control flow is allowed to branch to unexpected code regions), this can lead to potential problems.

Figures 2-3 help illustrate how this problem can occur. Specifically, Figures 2A and 2B illustrate examples of permissions that one might wish to define for a particular address space 200. As shown, different portions of code ("Code 1", "Code 2", and "Code 3") and different data ("Data A" and "Data B") may be stored in different regions of the address space. Each of these different regions may have different read/write access permissions, which may depend, among other things, on what code is being executed at any particular point in time. For example, as shown in FIG. 2A , instructions fetched from code region 1 (code 1) may have read (R) and write (W) access to data (data A) in data region A (data A) (e.g., the right to load data from it and store data to it), but may not have access to data (data B) stored in data region B. Meanwhile, code region 3 (code 3) may have read-only (RO) access to data region A, and read and write access to data region B.

Similarly, as shown 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 a different code portion). 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 4), while instructions from code region 3 are allowed to branch to instructions in code region 2 but not to instructions in code region 4.

It may be expected that the permission overlay mechanism defined above can be used when enforcing such permissions, for example, by changing the contents of the overlay interpretation register when switching from one code region. However, as will be explained below with reference to Figures 3A and 3B, this mechanism is less effective in situations where there is a loss of control flow integrity.

3A and 3B show examples of how instructions from different code regions may be executed. FIG. 3A shows an example of an expected instruction flow. As shown, before switching from code region 3 to code region 1, an instruction is executed to update the configuration register so that the access permissions defined by the page table combined with the overlap bit are updated. After this update, an instruction from code region 1 (instruction C) is executed, causing the processing circuit system to issue an access request to read the data in region B. However, the permissions in the configuration register and page table combined with the overlap bit indicate that read access to data region B is prohibited, and therefore 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 shows what might happen if an instruction from code area 3 unexpectedly branches to an instruction from code area 1. In this case, instruction A is branched to instruction C without the configuration register being updated. This means that when instruction C is executed, the permissions defined by the configuration register in combination with the page table remain the same as for code area 3. Instructions from code area 3 are allowed read and write access to data area A, and therefore read access to data area B. Therefore, due to a loss of control flow integrity, the integrity or confidentiality of the data stored in data area B may be compromised. In other words, the integrity/confidentiality of the data stored in data area B depends on maintaining the integrity of the control process.

The present technology provides a mechanism to solve this problem. Specifically, the present technology defines a source region identifier (also called a spatial region identifier, SRegionID) that depends on the instruction fetch address of an instruction requesting access to a specific memory location (whether read, write, or execute access). This allows access permission information to depend on the source of the access request, rather than just the destination of the access request and/or the timing definition of the access request.

For example, Figure 4 illustrates how a spatial region identifier (SRegionID) may be determined based on an instruction fetch address (which may be obtained from the PC register). The spatial 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, although it should be understood that this is merely an example—the instruction fetch address may have an implementation-dependent size, although the example illustrated in FIG. 4 may be more applicable to architectures employing larger address widths, such as 64 bits or larger. The spatial region identifier is determined based on a selected portion of the instruction fetch address, wherein some state (e.g., register) 400 in the memory security circuit system 135 indicates which bits of the instruction fetch address are to be used, for example, the state 400 in the memory security circuit system may indicate the first and last bit positions of the portion to be used, or the first/last bit positions and size of the portion. In an alternative example, the portion of the instruction fetch address to be used may be hard-wired rather than programmable in a configuration register.

FIG. 4 shows an example of the general format of a 64-bit PC in “A”. The figure also shows three examples (B, C, D) of the portion of the instruction fetch address to be used as or derived as a space region identifier. In all four examples, the instruction fetch address includes a number of regular/tag bits, and useful VA (virtual address) bits that define the location where the instruction is stored in memory. Examples B, C, and D each include a portion (SRegionID) used to derive a space region identifier. It should be noted that although the examples show the use of a virtual instruction fetch address to determine the space region identifier, a physical address may be used instead.

The first example (A) shows an example of a general instruction fetch address. The regular/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 regular/label bits, but bits 44:38 are used to derive the space region identifier. In this example, an additional constant that can provide additional information is defined in bit positions 48:45, for example, the memory security circuitry can be configured to determine that a default space region identifier should be used when the constant has certain values. This leaves bits 37:0 to define useful VA bits.

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

In the fourth example (D), the spatial region identifier is derived using bit positions 63:55, where the number of regular/tag bits is reduced to occupy bit positions 54:49. This leaves bits 48:0 to define the useful VA bits.

In all of Examples B to D, the bits of the instruction fetch address are selected to determine the space region identifier so that the space region identifier depends on the source of the memory access request (e.g., on the instruction fetch address of the instruction that caused the memory access request to be issued), 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 space region identifier is not particularly limited. In some examples, the selected bits can be used directly as the space region identifier, while in other examples, the selected bits can be mapped into the space region identifier by the memory security circuit system in some other manner.

In some examples, the SRegionID portion and the useful VA bits may overlap by a number of bits (e.g., a number of bits used to determine the SRegionID and used to determine where the instruction is stored in memory). As explained above, this may provide a mechanism to distinguish between alias virtual addresses while forcing the software to keep all other VA bits constant between alias virtual addresses. Additionally, the useful VA bits may include all of the SRegionID bits in some examples.

In some examples, the architecture may support multiple techniques for determining SRegionID based on the instruction fetch address. For example, two or more of the methods shown in FIG. 4 may be supported, for example, the PC bit register 400 may be configurable so that the bits to be processed as SRegionID slices are programmable.

In addition, in addition to supporting the use of instruction fetch address slice determination SRegionID, the architecture can also support additional mechanisms. This can provide additional flexibility to chip designers using the architecture. For example, Figure 5 shows another method for determining a spatial region identifier. Specifically, the memory security circuit system 135 shown in Figure 5 includes a register group 500 that maps different regions of the address space (e.g., virtual or physical) to region identifiers. In the specific example shown in Figure 5, a pair of registers is provided for each of a plurality of spatial region identifiers, the pair of registers including a base address register 505 that identifies the base address of the corresponding region in the memory and a size register 510 that identifies the size of the corresponding region in the memory. In this example, the memory security circuitry is configured to compare all or part of the instruction fetch address with the base address and size indicated by the register to determine which of the regions the instruction fetch address falls within. The spatial region identifier is then associated with the identification of the region.

It should be noted that the size of each region may be indicated as, for example, the number of bytes of memory corresponding to the region, the number of pages in the memory region, the number of bits of the base address masked out as part of the region identification or as the end address of the region in memory.

6 shows 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 by looking up a table in memory 605 based on the instruction fetch address of the instruction that caused the memory access request to be issued. 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 spatial region identifiers, such as the example shown in FIG. 6 , the memory security circuit system may also include one or more cache memories to cache data from the table in memory.

Thus, the spatial region identifier depends on the source of the memory access and may therefore also be referred to as a source region identifier. A set of memory access permissions (e.g., read/write permissions) may then be defined that depend on the spatial region identifier (and optionally also on the target address of the memory access). Such permissions may be defined in addition to those defined in the page table.

Additionally, while much of the discussion above has focused on permissions defined for memory access (e.g., loading and storing data or instructions from/to memory), it should be understood that execution permissions may also depend on spatial region identifier definitions - for example, a spatial region identifier for a branch instruction may be used to determine whether the branch is allowed.

The access rights may further depend on a temporal region identifier (TRegionID) which may be stored in a temporal identifier register 130 shown in FIG1 . This register may be software accessible, in which case the temporal region identifier may be updated by instructions executed by the processing circuit system. In a specific example, a region identifier (RegionID) is defined which is the concatenation of a spatial region identifier (SRegionID) and a temporal region identifier (TRegionID).

FIG7 shows an example of how read, write, and execute permissions can be defined based on region identifiers. In this particular example, the access permissions for a given memory access request or branch request are defined for each of several combinations of a current region identifier (e.g., the concatenation of the spatial region identifier of the request instruction and the current temporal region identifier) and a target region identifier (e.g., the concatenation of the spatial region identifier of the target address and the current temporal identifier). Thus, the table shown in FIG7 can be viewed as a two-dimensional (2D) table because it is searched by both the current region identifier and the target region identifier.

In the table, "RW" indicates that read and write access is allowed, "RO" indicates that read access is allowed but write access is not allowed, "X" indicates that branches are allowed, and "XL" indicates function calls (branches that save the return address to, for example, a link register) but not other types of branches. A dash "-" indicates that access is not allowed.

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

FIG8 shows an example of a circuit system that can be used to identify and access one or more permission tables (such as the table shown in FIG7 ). In this example, the memory security circuit system 135 includes a permission table access circuit system 800 to access a permission table 805 in the memory 605. The base address in the permission table is defined in a set of registers 810. In this particular example, it is assumed that the data processing device can operate in any one of three privilege levels, and a table is defined for each privilege level. Therefore, a register 815 is provided to store the base address of each table in the memory, and the permission table access circuit system accesses the permission table based on the base address stored in the corresponding register. The memory security circuit system in this example also includes one or more permission table caches 820 configured to cache a subset of the contents of the permission table. The entries in the permission table cache can be marked by a virtual machine identifier (VMID) and an address space identifier (ASID) so that the cache does not need to be cleared every time there is a context switch. Alternatively, the cache can be marked by some alternative context identifier.

In the example shown in FIG8 , only some of the circuitry that may be present in the memory security circuitry 135 is shown. It should be understood 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 shown in other figures. Further, although this example assumes that the data processing device is capable of operating at multiple different privilege levels, this is not necessary.

9 is a flow chart illustrating an example of a method that may be performed by a data processing device in response to an issued memory access request. It should be noted that a similar method may also be performed in response to the execution of a branch instruction.

As shown, the method includes step 900 of reading the current temporal region identifier from the TRegionID register, and step 905 of determining the current spatial region identifier (SRegionID) based on the instruction fetch address of the instruction whose execution caused the memory access request to be issued. The method also includes step 910 of determining the target spatial region identifier (i.e., the spatial region identifier corresponding to the target of the access request) based on the target address of the memory access request. Having determined the current temporal region identifier and the current spatial identifier, the method includes a step 915 of determining a current region identifier (RegionID) based on the current spatial and temporal region identifiers (e.g., as explained above, RegionID may be a concatenation of SRegionID and TRegionID). Further, the method includes a step 920 of determining a target region identifier (RegionID) based on the target spatial region identifier and the current temporal region identifier. Having determined the current and target region identifiers, the method includes a step 925 of looking up an authorization table based on these two identifiers—for example, this may be a lookup in a table such as that shown in FIG. 7 .

FIG. 10 is another flow chart, in this case illustrating an example of how a data processing device may respond to the execution of a branch instruction. Specifically, in some examples, the data processing device may be configured to set the temporal region identifier to zero (or some other default value) when the execution of a branch instruction causes the spatial region identifier (SRegionID) to change (e.g., when the branch instruction is associated with one spatial region identifier and the target of the branch instruction is associated with a different spatial region identifier). This helps maintain control flow integrity.

Specifically, the method shown in Figure 10 includes a step 1000 of determining whether a branch instruction has been executed. When it is determined that the branch instruction has been executed, the method includes a step 1005 of determining whether the execution of the branch instruction has caused the spatial region identifier to change. When it is determined that this is the case, the temporal region identifier is set 1010 to zero.

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

Where an embodiment has been previously described with reference to a particular hardware architecture or feature, in a simulated embodiment, equivalent functionality may be provided by an appropriate software architecture or feature. For example, a particular circuit system may be implemented as computer program logic in a simulated embodiment. In the example shown in FIG. 11 , instruction fetch program logic 1340 is provided that provides the same functionality as the instruction fetch circuit system of the previous example. Additionally, processing program logic 1350 is provided that provides the same functionality as the processing circuit system described above, and memory security program logic 1360 is provided that provides the functionality of the memory security circuit system in the above-described example. Similarly, memory hardware (such as registers or caches) may be implemented as software data structures in emulated embodiments. In configurations where one or more of the hardware elements mentioned in the previously described embodiments reside on host hardware (e.g., host processor 1330), some emulated embodiments may utilize host hardware when appropriate.

The emulator program 1310 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a programming interface (instruction execution environment) to the object code 1300 (which may include an application, an operating system, and a hypervisor), the programming interface being the same as the interface of the hardware architecture modeled by the emulator program 1310. Therefore, program instructions of the object code 1300 including instructions that require issuing memory access requests, branch instructions, function call instructions, and function return instructions as described above may be executed using the emulator program 1310 within the instruction execution environment, so that a host computer 1330 that does not actually have the hardware features of the device 100 discussed above may emulate such features.

In this application, the phrase "configured to..." is used to mean that a component of a device has a configuration that enables it to perform the defined operation. In this context, "configuration" means the arrangement or manner in which hardware or software is interconnected. For example, the 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 mean that the device component needs to be changed in any way to provide the defined operation.

Furthermore, the term "comprising at least one of..." is used in this application to mean including any one of the following options or any combination of the following options. For example, "at least one of the following: 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 illustrative embodiments of the present invention have been described in detail with reference to the accompanying drawings, it should be understood that the present invention is not limited to those precise embodiments and that a person skilled in the art may implement various changes and modifications therein without departing from the scope of the present invention as defined by the appended claims.

100: data processing device; device 105: instruction fetch circuitry; fetch circuitry 110: program counter (PC) register 115: register; register file 120: instruction decoding circuitry 125: processing circuitry 130: time region identifier register; time identifier register 135: memory security circuitry 200: address space 400: status; PC bit register 500: group; SRegionID register 505: base address register 510: size register 600: table access circuitry; SRegionID table access circuitry 605: memory 610: table 800: permission table access circuitry 805: permission table 810: register 815: register 820: permission table cache 900: step 905: step 910: step 915: step 920: step 925: step 1000: step 1005: step 1010: setup 1300: target code 1310: simulator program 1320: host operating system 1330: host processor; host computer 1340: instruction fetch program logic 1350: processor logic 1360: Memory Security Program Logic A: Instance B: Instance C: Instance D: Instance

Further aspects, features, and advantages of the present technology will become apparent from the following example descriptions read in conjunction with the accompanying drawings, in which: [FIG. 1] schematically illustrates a data processing device; [FIG. 2A] and [FIG. 2B] illustrate examples of permissions defined for a particular address space; [FIG. 3A] and [FIG. 3B] show examples of how instructions in different code regions may be executed; [FIG. 4] to [FIG. 6] show various examples of determining a space region identifier (SRegionID) based on an instruction fetch address; [FIG. 7] shows an example of how read, write, and execute permissions may be defined in a permission table; [FIG. 8] shows an example of a circuit system that may be used to identify and access one or more permission tables; [Figure 9] is a flow chart illustrating an example of a method that may be performed in response to an issued memory access request; [Figure 10] is a flow chart illustrating an example of how a data processing device may respond to the execution of some branch instructions; and [Figure 11] illustrates an emulator implementation that may be used.

135:Memory security circuit system

400: Status; PC bit register

A: Example

B: Example

C: Example

D: Example

Claims (18)

A device comprising: an instruction fetch circuit system that fetches an instruction associated with an instruction fetch address in response to an instruction fetch address; a processing circuit system that performs an operation depending on a target memory address in response to the instruction when the instruction includes a request to specify a target memory address and the request to specify the target memory address is permitted; and a memory security circuit system that, when the instruction includes the request to specify the target memory address: determines a current region identifier based on a predetermined slice of the instruction fetch address; identifies permission information of a request issued in response to an instruction associated with the current region identifier based on the current region identifier; determines whether to prohibit the request based on the permission information; and In response to determining that the request is prohibited, issuing a response to the processing circuit system indicating that the request is prohibited. The device of claim 1, wherein the memory security circuit system is configured to: determine whether to prohibit the request based on page table access permission information derived from a page table entry associated with the target memory address; and issue the response indicating that the request is prohibited in response to determining that the request is prohibited based on at least one of the permission information and the page table permission information. The device of claim 1 or claim 2, wherein the memory security circuit system is configured to determine a source region identifier corresponding to a memory region storing the instruction based on the predetermined slice of the instruction fetch address, and determine the current region identifier based on the source region identifier. The apparatus of claim 3, wherein the processing circuit system determines a current source region identifier in response to a return space identifier instruction identifying a destination register and stores the current source region identifier in the destination register. A device as claimed in claim 3 or claim 4, comprising: a register for storing a current time identifier, wherein the memory security circuit system is configured to determine the current region identifier based on the source region identifier and the current time identifier, the current time identifier being looked up independently of the instruction fetch address; and the processing circuit system sets the current time identifier to a predetermined value in response to detecting an instruction having a given source region identifier that is different from a source region identifier associated with a previous instruction. A device as claimed in any of the preceding claims, comprising: a configuration register for storing slice identification information indicating the predetermined slice of the instruction fetch address. A device as in any of the preceding claims, wherein the memory security circuit system determines that the source region identifier is a default source region identifier in response to determining that a further slice of the instruction fetch address has a value different from a predetermined value. A device as in any of the preceding claims, wherein: the instruction fetch address comprises a virtual address; the instruction fetch circuitry is configured to fetch the 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 the given portion of the instruction fetch address and the predetermined slice of the instruction fetch address overlap by at least one bit. A device as in any of the preceding claims, wherein the memory security circuit system is configured to determine whether to prohibit the request based on the permission information identifying at least one of the following: read access permission; write access permission; permission to execute a branch; and permission to execute a branch without causing a return address to be stored. A device as in any of the preceding claims, wherein: the memory security circuitry is configured to determine a destination region identifier based on the target memory address; the memory security circuitry includes table access circuitry to search a permission table in memory based on the current region identifier and the destination region identifier, the permission table defining the permission information; and the table access circuitry is configured to support at least one encoding of the permission table, wherein different permission information is defined for different combinations of the current region identifier and different destination region identifiers. A device as in any of the preceding claims, wherein: the memory security circuitry includes a table access circuitry to access a permission table in memory that defines the permission information; and the device includes a table identification register to store address information indicating a location of the permission table in memory. The device of claim 11, wherein: the device is configured to operate in one of a plurality of privilege levels; and the device comprises: a plurality of registers, each of which is configured to store address information indicating a location of a corresponding permission table in memory; and a register selection circuit system for selecting one of the plurality of registers as the permission table identification register based on a current privilege level. A device as in any of the preceding claims, wherein: the memory security circuitry includes table access circuitry to access a permission table in memory defining the permission information; and the device includes a register to store a set of current permissions indicating the permission information in the permission table defined in the current region identifier; and the table access circuitry searches the permission table based on the new region identifier to identify a set of updated permissions to be stored in the register in response to determining that the current region identifier has changed to a new region identifier. A device as in any of the preceding claims, wherein: the memory security circuitry includes table access circuitry to access a permission table in memory defining the permission information; the device includes a cache to store a subset of the permissions defined in the permission table; the device is configured to operate in one of a plurality of contexts each associated with a context identifier; and the cache includes a plurality of entries each associated with a corresponding context identifier. A device as in any of the preceding claims, comprising a plurality of registers, including a register for each of a plurality of current locale identifiers to store a set of permissions indicating permission information of the current locale identifier. A method comprising: responsive to an instruction fetch address, fetching an instruction associated with the instruction fetch address; and when the instruction includes a request specifying a target memory address: responsive to the instruction, when the request specifying the target memory address is permitted, performing an operation depending on the target memory address; determining a current region identifier based on a predetermined slice of the instruction fetch address; based on the current region identifier, identifying permission information for a request issued in response to the instruction associated with the current region identifier; determining whether the request is prohibited based on the permission information; and responsive to determining that the request is prohibited, issuing a response indicating that the request is prohibited. A computer program that, when executed on a computer, causes the computer to provide: instruction fetch program logic that, in response to an instruction fetch address, fetches an instruction associated with the instruction fetch address; processing program logic that, in response to the instruction, performs an operation dependent on the target memory address when the instruction includes a request to specify a target memory address and the request to specify the target memory address is permitted; and memory security program logic that, when the instruction includes the request to specify the target memory address: determines a current region identifier based on a predetermined slice of the instruction fetch address; identifies permission information for requests issued in response to instructions associated with the current region identifier based on the current region identifier; Determining whether the request is prohibited based on the permission information; and In response to determining that the request is prohibited, issuing a response to the processing program logic indicating that the request is prohibited. A computer-readable storage medium for storing a computer program as claimed in claim 17.

Images