A device authorization table that defines authorization information for the translated access request.

Abstract

Apparatus, methods and code for manufacturing an apparatus, the apparatus comprising an address translation circuit (116) for translating virtual addresses to physical addresses in response to advance address translation requests issued by the device (105) on behalf of the software context (125). The apparatus also comprises a translated access control circuit (117) for controlling access to the memory (110) in response to translated access requests issued by the device (105) on behalf of the software context (125) based on permission information defined in a device permission table (220), the corresponding access permissions providing information for checking whether translated access requests from multiple software contexts are prohibited.

Description

[Technical field]

[0001] The present technique relates to data processing systems.

[0002] Some data processing systems support ahead-of-time address translation, in which a requesting device issues a ahead-of-time address translation request that specifies a given virtual address (VA), and address translation circuitry translates the virtual address into a corresponding physical address (PA) that is returned to the requesting device. The requesting device can then issue a translated access request that specifies the physical address, which may be serviced more quickly than if a virtual address were specified, because the address does not need to be translated when issuing the translated access request, since it was already translated when the ahead-of-time address translation request was sent.

[0003] Looking at the first example of this technique, an address translation circuit configured to, in response to a prior address translation request issued by a requesting device on behalf of a given software context and specifying a given virtual address, translate the given virtual address to a given physical address, and to provide the given physical address to the requesting device to be associated with a subsequent translated access request issued by the requesting device; a translated access control circuit responsive to a translated access request issued by a requesting device on behalf of a given software context and specifying a target physical address; Based on the target physical address, look up corresponding permission information indicating a corresponding permission defined in a device permission table for a region of the physical address space that contains the target physical address, the corresponding permission providing information for checking whether the translated access requests from the multiple software contexts are prohibited; determining whether a given software context is prohibited from accessing a target memory location corresponding to the target physical address in response to the translated access request based on the corresponding permission information; and a translated access control circuit that triggers an error response when it is determined that a given software context is prohibited from accessing the target memory location in response to the translated access request.

[0004] Another example of this technique is in response to a pre-address translation request issued by a requesting device on behalf of a given software context and specifying a given virtual address, providing the given physical address to the requesting device to translate the given virtual address to a given physical address and to be associated with a subsequent translated access request issued by the requesting device; a translated access control circuit responsive to a translated access request issued by a requesting device on behalf of a given software context and specifying a target physical address; looking up corresponding permission information indicating corresponding access permissions defined in a device permission table for a region of a physical address space containing the target physical address based on the target physical address, the corresponding access permissions providing information for checking whether translated access requests from multiple software contexts are prohibited; determining whether a given software context is prohibited from accessing a target memory location corresponding to the target physical address in response to the translated access request based on the corresponding permission information; and triggering an error response when it is determined that a given software context is prohibited from accessing the target memory location in response to the translated access request.

[0005] In view of another example of the present technique, there is provided a computer readable medium for storing computer readable code for the manufacture of an apparatus, the apparatus comprising: an address translation circuit configured to, in response to a prior address translation request issued by a requesting device on behalf of a given software context and specifying a given virtual address, translate the given virtual address to a given physical address, and to provide the given physical address to the requesting device to be associated with a subsequent translated access request issued by the requesting device; a translated access control circuit responsive to a translated access request issued by a requesting device on behalf of a given software context and specifying a target physical address; Based on the target physical address, look up corresponding permission information indicating a corresponding permission defined in a device permission table for a region of the physical address space that contains the target physical address, the corresponding permission providing information for checking whether the translated access requests from the multiple software contexts are prohibited; determining whether a given software context is prohibited from accessing a target memory location corresponding to the target physical address in response to the translated access request based on the corresponding permission information; and a translated access control circuit that triggers an error response when it is determined that a given software context is prohibited from accessing the target memory location in response to the translated access request. [Brief description of the drawings]

[0006] Further aspects, features, and advantages of the present technique will become apparent from the following description of examples, read in conjunction with the accompanying drawings. [Figure 1] Illustrates multiple devices sharing access to memory. [Diagram 2] Illustrates an example of a system-on-chip (SoC) and off-chip devices sharing access to memory. [Diagram 3] Illustrates a method for processing proactive address translation requests. [Figure 4] Illustrates another method for handling proactive address translation requests. [Diagram 5] 1 illustrates an exemplary method for processing a translated access request. [Figure 6] Illustrates an example of an incoming packet in a protocol such as peripheral component interconnect express (PCIe). [Figure 7] Illustrates another method for processing a converted access request. [Figure 8] Illustrates a device configuration table and a device permission table. [Figure 9] Illustrates an exemplary set of permission levels and privilege levels and the interactions between them. [Figure 10] Illustrates an example of a physical address and how the physical address can be used to look up an entry in a device permissions table. [Figure 11] Illustrates an example of providing a device permission table for multiple execution states.

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

[0008] According to one exemplary configuration, an apparatus is provided that includes an address translation circuit configured to, in response to a prior address translation request issued by a requesting device on behalf of a given software context and specifying a given virtual address, translate the given virtual address to a given physical address, and to provide the given physical address to the requesting device to be associated with a subsequent translated access request issued by the requesting device. The apparatus also includes a translated access control circuit configured to, in response to a translated access request issued by the requesting device on behalf of the given software context and specifying a target physical address, translate the given virtual address to a given physical address. Based on the target physical address, look up corresponding permission information indicating corresponding permission defined in a device permission table for a region of the physical address space that contains the target physical address, the corresponding permission providing information for checking whether the translated access requests from the multiple software contexts are prohibited; determining whether a given software context is prohibited from accessing a target memory location corresponding to the target physical address in response to the translated access request based on the corresponding permission information; · A translated access control circuit is provided that triggers an error response when a given software context is determined to be prohibited from accessing a target memory location in response to a translated access request.

[0009] In a data processing system, a location in memory can be identified using a physical address in a physical address space. Thus, a device may access data at a given location in memory by issuing an access request that specifies a physical address that corresponds to the given memory location. A device may also issue access requests on behalf of a software context (e.g., a virtual machine, an application, or a hypervisor) executing on the data processing system (e.g., a device may be a virtualized hardware accelerator or an I / O device shared for use by some software contexts). However, some devices (or some software contexts) may not be trusted to only issue access requests to memory regions that they are permitted to access; for example, a malicious actor may cause a device to issue an access request to protected memory, or in fact, such access may be made in error (e.g., if an incorrect physical address is specified for the access request). Thus, a potential security risk exists if a device is permitted to issue access requests that specify physical addresses.

[0010] To address this issue, one approach may be to prevent devices in a data processing system from sending access requests that specify physical addresses; instead, the devices may issue access requests that specify virtual addresses from a virtual address space. These virtual addresses may then be translated to physical addresses by an address translation circuit. In some examples, there may be two further stages of address translation: a first stage of translating a virtual address (VA) from a VA space to an intermediate address (which may be in a physical address (PA) space as perceived by the virtual machine or operating system, but may actually be in an "intermediate PA space" or "guest PA space" and addresses in this address space may be referred to as intermediate physical addresses (IPAs)), and a second stage of translating the intermediate address to a PA in the system's PA space. However, it should be noted that the two-stage translation is optional and the present technique may be used regardless of whether a one-stage or two-stage address translation process is used.

[0011] Virtual addressing allows address mappings that define the translation between virtual addresses and physical addresses to be set such that certain physical addresses (that are not mapped to any virtual address for a given software context) cannot be accessed by requests made for that software context. The address translation circuitry can also perform checks (e.g., access permission checks) when translating virtual addresses to determine whether the requesting device is permitted to access the specified memory region. Thus, the security of a data processing system can be improved by preventing devices from directly accessing memory (e.g., by issuing memory access requests that specify physical addresses).

[0012] However, the process of translating a physical address to a virtual address and checking access permissions can be time consuming, and may require, for example, performing a page table walk of a page table in memory. Even if a page table walk is not required (e.g., if the request can be translated using mapping information cached in a translation lookaside buffer), the address translation circuitry may be shared among multiple sources of memory access requests (e.g., among multiple devices), and thus contention for translation bandwidth can delay servicing of the address translation for a given access request.

[0013] Therefore, to reduce the latency of access requests, some devices may be permitted to issue pre-address translation requests that specify a virtual address to be translated, but do not actually require access to memory at that time. The address translation circuitry translates the virtual address to a physical address, checks any access permissions (if defined, it is not mandatory to define such access permissions), and then returns the physical address to the device (if the device is permitted to access the memory location corresponding to the translated physical address). The device can then issue a translated access request specifying the translated physical address at a later time (when memory access to the location associated with the translated physical address is actually required). In this way, the latency associated with the access requests issued by the device can be reduced. If the device needs to issue multiple access requests to the same location in memory, the reduction in latency may be even greater (e.g., the translated physical address may be cached in the device to allow reuse for later access requests).

[0014] However, the inventors of the present technique have recognized that allowing a device to issue an access request that specifies a physical address still carries the risk that the device may issue a translated access request that specifies a physical address of a memory location that it does not have permission to access. For example, a device may issue an access request that specifies a physical address that was not received in response to a prior address translation request, which may be the result of a malicious actor or an error during operation, for example.

[0015] It would therefore be advantageous to be able to improve the security of a data processing system while still providing the benefits of pre-address translation (eg, reduced latency associated with an access request).

[0016] To address this issue, the present technique provides a translated access control circuit (e.g., may be an extended version of an existing access control circuit for receiving a translated physical address from an address translation circuit and performing an access in response to an access request specifying a virtual address, or may be a dedicated circuit for processing a translated access request) that responds to a translated access request by looking up permission information corresponding to a target physical address specified by the request. The permission information is defined in a device permission table (DPT) and indicates a set of access permissions associated with a region of a physical address space (e.g., a system PA space, if two-stage address translation is implemented) that encompasses the target physical address. For example, the permission information may be the access permission itself, and in one example, the translated access control circuit directly looks up the access permission in the table. The table may be a memory-based table, and thus such a direct lookup in the table may be an access to a memory system (the same memory system whose access is controlled using the DPT) to access an entry in the DPT. However, in other examples, the lookup of the permission information may be performed in some other structure (e.g., a cache), and the permission information need not be in the same format as the access permission in the DPT. Based on the permission information, the translated access control circuitry can then determine whether the software context in which the access request was issued is prohibited (e.g., not authorized) from accessing the target memory location corresponding to the target physical address by issuing the translated access request.If the translated access control circuitry determines that the software context is not permitted to access the identified target memory location using the translated access request, an error response is triggered, which may include, for example, that the translated access request is denied, and / or which may include a different response, such as updating an error log to record that a prohibited access request was made (although not necessarily preventing the access request itself from proceeding, the error log may be checked before a later access to the affected physical address to check whether it is safe to rely on the contents of the data stored at that physical address). In this way, the security of the system may be improved while still supporting early address translation.

[0017] Note that if a given software context is not permitted to access an identified target memory location using a translated access request, this does not necessarily mean that the given software context is also not permitted to access the identified target memory location using an untranslated access request that specifies a virtual address. The identified target memory location is indeed accessible to the software context, provided that the memory access request to that location specifies a virtual address, so that the security provided by the address translation lookup by the address translation circuitry can be enforced. The reason for denying access to the target physical address may simply be that the device is not trusted to directly specify a physical address, rather than a matter of accessing the target physical address itself. Thus, the DPT may be a table used to control whether a translated access request (based on a physical address that should already have been translated in response to a previous pre-address translation request) is permitted for the target physical address.

[0018] If the translated access control circuitry determines, based on the permission information, that a given software context is not prohibited from accessing the target memory location in response to a translated access request, the request may be allowed to be serviced in memory or may be subject to further checks. Thus, although failure to meet the requirements of the DPT may cause the request to be rejected (and / or may trigger some other error response), it is not mandatory that a request that meets the requirements of the DPT be accepted, since there may be other reasons for rejecting a request depending on what other checks are implemented for a given system (e.g., checks for pre-address translation requests / reason unrelated to processing translated access requests).

[0019] As described above, access requests (including translated access requests) may be issued on behalf of a software context. A software context may be, for example, a virtual machine, which may be a virtual emulation of a computer system that may share a physical hardware platform with other virtual machines. Other examples of software contexts are applications or hypervisors. Devices such as I / O devices or hardware accelerators may be configured to provide functionality on behalf of a particular software context. Note that there is not necessarily a 1:1 correlation between software contexts and devices (e.g., a single software context may be associated with two or more devices, or multiple software contexts may share a single device).

[0020] In the present technique, the access permissions defined in the DPT provide information that can be used to check whether a translated access request from multiple software contexts is permitted. For example, the access permissions can be shared between multiple software contexts, allowing a single DPT to define the access permissions for multiple software contexts. This can help reduce the overall memory footprint required for table data compared to alternative approaches that define an entirely separate table structure for each software context. Furthermore, by allowing the use of a single DPT for multiple software contexts, this provides a DPT whose size is statically determinable (e.g., no memory needs to be allocated for an entirely new table each time a new software context begins execution). This can improve performance. Also, providing a single DPT structure shared between multiple software contexts can improve cacheability in implementations that cache information from the DPT structure, since it means that a single cache entry can be used to validate requests for multiple software contexts, rather than requiring separate cache entries for each context.

[0021] In some examples, the converted access control circuitry is configured to support at least one encoding of an entry in the device permission table that identifies at least one access permission associated with an identified software context specified from among the plurality of software contexts by the entry in the device permission table.

[0022] In some situations, it may be desirable to define different access permissions for different software contexts; for example, some software contexts may be prohibited from accessing a given memory region using a translated access request, while other software contexts are permitted to access the region using the translated access request. Thus, the translated access control circuitry according to the present technique also supports encoding a device permission table that allows an identified software context to be associated with a set of device permissions for a given physical address. This allows the permissions for a given physical address to be defined depending on the software context issuing the request, which may be useful as it allows a richer set of permissions to be defined. For example, this may allow some pages in memory to be accessible only to a particular software context via a translated access request, or to be shared between a particular software context and one or more other processes (when accessed using a translated access request). Thus, identifying a software context in association with a set of permission information may further improve the security of the system and improve usability.

[0023] In some examples, the translated access control circuitry is configured to support a device permission table including a plurality of entries indexed by physical address, each of the plurality of entries identifying access permissions for an associated region of the physical address space.

[0024] Thus, unlike the page table that is looked up by the address translation circuitry, the device permission table, in this example, is indexed by the physical address, as opposed to being indexed by the virtual address (or by the intermediate address provided by stage 1 of the two-stage address translation).

[0025] In some examples, the access permission includes a device permission level selected from a plurality of device permission levels, at least one permission level being: a private permission level that identifies a given software context of the plurality of software contexts and indicates that translated access requests associated with processes other than the given software context are prohibited from accessing the associated region of the physical address space; a shared permission level that identifies a given software context of the plurality of software contexts and indicates that translated access requests associated with processes other than the given software context and a supervisor process operating at a higher privilege level than the plurality of software contexts are prohibited from accessing the associated region of the physical address space.

[0026] In this way, some pages in memory can be made private to a given software context (for the purpose of access via a translated access request), providing greater protection for processes executed by the given software context, or shared with a supervisor process by the given software context. It will be understood that in addition to the private and shared permission levels defined above, other permission levels can also be defined. Thus, the device permission table can support a richer set of permissions than simply defining that access using a translated access request is permitted or prohibited for a given address. As mentioned above, whether a given address is specified with a private or shared permission level for the purpose of processing a translated access request can be set separately from whether a given software context is permitted to access the address using an untranslated access request that specifies a virtual address, and the permission for an untranslated access request can be more or less permissive than the permission for a translated access request.

[0027] In some examples, the translated access control circuit is configured to look up corresponding device configuration information indicating a given software context associated with the device identifier based on a device identifier specified in the translated access request, and when the corresponding permission information specifies the at least one access permission associated with the identified software context, the translated access control circuit is configured to determine whether the given software context is prohibited from accessing the target memory location in response to the translated access request based on a comparison of the given software context with the identified software context.

[0028] In this way, the association between devices and software contexts can be variably configured using device configuration information. By abstracting the relationship between devices and software context identifiers using a device configuration table and defining permissions in a device permission table that can be encoded to define software context specific permissions, this avoids the need to redefine detailed address specific permissions in the device specific table every time there is a change in the software context on the device; instead, it is sufficient to change the software context identifier associated with the device, and the device permission table can remain the same. If a software context swaps device usage, the permissions of that software context in the device permission table can be easily associated with the new device by simply updating the associated software context identifier indicated for the new device in the device configuration table.

[0029] In some examples, the converted access control circuitry is configured to support a device configuration table including a plurality of entries indexed by a device identifier, each of the plurality of entries identifying device configuration information for an associated device. Thus, unlike the device authorization table, which is indexed by a physical address, the device configuration table, in this example, is indexed by the device identifier.

[0030] In some examples, the device configuration information in each of the plurality of entries includes privilege information indicating whether the associated device is prohibited from issuing the translated access request, the privilege information including a privilege level selected from a plurality of privilege levels, the plurality of privilege levels including at least one privilege level indicating that the associated device is permitted to issue the translated access request even when the device authorization table indicates that access to the subset of the physical address space in response to the translated access request is prohibited for at least one software context associated with the device identifier.

[0031] Thus, at least in some cases, the device configuration table may also be used to define a second set of permissions per device, which may be orthogonal to the permissions defined per address region in the device permission table. This may allow a richer set of permissions to be expressed that may be useful to software. In some examples, the permissions indicated by the device configuration information in the device configuration table may supersede (prefer) the permissions indicated by the permission information in the device permission table, allowing a particular device to be designated as (for example) a trusted device with more lenient access permissions indicated in the device permission table, or an untrusted device with stricter access permissions than those indicated in the device permission table. Other encodings of the device configuration table may indicate that (for a particular memory region) the permissions indicated in the device permission table should be followed.

[0032] In some examples, the apparatus includes a device authorization cache configured to store authorization information corresponding to a subset of access permissions defined in the device authorization table, and the translated access control circuit, in response to a translated access request, looks up the corresponding authorization information in the device authorization cache based on a target physical address of the translated access request.

[0033] It can be implemented as a hardware structure associated with the translated access control circuit, and performing a lookup in a cache that stores only a subset of the permission information may take significantly less time than looking up a device permission table in memory, which means there are fewer entries to consider. Thus, providing a device permission cache that stores permission information for a subset of access permissions allows the latency associated with access requests issued by the device to be reduced, which may lead to increased performance. It should be understood that the device permission cache may also cache other information, such as information from a security table that indicates further access permissions that depend on the security state.

[0034] In some examples, the translated access control circuit is responsive to the advance address translation request to determine corresponding permission information for a region of the physical address space that contains the target physical address and store the corresponding permission information in a device permission cache.

[0035] In some examples, the address translation circuit is configured to look up a set of translation table permissions defined in an address translation table entry corresponding to a given virtual address and a given software context in response to an advance address translation request, and the translated access control circuit is configured to determine corresponding permission information according to the translation table permissions, and store the corresponding permission information in a device permission cache.

[0036] For example, the address translation table may be a page table in memory that defines virtual-to-physical address translations and associated access permissions, and the lookup may be to these tables in memory, or a cache (e.g., a translation lookaside buffer (TLB)) that stores a subset of the translations defined in the page tables. The page table may already specify some access permission information (e.g., whether read access, write access, or instruction fetch is permitted for the corresponding page), and this information may be used to set the cached permission information in the device permission cache. Because the address translation circuitry has already looked up the address translations defined in the translation table (to translate a given virtual address to a given physical address), using the access permissions defined in the translation table may avoid the need to look up the access permissions defined in the DPT, which may require additional accesses to memory. This further improves performance.

[0037] In some examples, the translated access control circuit, in response to determining, based on the translation table permissions, that at least one of the corresponding access permissions for the given physical address is unknown from the translation table permissions, sets a default access permission as the corresponding permission information stored in the device permission cache.

[0038] In some cases, for example, when the access permissions identify a device permission level (e.g., private or shared) as discussed above, at least one of the access permissions for a given physical address may be unknown from the translation table permission. For example, the translation table permission may indicate access permissions for a given software context, but not for other software contexts. In such cases, the translated access control circuit may be configured to set the corresponding permission information in the DPT cache to a default access permission when pre-populating the cache in response to a pre-address translation request. For example, the default access permission may be the most restrictive access permission that still allows the given software context to access data stored in a memory location corresponding to the target physical address (e.g., the default may be the "private" permission level, as discussed above, in some examples). This allows for improved latency for at least some translated access requests (e.g., those sent on behalf of the given software context) to the region encompassing the target physical address without compromising the security of the system (e.g., by making pessimistic predictions).

[0039] In an alternative implementation, the translated access control circuit may be configured to look up the device permission cache in response to a pre-address translation request, and in response to detecting a miss in the DPT cache device permission table, the access circuit may be configured to look up a given access permission in the device permission table. This approach may incur higher latency than the approach of using the access permissions defined in the translation table to pre-populate the cache (as it may require additional accesses to memory), but may nevertheless improve the latency associated with the translated access request. In particular, by preemptively looking up the device permission cache in response to a pre-address translation request (even though the permission in the pre-address translation request is not required until a subsequent translated access request is received), any miss in the device permission cache may be detected early, and a device permission cache line fill operation to store the required permission in the device permission cache may be initiated early, reducing the likelihood of a miss when a translated access request is received.

[0040] In some examples, when the DPT cache is pre-populated in response to a pre-address translation request, the device authorization table access circuit is configured to perform a further lookup of the device authorization table in response to detecting, during a lookup of the device authorization cache performed in response to the translated access request, that there is no corresponding authorization information in the device authorization cache. In these examples, the further lookup is based on a target physical address specified by the translated access request, the further lookup includes identifying a corresponding access permission in the device authorization table, and the device authorization table access circuit is configured to store the corresponding authorization information identified during the further lookup in the device authorization cache.

[0041] Thus, in one implementation, permission information for a particular translated access request can be cached in a device permission cache after a miss is detected when executing the translated access request, which reduces latency for subsequent translated accesses to the same region of physical address space, thus improving performance.

[0042] In other examples, the translated access control circuitry is configured to reject the translated access request in response to detecting the absence of corresponding authorization information in the device authorization cache in a lookup of the device authorization cache performed in response to the translated access request. Furthermore, in some examples, this behavior may be enabled or disabled on a per-device basis (e.g., indicating for a given device that "this device should never directly access physical address space").

[0043] Therefore, in an alternative implementation, if the lookup of the device permission cache (performed at the time of the translated access request) results in a miss, the translated access request is simply rejected. This approach is counterintuitive because one may assume that this would lead to an increase in overall latency due to the fact that any subsequent translated access to the same region of the physical address space would also miss. However, the inventors have recognized that for access requests that are translated based effectively on a physical address returned by a previous pre-address translation request, the corresponding permission information should have been stored in the cache when the pre-address translation request was serviced as described above, so that the lookup of the device permission cache should miss for only a small percentage of the permitted translated access requests. In addition, the inventors have recognized that the time it takes to walk the device permission table is unlikely to be significantly longer than the time it takes to, for example, reissue the translated access request as an untranslated access request specifying a virtual address and perform address translation of the virtual address using the address translation circuitry. Thus, in practice, the latency impact associated with an granted translated access request may be minimal, and it may be more efficient to simply reject translated access requests that miss in the device authorization cache (in practice, many such translated access requests that miss in the device authorization cache may be forbidden accesses in any case).

[0044] In some examples, the apparatus includes a device permission table walk circuit configured to look up a multi-level table representing a device permission table, each level of the multi-level table including entries associated with successively smaller regions of the physical address space, a final level of the multi-level page table defining access permissions, and each level other than the final level defining pointers to multiple tables in the next level, the pointers being selectable based on a portion of the physical address.

[0045] By supporting a multi-level device permission table, the technique avoids the need to reserve a contiguous range of address space large enough to store an entire table that covers the entire address range.

[0046] In some examples, the upper limit on the number of levels of the multi-level table supported by the device permission table walk circuitry is less than the upper limit on the number of levels of the page table supported by the page table walk circuitry.

[0047] Thus, even when implemented as a multi-level table, the device permission table may be flatter (e.g., have fewer levels) than a multi-level page table. This means that the access permissions defined in the table may be looked up more quickly than any access permissions that may be defined in a page table, which leads to reduced latency and therefore improved performance. In practice, the granularity at which permissions are specified for the device permission table may be less fine than the granularity used for the address translation table (e.g., because address mapping may require finer granularity than the device permissions), and thus providing a larger number of page table levels than the device permission table levels may provide an improved balance between efficiency and functionality.

[0048] In some examples, the device permission table walk circuitry is configured to support at least one encoding of an entry at at least one level other than the final level that indicates access permissions that apply to an entire block of physical address space covered by that entry at that at least one level other than the final level.

[0049] In this way, if the access permissions for all of a given block of physical addresses covered by a higher level table entry are the same, the access permissions can be defined in a single entry of the higher layer table that corresponds to the entire block of addresses, without having to incur the latency associated with performing a table walk all the way to the last level.

[0050] In some examples, the apparatus includes a device authorization cache configured to store authorization information corresponding to a subset of access permissions defined in a device authorization table, and the translated access control circuitry is configured to support encoding of at least one of the entries of the device authorization table indicating that the access permissions for each of a plurality of regions of the physical address space are identical and can be represented by a single entry in the device authorization cache corresponding to a given one of the plurality of regions.

[0051] For example, at least some entries in the DPT may hold a contiguous indicator (e.g., this may be a single bit, or may be a multi-bit indicator if contiguous regions of multiple sizes are supported) indicating that the access permissions defined in that entry also apply to at least one other entry in the table (e.g., this may be an adjacent entry in the table). This may mean that a single entry in the device authorization cache can be used to indicate access permissions for a region of the physical address space covered by multiple entries in the DPT (e.g., if the multiple entries are for contiguous regions in memory, this may mean that an entry in the device authorization cache can indicate permission information for a larger region of memory). This improves the cacheability of the authorization information, as it allows authorization information for a larger percentage of the address space to be stored in the device authorization cache simultaneously without increasing the size of the cache, thus leading to further reduction in latency.

[0052] In some examples, the translated access request is associated with a security state selected from among a plurality of possible security states, and a lookup of corresponding permission information is based on the security state and the target physical address.

[0053] For example, the software context may operate in one of a secure state (which may alternatively be referred to as a "trusted" or "sensitive" state) or a less secure state (which may also be referred to as a "non-secure" state), or there may be more than two possible states defined, and different regions of the physical address space may be assigned for access in a particular security state. For example, a software context operating in one security state may be permitted to access more or different regions of the physical address space than a software context operating in another security state (e.g., a software context operating in a less secure state may be prohibited from accessing a particular region of the physical address space associated with a secure state). Thus, it may be useful to further define access permissions based on the security state in which the software context is operating, and to look up the permission information based on the security state associated with the translated access request. This may provide an additional layer of security.

[0054] In some examples, the converted access control circuit is configured to support multiple device permission tables, each corresponding to a different security state.

[0055] One way to specify access permissions that depend on security state and physical address is to support a separate table for each security state. This approach may simplify lookup of permission information because the DPT for each security state may not need to cover the entire physical address space (e.g., if a given security state is always prohibited from accessing a particular region of the physical address space, it may not be necessary to define access permissions for this region in the DPT for the given security state).

[0056] In some examples, the translated access control circuitry is configured to support, as a device permission table, a table shared among multiple devices for defining access permissions for translated accesses issued by the multiple devices.

[0057] For example, a single DPT can be used to define access permissions for multiple devices, which reduces the memory footprint of the DPT.

[0058] In some examples, the apparatus includes a device authorization cache configured to store permission information corresponding to a subset of access permissions defined in a device authorization table, a processing circuit configured to execute software, and a device authorization cache control circuit configured to invalidate entries in the device authorization cache in response to a device authorization cache maintenance command triggered by the software executing on the processing circuit and having a different encoding than a translation lookaside buffer invalidation command for triggering invalidation of page table information from the translation lookaside buffer.

[0059] For example, a dedicated command may be defined to invalidate entries in a device authorization cache, which is different from any invalidation command used to invalidate entries in a translation lookaside buffer (TLB). Such a device authorization cache invalidation command may be used to invalidate entries in a stale device authorization cache, for example, because the corresponding access permissions in the DPT have been updated. This may help improve security. A device authorization cache invalidation command may, in some examples, specify at least one filter condition that is used to select which device authorization cache entries to invalidate. For example, a device authorization cache invalidation command may specify an address range or a specific address for which device authorization cache entries should be invalidated (this may be specified using a virtual address, thus requiring translation, although in other examples it may be easier to support only physically addressed device authorization cache invalidation commands). The filter condition may be based on a software context identifier (e.g., a virtual machine identifier (VMID)). In other examples, a device authorization cache invalidation command may simply be a global command that triggers all entries in the device authorization cache to be invalidated.

[0060] The concepts described herein may be embodied in computer readable code for the manufacture of devices embodying the concepts described. For example, the computer readable code may be used at one or more stages of a semiconductor design and manufacturing process, including an electronic design automation (EDA) stage, to manufacture integrated circuits comprising devices embodying the concepts. Such computer readable code may additionally or alternatively enable the definition, modeling, simulation, verification and / or testing of devices embodying the concepts described herein.

[0061] For example, computer readable code for producing a device embodying the concepts described herein can be embodied in code defining a hardware description language (HDL) representation of the concept. For example, the code may define a register-transfer-level (RTL) abstraction of one or more logic circuits to define a device embodying the concept. The code may define an HDL representation of one or more logic circuits embodying the device in Verilog, SystemVerilog, Chisel, or VHDL (Very High-Speed ​​Integrated Circuit Hardware Description Language), as well as intermediate representations such as FIRRTL. The computer readable code may provide a definition embodying the concept using a system-level modeling language such as SystemC and SystemVerilog, or other behavioral representation of the concept that can be interpreted by a computer to enable simulation, functional and / or formal verification, and testing of the concept.

[0062] Additionally or alternatively, the computer readable code may embody a computer readable representation of one or more netlists. The one or more netlists may be generated by applying one or more logic synthesis processes to the RTL representation. Alternatively or additionally, the one or more logic synthesis processes may generate a bitstream from the computer readable code that is loaded into a field programmable gate array (FPGA) to configure the FPGA to embody the described concepts. The FPGA may be deployed for proof of concept and testing purposes prior to manufacture in an integrated circuit, or the FPGA may be deployed directly into a product.

[0063] The computer readable code may include a mixture of code representations for fabrication of a device, including, for example, a mixture of one or more of an RTL representation, a netlist representation, or another computer readable definition used in a semiconductor design and manufacturing process to fabricate a device embodying the invention. Alternatively or additionally, a concept may be defined in a combination of a computer readable definition used in a semiconductor design and manufacturing process to fabricate a device, and computer readable code that defines instructions to be executed by the defined device once fabricated.

[0064] Such computer readable code may be disposed on any known transitory computer readable medium (such as wired or wireless transmission of code over a network) or on a non-transitory computer readable medium such as a semiconductor, magnetic disk, or optical disk. Integrated circuits manufactured using the computer readable code may include components such as one or more of a central processing unit, a graphic processing unit, a neural processing unit, a digital signal processor, or other components that individually or collectively embody the concepts.

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

[0066] FIG. 1 illustrates an example of a data processing system 100 that includes multiple devices 105 with access to a shared memory 110. Each device 105 is configured to perform operations under the control of one or more software contexts 125, e.g., each device may be associated with a single software context (e.g., device 105c and software context 125c) or with two or more software contexts (e.g., device 105a and software contexts 125a and 125b). Additionally, a single software context 125 may be associated with multiple devices 105 (e.g., software context 125d is associated with two devices 105d, 105e). Each software context may be, for example, a virtual machine (VM), a hypervisor, or an application. Although FIG. 1 illustrates the devices 105 as off-chip devices separate from the SoC 115, the techniques described below may also be used for on-chip devices on the same integrated circuit as other components of the SoC 115.

[0067] The data processing system 100 also includes a system-on-chip (SoC) 115 coupled to the memory 110 and coupled to each of the devices 105 via an interconnect 120. The SoC 115 includes an address translation circuit 116 configured to translate a virtual address (VA) to a physical address (PA) that directly identifies a location in the memory 110. For example, the device 105, under control of a software context 125, may issue an access request to access data in the memory 110, and the access request may specify a virtual address from a virtual address space that needs to be translated to a physical address to perform the access in the memory. Some of the devices are also configured to issue pre-address translation requests that specify a virtual address that is translated by the address translation circuitry to a physical address that is then returned to the device (without actually requesting a memory access to a memory system location associated with that physical address when servicing the pre-address translation request). The device may then issue a translated access request that specifies the translated physical address.

[0068] Thus, the SoC 115 also includes an access control circuit 117 that controls access to the memory 110. In particular, the access control circuit 117 receives physical addresses from the address translation circuit 116 (e.g., following translation from a VA specified in the access request) and from the device 105 (e.g., with a translated access request) and performs access to data stored at corresponding locations in the memory 110. Thus, the access control circuit 117 functions as both an access control circuit for controlling access to the memory in response to normal (e.g., untranslated) access requests and a translated access control circuit for controlling access to the memory in response to a translated access request. However, it should be noted that in some implementations thereof, separate access control circuitry and translated access control circuitry may be provided.

[0069] As described above, the address translation circuit 116 supports advance address translation requests. Providing support for advance address translation requests can be advantageous because it allows subsequent translated access requests issued by the device 105 to specify a physical address. This means that the translated access requests can be serviced more quickly (e.g., with reduced latency) than normal access requests (e.g., access requests that specify a virtual address) because the process of translating the virtual address to a physical address has already been performed. In some examples, a given process running on one of the devices 105 may need to access a particular memory location multiple times. Servicing an advance address translation request to provide a physical address corresponding to that particular memory address means that the device 105 can subsequently issue multiple translated access requests that specify a physical address, while the latency associated with the address translation only needs to occur once. This can provide a further reduction in latency (and reduced pressure on the translation bandwidth in the address translation circuit 116 compared to performing a new translation for each access to the same address). Nonetheless, even for addresses that are only accessed once by device 105, pre-address translation can still be useful to remove the latency of address translation from critical timing paths when a memory access is actually required.

[0070] Much of the latency associated with address translation typically results from the need to check address mapping and access permissions for access requests or pre-address translation requests received by the address translation circuitry 116, which can result in delays while waiting for sufficient translation bandwidth when the address translation circuitry 116 is shared among multiple requestors, and long delays in accessing memory 110 to obtain the relevant translation table entry that provides the address mapping and access permissions if the required entry is not already cached in the address translation circuitry 116.

[0071] In the case of a permission check, the address translation circuitry 116 may check whether the requesting device 105 (e.g., the device issuing the request) and / or the software context 125 running on the device 105 is authorized to access the identified location in memory. Thus, in the case of a pre-address translation request, a physical address may be returned to the device, provided any necessary permission checks have passed.

[0072] However, in practice, it may be possible for the device 105 to issue a translated access request that specifies a physical address that was not received from the address translation circuitry 116 in response to a pre-address translation request. For example, a malicious actor may insert a translated access request into program code executed by one of the devices 105 that specifies a physical address that the device 105 is not authorized to access. In another example, the device 105 may erroneously specify a protected physical address. Either situation may lead to the device 105 accessing data in the memory 110 that it is not authorized to access. This leads to a potential security risk unless the address translation is performed again (with additional permission checks) in the access control circuitry 117 when the translated access request is received. However, it is expected that re-performing the address translation and permission checks when the translated access request is issued may negate the performance improvement that would otherwise be associated with pre-address translation. It may also be that there is no point in issuing a translated access request if the translated access request needs to undergo the same permission checks, and therefore the same associated latency, as a non-translated access request (e.g., an access request specifying a virtual address).

[0073] However, the inventors of the present technique have proposed an alternative approach that can improve the security of systems that employ pre-address translation without significantly increasing the latency associated with access requests.

[0074] 2 illustrates a particular example of a SoC 115 in communication with a device 105 and connected to a memory 110. While the memory 110 is illustrated in the figure as separate off-chip from the SoC 115, it will be understood that the memory 110 may also include on-chip memory on the same integrated circuit as the SoC 115. The SoC 115 in this example includes a root port 205 configured to forward messages received from the device 105 to components within the SoC 115 and to forward messages from within the SoC 115 to the device 105. The SoC 115 also includes a central processing unit (CPU) 240, which includes a memory management unit (MMU) for translating VAs to PAs for access requests issued by processing circuitry on the CPU. The SoC also includes a direct memory access (DMA) agent 245 (an example of an on-chip device) and a system memory management unit (SMMU) 242, which may also be referred to as an input / output MMU (IOMMU) or translation agent (TA), that receives requests from the DMA agent 245 and the root port 205 and translates the VA specified in the request to a PA. The SMMU 242 includes the aforementioned address translation circuit 116, which performs the address translation and also checks various access permissions; for example, these access permissions (as well as the address mapping for the translation) may be defined in a page table stored in the memory 110. The address translation circuit 116 may have a translation lookaside buffer (TLB) to cache page table entries for faster access than in the memory 110.

[0075] The access control circuitry 117 mentioned above may be provided within the SMMU 242 to generate access requests to be sent to the memory system based on the translation performed by the address translation circuitry 116. The access control circuitry 117 may also be implemented as distributed circuit logic, including a portion within the SMMU 242 as well as a portion of the (translated) access control circuitry 117 within the root port 205. It may be useful to provide a portion of the translated access control circuitry 117 to the root port 205 so that translated access requests (which do not require address translation because they already specify a physical address) can be issued to the memory without going through the SMMU 242, saving bandwidth in the SMMU 242 for requests that require translation. On the other hand, the portion of the access control circuitry 117 used to service untranslated requests that are translated by the address translation circuitry 116 may be provided in the SMMU 242 itself.

[0076] Also provided is an interconnect 215 that includes a memory controller for controlling access to memory in response to access requests that specify a PA. For example, this can include access requests forwarded to the interconnect 215 by the address translation circuitry 116 following translation of a VA to a PA, and / or translated access requests forwarded by the root port 205 from the device 105, as well as memory access requests made by the CPU 240 based on address translation by the CPU's MMU.

[0077] In the case of a device memory access, if the permission checks are all passed (e.g., it is determined that the device 105 and / or software context 125 are permitted to access the memory location based on page table permissions), the access request is passed to the interconnect / memory controller 215, which accesses the associated location in memory 110 before providing a response to the root port 205 for forwarding to the device 105.

[0078] The SoC 115 also includes a device authorization cache 230, which in this particular example is associated with the root port 205. However, in other examples, the cache 230 may be associated with multiple different root ports 205 (if more than one root port 205 is provided) or may instead be associated with the SMMU 242. The device authorization cache is controlled by the device authorization cache control circuitry 225, which, in response to a translated access request received by the root port 205, looks up the device authorization cache 230 based on the translated physical address specified in the request. If there is a hit in the device authorization cache 230, the authorization information in the identified entry is checked, and the translated access request is denied or granted based on the set of access permissions indicated by the authorization information. If the access permissions indicate that the translated access request is granted, it is passed to the memory controller 215 to be serviced. Thus, by performing an additional lookup of the authorization information when the translated access request is received, the security of the translated access request may be improved.

[0079] The permission information stored in the device permission cache 225 is a subset of the set of permissions defined in a device permission table (DPT) 220 in memory 110. Thus, if a lookup in the device permission cache (also referred to herein as a DPT cache) 230 fails, a lookup of the DPT can be performed to find the required permissions. Unlike any permission that may be defined in a page table referenced by the address translation circuit 116, the permissions defined in the DPT (and the corresponding permission information in the DPT cache) are indexed by a physical address such that they can be looked up based on the PA specified by the translated access request.

[0080] Providing the DPT cache 230 in addition to the in-memory DPT helps reduce the latency associated with translated access requests because a cache lookup typically consumes significantly less time than a lookup of an in-memory structure. This allows the additional security provided by checking these access permissions on translated access requests to be provided without significantly increasing the latency associated with the translated access requests.

[0081] Further, in some implementations, the DPT cache may be pre-populated with permission information when performing a pre-address translation request. For example, access permissions defined in a page table in memory (looked up during address translation) may be used to populate the cache. Alternatively, a lookup of permission information may be performed in the DPT when processing a pre-address translation request. For example, this may include performing a lookup in the DPT cache to see if corresponding permission information for the translated physical address is already defined in the cache, and performing a linefill if the permission does not exist. In any implementation, a lookup of the DPT cache 230 when receiving a translated access request from the device 105 is less likely to miss (the size of the device permission cache 230 may be selected to make such capacity conflicts less likely) unless the physical address was provided to the device 105 in a previous pre-address translation request, or the permission for that address has already been evicted from the device permission cache 230 due to a capacity conflict by the time the translated access request is received, because the corresponding permission information was stored in the cache when the pre-address translation request was serviced. Thus, in either implementation, the permission information for a translated access request is preloaded into DPT cache 225 when performing early address translation. This means that if the translated access request specifies a physical address obtained in response to an early address translation request (which is only possible for an authorized translated access request), then the lookup in DPT cache 230 upon receiving the translated access request should typically be a hit, and thus the latency associated with checking the permission information will be minimal for an authorized translated access request.

[0082] Additionally, in this example, device configuration information defined in a device configuration table (DCT) 250 is also looked up when a translated access request is received. The DCT identifies the correspondence between software contexts 125 and devices 105. The DCT 250 may also specify additional permissions to be applied to the translated access request on a per-device basis (which may provide an additional layer of protection on top of the per-region permissions defined in the DPT 220 indexed using a physical address). The DPT 220 and the DCT 250 are described in more detail below.

[0083] Although not explicitly shown in FIG. 2, device configuration information may also be looked up when responding to a pre-address translation request, and entries in the DCT 250 may be cached in the device authorization cache 230 or in a separate cache used for device configuration information from the DCT 250.

[0084] The format of information cached in device authorization cache 230 need not be exactly the same as the corresponding information in DCT 250 or DPT 220 on which the cached information is based. For example, information from DCT 250 and DPT 220 could be combined in a combined format, or information could be stored in cache 230 in a compressed form or in an expanded form that also includes other information.

[0085] As described above, when address translation circuit 116 receives a virtual address (specified either by an access request or a pre-address translation request), it may check a set of access permissions defined in a page table in memory 110 (which also defines the translation between virtual addresses and physical addresses).

[0086] The information in the DCT 250 and DPT 220 may be controlled by software executing on the CPU 240. Access control permissions governing which software is permitted to update entries in the DCT 250 or DPT 220 may be set in page tables used by the MMU of the CPU 240, such that the page tables for a given software process define whether addresses in the DCT 250 and DPT 220 are accessible to a given software process. The CPU 240 may support device authorization cache maintain commands that can be used by software to trigger invalidation of cached DPT (and DCT) information in the device authorization cache 230, which may be issued by software when the software modifies any information specified in the DCT 250 or DPT 220. The device authorization cache maintenance command may simply be a global cache invalidation command that triggers the invalidation of all entries in the device authorization cache 230, or it may be a more granular invalidation command that triggers the invalidation of entries that meet some filter criteria (e.g., cached DPT / DCT entries corresponding to a specified software context identifier, or cached DPT entries corresponding to a particular physical address or physical address range). The filter criteria may be specified by the device authorization cache maintenance command. The device authorization cache maintenance command may be an instruction supported in the instruction set architecture of the CPU 240, or it may be a memory-mapped command triggered by software by issuing a read or write memory access request that specifies an address that is mapped to represent the command addressed to the SMMU 242 or the DPT processing component 235, 230, 225. The type of command may be indicated by a particular address specified by the memory-mapped command, or, in the case of a write request, by the write data provided as the payload of the memory transaction.Thus, although there are a wide range of ways in which the CPU 240 (in response to software) may signal that an entry in the device authorization cache 230 should be invalidated, generally it may be useful to support such a mechanism so that old information can be invalidated when the DCT 250 or DPT 220 is updated in memory 110.

[0087] FIG. 3 illustrates one example of how a proactive address translation request issued by device 105 may be handled by the address translation circuitry and other components of the SoC.

[0088] As shown in FIG. 3, a pre-address translation request is issued by a device on behalf of a software context running on the device (305). The pre-address translation request specifies a VA to be translated to a PA and is received at a root port, which forwards the pre-address translation request to an address translation circuit (e.g., an SMMU) (310). The address translation circuit then looks up the VA in a set of page tables in memory (or in a translation lookaside buffer (TLB)) and checks the access permissions defined in the page tables for the virtual address (315). If it is determined based on these access permissions that the pre-address translation request is not allowed ("no") (320), the request is rejected (325) and the translation of the VA to a PA is not provided to the device. On the other hand, if it is determined that the pre-address translation request is allowed (320, "yes"), the address translation circuit translates the VA to a PA (the TLB or page table entry for the VA also specifies the corresponding PA) and sends the PA back to the root port (330) for forwarding to the device (335). The PA may then be specified in a translated access request that is later issued (340) by the device.

[0089] As mentioned above, the access permissions looked up by the address translation circuit in this example differ from the access permissions defined in the DPT in that they are specifically defined in a page table looked up based on a virtual address. The DPT defines a further set of permissions that define whether a particular physical address region is permitted to be accessed by a particular software context using a translated access request that specifies a physical address. The permissions in the DPT may be less or more permissive than the permissions defined in the page table, for example, the DPT may deny an access (using a translated access request) that would have been accessible using an untranslated access request if looked up using a page table based on a virtual address.

[0090] Figure 4 illustrates another example of how a pre-address translation request issued by device 105 may be processed by the address translation circuitry and other components of the SoC. The method illustrated in Figure 4 may include all of the steps of Figure 3, but also includes pre-populating the DPT cache based on access permissions defined in the page table.

[0091] 4, when it is determined that a device has issued a pre-address translation request on behalf of a software context (405) ("yes"), the address translation circuitry looks up the VA specified by the request in a TLB or page table and checks the access permissions defined in the page table for the VA (410). If the address translation circuitry determines (415) that the request is allowed ("yes"), the PA obtained by translating the VA is provided to the device (425).

[0092] In this example, for a pre-translation request that is successful (PA returned to the device), the translated access control circuit 117 also sets (430) permission information in the DPT cache for the physical address. For example, the permission information may be set based on the access permissions defined in the page table, which is already looked up when performing the address translation. These permissions are typically defined for a particular software context (e.g., separate page tables may be provided for different software contexts, since each software context may be associated with a different virtual address space). Thus, the access permissions defined in the page table for the translated VA indicate whether the requesting software context is permitted to access that memory location (and may indicate the particular type of request, e.g., read and / or write, that may be permitted), but do not indicate whether any other software contexts are also permitted to access that memory location. Thus, when the cache is pre-populated based on the page table, it may be appropriate to set the permissions for other software contexts to a default permission level. In a particular example, if the page table indicates that the requesting software context is allowed read and write access to the memory region containing the PA, then the permission information in the corresponding DPT cache entry may be set to indicate that the memory region is "private" to that software context for read and write access (e.g., to indicate that read and write access from that software context is allowed, but read and write requests for other contexts are not prohibited).

[0093] In an alternative implementation, instead of setting the permission information based on the access permission defined in the page table, the address translation circuitry may look up the permission information in the DPT cache. If it is determined that there is a hit in the DPT cache, no further action is taken. On the other hand, if it is determined that there is no hit in the DPT cache (e.g., there is a miss), the DPT access circuitry 235 accesses the required device access permission in the DPT, and the DPT cache control circuitry 225 updates the DPT cache to allocate the obtained device access permission to the DPT cache 230. This is another approach to warm up the DPT cache 230 in preparation for subsequent translated access requests that are likely to specify the same physical address. This particular approach allows the full set of access permissions defined in the DPT for the PA to be copied to the DPT cache, but may incur longer latency than the approach using page table permissions, since it may require an extra access to memory to read the DPT.

[0094] Returning to step 415, if the address translation circuit check determines (415) that the software context is not authorized to access the memory location identified by the PA ("no"), the request is denied (420). At this point, a DPT cache lookup (430) may still be performed, as indicated by the dotted line. However, in some implementations, this may be considered an unnecessary extra step given that the corresponding PA was not authorized to be accessed by the device.

[0095] FIG. 5 illustrates a method for processing a translated access request. In the method of FIG. 5, the device issues a translated access request that specifies a PA (505). The translated access request is sent by the device on behalf of the software context and is usually legitimate (previously translated following a prior address translation request), but may be malicious (e.g., the device may specify a PA that the software context is not allowed to access). The translated access control circuit 117 then looks up the physical address in the device authorization cache 230 in response to the translated access request (510). If the translated access control circuit 117 detects a hit in the device authorization cache for the physical address (515), it accesses the identified entry in the DPT cache and determines whether the translated access request issued by the requesting software context is allowed to access the memory location corresponding to the specified physical address based on the permission information defined in the identified entry (520). If such access is not allowed ("no"), the access is denied (525). On the other hand, if it is determined (520) that such access is permitted (“yes”), the access control circuit 117 issues (530) a memory request requesting access to the data in the identified memory location and sends a response to the device.

[0096] Returning to step 515, if no hit is found in the DPT cache ("NO"), for example if a miss is detected, the DPT walk circuitry may look up the access permissions for the PA in the DPT table (535). The DPT cache is then updated (540) to store the required access permissions and the method proceeds to step 520.

[0097] However, in an alternative implementation (as indicated by the dashed lines), the DPT lookup (535) and DPT cache update (540) may be omitted, and the translated access control circuitry may instead simply reject (525) any translated access request for which a hit is not found in the DPT cache (in response, the device may issue a further access request specifying the VA instead of the PA). As explained above, due to the early cache line fills shown in steps 440, 445 of FIG. 4 for early address translation requests, it may be relatively rare for a DPT cache lookup to miss when a translated access request is granted, and therefore, in some cases, the circuit logic required to support a DPT table walk and cache line fill when processing a translated access request may not be justified (particularly if the translated access control circuitry 117 is distributed, such that no portion of the circuit logic in the root port 205 needs to have the ability to trigger a DPT table walk, since this may be done in the portion in the SMMU 242 that invokes such a DPT table walk when processing an early address translation request). Alternatively, the DPT lookup (535) and DPT cache update (540) may depend on configuration information defined in the DCT; for example, these steps may be omitted if the configuration information determines that the device is not authorized to issue the translated access request at all.

[0098] Although devices may communicate with the SoC 100 according to any protocol, one example of a standard that may be used for communication by devices and, for example, the SoC is the Peripheral Component Interconnect Express (PCIe) standard.

[0099] 6 shows an example of a packet 605 carrying a translated access request using the PCIe standard. In this example, the packet 605 includes a data payload 610 and a target address 615. The target address is a physical address, and the data payload holds the data to be written to the target address in the case of a write request. The packet 605 also includes a header 620 that defines the request (e.g., in this case indicates that the packet 605 contains a translated access request and indicates whether it is a read request or a write request) and specifies a requester identifier 625 (also referred to herein as a device identifier) ​​that identifies the device that sent the request.

[0100] As shown in the figure, the requestor identifier 625 is used to look up device configuration information defined in one or more device configuration tables 250 (the device configuration information may specify a software context identifier of a software context 125 associated with the device that issued the packet 605), and the target address 615 is used to look up authorization information defined in one or more device authorization tables 220.

[0101] 7 is a flow diagram illustrating another example of responding to a translated access request in which both the DPT and the device configuration table (DCT) are taken into account. In this example, when a translated access request is received (705), the translated access control circuit 117 looks up device configuration information (defined in the DCT) according to a requester identifier indicated by the request (730). The device configuration information specifies a software context identifier associated with the requester identifier (and may optionally specify device-specific authorization information, as described below), and may be looked up in the DCT (in memory) or a cache. The translated access control circuit also looks up authorization information (defined in the DPT) based on a physical address specified as the target address of the request (735), which may also be looked up in the DPT or DPT cache in memory. Based on the device configuration information in combination with the device authorization information, the translated access control circuit checks whether the translated access request is allowed to proceed (740). If the translated access control circuitry determines that the access is allowed to proceed (745), the access is performed (750) and a response is returned to the requester. Otherwise, the access is denied (755). If the access is denied, this does not necessarily mean that the device cannot access the corresponding physical address at all; the device can instead issue an untranslated access request specifying a virtual address, which can then be processed using the address translation circuitry 116 based on the address mapping and access permissions defined in the page table.

[0102] It should be noted that the order of steps shown in the flow diagram is purely illustrative, and that in practice some of the steps may be performed in a different order than that shown, for example, steps 730 and 735 may be performed in either order or in parallel with each other. Furthermore, the information looked up in steps 730 and 735 may in some example implementations be defined in the same cache entry, in which case a single lookup of that entry would cover both steps.

[0103] 8 shows an example of a device configuration table (DCT) 250 and a device permission table (DPT) 220. In this example, the DCT 250 specifies, for each device (e.g., as identified by a device identifier 805), an associated software context identifier 810 that indicates the software context associated with the identified device. For example, the software context indicated in the DCT for a given device is the software context currently associated with that device. In addition, the DCT 250 specifies a privilege level (also referred to herein as device configuration information) 815, and each entry also includes a valid indicator 820 that indicates whether the entry is valid.

[0104] The privilege level 715 indicates whether the identified device is permitted to issue a translated access request on behalf of the identified software context, and what type of access is or is not permitted. In other words, the device privilege level may indicate a level of trust associated with the device. In this particular example, four privilege levels are defined: 1. No access allowed. If a privilege level of 1 is specified, this indicates that the identified device is not allowed to issue translated access requests on behalf of any software context. A device with a privilege level of 1 may be considered to be an untrusted device. 2. Private access is allowed. If a privilege level of 2 is specified, this indicates that the device is allowed to issue translated access requests on behalf of the identified software context to memory locations that are indicated in the DPT as being accessible only to the identified software context, e.g., memory locations that are defined as being private to the software context. 3. Shared access is allowed. If a privilege level of 3 is specified, this indicates that the device is permitted to issue translated access requests on behalf of the identified software context to memory regions that are either private to the software context or shared between the software context and one or more other processes. 4. All accesses are allowed. If a privilege level of 4 is specified, this indicates that any translated access requests issued by the device on behalf of the identified software context are allowed (even to memory regions marked in the DPT as not accessible, private, or shared, in which case the DCT permissions take precedence over the DPT permissions). A device with a privilege level of 4 may be considered a trusted device that is trusted not to specify an erroneous physical address that was not previously returned by a previous prior address translation request.

[0105] DCT thus allows a range of different permission levels to be assigned to specific devices: Some devices may have undergone strict controls during manufacturing to establish a root of trust in the device, and therefore may be assigned the more privileged permission 3 or 4. Other devices may be less expensive, are not known to have undergone such rigorous manufacturing steps, and may be more vulnerable to tampering or errors, and may be assigned the stricter permission levels 1 or 2 to limit the ability to use translated access requests that directly specify physical addresses.

[0106] Referring now to the DPT 220, the table specifies, for each physically addressed memory region 824, a software context identifier 825 for the associated software context, and a permission level 830 that defines a set of access permissions for the corresponding region. The table also defines a read / write / execute designation 835 to identify whether the permission information is applicable for read, write, and / or execute access, and each entry also includes a valid indicator 840 that indicates whether the entry is valid, and a continuity value 845. Alternatively, a DPT entry may include a permission "index," i.e., a small integer value that may be used to look up a separate configurable register or table of permission configurations. The continuity indicator 845, when set, indicates that the permission information defined in the entry is identical to the permission information defined in one or more other entries (so that these multiple entries may be represented within a single entry of the device permission cache).

[0107] The permission level 830 indicates the degree to which the corresponding memory region may be accessed using the translated access request. In particular, in this example, four permission levels are defined. 1. Access is not permitted. If a permission level of 1 is recorded, this indicates that the identified memory region is not permitted to be accessed using any translated access request. If a region has a permission level of 1, there is no need to specify a software context identifier (the Software Context ID field 825 can be ignored) since the access permissions in this case are independent of the software context identifier. 2. Private access is allowed (for the specified software context): If a permission level of 2 is recorded with an identified software context, this indicates that the memory region is private to the identified software context and therefore translated access requests to the identified memory region from the identified software context are allowed, but other translated accesses from other software contexts are not allowed. 3. Shared access is permitted. If a permission level of 3 is recorded, this indicates that access to the indicated memory region is shared between the indicated software context and one or more other processes (e.g., the indicated software context and a monitoring process that monitors the indicated software context), and thus the software context and the one or more other processes are permitted to access the region using the translated access request. Optionally, the DPT entry may also have an additional software context ID field to specify additional software context IDs of other software contexts that are permitted to share access to the memory region with the indicated software context. 4. Access is permitted. If a permission level of 4 is recorded, this indicates that the translated access to the identified memory location is permitted to be issued by any process. Again, if the PA has a permission level of 4, there is no need to specify a software context because the access permission in this case is independent of the software context ID.

[0108] Thus, the DCT defines device-level access permissions (e.g., each entry in the DCT corresponds to a particular device, but not to a particular range of addresses), while the DPT defines address-level permissions (e.g., each entry corresponds to a particular range of physical addresses).

[0109] In some cases, when a device issues a translated access request indicating a given PA, it may be possible for the privilege level defined in the DCT of that device to conflict with the permission level defined in the DPT of the indicated PA. Thus, in some cases, one of the privilege level and permission level may supersede (take precedence over) the other.

[0110] FIG. 9 illustrates how the privilege level defined in the DCT 250 and the permission level defined in the DPT 220 can be combined, in one example, to indicate whether a translated access request is allowed. In this example, there are some cases where the privilege level takes precedence over the permission level, e.g., when a privilege level of 1 is defined, access is always blocked, and when a privilege level of 4 is defined, access is always allowed. For example, a privilege level of 1 can indicate that the device is not trusted, and therefore, all translated access requests issued by the device should be denied, regardless of the PA specified in the request. Similarly, a privilege level of 4 can indicate that the device is trusted, and that translated access requests issued by the device should be allowed, regardless of the PA specified in the request. In this way, when a device is considered trusted or not trusted, this can be indicated by updating a single entry in the DCT, without the need to update multiple entries in the DPT. This may also avoid the need for the DPT to be looked up in some cases.

[0111] In all other cases (e.g., when the privilege level is 2 or 3), the most restrictive permission takes precedence. Thus, if either the privilege level or the permission level is 2 (private), the access is treated as private for a given software context, regardless of whether the other of the privilege / permission levels is 3.

[0112] It will be appreciated that this is just one possible way of defining the permission levels in the DPT 220 and DCT 250, and that other types of permissions may also be defined. Also, as shown in Figure 8, within the combined permissions shown in Figure 9, these may be further qualified using the R / W / E field 835 shown in Figure 8, which indicates whether the permission applies to read (R), write (W), and / or instruction fetch (Execute-E), respectively, for the region permitted to be accessed using the translated access request.

[0113] The device permission table may be implemented as a multi-level table in memory, and a table walk circuit is provided to look up the permissions defined in the table. FIG. 10 shows how a physical address 1005 may be used to look up an entry in a multi-level DPT. As shown in FIG. 10, a portion of the physical address is used as a level 0 index 1010, which may be combined with a DPT base address 1015 (e.g., configured in a register of the SMMU 242) to identify an entry in the level 0 table 1020. Each entry in the level 0 table corresponds to a block of memory and stores a base address that points to a corresponding level 1 table 1025 for that block of memory. A separate level 1 table is defined for each block of addresses, and the base address in each entry in the level 0 table 1020 identifies the table. Some entries in the level 0 table may also define a permission level for the entire block of memory. If so, the table walk circuit does not need to continue walking, since the permission level defined in the level 0 table entry is applicable to all addresses in that block.

[0114] Once the base address of the level 1 table is obtained from the level 0 table, a level 1 index 1030 derived from the physical address is used in combination with this base address to identify a level 1 table entry. Each entry in the level 1 table 1025 corresponds to a subset of memory addresses covered by the table and defines a permission level for that subset. For example, each level 1 table entry may include the fields shown in the device permission table 220 illustrated in FIG. 7.

[0115] Further, in this particular example, each entry 1035 in the level 1 table may specify separate access permissions for separate address ranges. Thus, to identify a particular access permission in the level 1 entry 1035, the GPI index 1040 is also derived from the physical address. For example, if the size of one DPT entry is smaller than a single cache line (the basic unit of memory access used to transfer data between different parts of a memory system), multiple DPT entries may fit in one cache line, and the GPI index 1040 portion of the physical address may be used to select the associated DPT entry from that cache line. In other examples, if the DPT entry size is a full cache line, the GPI index portion 1040 may not be necessary.

[0116] In this particular example, the physical address is 52 bits long, but the most significant bits 1050 are not used to identify a location in memory (e.g., they may be set to all 0's or all 1's) and are not used in the DPT lookup. Similarly, the least significant bits 1055 are also not used in the DPT lookup, as they indicate an individual address within the region that corresponds to a single DPT entry.

[0117] Although the DPT is illustrated in FIG. 10 as a two-level table, it should be understood that the table may include any number of levels. It may be useful for the number of levels in the DPT structure to be less than the number of levels supported for a multi-level page table structure used for address translation by the address translation circuit 116. For example, a two-level DPT may be used and a four-level page table structure may be used for a given stage of address translation. This may reflect that the page table structure may define address mappings and permissions for controlling the handling of untranslated memory accesses at a finer granularity than the permissions defined in the DPT for controlling the use of translated memory accesses.

[0118] In some examples, access permissions in a DPT may depend on the operational state of the software context issuing the request, e.g., a separate DPT may be defined for each operational state of multiple operational states. Figure 11 shows an example where separate tables are defined for software contexts running in a secure state (e.g., secure DPT 1105) and for software contexts running in a non-secure state (e.g., non-secure DPT 1110). Note that the label "non-secure" in non-secure DPT 1110 does not necessarily indicate that the table itself is not secure, this label simply indicates that this is a table used for software contexts running in a non-secure (e.g., less secure) state. Additionally, additional permission tables may be defined for other security states, as shown in Figure 11.

[0119] In this application, the term "configured to..." is used to mean that an element of an apparatus has a configuration that is capable of performing a defined operation. In this context, "configuration" refers to a manner of arrangement or interconnection of hardware or software. For example, an apparatus 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 an apparatus element needs to be modified in any way to provide the defined operation.

[0120] Although illustrative embodiments of the present invention are described in detail herein with reference to the accompanying drawings, it will be understood that the invention is not limited to these precise embodiments, and that various changes and modifications can be made to the embodiments by those skilled in the art without departing from the scope of the present invention as defined by the appended claims.

Claims

1. 1. An apparatus comprising: an address translation circuit configured to, in response to a pre-address translation request issued by a requesting device on behalf of a given software context and specifying a given virtual address, translate the given virtual address into a given physical address and provide the given physical address to the requesting device to be associated with a subsequent translated access request issued by the requesting device; a translated access control circuit responsive to a translated access request issued by the requesting device on behalf of the given software context and specifying a target physical address; based on the target physical address, looking up corresponding permission information indicating corresponding permissions defined in a device permission table for a region of physical address space that encompasses the target physical address, the corresponding permission providing information for checking whether translated access requests from multiple software contexts are prohibited; determining whether the given software context is prohibited from accessing a target memory location corresponding to the target physical address in response to a translated access request based on the corresponding permission information; and a translated access control circuit that triggers an error response when it is determined that the given software context is prohibited from accessing the target memory location in response to a translated access request.

2. 2. The apparatus of claim 1, wherein the converted access control circuitry is configured to support at least one encoding of an entry of the device authorization table that identifies at least one access permission associated with an identified software context specified by the entry in the device authorization table from among a plurality of software contexts.

3. 3. The apparatus of claim 1, wherein the translated access control circuitry is configured to support the device permission table including a plurality of entries indexed by physical address, each of the plurality of entries being shared among the plurality of software contexts and identifying access permissions for an associated region of physical address space.

4. the access permission includes a device permission level selected from a plurality of device permission levels; At least one of the device permission levels includes: a private permission level that identifies an identified software context of the plurality of software contexts and indicates that translated access requests associated with processes other than the identified software context are prohibited from accessing the associated region of physical address space; and a shared permission level that identifies an identified software context of the plurality of software contexts and indicates that translated access requests associated with processes other than the identified software context and a supervisor process operating at a higher privilege level than the plurality of software contexts are prohibited from accessing the associated region of physical address space.

5. the translated access control circuitry is configured to look up, based on a device identifier specified in the translated access request, corresponding device configuration information indicating the given software context associated with the device identifier; 3. The apparatus of claim 1, wherein when the corresponding permission information specifies at least one access permission associated with the identified software context, the translated access control circuitry is configured to determine whether the given software context is prohibited from accessing the target memory location in response to the translated access request based on a comparison of the given software context with the identified software context.

6. 6. The apparatus of claim 5, wherein the converted access control circuitry is configured to support a device configuration table including a plurality of entries indexed by a device identifier, each of the plurality of entries identifying device configuration information for an associated device.

7. the device configuration information in each of the plurality of entries includes privilege information indicating whether the associated device is prohibited from issuing translated access requests; the privilege information includes a privilege level selected from a plurality of privilege levels; 7. The apparatus of claim 6, wherein the plurality of privilege levels includes at least one privilege level indicating that the associated device is permitted to issue a translated access request even when the device permission table indicates that access to a subset of physical address space in response to the translated access request is prohibited for at least one of the software contexts associated with the device identifier.

8. a device permission cache configured to store permission information corresponding to a subset of the access permissions defined in the device permission table; 3. The apparatus of claim 1, wherein the translated access control circuitry is configured to, in response to the translated access request, look up the corresponding permission information in the device permission cache based on the target physical address of the translated access request.

9. 9. The apparatus of claim 8, wherein the translated access control circuitry is responsive to the advance address translation request to determine the corresponding permission information for the region of physical address space that contains the target physical address and store the corresponding permission information in the device permission cache.

10. the address translation circuitry is configured to, in response to the advance address translation request, look up a set of translation table permissions defined in an address translation table entry corresponding to the given virtual address and the given software context; 9. The apparatus of claim 8, wherein the translated access control circuitry is configured to determine the corresponding permission information based on the translation table permissions and store the corresponding permission information in the device permission cache.

11. 11. The apparatus of claim 10, wherein the translated access control circuitry, in response to determining based on the translation table permissions that at least one of the corresponding access permissions for the given physical address is unknown from the translation table permissions, sets a default access permission as the corresponding permission information stored in the device permission cache.

12. a device permission table walk circuit configured to look up a multi-level table representing the device permission table; each level of the multi-level table includes entries associated with successively smaller regions of the physical address space; the final level of the multi-level table defines the access permissions; 3. The apparatus of claim 1, wherein each level other than the last level defines pointers to a plurality of tables in the next level, the pointers being selectable based on a portion of a physical address.

13. 13. The apparatus of claim 12, wherein an upper limit on the number of levels of the multi-level table supported by the device permission table walk circuitry is less than an upper limit on the number of levels of a page table supported by a page table walk circuitry.

14. 13. The apparatus of claim 12, wherein the device permission table walk circuitry is configured to support at least one encoding of the entries at the at least one level other than the last level that indicates access permissions that apply to an entire block of physical address space covered by entries at the at least one level other than the last level.

15. a device permission cache configured to store permission information corresponding to a subset of the access permissions defined in the device permission table; 3. The apparatus of claim 1, wherein the translated access control circuitry is configured to support encoding of at least one of the entries of the device permission table indicating that access permissions for each of a plurality of regions of a physical address space are identical and can be represented by a single entry in the device permission cache corresponding to a given one of the plurality of regions.

16. the translated access request is associated with a security state selected from a plurality of possible security states; The apparatus of claim 1 or 2, wherein the lookup of the corresponding permission information is based on the security state and the target physical address.

17. 17. The apparatus of claim 16, wherein the converted access control circuit is configured to support multiple device permission tables, each corresponding to a different security state.

18. 3. The apparatus according to claim 1, wherein the translated access control circuit is configured to support, as the device permission table, a table shared among a plurality of devices for defining access permissions for translated accesses issued by the plurality of devices.

19. a device permission cache configured to store permission information corresponding to a subset of access permissions defined in the device permission table; processing circuitry configured to execute software; 3. The apparatus of claim 1, further comprising: device authorization cache control circuitry configured to invalidate entries in the device authorization cache in response to a device authorization cache maintenance command triggered by the software executing on the processing circuitry and having a different encoding than a translation lookaside buffer invalidate command for triggering invalidation of page table information from a translation lookaside buffer.

20. 1. A method comprising: In response to a pre-address translation request issued by a requesting device on behalf of a given software context and specifying a given virtual address, providing the given physical address to the requesting device to translate the given virtual address into a given physical address and to be associated with a subsequent translated access request issued by the requesting device; a translated access control circuit in response to a translated access request issued by the requesting device on behalf of the given software context and specifying a target physical address; looking up corresponding permission information, based on the target physical address, indicating corresponding permission permissions defined in a device permission table for a region of physical address space that encompasses the target physical address, the corresponding permission permissions providing information for checking whether translated access requests from multiple software contexts are prohibited; determining, based on the corresponding permission information, whether the given software context is prohibited from accessing a target memory location corresponding to the target physical address in response to a translated access request; and triggering an error response when it is determined that the given software context is prohibited from accessing the target memory location in response to the translated access request.

21. 1. A computer readable medium for storing computer readable code for manufacturing an apparatus, the apparatus comprising: an address translation circuit configured to, in response to a pre-address translation request issued by a requesting device on behalf of a given software context and specifying a given virtual address, translate the given virtual address into a given physical address and provide the given physical address to the requesting device to be associated with a subsequent translated access request issued by the requesting device; a translated access control circuit responsive to a translated access request issued by the requesting device on behalf of the given software context and specifying a target physical address; based on the target physical address, looking up corresponding permission information indicating corresponding permissions defined in a device permission table for a region of physical address space that encompasses the target physical address, the corresponding permission providing information for checking whether translated access requests from multiple software contexts are prohibited; determining whether the given software context is prohibited from accessing a target memory location corresponding to the target physical address in response to a translated access request based on the corresponding permission information; and a translated access control circuit that triggers an error response when it is determined that the given software context is prohibited from accessing the target memory location in response to a translated access request.

Images