Hardware identity simulation for target access control

Abstract

Systems and techniques are provided for identity simulation in an access control system. For example, a process for identity simulation in an access control system may include receiving, at a hardware identity simulator, a request from a first access domain to enable a target region to be accessible by a second access domain; updating the second access domain identity data structure to include an entry corresponding to the first access domain, the entry including an address of the target region and the first access domain identifier; receiving, at the hardware identity simulator, an access request from a second access domain to access the target area, the access request including a second access domain identifier and an address of the second access domain; and transmitting, at the hardware identity simulator, the address and the first access domain identifier to a memory management unit (MMU) of the access control system based on the access request.

Description

Technical Field

[0001] In general, the present disclosure relates to security of access control. For example, aspects of the present disclosure relate to using hardware identity simulator hardware to reduce the complexity of setting up access to a target area (eg, memory) to improve access setup time. Background Art

[0002] Devices typically implement various techniques for access control. Access control may refer to techniques for ensuring that various entities executing on a device can only access targets (e.g., memory areas) for which the entities have appropriate access rights. Such access control techniques typically require complex configuration processes that involve various software entities of the device configuring various hardware components of the device so that reads and / or writes issued to the target may be checked by the various hardware components before access is allowed (or denied).

[0003] There are scenarios where one entity on a device that has access to a particular target seeks to share access to at least a portion of the target with another entity for a limited amount of time (e.g., to perform a certain service). However, such sharing of access in a device that implements access control techniques typically requires complex interactions between the sharing entity, various software entities, and / or entities with which access is shared to reconfigure various hardware components to allow access before performing the service, and to remove access when the service is completed. Such complex interactions performed to share target access may degrade the performance of the device, for example, which may cause the device to fail to meet real-time performance goals. Summary of the invention

[0004] Systems and techniques are described herein for reducing the complexity of setting up access to a target area (e.g., memory) using one or more hardware identity simulator hardware components to improve access setup time. According to some aspects of the present disclosure, systems and techniques can use a hardware identity simulator to provide an access domain and / or an engine therein with the ability to share target area access with other access domains and / or engines to allow other access domains and / or engines to simulate the access domain and / or engine sharing the target area access in order to access the target area.

[0005] According to at least one example, a method for identity simulation in an access control system is provided. The method includes: receiving a request from a first access domain at a hardware identity simulator to make a target area accessible to a second access domain; updating a second access domain identity data structure at the hardware identity simulator to include an entry corresponding to the first access domain, wherein the entry includes an address of the target area and a first access domain identifier; receiving an access request from the second access domain at the hardware identity simulator to access the target area, wherein the access request includes a second access domain identifier and an address of the second access domain; and sending the address and the first access domain identifier to a memory management unit (MMU) of the access control system by the hardware identity simulator based on the access request.

[0006] In another illustrative example, a device for identity simulation in an access control system is provided. The device may include at least one memory and at least one processor coupled to the at least one memory. The processor may be configured to: receive a request from a first access domain via a hardware identity simulator to make a target area accessible to a second access domain; update a second access domain identity data structure at the hardware identity simulator to include an entry corresponding to the first access domain, wherein the entry includes an address of the target area and a first access domain identifier; receive an access request from the second access domain at the hardware identity simulator to access the target area, wherein the access request includes a second access domain identifier and an address of the second access domain; and send the address and the first access domain identifier from the hardware identity simulator based on the access request.

[0007] In another illustrative example, a non-temporary computer-readable medium having instructions stored thereon is provided, wherein the instructions, when executed by one or more processors, cause the one or more processors to perform the following operations: receiving a request from a first access domain via a hardware identity simulator to make a target area accessible to a second access domain; updating a second access domain identity data structure at the hardware identity simulator to include an entry corresponding to the first access domain, wherein the entry includes an address of the target area and a first access domain identifier; receiving an access request from the second access domain at the hardware identity simulator to access the target area, wherein the access request includes a second access domain identifier and an address of the second access domain; and sending the address and the first access domain identifier to a memory management unit (MMU) of an access control system via the hardware identity simulator and based on the access request.

[0008] In another illustrative example, a device for identity simulation in an access control system is provided, the device comprising: a unit for receiving a request from a first access domain at a hardware identity simulator to make a target area accessible to a second access domain; a unit for updating a second access domain identity data structure at the hardware identity simulator to include an entry corresponding to the first access domain, wherein the entry includes an address of the target area and a first access domain identifier; a unit for receiving an access request from the second access domain at the hardware identity simulator to access the target area, wherein the access request includes a second access domain identifier and an address of the second access domain; and a unit for sending the address and the first access domain identifier to a memory management unit (MMU) of the access control system based on the access request at the hardware identity simulator.

[0009] In some aspects, one or more of the devices described herein are, are part of, and / or include a mobile or wireless communication device (e.g., a mobile phone or other mobile device), an extended reality (XR) device or system (e.g., a virtual reality (VR) device, an augmented reality (AR) device, or a mixed reality (MR) device), a wearable device (e.g., a network-connected watch or other wearable device), a vehicle or a computing device or component of a vehicle, a camera, a personal computer, a laptop computer, a server computer or server device (e.g., an edge or cloud-based server, a personal computer acting as a server device, a mobile device (such as a mobile phone) acting as a server device, an XR device acting as a server device, a vehicle acting as a server device, a network router, or other device acting as a server device), a system on a chip (SoC), any combination thereof, and / or other types of devices. In some aspects, the device includes one or more cameras for capturing one or more images. In some aspects, the device includes a display for displaying one or more images, notifications, and / or other displayable data. In some aspects, an apparatus may include one or more sensors (eg, one or more RF sensors) such as one or more gyroscopes, one or more gyrometers, one or more accelerometers, any combination thereof, and / or other sensors.

[0010] This summary is neither intended to identify key or essential features of the claimed subject matter nor to be used in isolation to determine the scope of the claimed subject matter. The subject matter should be understood by reference to appropriate portions of the entire specification of this patent, any or all drawings, and each claim.

[0011] The foregoing as well as other features and examples will become more apparent after reference to the following description, claims and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Illustrative examples of the present application are described in detail below with reference to the following drawings:

[0013] Figure 1 is a block diagram illustrating a computing device according to some examples;

[0014] Figure 2 is a block diagram illustrating a hardware identity simulator according to some examples;

[0015] Figure 3 is a block diagram illustrating a memory management unit according to some examples;

[0016] Figure 4 is a block diagram illustrating a protection unit according to some examples;

[0017] Figure 5 is a block diagram illustrating a computing device according to some examples;

[0018] Figure 6 is a block diagram illustrating an environment including a hardware identity simulator according to some examples;

[0019] Figure 7 is a flow chart illustrating an example process for identity simulation in an access control system according to some examples;

[0020] Figure 8 is a diagram illustrating an example of a computing system for implementing certain aspects described herein. DETAILED DESCRIPTION

[0021] Certain aspects and examples of the present disclosure are provided below. As will be apparent to those skilled in the art, some of these aspects and examples may be applied independently, and some of them may be applied in combination. In the following description, for the purpose of explanation, specific details are set forth in order to provide a thorough understanding of the examples of the present application. However, it will be apparent that each example may be implemented without these specific details. The accompanying drawings and descriptions are not intended to be restrictive. In addition, certain details known to those of ordinary skill in the art may be omitted to avoid ambiguous descriptions.

[0022] In the following description of the drawings, in the various examples described herein, any component described with respect to a drawing may be equivalent to one or more similarly named components described with respect to any other drawing. For the sake of brevity, the description of these components may not be completely repeated with respect to each drawing. Therefore, each and every example of the components of each drawing is combined together by reference, and it is assumed that it is optionally present in each other drawing with one or more similarly named components. In addition, according to the various examples described herein, any description of the components of the drawings will be interpreted as optional examples, which can be implemented in addition to, in conjunction with, or in place of the examples described with respect to the corresponding similarly named components in any other drawings.

[0023] The following description provides only illustrative examples and is not intended to limit the scope, applicability or configuration of the present disclosure. Specifically, the following description of the illustrative examples will provide a feasible description for implementing the exemplary examples to those skilled in the art. It should be understood that various changes may be made to the function and arrangement of the elements without departing from the spirit and scope of the present application as set forth in the appended claims.

[0024] As used herein, the phrase "operably connected" or "operably connected" means that there is a direct or indirect connection between elements / components / devices, etc. that allows the elements to interact with each other in some manner. For example, the phrase "operably connected" can refer to any direct (e.g., a wired connection directly between two devices or components) or indirect (e.g., a wired and / or wireless connection between any number of devices or components that connect an operably connected device) connection. Therefore, any path that information can pass can be considered an operable connection. In addition, operably connected devices and / or components can exchange things other than information, such as electrical current, radio frequency signals, etc.

[0025] In some scenarios, a device (e.g., a computing device, a mobile device, a system-on-chip (SoC) device, etc.) implements various technologies for access control of various engines in various access domains for accessing a target or an area therein. An access domain can be a group of one or more engines with the same or similar access rights to access one or more targets. An engine can be any entity configured to generate read and / or write transactions (e.g., an operating system, an application, a processing element, a direct memory access (DMA) engine, etc.). A target can be any device, component, etc. configured to write data to and / or read data from it (e.g., a memory device (e.g., a random access memory (RAM)), an input / output (I / O) device, a memory-mapped I / O device or area, a port-mapped I / O device or area, a register, etc.). A target can have a location (e.g., identified by an address) where data can be written, read, and / or otherwise accessed and / or operated. A group of such locations can be referred to as an area of ​​a target. Access control can refer to a technique by which the ability of an engine in an access domain to access one or more targets and / or target areas is controlled so that only certain engines and / or access domains can access certain targets.

[0026] For example, to implement access control for a number of access domains, each of which includes a plurality of engines configured to perform read, write, and / or other operations, a hypervisor may be used to configure a memory management unit to associate identifiers of various access domains and / or engines therein with one or more targets, e.g., one or more address ranges of target resources, such as memory devices, registers, etc. In addition, a trust zone entity may be used to configure one or more protection units that control access to target resources, e.g., configuring one or more protection units to include associations between one or more target resources to which access is controlled by a protection unit and various access domains and / or engines therein having appropriate permissions to access the various target resources. In such a scenario, once the access control technique is implemented by having various software entities configure the memory management unit and the protection unit, the engine may perform read, write, and / or other operations by first sending the operation to the memory management unit to perform a first check, and if the first check is successful, sending the operation to an appropriate protection unit where a second check is performed. When both checks succeed (indicating that the engine has access rights to the target area), the read, write, and / or other operations may be performed, and the results of the operations may be returned to the engine that initiated the operation through various components.

[0027] In some scenarios, an engine and / or access domain may seek to share access to a target and / or target region with another access domain and / or an engine in another access domain, for example, to request execution of a specific service that uses specific data (e.g., when a read is requested) or address space (e.g., when a write is requested). However, techniques for implementing access control in such scenarios typically require complex interactions between the engine and / or access domain and various software entities (e.g., hypervisors and trust zones) to reconfigure various hardware components (e.g., memory management units, protection units, etc.) to share the target and / or target region.

[0028] For example, access control may be implemented at least in part by a memory management unit controlled by a hypervisor and a protection unit controlled by a trust zone entity. In such an example, a first engine in a first access domain may seek to cause a second engine in a second access domain to perform an integrity check on a particular data item by performing a hash function using the data item to obtain a hash, comparing the hash to a previously generated hash of the data item, and returning whether the comparison produces a match. In such a scenario, the second engine needs access to the data item in order to perform the requested service. However, the data item is stored in a memory device (e.g., a target) to which the first engine has exclusive access.

[0029] Therefore, in order to perform the service in this example scenario, a complex set of interactions is required to reconfigure the memory management unit and the protection unit to allow access to the memory area. In order to allow access, the first engine interacts with the hyper manager to request the hyper manager to reconfigure the memory management unit to associate the memory area (e.g., the target area) in which the data item is stored with the second engine. Then, the first engine interacts with the trust zone entity to request the trust zone entity to reconfigure the protection unit to associate the memory area with the second engine. This reconfiguration of the protection unit may require adding and / or updating several entries to the data structure of the protection unit. For example, an entry is created for a portion of the memory of the memory device before the memory area of ​​the data item, and the entry is associated only with the first engine, and a similar entry is created for a portion of the memory after the memory area, while creating another entry that associates the memory area with shared access for both the first engine and the second engine. Once all reconfigurations of the memory management unit and the protection unit are complete, the second engine can initiate an operation to read the data item, and the read operation request is checked by the reconfigured memory management unit, then checked by the reconfigured protection unit, and then the read is performed, and the data item is returned to the second engine, allowing the second engine to perform the requested service. After the second engine performs the service (e.g., integrity check), all various reconfigurations must then be undone to remove shared access to the memory region.

[0030] Such complex interactions typically degrade the performance of devices implementing access control because reads and / or writes from engines and / or access domains to targets and / or target areas are required to wait for various interactions and reconfigurations to complete before access can begin. Furthermore, additional device resources are required to remove access once service of a particular request is complete. Therefore, in order to address improvements in device performance of devices implementing access control techniques, additional capabilities should be added to such devices in order to reduce the complexity of the interactions required to share access to target resources. Therefore, there is a need for systems and techniques to add one or more hardware identity simulator components to a device to allow various engines and / or access domains to allow other engines and / or access domains to simulate the identities of engines and / or access domains with which they need to share access to target resources.

[0031] Described herein are systems, apparatus, processes (also referred to as methods), and computer-readable media (collectively, "systems and techniques") for enhancing the ability of a device that implements access control to a target resource to allow engines and / or access domains to share access to a particular target resource with a reduced level of complexity of the interactions required to enable shared access. The systems and techniques provide for a hardware component (referred to herein as a hardware identity simulator) to exist between an access domain (including one or more engines therein) and various other hardware components. In some examples, the hardware identity simulator is configured to change an identifier of an engine and / or access domain that seeks access to a particular target area to perform one or more operations (e.g., read and / or write operations). Thus, in some examples, hardware components (e.g., a memory management unit, a protection unit, etc.) do not need to be reconfigured to allow an engine and / or access domain to access a particular target and / or target area, which can reduce the complexity of shared target access and thereby improve device performance.

[0032] In some examples, an access domain is any set of one or more engines that have the same or similar access rights set to a target resource. In some examples, an engine is any entity executed on a device configured to perform operations (e.g., read and / or write operations) on a target resource. Examples of engines include, but are not limited to, operating systems, trust zone management entities, DMA engines, applications, processes, processing elements, etc. In some examples, a target resource (which may be referred to herein as a target) is any device, component, etc. that stores data and / or is configured to store data at an identifiable location. Examples of targets include, but are not limited to, a memory (or any part thereof) of a memory device, any number of registers for storing any number of data, any part of any I / O device capable of storing data, a storage device (or any part thereof), a memory-mapped I / O device, a device that maps registers to a memory area, etc. A given computing device may include any number of access domains, each of which includes any number of engines. A computing device may also include any number of targets. Any one or more of an access domain and / or an engine therein may be configured to access any one or more targets of a computing device.

[0033] Such access may be controlled, at least in part, by one or more memory management units and / or one or more protection units. In some examples, a memory management unit is a hardware component that receives operations seeking access to locations where data may be stored, and may perform various related services, such as address translation. The memory management unit may also perform services such as access control, during which the memory management unit determines whether a given engine and / or access domain is associated with a particular target or a portion thereof, and therefore determines whether a given engine and / or access domain has access rights to a particular target or a portion thereof. To this end, the memory management unit may include any number of data structures (each data structure including any number of entries) and circuitry for processing operation requests based, at least in part, on one or more data structures, the data structures including associations between engines and / or access domains and one or more targets (thereby indicating valid access rights).

[0034] Such access may be further controlled, at least in part, by one or more protection units. In some examples, a protection unit is a hardware component configured to provide additional access control protection to various target resources (e.g., memory, registers, etc.). In some examples, a particular protection unit of a computing device at least partially controls access to a certain set of target resources (e.g., one or more memory devices, one or more groups of registers, any combination thereof, etc.). To this end, a protection unit may include any number of data structures (each data structure including any number of entries) and circuitry for processing operation requests based at least in part on one or more data structures, the data structures including associations between target resources and engines and / or access domains that have appropriate access rights to the target resources.

[0035] In some examples, access control using hardware components (e.g., memory access units and / or protection units) can be controlled at least in part using a hardware identity simulator. In some examples, a hardware identity simulator is any hardware (e.g., circuitry) and / or data structure storage device (e.g., registers) that can be configured to allow one engine and / or access domain to simulate the identity of another engine and / or access domain to allow access-controlled target resources to be shared between access domains and / or engines.

[0036] In some examples, each access domain that can be authorized to simulate the ability of another access domain to access a target is configured with a dedicated hardware identity simulator. Such a hardware identity simulator may include an access domain identity data structure configured to include any number of entries. In some examples, such entries include, but are not limited to: an identifier of an access domain and / or an engine therein that authorizes access to a target resource; and an area (e.g., an address range) of a target resource or thereof that is authorized to be accessed. In some examples, the identifier in such an entry is an identifier of an engine and / or access domain that is different from the engine and / or access domain associated with the access domain identity data structure in the hardware identity simulator that includes the entry, and indicates that the different access domain and / or engine has the right to request modification of the entry to authorize temporary access to the target. Therefore, each entry is logically associated with two access domains; (i) an access domain associated with a hardware identifier that will simulate other access domains; and (ii) an access domain identified by an identifier in the entry that identifies a separate access domain that has the right to modify the entry. In some examples, the identifiers of the different access domains and / or engines in the entry are also identifiers that allow the identity of the access domain and / or engine to be simulated by being replaced with the identifier of the access domain for which the hardware identity simulator is configured.

[0037] In other examples, the hardware identity simulator can be configured to grant access to other access domains to access target resources, rather than being configured to simulate the identity of another access domain. In such examples, the hardware identity simulator is associated with the access domain in a manner dedicated to the access domain to which access is granted. An entry in the access domain identity data structure may include an identifier of the access domain that is authorized to access the target, and the entry may be associated with the specific access domain. Such an entry may also include the target or region therein of the authorized access id.

[0038] In other examples, a single hardware identity simulator may be configured for more than one access domain. In such examples, each entry in the access domain identity data structure of the hardware identity simulator may include a target that is authorized to access and / or a region therein, an identifier of the access domain that is authorized to access, and an identifier of the access domain that is authorized to access. The identifier of the access domain that is authorized to access may identify the entry as being associated with the authorized access domain (and therefore being the only access that can update the entry), and may also be used as a simulated identity used when the access domain that is authorized to access seeks to access the target. The identifier of the access domain that is authorized to access may indicate that the entry is associated with the access domain, so that when the access domain seeks to access a target in the entry, the hardware identity simulator may replace the access domain identifier of the access domain that is seeking to access the target with the access domain identifier of the access domain that is authorized to access the target.

[0039] Entries may be allowed in the access domain identity data structure for any one or more engines and / or access domains that have access to one or more access-controlled target resources. For example, a particular set of one or more entries may be assigned to a particular engine and / or access domain for which an update may be requested to grant at least temporary access to a target resource to another access domain and / or engine. The access domain identity data structure may include any other information items without departing from the scope of the examples described herein. For example, an entry in the access domain identity data structure may include a valid indicator that indicates whether the entry is valid at a given point in time.

[0040] In some examples, when a first access domain and / or an engine therein seeks to allow a second access domain and / or engine to access a target, the first access domain and / or engine may cause an update to an access domain identity data structure of the second access domain and / or engine to be granted access to include an entry that includes at least an identifier of the first access domain and / or engine for which access is sought, and an identifier of at least a portion of the target to which temporary access is granted (e.g., an address range).

[0041] In some examples, after updating an access domain identity data structure of an access domain and / or engine that is authorized to access at least a portion of the target, the access domain seeking to allow access can provide an indication of a request for a service to be performed to the access domain that is authorized to access. In some examples, in response, the access domain and / or engine that is authorized to access can confirm that access has been authorized by verifying that a valid indicator is present in an entry in its associated access domain identity data structure for the target associated with the request.

[0042] In some examples, once the validity of the authorized access to the target is verified, the access domain and / or engine that has been authorized to access the target or a portion thereof sends a request to perform an operation to the hardware identity simulator (e.g., its associated hardware identity simulator). In some examples, the request includes any number of bus attributes. Examples of such attributes include, but are not limited to, the address of the target where the target area to be accessed begins, the size of the target area to be accessed (e.g., four bytes), the type or operation to be performed (e.g., read, write, etc.), the identity of the engine and / or access domain seeking to perform the operation, the transaction number, etc.

[0043] In some examples, in response to receiving such a request, the hardware identity simulator may use hardware logic (e.g., implemented in a circuit) to perform a lookup of an address in an access identity data structure associated with the requesting engine and / or access domain. In some examples, if the address is not found, the operation request is denied. For example, if the access domain for which the operation is requested is not associated with an entry that includes the target address, the operation request may also be denied. In some examples, if the address is not found in the access domain identity data structure, the operation request may still be attempted using the identity of the access domain and / or engine for which the operation is requested. In some examples, if the address is found (and the requesting access domain is associated with the entry in which the address is found), the hardware identity simulator replaces the identifier of the engine and / or access domain for which the operation is requested with an identifier from the entry corresponding to the address, which is associated with the engine and / or access domain for which the entry is requested to be updated to allow access to the target area. In some examples, replacing the identifier of the engine and / or access domain requesting the operation with the identifier of the engine and / or access domain that has access to the target resource and requests shared access can be referred to as emulating the identity of the engine and / or access domain that has access to the target resource by the engine and / or access domain requesting the operation.

[0044] In some examples, the operation request is then sent along with the bus attributes including the simulated identity to various hardware components that contribute to the access control technology implemented on the computing device. For example, the bus attributes may be sent to a memory management unit (which verifies whether the simulated identity has access rights to the target resource area) and then to a protection unit (which verifies that the target resource area is associated with access rights indicating that the entity with the simulated identity can access the target resource area). In some examples, once the various hardware components (which may be collectively referred to as access rights check blocks) successfully perform a check on the access attempt based on the simulated identity, the operation may be performed, and the result of the operation (e.g., based on, for example, a transaction number associated with the operation request and included in the bus attributes) may be returned to the engine and / or access domain that originally requested the operation via the hardware identity simulator. The engine and / or access domain that requested the operation may then use the result of the operation to perform the service requested by the engine and / or access domain that authorized temporary access.

[0045] In some examples, once the requested service / services have been completed, the engine and / or access domain that authorized temporary access to the target resource may then cause the entry for the authorized access to be removed or otherwise invalidated (which may be referred to herein as deleted) from an access domain identity data structure associated with the engine and / or access domain that was authorized target resource access, thereby removing access to the target resource.

[0046] In some examples, complex interactions required to reconfigure various hardware components (e.g., memory management units, protection units, etc.) are no longer required based on having a hardware identity simulator for a given access domain and / or engine therein replace the identifier of the engine and / or access domain requesting an operation to be performed on a target resource with the identifier of the access domain and / or engine that has access rights to the target resource. In particular, such components may not require reconfiguration because the requested operation may already include the identifier of the engine and / or access domain, which the hardware component already knows has access to the target resource specified in the operation request.

[0047] Examples described herein may address the need to improve device performance by reducing or eliminating time-consuming software interactions and / or hardware component reconfigurations necessary to allow temporary sharing of target resource access between engines and / or access domains of a computing device.

[0048] Various aspects of the systems and techniques described herein are discussed below with reference to the accompanying figures. Figure 11 is a block diagram of a computing device 100. As shown, computing device 100 includes access domain A 102, access domain B 104, access domain C 106 (collectively referred to as access domains 102, 104, 106), hardware identity simulator A 108, hardware identity simulator B 110, hardware identity simulator C 112 (collectively referred to as hardware identity simulators 108, 110, 112), memory management unit 114, protection unit 116, target X 118, target Y 120, and target Z 122 (collectively referred to as targets 118, 120, 122). Each of these components is described below.

[0049] Computing device 100 is any device, portion of a device, or any group of devices capable of electronically processing instructions, and may include, but is not limited to, any of the following: one or more processors (e.g., components including integrated circuits), memory (e.g., all or any portion of targets 118, 120, 122), input and output devices (not shown), non-volatile storage hardware (e.g., all or any portion of targets 118, 120, 122), one or more physical interfaces, any number of other hardware components (not shown), and / or any combination thereof. Examples of computing devices include, but are not limited to, mobile devices (e.g., laptops, smartphones, personal digital assistants, tablet computers, automotive computing systems, and / or any other mobile computing devices), Internet of Things (IoT) devices, servers (e.g., blade servers in blade server chassis, rack servers in racks, etc.), desktop computers, storage devices (e.g., disk drive arrays, Fibre Channel storage devices, Internet Small Computer System Interface (iSCSI) storage devices, tape storage devices, flash arrays, network-attached storage devices, etc.), network devices (e.g., switches, routers, multi-layer switches, etc.), wearable devices (e.g., network-connected watches or smart watches or other wearable devices), robotic devices, smart TVs, smart home appliances, extended reality (XR) devices (e.g., augmented reality, virtual reality, etc.), any device including one or more SoCs, and / or any other type of computing device having the above requirements. In one or more examples, any or all of the above examples may be combined to create a system of such devices (which may be collectively referred to as computing devices). Other types of computing devices may be used without departing from the scope of the examples described herein.

[0050] In some examples, computing device 100 includes any number of access domains (e.g., 102, 104, 106). In some examples, an access domain is a collection of one or more engines that have the same or similar security permissions at least with respect to accessing one or more targets (discussed below). In some examples, an engine (not shown) is any entity that executes using resources of computing device 100 and is configured to request the use of a target (e.g., 118, 120, 122) to perform an operation (e.g., a read operation, a write operation, etc.). Examples of engines may include, but are not limited to, operating systems, applications, services, processes, processing elements, direct memory access (DMA) engines, etc.

[0051] In some examples, the engine may use a processor (not shown) to perform operations. In some examples, a processor is any component including a circuit for executing instructions / operations (e.g., of a computer program). For example, such a circuit may be an integrated circuit implemented at least in part using transistors implementing components such as an arithmetic logic unit, a control unit, a logic gate, a register, etc. In some examples, the processor may include additional components, such as a cache memory. In some examples, in order to perform an operation, the processor retrieves and decodes instructions and then executes the instructions. The execution of instructions may include operating on data, which may include reading data, writing data, converting data, etc. In some examples, the instructions and data used by the processor are stored in the memory and / or other components (e.g., registers) of the computing device 100. The processor may perform various operations for executing software (such as an operating system, an application, etc.). The processor may cause data to be written from a memory to a storage device of the computing device 100 and / or cause data to be read from a storage device via a memory. Examples of processors include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), a neural processing unit, a tensor processing unit, a data processing unit (DPU), a digital signal processor (DSP), etc.

[0052] In some examples, an access domain (e.g., 102, 104, 106) is associated with one or more identifiers. For example, access domain A 102 can be associated with identifier "A". As another example, access domain A 102 can be associated with any number of identifiers, each of which corresponds to one or more engines (e.g., A1, A2, A3, etc.) of access domain A 102. At least in the context of implementing access control techniques, an identifier corresponding to an access domain or any engine therein can have any form suitable for identifying an access domain and / or an engine therein.

[0053] although Figure 1The computing device 100 is shown as having three access domains 102, 104, 106, but the computing device 100 may have any number of access domains without departing from the scope of the examples described herein. Figure 1 Not shown, all or any portion of the visited domains 102, 104, 106 may be operably connected to each other, for example, to exchange information, request services from each other, and so on.

[0054] In some examples, each access domain 102, 104, 106 is operably connected to at least one hardware identity simulator. Figure 1 As shown in the example of FIG. 1 , access domain A 102 is operably connected to hardware identity simulator A 108, access domain B 104 is operably connected to hardware identity simulator B 110, and access domain C 106 is operably connected to hardware identity simulator C 112. Figure 1 Individual hardware identity simulators 108, 110, and 112 are shown as separate components, but in some examples, there may be any number of hardware identity simulators, each corresponding to any one or more access domains and / or engines therein. For example, computing device 100 may include a single hardware identity simulator that is operably connected to all access domains of computing device 100 that have access to one or more access-controlled targets or regions therein and is configured to perform identity simulation for all access domains.

[0055] In some examples, a hardware identity simulator (e.g., 108, 110, 112) is any hardware, software, firmware, and / or any combination thereof configured to provide identity simulation services for one or more access domains (e.g., 102, 104, 106). For example, a hardware identity simulator A108 may include one or more data structures including entries. In some examples, an entry includes an address of a target or target area that is associated with an identifier of an access domain and / or engine other than the access domain and / or engine for which the hardware identity simulator is configured. In some examples, the identifier of the other access domain and / or engine allows the access domain and / or engine associated with the data structure to simulate the identity of the other access domain and / or engine. In some examples, such a data structure of entries may be referred to as an access domain identity data structure. In the following Figure 2 The access domain identity data structure is discussed in more detail in the description of . In some examples, the hardware identity simulator (e.g., 108, 110, 112) also includes a logic component (e.g., implemented using circuits) for accessing the access domain identity data structure, manipulating received operations, sending operation requests, etc. Figure 1The computing device 100 is shown as including three hardware identity simulators 108 , 110 , 112 , but the computing device 100 may include any number of hardware identity simulators without departing from the scope of the examples described herein.

[0056] In some examples, the hardware identity simulator (e.g., 108, 110, 112) is configured to receive a request to perform an operation (e.g., a read operation, a write operation, etc.) from one or more access domains and / or engines therein for which the hardware identity simulator is configured. In some examples, the request includes any number of bus attributes. Examples of bus attributes include, but are not limited to, an address (e.g., a starting address of a target area on which the operation is to be performed), a size (e.g., a size of the target area starting from the address, e.g., four bytes), an operation to be performed (e.g., read, write, etc.), a transaction number (TXN) associated with the operation that allows the result of the operation to be properly routed back to the engine and / or access domain requesting the operation, other information used to route the operation request and / or the result of the operation (e.g., a port identifier), etc.

[0057] In some examples, the hardware identity simulator (e.g., 108, 110, 112) is also configured to use the address in the operation request to perform a lookup in the access domain identity data structure. For example, such a lookup can determine whether the engine and / or access domain requesting the operation has been authorized by another access domain and / or engine to access a particular target or target area. In some examples, if the address does not exist in the access domain identity data structure, the operation request is denied. In some examples, if the address (e.g., a memory address, a register identifier, etc.) exists in the access domain identity data structure, the operation can proceed.

[0058] In some examples, entries of the access domain identity data structure include entries for targets to which an access domain associated with a hardware identity simulator and / or an engine therein has access rights, and such entries include identifiers of the access domain and / or engine. Other entries in the access domain identity data structure may be associated with other access domains and / or engines that have access control rights to targets to which the access domain and / or engine associated with the access domain identity data structure does not have access rights. In such a scenario, an access domain and / or engine with access rights to such other targets may authorize access to such targets or regions therein by requesting an update of an entry in the access domain identity data structure to which the access domain and / or engine with access rights to the other targets is associated.

[0059] For example, access domain B 104 may seek to allow access domain A to access a region of target Y 120 to which access domain B 104 has access rights but access domain A 102 does not have access rights. To this end, access domain B 104 may request an update to the access domain identity data structure of hardware identity simulator A 108 at an entry associated with access domain B 104. For example, such an update may include a request to include, for that entry, the address of the region of target Y 120 associated with the identifier of access domain B 104. In this scenario, access domain B may request access domain A or any engine therein to use the region of target Y 120 to perform a certain service. To perform the service, access domain A 102 may send an operation request to hardware simulator A, the operation request including bus attributes including the identifier of access domain A, the address of the target region of target Y 120, the size of the target region, a transaction number for the operation, and the like. Hardware identity simulator A may then perform a lookup in the access domain identity data structure to find the address included in the bus attributes. Once the lookup is successful, hardware identity simulator A 108 may replace the identifier of access domain A 102 with the identifier of access domain B obtained from the entry including the address used to perform the lookup. In some examples, the modified operation request is then sent from hardware simulator A 108 to memory management unit 114.

[0060] In some examples, computing device 100 includes a memory management unit 114. In some examples, memory management unit 114 is any hardware (e.g., circuitry), software, firmware, and / or any combination thereof that is configured to, at least in part, manage any attempt to access a target or region therein (e.g., system memory, I / O device memory, registers, etc.) that includes a reference to an address of the target or region therein. Memory management unit 114 can be operably connected to any number of hardware identity emulators (e.g., 108, 110, 112). The memory management unit can be controlled, configured, reconfigured, etc., at least in part, by another entity of computing device 100 (e.g., a hypervisor, an operating system, I / O device firmware, other hardware components, etc. (not shown)). Although Figure 1 The computing device 100 is shown as including a single memory management unit 114 , but the computing device 100 may include any number of memory management units without departing from the scope of the examples described herein.

[0061] In some examples, as described above, the memory management unit 114 can be a hardware component that receives operations seeking access to locations where data can be stored and can perform various related services, such as address translation. The memory management unit can also perform services such as access control, during which the memory management unit determines whether a given engine and / or access domain (e.g., 102, 104, 106) is associated with a particular target (e.g., 118, 120, 122) or a portion thereof, and therefore determines whether it has access rights to the particular target or a portion thereof. To this end, the memory management unit 114 can include any number of data structures and circuitry for processing operation requests based at least in part on one or more data structures, each data structure including any number of entries that include associations between engines and / or access domains and one or more targets. In some examples, the memory management unit 114 uses all or any portion of bus attributes (e.g., addresses, access domains, and / or simulation identifiers of engines, etc.) received from a hardware identity simulator (e.g., 108, 110, 112) as part of the operation request to use one or more data structures of the memory management unit 114 to process the operation request. Such a data structure can be called a memory management unit data structure. Figure 3 Memory management data structures are further discussed in the description of .

[0062] In some examples, the computing device 100 includes a protection unit 116. In some examples, the protection unit 116 is any hardware, software, firmware, or any combination thereof that is configured to provide protection (e.g., access control) to any number of targets (e.g., 118, 120, 122). The protection unit 116 can be configured to operate in any number of modes, each of which provides protection to prevent unauthorized access to certain types of target resources. For example, the protection unit 116 can include a memory protection unit mode for protecting various memory devices and regions therein, a register protection unit mode for protecting any number of registers of the computing device 100, and / or an address protection unit mode for protecting any number of segmented or contiguous sets of addresses corresponding to target regions of various targets (e.g., 118, 120, 122). Other modes can be implemented on the protection unit 116 without departing from the scope of the examples described herein. The protection unit can be operably connected to the memory management unit 114 and to any number of targets (e.g., 118, 120, 122). Protection unit 116 may be controlled, configured, reconfigured, etc., at least in part, by another entity of computing device 100 (eg, a trusted zone entity, a trusted platform module, a secure element, another hardware element, a manageability engine, etc.).

[0063] In some examples, protection unit 116 is a hardware component that is configured to provide additional access control protection to various target resources (e.g., memory, registers, I / O memory, etc.). In some examples, protection unit 116 of computing device 100 at least partially controls access to a set of target resources (e.g., one or more memory devices, one or more groups of registers, any combination thereof, etc., such as targets 118, 120, 122). To this end, protection unit 116 may include any number of data structures and circuitry for processing operation requests based at least in part on one or more data structures, each data structure including any number of entries that include associations between target resources and engines and / or access domains that have appropriate access rights to the target resources. Such data structures may be referred to as protection unit data structures. Below in Figure 4 Protection unit data structures are further discussed in the description of .

[0064] In some examples, the protection unit 116 is configured to receive an operation request from the memory management unit 114. In some examples, the protection unit 116 only receives operation requests that are not rejected by the memory management unit 114 (e.g., operation requests that pass the access control check of the memory management unit 114). In some examples, the received operation request includes various bus attributes, such as the address of the target area requested to be accessed and the simulation identifier added by the hardware identity simulator (e.g., 108, 110, 112). Such bus attributes can be used by the protection unit 116 together with the protection unit data structure to determine whether the operation request can continue. In some examples, if the simulation identifier is not associated with the address in the protection unit data structure, the operation request is rejected. In some examples, if the simulation identifier is associated with the address in the protection unit data structure, the operation request can continue. In some examples, if the protection unit 116 allows the operation request to continue, the requested operation can be performed using the target resource requested to be accessed.

[0065] In some examples, computing device 100 includes any number of targets (e.g., 118, 120, 122). In some examples, a target is any hardware, software, firmware, or any combination thereof, including a location (e.g., identified by an address) to which data may be written, from which data may be read, and / or at which any other operation (e.g., data may be deleted, added, modified, updated, etc.) may be performed. Examples of targets 118, 120, 122 include, but are not limited to, memory devices (e.g., random access memory (RAM)), input / output (I / O) devices, memory-mapped I / O devices or regions, port-mapped I / O devices or regions, registers, storage devices, and the like. Target devices 118, 120, 122 may be operably connected to protection unit 116. Although Figure 1A computing device is shown having three targets 118 , 120 , 122 , but computing device 100 may have any number of targets without departing from the scope of the examples described herein.

[0066] In some examples, the target (e.g., 118, 120, 122) can include any number of target regions (not shown). In some examples, the target region is any portion of a location included in the target. For example, a target region of a memory device can be a region that starts at a specific memory address and extends a specific number of bytes, which may or may not be continuous within the memory device. As another example, the target region can be a portion of a specific set of registers. The location of the target (e.g., 118, 120, 122) can be used to perform various operations requested by an engine of an access domain (e.g., 102, 104, 106).

[0067] In some examples, the result of the requested operation can be returned to the engine and / or access domain that requested the operation. For example, at each step of an operation request between a requesting entity (e.g., an engine of an access domain) and a target (e.g., 118, 120, 122) for performing the operation, the entity can provide information (e.g., a return port) identifying a portion of a return path for the result of the operation, the return path being associated with a transaction number corresponding to the requested operation. In such a scenario, the target (e.g., 118, 120, 122) can send the result of the operation (e.g., data being read, an indication of a successful write, etc.) to the protection unit 116 via the protection unit return port, the protection unit 116 can return the result to the memory management unit 114 via the memory management unit return port, the memory management unit 114 can return the result to the hardware identity simulator (e.g., 108, 110, 112) that requested the operation using the simulation identifier via the hardware identity simulator return port, and the appropriate hardware identity simulator can return the result to the access domain (e.g., 102, 104, 106) and / or the engine therein that initiated the operation request. If appropriate, the access domain and / or engine may then communicate the results of the one or more operations via the hardware identity simulator (eg, 108, 110, 112) to the access domain and / or engine providing shared access to the target.

[0068] Although Figure 1 A specific number of components in a specific configuration are shown, but one of ordinary skill in the art will appreciate that the computing device 100 may include more components or fewer components, and / or components arranged in any number of alternative configurations without departing from the scope of the examples described herein. Figure 1Various components are shown as included in computing device 100, but all or any portion of these components (e.g., access domains, targets, etc.) may be separate from and operatively connected to computing device 100 without departing from the scope of the examples described herein. As another example, although Figure 1 Each access domain that is authorized to access via identity simulation is shown to be configured with a dedicated hardware identity simulator, but other configurations may be used without departing from the scope of the examples described herein. Such other configurations may include, but are not limited to: the hardware identity simulator is configured for and dedicated to the access domain that authorizes access rights, rather than the access domain that receives access rights; and / or the hardware identity simulator is configured for and dedicated to more than one access domain. Therefore, the examples disclosed herein should not be limited to Figure 1 Configuration of the components shown in .

[0069] Figure 2 is a block diagram of an example hardware identity simulator 200 according to one or more examples described herein. In some examples, the hardware identity simulator 200 is Figure 1 Any of the hardware identity simulators 108, 110, 112 shown in and described above. Figure 2 As shown, the hardware identity simulator 200 includes an access domain identity data structure 202 and entries 204 described below. For clarity, other components of the hardware identity simulator 200 (eg, circuitry that implements the functionality of the hardware identity simulator 200) are omitted.

[0070] In some examples, the access domain identity data structure 202 is any type of data structure (e.g., a table) implemented in one or more hardware components of the hardware identity simulator 200. In some examples, the access domain identity data structure 202 includes any number of entries 204. In some examples, the entry 204 includes any number of information items. For example, the entry 204 can be a row in a table. The entry 204 can include, but is not limited to, an address of a target resource (e.g., a target resource address), an access domain identifier, and a valid indicator. In some examples, the target resource address is a target that identifies the access domain to which the access domain has access rights (e.g., Figure 1 In some examples, the access domain identifier is an identifier of an access domain and / or engine that has access rights to the location indicated by the target resource address associated with it (e.g., in the same row as in Figure 2In some examples, the valid indicator is an indication of whether a particular entry 204 is valid at a given point in time. Each of the target resource address, access domain identifier, and valid indicator portion of the particular entry 204 can be any form of data (e.g., one or more bits).

[0071] In some examples, the hardware identity simulator 200, and therefore the access domain identity data structure 202 therein, is associated with a set of one or more access domains and / or engines. In some examples, each entry 204 in the entries 204 is associated with an access domain and / or engine. A portion of the entries may be associated with such access domains and / or engines, where the hardware identity simulator 200 is associated with the access domains and / or engines and is configured for the access domains and / or engines. For example, the hardware identity simulator 200 may be associated with an access domain having an access domain identifier "A", and the first two rows of the entry 204 indicate that access domain A has access to target X and target Y, respectively. One of ordinary skill in the art will understand that in some examples, the first two entries, each having the access domain identifier A, may not be included in the access domain identity data structure 202 because the entry for the access domain with which the hardware identity simulator is associated may not be necessary. Other portions of the access domain identity data structure 202 (e.g., other entries in the entries 204) may be associated with a computing device (e.g., Figure 1 Associated with other access domains and / or engines of the computing device 100) shown in and described above.

[0072] For example, hardware identity simulator 200 may be configured to access domain A (eg, Figure 1 In this scenario, Figure 2 The first two lines of entry 204 shown in (which are optional as described above) are associated with the access domain. Therefore, the first two lines can be used for access domain A to access target resources to which it has access rights without simulating the identity of another access domain. Such entries not related to identity simulation for access domains associated with hardware identity simulators are optional. The third entry in entry 204 (in Figure 2 ) can be accessed by domain B (e.g. Figure 1 The third entry is associated with access domain B 104 of access domain B and is mostly blank because access domain B does not currently share access to any targets with access domain A. In one or more embodiments, the third entry includes access domain identifier B, which indicates that only access domain B can update the entry and that if access to the target resources of access domain B is granted to access domain A, then this access domain identifier B is also the identifier that will be used to allow access domain A to impersonate access domain B. The fourth entry in entry 204 is associated with access domain C (e.g., Figure 1 The access domain C 106) is associated with the Figure 2 As shown, access domain C wants access domain A to have access to zone Z1 of target Z to which access domain C has access rights. Therefore, access domain C has requested that the hardware identity simulator 200 be updated to have a fourth entry to be updated (which is associated with access domain C according to access domain identifier C) to include the address of zone Z1, access domain identifier C, and a valid indicator Yes. While this entry remains valid, but in this example, when access domain A sends an operation request including the address of zone Z1 to the hardware identity simulator 200, the hardware identity simulator 200 performs a lookup, finds the address of zone Z1, obtains the access domain identifier C, and replaces A's access domain identifier with the access domain identifier C when sending the operation request for further access control checking by one or more access rights check blocks (e.g., a memory management unit, a protection unit, etc.). In some examples, if the operation request includes a target address that is not included in the access domain identity data structure of the hardware identity simulator, the operation request can be passed to one or more access control check blocks with the access domain identifier of the access domain requesting the operation.

[0073] In some examples, when the hardware identity simulator 200 receives an operation request from an associated access domain, the hardware identity simulator 200 may use the address included in the operation request to perform a lookup in the access domain identity data structure 202. In some examples, when the access domain identity data structure 202 does not include the address, the operation request is rejected. In some examples, when the address is present in the access domain identity data structure 202, the operation request may continue. In some examples, when the address is associated with an access domain identifier of the access domain with which the hardware identity simulator 200 is associated, the hardware identity simulator 200 may pass the operation request intact to one or more access rights check blocks (e.g., a memory management unit) for further access control checks. In some examples, when the address is associated with an access domain identifier of an access domain other than the access domain with which the hardware identity simulator is associated and configured, the hardware identity simulator may modify the operation request before sending the operation request to the one or more access rights check blocks.

[0074] In some examples, the modification of the operation request includes replacing an identifier of an access domain requesting the operation received in the operation request with an access domain identifier included in an entry in entry 204 that corresponds to an address in the operation request used to perform a lookup in access domain identity data structure 202. Such a replacement can allow the access domain requesting the operation to effectively simulate the identity of the access domain identified by the access domain identifier, thereby allowing access to a target resource that would otherwise be blocked by access control technology. For example, such access can be allowed because various access permission check blocks (e.g., memory management unit, protection unit, etc.) receive the operation request including the simulated identity and allow operations based on the simulated identity. Therefore, identity simulation of one access domain to another access domain can allow sharing of target resources without reconfiguring the various access permission check blocks (e.g., memory management unit, protection unit, etc.).

[0075] In some examples, as described above, certain entries of entries 204 may be associated with access domains for which hardware identity simulator 200 is configured, while other entries in entries 204 may be associated with computing devices (e.g., Figure 1 In some examples, only the access domain associated with a particular entry in entries 204 can request an update to the particular entry. For example, in Figure 2 In the access domain identity data structure 202 configured for access domain A shown in , the third row can be updated only by access domain B, and the fourth row can be updated only by access domain C. In some examples, the explicit association between entries in entry 204 and access domains that have permission to request updates to those entries prevents access domains that do not have access rights to specific target resources from allowing access domains associated with hardware identity simulator 200 to access those specific target resources.

[0076] In some examples, for each entry 204 in the entry 204, the valid indicator portion of the access domain identity data structure 202 includes an indication of whether the entry is valid at a given time. In some examples, when access to a specific target area is intended to be allowed for an access domain associated with the hardware identity simulator 200, the access domain associated with the specific entry can request that the valid indicator be set to yes (or any other indication of validity). For example, when an entry is updated, the valid indicator can be set to yes, and when the requested service has been completed, the valid indicator can be set to no. Before an access domain associated with the hardware identity simulator 200 requests an operation using a specific target area, the valid indicator can be checked by the access domain. Upon receiving an operation request, the hardware identity simulator 200 can also verify the valid indicator. In some examples, if the valid indicator is set to no, the access domain associated with the hardware identity simulator 200 is not allowed to use the access domain identifier to simulate the identity of another access domain for the purpose of accessing the associated target resource address.

[0077] Figure 2 An example is shown in which the hardware identity simulator 200 is associated with access domain A. Thus, each entry in the access domain identity data structure 202 is implicitly associated with access domain A, which is an access domain for which other access domains can use the entries of the access domain identity table 202 to authorize access to targets. Each entry in the access domain identity data structure 202 may also be associated with another access domain that is authorizing access to a particular target and / or target area. This association may be represented by the access domain identifier portion of a particular entry, which is used to indicate the identity of the access domain that has authority to update the entry, and the identity that will be replaced with the identity of access domain A in order to allow access domain identity impersonation.

[0078] However, without departing from the scope of the examples described herein, other Figure 2. For example, a particular hardware identity simulator may be dedicated to an access domain that is authorizing target access to other access domains. In such a scenario, each entry in the access domain identity data structure is implicitly associated with an authorized access domain, and each entry may explicitly include a portion containing an identifier of the access domain to which access is to be authorized. When the authorized access domain updates the entry to include the target or an area therein, when the access domain authorized to access seeks to access the target, the hardware identity simulator may replace the identifier included in the entry identifying the access domain authorized to access the target with the identity of the authorized access domain. As another example, the hardware identity simulator may be configured for more than one access domain. In such a scenario, each entry may include a portion for explicitly including an identifier of the access domain that authorizes access to the target, and a portion for explicitly including an identifier of the access domain authorized to access. Each entry in such an access domain identity table (e.g., for two or more access domains) may be updated only by the authorized access domain identified by the identifier of the authorized access domain. When the hardware identity simulator receives a request to access a target from an access domain authorized to access, the hardware identity simulator may replace the identity of the access domain authorized to access the target with the identifier of the authorizing access domain, wherein both identifiers exist in the entry for authorizing the target to access.

[0079] Although Figure 2 A specific number of components in a specific configuration are shown, but one of ordinary skill in the art will appreciate that the hardware identity simulator 200 may include more components, fewer components, and / or components arranged in any number of alternative configurations without departing from the scope of the examples described herein. Figure 2 Although described above as being associated with a particular access domain, the hardware identity simulator may be associated with any number of access domains and / or any number of engines within an access domain, as discussed above, without departing from the scope of the examples described herein. As another example, although a given hardware identity simulator is described herein as enforcing which access domains may update certain entries, a computing device may include a separate enforcement component that is operably connected to one or more hardware identity simulators of the computing device and is configured to ensure that each entry in the access domain identity data structure is properly associated with an access domain that is authorized for target access and an access domain that authorizes said access and has permission to update the entry. Thus, the examples disclosed herein should not be limited to Figure 2 Configuration of the components shown in .

[0080] Figure 3 is a block diagram of an example memory management unit 300 according to one or more examples described herein. In some examples, the memory management unit 300 may be Figure 1 The memory management unit 114 is shown in FIG. Figure 3 As shown, the memory management unit 300 includes a memory management unit data structure 302 and entries 304 described below. For clarity, other components of the memory management unit 300 (eg, circuits implementing the functionality of the memory management unit 300) are omitted.

[0081] In some examples, the memory management unit 300 includes a memory management unit data structure 302, which includes entries 304. The memory management unit data structure 302 is intended as a simple example of a data structure in which access domains are associated with targets to which they have access rights. In the example memory management unit data structure 302, the first entry in the entries 304 includes access domain A (e.g., Figure 1 The domain ID A of the visited domain A 102) is associated with the target X (e.g., Figure 1 Target X 118) and Target Y (e.g., Figure 1 The target identifier of the target Y120) (in Figure 3 The association between the resource addresses). Figure 3 The example memory management unit data structure 302 also includes a second entry in the entry 304, the second entry including access domain B (eg, Figure 1 The domain ID B of the visited domain B 104) is associated with the target X (e.g., Figure 1 Target X 118) and Target Y (e.g., Figure 1 The target identifier of the target Y120) (in Figure 3 An association between access domains (referred to as resource addresses in the example) (e.g., indicating that access domain A and access domain B have access to the same target resource in this example). Figure 3 The example memory management unit data structure 302 also includes a third entry in the entry 304, the third entry including the access domain C (eg, Figure 1 The domain ID C of the visited domain C 106) is associated with the target X (e.g., Figure 1 Target X 118) and Target Z (e.g., Figure 1 The target identifier of the target Z 122) (in Figure 3 is called a resource address). Figure 3 The domain ID and resource address are shown as letters, but one of ordinary skill in the art will understand that any form of data (eg, bits) may be used to identify the access domain and target in the memory management unit data structure 302 .

[0082] In some examples, the memory management unit 300 is configured to receive from one or more hardware identity simulators (e.g., Figure 2The memory management unit 300 receives an operation request by means of a hardware identity simulator 200. In a scenario where access to a particular target resource is shared, such an operation request may include a simulated identity, which may be an identifier of an access domain that has access rights to the particular target resource, rather than an identifier of the access domain that initiated the operation request. Therefore, in some examples, the memory management unit 300 does not need to be reconfigured to be able to verify the operation request and allow the operation to proceed. In some examples, the memory management unit 300 is one of any number of access rights check blocks, and when an operation request is received, access control to the target resource is facilitated by performing an access rights check using a memory management unit data structure 302 to verify whether the domain ID included in the operation request is associated with the target resource that will be used by the operation to be performed.

[0083] Although Figure 3 A specific number of components in a specific configuration are shown, but one of ordinary skill in the art will appreciate that the memory management unit 300 may include more components or fewer components, and / or components arranged in any number of alternative configurations without departing from the scope of the examples described herein. Therefore, the examples disclosed herein should not be limited to Figure 3 Configuration of the components shown in .

[0084] Figure 4 is a block diagram of an example protection unit 400 according to one or more examples described herein. In some examples, the protection unit 400 may be Figure 1 The protection unit 116 shown in FIG. Figure 4 As shown, protection unit 400 includes protection unit data structure 402 and entries 404 described below. For clarity, other components of protection unit 400 (eg, circuits implementing the functionality of protection unit 400) are omitted.

[0085] In some examples, protection unit 400 includes a protection unit data structure 402, which includes entries 404. Protection unit data structure 402 is intended as a simple example of a data structure in which certain target resources are associated with one or more access domains having access rights to the target resources. In example protection unit data structure 402, the first entry in entries 404 includes a target resource X (e.g., Figure 1 The association between the target resource X 118) and the access domains associated with the identifiers A, B, and C indicates that each of these access domains has access rights to the target resource X. In the example protection unit data structure 402, the second entry in the entries 404 includes the target resource Y (e.g., Figure 1The association between the target resource Y 120) and the access domains associated with the identifiers A and B indicates that each of these access domains has access rights to the target resource Y. In the example protection unit data structure 402, the third entry in the entries 404 includes the target resource Z (e.g., Figure 1 An association between a target resource Z 122) and an access domain associated with identifier C, indicating that access domain C has access rights to target resource Z. Figure 3 The domain ID and resource address are shown as letters, but one of ordinary skill in the art will understand that any form of data (eg, bits) may be used to identify the access domain and target in the memory management unit data structure 302 .

[0086] In some examples, protection unit 400 is configured to receive data from one or more memory management units (e.g., Figure 3 The protection unit 400 receives an operation request from a memory management unit 300. In a scenario where access to a specific target resource is shared, such an operation request may include an impersonation identity, which may be an identifier of an access domain that has access rights to the specific target resource, rather than an identifier of the access domain that initiated the operation request. In some examples, the protection unit 400 does not need to be reconfigured to be able to verify the operation request and allow the operation to proceed. In some examples, the protection unit 400 is one of any number of access rights check blocks, and when an operation request is received, access control to the target resource is facilitated by performing an access rights check using a protection unit data structure 402 to verify whether the domain ID included in the operation request is associated with the target resource that the operation to be performed will use.

[0087] Although Figure 4 A specific number of components in a specific configuration are shown, but one of ordinary skill in the art will appreciate that the protection unit 400 may include more components or fewer components, and / or components arranged in any number of alternative configurations without departing from the scope of the examples described herein. Figure 4 Configuration of the components shown in .

[0088] Figure 5 An example computing device 500 according to one or more examples described herein is shown. The following example is for explanation purposes only and is not intended to limit the scope of the examples described herein. In addition, although this example illustrates certain aspects of the examples described herein, all possible aspects of these examples may not be shown in this particular example.

[0089] According to various aspects described herein, the computing device 500 can implement access control to a target resource. The computing device 500 can be connected to Figure 1The access domains 502, 506, and 508 may be the same as or substantially similar to the computing device 100 shown in FIG. Figure 1 The access domains 102, 104, and 106 shown in FIG. 1 and described above are the same or substantially similar. In this example scenario, access domain A 502 includes an engine 504 that is configured to request that an operation be performed using a target resource. Hardware ID simulators 512, 514, and 516 may be associated with Figure 1 The hardware identity simulators 108, 110 and 112 shown in and described above and / or Figure 2 The hardware identity simulator 200 shown in FIG. 1 and described above is the same or substantially similar. In this example scenario, an access domain identity data structure (e.g., similar to Figure 2 The access permission check block 518 may be any hardware component of the computing device 500 for implementing access control techniques. For example, the access permission check block 518 may be or include a memory management unit (e.g., Figure 1 The memory management unit 114 or Figure 3 300) and a protection unit (e.g., Figure 1 Protection unit 116 or Figure 4 Targets 520, 522, and 524 may be associated with Figure 1 Targets 118 , 120 , and 122 shown in and described above are the same or substantially similar.

[0090] Figure 5 The example scenario shown in FIG. 5 is intended, in part, to illustrate a scenario in which access domain B 506 needs to share access to target X 520 with access domain A 502. To this end, access domain B 506 has issued a request to hardware ID simulator A 512 associated with access domain A to update an entry associated with access domain B 504 therein. Based on the request, hardware ID simulator A 512 has updated Figure 5 The first entry shown in the access domain identity data structure is shown to include the resource address X, the access domain identifier B, and the valid indicator Yes. Therefore, while the entry is still valid, an operation request to access the target X 520 made by, for example, the engine A 504 of the access domain A 502 may be allowed, and when sending the operation request to the access permission check block 518, the hardware simulator A 512 may replace the access domain identifier A with the access domain identifier B, thereby allowing the operation request to proceed as if it was initiated by the access domain B 506 instead of the access domain A 502. Therefore, the access permission check block 518 does not need to reconfigure the access to the target X 520 shared by the access domain A 502 and the engine A 504 from the access domain B 506.

[0091] Figure 5 The example scenario shown in FIG. 5 is also intended in part to illustrate a scenario in which access domain C 506 needs to share access to zone Z1 of target Z 524 with access domain A 502. To this end, access domain C 506 has issued a request to hardware ID simulator A 512 associated with access domain A to update an entry associated with access domain C 508 therein. Based on the request, hardware ID simulator A 512 has updated Figure 5 The second entry shown in the access domain identity data structure shown is to include the resource address Z1, the access domain identifier C, and the valid indicator Yes. Therefore, while the entry is still valid, an operation request to access the region Z1 of the target Z 524, for example, made by the engine A 504 of the access domain A 502, can be allowed, and when sending the operation request to the access permission check block 518, the hardware simulator A 512 can replace the access domain identifier A with the access domain identifier C, thereby allowing the operation request to proceed as if it was initiated by the access domain C 508 instead of the access domain A 502. Therefore, the access permission check block 518 does not need to reconfigure the access to the region Z1 of the target Z 524 shared by the access domain A 502 and the engine A 504 from the access domain C 508.

[0092] Figure 5 The example scenario shown in is also intended in part to illustrate a scenario in which the computing device 500 includes an access domain D 510 that is considered an untrusted domain and does not have access to target X 520, target Y 522, or target Z 524. Therefore, the access domain D 510 does not have an associated entry in the hardware ID simulator A 512, the hardware ID simulator B 514, or the hardware ID simulator C 516. Therefore, the access domain D 510 may not update an entry in any hardware ID simulator, and therefore may not allow other access domains to access any target. In addition, the access permission check block 518 will deny operation requests from the access domain D 510 that attempt to access target X 520, target Y 522, and / or target Z 524.

[0093] Figure 6 An example environment 600 according to one or more examples described herein is shown. The following example is for explanation purposes only and is not intended to limit the scope of the examples described herein. In addition, although the example illustrates certain aspects of the examples described herein, all possible aspects of these examples may not be shown in this particular example.

[0094] Figure 6 The environment 600 shown in FIG. 6 depicts an example scenario in which a computing device (not shown for clarity) is implementing access control to a target resource. The computing device may be associated with Figure 1 The access domains 602 and 604 may be the same as or substantially similar to the computing device 100 shown in FIG. 1 and described above. Figure 1 The access domains 102, 104, and 106 shown in FIG. 1 and described above are the same or substantially similar. The hardware ID simulator 608 may be used with Figure 1 The hardware identity simulators 108, 110 and 112 shown in and described above and / or Figure 2 The hardware identity simulator 200 shown in FIG. 1 and described above is the same or substantially similar. In this example scenario, an access domain data identity structure (e.g., similar to Figure 2 The access permission check block 610 may be any hardware component of a computing device for implementing access control techniques. For example, the access permission check block 610 may be or include a memory management unit (e.g., Figure 1 The memory management unit 114 or Figure 3 300) and a protection unit (e.g., Figure 1 Protection unit 116 or Figure 4 Target Z 612 can be connected to Figure 1 Targets 118, 120, and 122 shown in and described above are the same or substantially similar. Target Z 612 in this example scenario includes target area Z1 614.

[0095] exist Figure 6 In the example scenario of , access domain C 604 wishes to verify the integrity of data stored in target zone Z1 614. However, the ability to perform integrity verification is included in the engine (not shown) of access domain A 602. Therefore, access domain C 604 first requests to update the entry in the access domain identity table of hardware ID simulator A 608 configured for access domain A 602. The second entry in the access domain identity table can be updated only by access domain C 604. In response to the request, hardware ID simulator A 608 updates the second entry to include resource address 0x5400 (which is the address of target zone Z1 614 within target Z 612) and access domain identifier C and valid indicator yes. Additionally or alternatively, after access domain C 604 updates the second entry and requests access domain A 602 to perform integrity verification, access domain A 604 can check the relevant entry in hardware ID simulator A 608 to confirm that the second entry is correctly configured with the identifier and address of access domain C, and if so, set the valid indicator to yes.

[0096] Access domain C 604 may then send a request for integrity verification to access domain A 602, the request including an indication that access domain C 602 has made the necessary updates to the access domain identity table of hardware ID simulator A 608 to allow access domain A 602 to access target zone Z1 614. The request also provides the address 0x5400 of target zone Z1 614. Next, access domain A 602 verifies that the entry associated with access domain C in the access domain identity table of hardware ID simulator A includes a valid indicator of yes. After successfully verifying the valid indicator, access domain A 602 issues an operation request to hardware ID simulator A 608. The operation request includes the following bus attributes: read operation; address 0x5400; A's access domain ID; transaction number (TXN) ABC; and a return port associated with engine A (which is the engine that will perform the integrity verification).

[0097] Next, the hardware ID simulator 608 performs a lookup on the address 0x5400 received in the operation request and finds the address in a valid entry in the access domain identity table. Based on the successful lookup, the hardware ID simulator 608 modifies the operation request to include access domain ID C instead of access domain ID A, and a return port associated with the hardware ID simulator 608 to allow the result of the read operation to be routed back to the hardware ID simulator 608. The hardware ID simulator A 608 then sends the operation request to the access permission check block 610. The memory management unit of the access permission check block 610 performs a first access control check on the operation request, which passes because the access domain identifier in the operation request is C and access domain C has access rights to target Z 612, which includes target region Z1 614 at address 0x5400. The protection unit of the access right check block 610 performs a second access control check on the operation request, which passes because the access domain identifier in the operation request is C, and access domain C has access rights to target Z 612, which includes target region Z1 614 at address 0x5400.

[0098] After the successful first access control check and second access control check of the access rights check block 610, a read operation is sent to the target Z 612, and the data in the target region Z1 614 at address 0x5400 is obtained and made available to the engine of the access domain A 602 to perform the integrity verification requested by the access domain C. The engine performs a hash function with the data as input to obtain a hash of the data, compares the hash with the hash of the data previously generated, and reports a successful match to the access domain C 604, thereby completing the service requested by the access domain C. After the service is completed, the access domain C 604 sends a request to the hardware ID simulator to delete the entry that allows the access domain A to access the target region Z1 614. In this scenario, by using the hardware simulator A 608, no reconfiguration of the access rights check block 610 is required, thereby reducing complexity and improving the access time required for the access domain C 604 to share access to the target region Z1 614 with the access domain A 602.

[0099] Figure 7 is a flow chart illustrating an example of a process 700 for identity simulation in an access control system according to examples described herein. The process 700 may be performed at least in part by, for example Figure 1 Any of the hardware identity simulators 108, 110, and 112 shown in and described above and / or Figure 2 The hardware identity simulator 200 shown in and described above is executed.

[0100] At block 702, process 700 includes: in a hardware identity simulator (e.g., Figure 1 108, 110, 112) from a first access domain (e.g., Figure 1 The access domain 102, 104, 106) receives (for example, Figure 1 A request that a target area of ​​a target 118, 120, 122) be accessible by a second access domain. In some examples, an access domain is a collection of one or more engines for performing any number of operations using information stored in any number of targets and / or target areas. In some examples, a target or any area therein is any device, component, etc. that includes any number of data that can be operated on by any number of access domains and / or engines therein. For example, a particular access domain may seek to cause another access domain to perform an operation. In such an example, a particular access domain may request to update an entry in an access domain identity table to allow other access domains to access a particular target by impersonating the identity of the particular access domain.

[0101] At block 704, process 700 includes updating, at the hardware identity simulator, a second access domain identity data structure to include an entry corresponding to the first access domain, wherein the entry includes an address of the target area and the first access domain identifier. In some examples, the entry can be configured such that only the first access domain can cause an update to the entry. In some examples, once the entry is configured, the second access domain can verify the configuration of the entry and, if valid, set a valid indicator to indicate the validity of the entry (e.g., based on the presence of an entry with the address and the correct access domain identifier).

[0102] At block 706, process 700 includes receiving, at the hardware identity simulator, an access request from a second access domain to access a target area, wherein the access request includes a second access domain identifier and an address of the second access domain. For example, an access domain that has been requested by another access domain to perform an operation using information stored in a target associated with, controlled by, or the like, the other domain may send a request to access a specific target to perform an operation. In some examples, the address is used to perform a lookup in an access domain identity table.

[0103] At block 708, process 700 includes sending, at the hardware identity simulator, an address and a first access domain identifier to a memory management unit (MMU) of the access control system based on the access request. In some examples, including the first access domain identifier allows the second access domain to simulate the first access domain to various access permission check blocks such as the MMU in order to access the address included in the request.

[0104] In some examples, process 700 or any other process described herein can be performed by a computing device or apparatus and / or one or more components therein and / or to which the computing device is operably connected. As an example, process 700 can be performed in whole or in part by Figure 1 Any of the hardware identity simulators 108, 110, and 112 shown in and described above and / or Figure 2 The hardware identity simulator 200 shown in and described above is executed

[0105] The hardware identity simulator can be any suitable device, including any suitable device, or a component of any suitable device, such as a vehicle or a computing device of a vehicle (e.g., a driver monitoring system (DMS) of a vehicle), a mobile device (e.g., a mobile phone), a desktop computing device, a tablet computing device, a wearable device (e.g., a VR headset, an AR headset, an AR glasses, a network-connected watch or smartwatch or other wearable device), a server computer, a robotic device, a television, a smart speaker, a voice assistant device, a SoC, and / or any other device having resource capabilities to perform the processes described herein (including process 700 and / or other processes described herein). In some cases, a computing device or apparatus (e.g., including a hardware identity simulator) may include various components, such as one or more input devices, one or more output devices, one or more processors, one or more microprocessors, one or more microcomputers, one or more cameras, one or more sensors, and / or other components configured to perform the operations of the processes described herein. In some examples, a computing device may include a display, a network interface configured to transmit and / or receive data, an RF sensing component, any combination thereof, and / or other components. The network interface may be configured to transmit and / or receive data based on an Internet Protocol (IP) or other types of data.

[0106] The components of the hardware identity simulator may be implemented at least in part in circuits. For example, the components may include and / or may be implemented using electronic circuits or other electronic hardware, which may include one or more programmable electronic circuits (e.g., a microprocessor, a graphics processing unit (GPU), a digital signal processor (DSP), a central processing unit (CPU), and / or other suitable electronic circuits), and / or may include and / or be implemented at least in part using computer software, firmware, or any combination thereof to perform the various operations described herein.

[0107] Figure 7 The process 700 shown in is shown as a logical flow diagram, the operations of which represent a sequence of operations that can be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations represent computer-executable instructions stored on one or more computer-readable storage media, which perform the operations when executed by one or more processors. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform specific functions or implement specific data types. The order in which the operations are described is not intended to be construed as a limitation, and any number of the described operations may be combined in any order and / or in parallel to implement the process.

[0108] In addition, process 700 and / or other processes described herein can be performed under the control of one or more computer systems configured with executable instructions, and can be implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is executed together on one or more processors, implemented by hardware, or a combination thereof. As described above, the code can be stored on a computer-readable or machine-readable storage medium, for example, in the form of a computer program including multiple instructions that can be executed by one or more processors. The computer-readable or machine-readable storage medium can be non-transitory.

[0109] Figure 8 is a schematic diagram showing an example of a system for implementing certain aspects of the technology herein. Specifically, Figure 8 An example of a computing system 800 is shown, which may be any computing device, for example, constituting an internal computing system, a remote computing system, a camera, or any components thereof, wherein the components of the system communicate with each other using connection 805. Connection 805 may be a physical connection using a bus, or a direct connection into processor 810 (such as in a chipset architecture). Connection 805 may also be a virtual connection, a network connection, or a logical connection.

[0110] In some examples, computing system 800 is a distributed system, where the functionality described in the present disclosure can be distributed across a data center, multiple data centers, a peer-to-peer network, etc. In some examples, one or more of the described system components represent a number of such components, each of which performs some or all of the functionality for which the component is described. In some examples, these components can be physical or virtual devices.

[0111] The example system 800 includes at least one processing unit (CPU or processor) 810 and connections 805 coupling various system components including system memory 815, such as read-only memory (ROM) 820 and random access memory (RAM) 825, to the processor 810. The computing system 800 may include a cache 812 of high-speed memory that is directly connected to the processor 810, close to the processor 810, or integrated as part of the processor 810.

[0112] Processor 810 may include any general purpose processor and hardware or software services configured to control processor 810, such as services 832, 834, and 836 stored in storage device 830, as well as special purpose processors where software instructions are incorporated into the actual processor design. Processor 810 may essentially be a completely self-contained computing system, including multiple cores or processors, buses, memory controllers, caches, etc. Multi-core processors may be symmetric or asymmetric.

[0113] To enable user interaction, the computing system 800 includes an input device 845 that can represent any number of input mechanisms, such as a microphone for voice, a touch-sensitive screen for gesture or graphical input, a keyboard, a mouse, motion input, voice, and the like. The computing system 800 may also include an output device 835, which may be one or more of a plurality of output mechanisms. In some cases, a multimodal system may enable a user to provide multiple types of input / output to communicate with the computing system 800. The computing system 800 may include a communication interface 840, which may generally govern and manage user input and system output. The communication interface may use a wired and / or wireless transceiver to perform or facilitate receiving and / or sending wired or wireless communications, including those that utilize the following: audio jacks / plugs, microphone jacks / plugs, universal serial bus (USB) ports / plugs, Port / plug, Ethernet port / plug, Optical port / plug, Proprietary wired port / plug, BLUETOOTH Wireless signal transmission, Low Energy (BLE) wireless signal transmission, Wireless signal transmission, radio frequency identification (RFID) wireless signal transmission, near field communication (NFC) wireless signal transmission, dedicated short range communication (DSRC) wireless signal transmission, 802.11 Wi-Fi wireless signal transmission, wireless local area network (WLAN) signal transmission, visible light communication (VLC), world interoperability for microwave access (WiMAX), infrared (IR) communication wireless signal transmission, public switched telephone network (PSTN) signal transmission, integrated services digital network (ISDN) signal transmission, 3G / 4G / 5G / LTE cellular data network wireless signal transmission, ad hoc network signal transmission, radio wave signal transmission, microwave signal transmission, infrared signal transmission, visible light signal transmission, ultraviolet light signal transmission, wireless signal transmission along the electromagnetic spectrum, or some combination thereof. The communication interface 840 may also include one or more global navigation satellite system (GNSS) receivers or transceivers for determining the location of the computing system 800 based on receiving one or more signals from one or more satellites associated with one or more GNSS systems. GNSS includes, but is not limited to, the United States' Global Positioning System (GPS), Russia's Global Navigation Satellite System (GLONASS), China's BeiDou Navigation Satellite System (BDS), and Europe's Galileo GNSS. There is no restriction on the operation of any particular hardware arrangement, and thus the basic features herein may be easily replaced with improved hardware or firmware arrangements as they are developed.

[0114] The storage device 830 may be a non-volatile and / or non-temporary and / or computer-readable memory device, and may be a hard disk or other type of computer-readable medium that can store data accessible by a computer, such as a cassette, a flash memory card, a solid-state memory device, a digital versatile disk, a magnetic cassette, a floppy disk, a floppy disk, a hard disk, a magnetic tape, a magnetic strip, any other magnetic storage medium, a flash memory, a memristor memory, any other solid-state memory, a compact disc read-only memory (CD-ROM) disc, a rewritable compact disc (CD) disc, a digital video disc (DVD) disc, a Blu-ray disc (BDD) disc, a holographic disc, another optical medium, a secure digital (SD) card, a micro secure digital (microSD) card, card, a smart card chip, an EMV chip, a subscriber identity module (SIM) card, a mini / micro / nano / pico SIM card, another integrated circuit (IC) chip / card, a random access memory (RAM), a static RAM (SRAM), a dynamic RAM (DRAM), a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a flash EPROM (FLASHEPROM), a cache memory (L1 / L2 / L3 / L4 / L5 / L#), a resistive random access memory (RRAM / ReRAM), a phase change memory (PCM), a spin-transfer torque RAM (STT-RAM), another memory chip or tape cartridge, and / or a combination thereof.

[0115] Storage device 830 may include software services, servers, services, etc., which cause the system to perform functions when the code defining such software is executed by processor 810. In some examples, hardware services that perform a particular function may include software components stored in a computer-readable medium connected to the necessary hardware components (such as processor 810, connection 805, output device 835, etc.) for performing the function.

[0116] As used herein, the term "computer-readable medium" includes, but is not limited to, portable or non-portable storage devices, optical storage devices, and various other media capable of storing, containing or carrying instructions and / or data. Computer-readable media may include non-transitory media in which data may be stored and does not include the following: carrier waves and / or temporary electronic signals propagated wirelessly or on a wired connection. Examples of non-transitory media may include, but are not limited to: disks or tapes, optical storage media such as compact discs (CDs) or digital versatile discs (DVDs), flash memory, memory, or memory devices. Computer-readable media may have codes and / or machine-executable instructions stored thereon, which may represent any combination of procedures, functions, subroutines, programs, routines, subroutines, modules, software packages, classes, or instructions, data structures, or program statements. A code segment may be coupled to another code segment or hardware circuit by passing and / or receiving information, data, independent variables, parameters, or memory contents. Any suitable means including memory sharing, message passing, token passing, network transmission, etc. may be used to pass, forward, or send information, independent variables, parameters, data, etc.

[0117] In some examples, computer-readable storage devices, media, and memories may include cables or wireless signals containing bit streams, etc. However, when referred to, non-transitory computer-readable storage media explicitly excludes media such as energy, carrier signals, electromagnetic waves, and signals themselves.

[0118] Specific details are provided in the above description to provide a thorough understanding of the examples and examples provided herein. However, it will be appreciated by those of ordinary skill in the art that examples can be implemented without these specific details. For clarity of explanation, in some cases, the technology herein may be presented as including separate functional blocks, which include functional blocks, which include devices, device components, operations, steps or routines in methods embodied in software, hardware or a combination of hardware and software. In addition to the components shown in the figures and / or described herein, additional components may also be used. For example, circuits, systems, networks, processes and other components may be shown as components in block diagram form so as not to obscure examples in unnecessary details. In other cases, known circuits, processes, algorithms, structures and techniques may be shown as not having unnecessary details so as to avoid obscuring examples.

[0119] Each example may be described as a process or method above, and the process or method is depicted as a flow chart, a flow diagram, a data flow chart, a structure diagram or a block diagram. Although the flow chart can describe the operation as a sequential process, many of these operations can be performed in parallel or concurrently. In addition, the order of the operation can be rearranged. The process terminates when its operation is completed, but may have additional operations that are not included in the figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to the function returning to a calling function or a main function.

[0120] The process and method according to the above examples can be implemented using computer executable instructions, which are stored in computer readable media or can be obtained from computer readable media in other ways. Such instructions may include, for example, instructions or data, which cause a general-purpose computer, a special-purpose computer or a processing device to perform or otherwise be configured to perform a specific function or a specific group of functions. The part of the computer resources used may be accessible through a network. Computer executable instructions may be, for example, binary files, intermediate format instructions such as assembly language, firmware, source code, etc. Examples of computer readable media that can be used to store instructions, information used, and / or information created during the method according to the described examples include disks or optical disks, flash memory, USB devices equipped with non-volatile memory, networked storage devices, etc.

[0121] The equipment implementing the process and method according to these disclosures may include hardware, software, firmware, middleware, microcode, hardware description language or any combination thereof, and may adopt any of various form factors. When implemented with software, firmware, middleware or microcode, the program code or code segment (e.g., computer program product) for performing the necessary tasks may be stored in a computer-readable or machine-readable medium. The processor may perform the necessary tasks. Typical examples of form factors include personal computers, personal digital assistants, rack-mounted devices, stand-alone devices, etc., of laptop computers, smart phones, mobile phones, tablet devices or other small form factors. The functions described herein may also be embodied in peripheral devices or plug-in cards. By further example, this function may also be implemented on circuit boards between different chips or different processes executed in a single device.

[0122] Instructions, media for transmitting such instructions, computing resources for executing them, and other structures for supporting such computing resources are example means for providing the functionality described in this disclosure.

[0123] In the foregoing description, various aspects of the present application are described with reference to the specific examples of the present application, but those skilled in the art will recognize that the present application is not limited thereto. Therefore, although the illustrative examples of the present application have been described in detail herein, it will be understood that the inventive concept can be embodied and adopted differently in other ways, and the appended claims are intended to be interpreted as including such variations, except for variations as limited by the prior art. Various features and aspects of the above-mentioned applications can be used individually or in combination. Further, without departing from the broader spirit and scope of this specification, the examples described herein can be utilized in any number of environments and applications other than the environments and applications described herein. Therefore, the description and the accompanying drawings are considered to be illustrative rather than restrictive. For the purpose of illustration, the method is described in a specific order. It should be understood that in an alternative example, the method can be performed in an order different from the described order.

[0124] One of ordinary skill will appreciate that the less than ("<") and greater than (">") symbols or terms used herein may be replaced with the less than or equal to ("≤") and greater than or equal to ("≥") symbols, respectively, without departing from the scope of the present description.

[0125] Where a component is described as being “configured to” perform certain operations, such configuration may be achieved, for example, by designing an electronic circuit or other hardware to perform the operation, by programming a programmable electronic circuit (e.g., a microprocessor or other suitable electronic circuit) to perform the operation, or any combination thereof.

[0126] The phrase "coupled to" refers to any component that is physically connected to another component, directly or indirectly, and / or any component that communicates directly or indirectly with another component (e.g., connected to another component via a wired or wireless connection and / or other suitable communication interface).

[0127] Claim language or other language that recites "at least one of" in a set and / or "one or more of" in a set indicates that one member of the set or multiple members of the set (in any combination) satisfies the claim. For example, claim language that recites "at least one of A and B" or "at least one of A or B" means A, B, or A and B. In another example, claim language that recites "at least one of A, B, and C" or "at least one of A, B, or C" means A, B, C, or A and B, or A and C, or B and C, or A and B and C. The language "at least one of" in a set and / or "one or more of" in a set does not limit the set to the items listed in the set. For example, claim language that recites "at least one of A and B" or "at least one of A or B" may mean A, B, or A and B, and may additionally include items not listed in the set of A and B.

[0128] Various illustrative logic blocks, modules, circuits and algorithmic operations described in conjunction with the examples disclosed herein can be implemented as electronic hardware, computer software, firmware or a combination thereof. In order to clearly illustrate this interchangeability of hardware and software, various illustrative components, frames, modules, circuits and operations have been generally described above around their functions. Whether this function is implemented as hardware or software depends on specific applications and the design constraints imposed on the entire system. Those skilled in the art can implement the described functions in different ways for each specific application, but this implementation decision should not be interpreted as causing a departure from the scope of the application.

[0129] The technology described herein can also be implemented with electronic hardware, computer software, firmware, or any combination thereof. Such technology can be implemented in any of a variety of devices, such as a general-purpose computer, a wireless communication device mobile phone, or an integrated circuit device with multiple uses (including applications in wireless communication devices and other devices). Any features described as modules or components can be implemented together in an integrated logic device, or as separate but interoperable logic devices. If implemented with software, the technology can be implemented at least in part by a computer-readable data storage medium, which includes a program code, and the program code includes instructions for executing one or more of the above methods when executed. The computer-readable data storage medium can form a part of a computer program product, and the computer program product can include packaging materials. The computer-readable medium can include a memory or a data storage medium, such as a random access memory (RAM) (such as a synchronous dynamic random access memory (SDRAM)), a read-only memory (ROM), a non-volatile random access memory (NVRAM), an electrically erasable programmable read-only memory (EEPROM), a flash memory, a magnetic or optical data storage medium, etc. Additionally or alternatively, the techniques may be implemented at least in part by a computer-readable communication medium (such as a propagated signal or wave) that carries or communicates program code in the form of instructions or data structures and that can be accessed, read, and / or executed by a computer.

[0130] The program code can be executed by a processor, which may include one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application-specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuits. Such a processor can be configured to perform any technology described in this disclosure. A general-purpose processor can be a microprocessor, but in an alternative, the processor can be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, a combination of one or more microprocessors and a DSP core, or any other such configuration. Therefore, the term "processor" as used herein may refer to any of the aforementioned structures, any combination of the aforementioned structures, or any other structure or device suitable for implementing the technology described herein.

[0131] Illustrative aspects of the disclosure include:

[0132] Aspect 1: A method for identity simulation in an access control system, the method comprising: receiving a request from a first access domain at a hardware identity simulator to make a target area accessible to a second access domain; updating a second access domain identity data structure at the hardware identity simulator to include an entry corresponding to the first access domain, wherein the entry includes an address of the target area and a first access domain identifier; receiving an access request from the second access domain at the hardware identity simulator to access the target area, wherein the access request includes a second access domain identifier and an address of the second access domain; and sending the address and the first access domain identifier to a memory management unit (MMU) of the access control system at the hardware identity simulator based on the access request.

[0133] Aspect 2: A method according to Aspect 1, wherein the second access domain obtains access to the target area based on a successful first access control check of the MMU and a successful second access control check of the protection unit of the access control system, and wherein the successful first access control check and the successful second access control check are at least partially based on the address of the target area and the first access domain identifier.

[0134] Aspect 3: The method according to Aspect 1 or 2 further includes: before sending the address and the first access domain identifier, performing the following operation: at the hardware identity simulator, using the address to perform a search in the second access domain identity data structure to obtain the first access domain identifier.

[0135] Aspect 4: The method according to any one of aspects 1-3, wherein: the access request is a read request; and obtaining access to the target area includes: allowing the engine of the second access domain to perform a read from the target area.

[0136] Aspect 5: The method according to any one of aspects 1-4, wherein: the access request is a write request; and obtaining access to the target area includes: allowing the engine of the second access domain to perform writing to the target area.

[0137] Aspect 6: The method according to any one of aspects 1-5, wherein the access request corresponds to an operation to be performed by a second access domain execution engine of the second access domain using data from the target area.

[0138] Aspect 7: The method according to any one of Aspects 1-6 further includes: after the second access domain execution engine performs the operation, performing the following operations: receiving a second request to delete the entry from the first access domain at the hardware identity simulator; and deleting the entry from the second access domain identity data structure at the hardware identity simulator, wherein deleting the entry removes access to the target area from the second access domain.

[0139] Aspect 8: The method according to any one of aspects 1-7, wherein the operation to be performed by the second access domain execution engine is requested by the first access domain execution engine of the first access domain.

[0140] Aspect 9: The method according to any one of Aspects 1-8 further includes: receiving a second request from a third access domain at the hardware identity simulator to make a second target area accessible to the second access domain; determining at the hardware identity simulator that the third access domain does not have access to the second target area; and rejecting the second request based on determining that the third access domain does not have access to the second target area.

[0141] Aspect 10: The method according to any one of Aspects 1-9 further includes: receiving a second request from a third access domain at the hardware identity simulator to make a second target area accessible to the second access domain; determining at the hardware identity simulator that the third access domain is an untrusted access domain; and rejecting the second request based on determining that the third access domain is the untrusted access domain.

[0142] Aspect 11: The method according to any one of aspects 1-10, wherein the entry further comprises a validity indicator, and the access request is sent based at least in part on the validity indicator.

[0143] Aspect 12: The method according to any one of Aspects 1-11, wherein the access request includes the address, size and operation type, and the method further comprises: sending the size and the operation type to the MMU at the hardware identity simulator.

[0144] Aspect 13: A device for identity simulation in an access control system, the device comprising: at least one memory; and at least one processor, coupled to the at least one memory and configured to: receive a request from a first access domain via a hardware identity simulator to make a target area accessible to a second access domain; update a second access domain identity data structure at the hardware identity simulator to include an entry corresponding to the first access domain, wherein the entry includes an address of the target area and a first access domain identifier; receive an access request from the second access domain at the hardware identity simulator to access the target area, wherein the access request includes a second access domain identifier and an address of the second access domain; and send the address and the first access domain identifier from the hardware identity simulator to a memory management unit (MMU) of the access control system based on the access request.

[0145] Aspect 14: An apparatus according to Aspect 13, wherein the second access domain obtains access to the target area based on a successful first access control check by the MMU and a successful second access control check by a protection unit of the access control system, and wherein the successful first access control check and the successful second access control check are at least partially based on the address of the target area and the first access domain identifier.

[0146] Aspect 15: An apparatus according to Aspect 13 or 14, wherein the at least one processor is further configured to: before sending the address and the first access domain identifier, perform the following operations: at the hardware identity simulator, use the address to perform a lookup in the second access domain identity data structure to obtain the first access domain identifier.

[0147] Aspect 16: An apparatus according to any one of Aspects 13-15, wherein: the access request is a read request; and in order to obtain access to the target area, the at least one processor is further configured to: allow the engine of the second access domain to perform a read from the target area.

[0148] Aspect 17: An apparatus according to any one of Aspects 13-16, wherein: the access request is a write request; and in order to obtain access to the target area, the at least one processor is further configured to: allow the engine of the second access domain to perform a write to the target area.

[0149] Aspect 18: The apparatus of any of Aspects 13-17, wherein the access request corresponds to an operation to be performed by a second access domain execution engine of the second access domain using data from the target area.

[0150] Aspect 19: An apparatus according to any one of Aspects 13-18, wherein the at least one processor is further configured to: after the second access domain execution engine executes the operation, perform the following operations: receive a second request to delete the entry from the first access domain via the hardware identity simulator; and delete the entry from the second access domain identity data structure at the hardware identity simulator, wherein deleting the entry removes access to the target area from the second access domain.

[0151] Aspect 20: The apparatus according to any one of aspects 13-19, wherein the operation to be performed by the second access domain execution engine is requested by the first access domain execution engine of the first access domain.

[0152] Aspect 21: An apparatus according to any one of Aspects 13-20, wherein the at least one processor is further configured to: receive a second request from a third access domain via the hardware identity simulator to make a second target area accessible to the second access domain; determine via the hardware identity simulator that the third access domain does not have access to the second target area; and reject the second request based on determining that the third access domain does not have access to the second target area.

[0153] Aspect 22: An apparatus according to any one of Aspects 13-21, wherein the at least one processor is further configured to: receive a second request from a third access domain via the hardware identity simulator to make a second target area accessible to the second access domain; determine via the hardware identity simulator that the third access domain is an untrusted access domain; and reject the second request based on determining that the third access domain is the untrusted access domain.

[0154] Aspect 23: The apparatus of any one of aspects 13-22, wherein the entry further comprises a validity indicator, and the access request is sent based at least in part on the validity indicator.

[0155] Aspect 24: An apparatus according to any one of Aspects 13-23, wherein the access request includes the address, size and operation type, and the at least one processor is further configured to: send the size and the operation type to the MMU via the hardware identity simulator.

[0156] Aspect 25: A non-temporary computer-readable medium having instructions stored thereon, which, when executed by one or more processors, cause the one or more processors to perform the following operations: receiving a request from a first access domain via a hardware identity simulator to make a target area accessible to a second access domain; updating a second access domain identity data structure at the hardware identity simulator to include an entry corresponding to the first access domain, wherein the entry includes an address of the target area and a first access domain identifier; receiving an access request from the second access domain at the hardware identity simulator to access the target area, wherein the access request includes a second access domain identifier and an address of the second access domain; and sending the address and the first access domain identifier to a memory management unit (MMU) of an access control system via the hardware identity simulator and based on the access request.

[0157] Aspect 26: A non-temporary computer-readable medium according to Aspect 25, wherein the second access domain obtains access to the target area based on a successful first access control check by the MMU and a successful second access control check by a protection unit of the access control system, and wherein the successful first access control check and the successful second access control check are based at least in part on the address of the target area and the first access domain identifier.

[0158] Aspect 27: The non-transitory computer-readable medium according to Aspect 25 or 26, having additional instructions stored thereon, which, when executed by the one or more processors, cause the one or more processors to perform the following operations before sending the address and the first access domain identifier: at the hardware identity simulator, use the address to perform a lookup in the second access domain identity data structure to obtain the first access domain identifier.

[0159] Aspect 28: The non-transitory computer-readable medium of any of Aspects 25-27, wherein the access request corresponds to an operation to be performed by a second access domain execution engine of the second access domain using data from the target area.

[0160] Aspect 29: The non-transitory computer-readable medium of any one of aspects 25-28, wherein the operation to be performed by the second access domain execution engine is requested by the first access domain execution engine of the first access domain.

[0161] Aspect 30: A non-temporary computer-readable medium according to any one of Aspects 25-29, wherein the access request includes the address, size, and operation type, and wherein the non-temporary computer-readable medium also includes additional instructions, which, when executed by the one or more processors, cause the one or more processors to perform the following operations: sending the size and the operation type to the MMU via the hardware identity simulator.

[0162] Aspect 31: An apparatus for identity simulation in an access control system, comprising one or more units for performing the operations according to any one of aspects 1-12.

Claims

1. A method for identity simulation in an access control system, the method comprising: receiving, at the hardware identity emulator, from the first access domain, a request to make the target area accessible to the second access domain; updating, at the hardware identity simulator, a second access domain identity data structure to include an entry corresponding to the first access domain, wherein the entry includes an address of the target area and a first access domain identifier; receiving, at the hardware identity simulator, an access request from the second access domain to access the target area, wherein the access request includes a second access domain identifier and an address of the second access domain; and The address and the first access domain identifier are sent, at the hardware identity emulator, to a memory management unit (MMU) of an access control system based on the access request.

2. The method according to claim 1, wherein: The second access domain obtains access to the target area based on a successful first access control check by the MMU and a successful second access control check by a protection unit of the access control system, and wherein the successful first access control check and the successful second access control check are based at least in part on the address of the target area and the first access domain identifier.

3. The method according to claim 1, further comprising: Before sending the address and the first visited domain identifier, perform the following operations: At the hardware identity simulator, a lookup is performed in the second visited domain identity data structure using the address to obtain the first visited domain identifier.

4. The method according to claim 1, wherein: The access request is a read request; and Obtaining access to the target area includes allowing an engine of the second access domain to perform a read from the target area.

5. The method according to claim 1, wherein: The access request is a write request; and Obtaining access to the target area includes allowing an engine of the second access domain to perform writes to the target area.

6. The method according to claim 1, wherein: The access request corresponds to an operation to be performed by a second access domain execution engine of the second access domain using data from the target region.

7. The method according to claim 6, further comprising: After the second access domain execution engine executes the operation, the following operations are performed: receiving, at the hardware identity simulator, from the first access domain, a second request to delete the entry; as well as The entry is deleted from the second access domain identity data structure at the hardware identity simulator, wherein deleting the entry removes access to the target area from the second access domain.

8. The method according to claim 6, wherein: The operation to be performed by the second access domain execution engine is requested by a first access domain execution engine of the first access domain.

9. The method according to claim 1, further comprising: receiving, at the hardware identity emulator, from a third access domain, a second request to make a second target area accessible to the second access domain; determining, at the hardware identity simulator, that the third access domain does not have access to the second target area; as well as The second request is denied based on a determination that the third visited domain does not have access to the second target area.

10. The method according to claim 1, further comprising: receiving, at the hardware identity emulator, from a third access domain, a second request to make a second target area accessible to the second access domain; Determining, at the hardware identity simulator, that the third access domain is an untrusted access domain; as well as The second request is denied based on a determination that the third access domain is the untrusted access domain.

11. The method according to claim 1, wherein: The entry also includes a valid indicator, and the access request is sent based at least in part on the valid indicator.

12. The method according to claim 1, wherein: The access request includes the address, size and operation type, and the method further includes: The size and the operation type are sent to the MMU at the hardware identity emulator.

13. A device for identity simulation in an access control system, the device comprising: at least one memory; as well as at least one processor coupled to the at least one memory and configured to: receiving, via the hardware identity emulator, from the first access domain a request to make a target area accessible to a second access domain; updating, at the hardware identity simulator, a second access domain identity data structure to include an entry corresponding to the first access domain, wherein the entry includes an address of the target area and a first access domain identifier; receiving, at the hardware identity simulator, an access request from the second access domain to access the target area, wherein the access request includes a second access domain identifier and an address of the second access domain; and The address and the first access domain identifier are sent from the hardware identity simulator to a memory management unit (MMU) of an access control system based on the access request.

14. The device according to claim 13, wherein: The second access domain obtains access to the target area based on a successful first access control check by the MMU and a successful second access control check by a protection unit of the access control system, and wherein the successful first access control check and the successful second access control check are based at least in part on the address of the target area and the first access domain identifier.

15. The device according to claim 13, wherein: The at least one processor is further configured to, before sending the address and the first visited domain identifier, perform the following operations: At the hardware identity simulator, a lookup is performed in the second visited domain identity data structure using the address to obtain the first visited domain identifier.

16. The apparatus of claim 13, wherein: The access request is a read request; and To obtain access to the target area, the at least one processor is further configured to allow an engine of the second access domain to perform a read from the target area.

17. The apparatus of claim 13, wherein: The access request is a write request; and To obtain access to the target area, the at least one processor is further configured to: allow an engine of the second access domain to perform a write to the target area.

18. The device according to claim 13, wherein: The access request corresponds to an operation to be performed by a second access domain execution engine of the second access domain using data from the target region.

19. The device according to claim 18, wherein: The at least one processor is further configured to: after the second access domain execution engine executes the operation, perform the following operations: receiving, via the hardware identity simulator, from the first access domain a second request to delete the entry; as well as The entry is deleted from the second access domain identity data structure at the hardware identity simulator, wherein deleting the entry removes access to the target area from the second access domain.

20. The device according to claim 18, wherein The operation to be performed by the second access domain execution engine is requested by a first access domain execution engine of the first access domain.

21. The device according to claim 13, wherein: The at least one processor is further configured to: receiving, from a third access domain via the hardware identity emulator, a second request to make a second target area accessible to the second access domain; determining, via the hardware identity simulator, that the third access domain does not have access to the second target area; as well as The second request is denied based on a determination that the third visited domain does not have access to the second target area.

22. The device according to claim 13, wherein: The at least one processor is further configured to: receiving, from a third access domain via the hardware identity emulator, a second request to make a second target area accessible to the second access domain; Determining, via the hardware identity simulator, that the third access domain is an untrusted access domain; as well as The second request is denied based on a determination that the third access domain is the untrusted access domain.

23. The device according to claim 13, wherein: The entry also includes a valid indicator, and the access request is sent based at least in part on the valid indicator.

24. The device according to claim 13, wherein: The access request includes the address, size, and operation type, and the at least one processor is further configured to: The size and the operation type are sent to the MMU via the hardware identity emulator.

25. A non-transitory computer readable medium having stored thereon instructions that, when executed by one or more processors, cause the one or more processors to: receiving, via the hardware identity emulator, from the first access domain a request to make a target area accessible to a second access domain; updating a second access domain identity data structure at the hardware identity simulator to include an entry corresponding to the first access domain, wherein: The entry includes an address of the target zone and a first visited domain identifier; receiving, at the hardware identity simulator, an access request from the second access domain to access the target area, wherein the access request includes a second access domain identifier and an address of the second access domain; as well as The address and the first access domain identifier are sent to a memory management unit (MMU) of an access control system via the hardware identity emulator and based on the access request.

26. The non-transitory computer readable medium of claim 25, wherein: The second access domain obtains access to the target area based on a successful first access control check by the MMU and a successful second access control check by a protection unit of the access control system, and wherein the successful first access control check and the successful second access control check are based at least in part on the address of the target area and the first access domain identifier.

27. The non-transitory computer readable medium of claim 25, having further instructions stored thereon that, when executed by the one or more processors, cause the one or more processors to, before sending the address and the first access domain identifier, perform the following operations: At the hardware identity simulator, a lookup is performed in the second visited domain identity data structure using the address to obtain the first visited domain identifier.

28. The non-transitory computer readable medium of claim 25, wherein: The access request corresponds to an operation to be performed by a second access domain execution engine of the second access domain using data from the target region.

29. The non-transitory computer readable medium of claim 28, wherein: The operation to be performed by the second access domain execution engine is requested by the first access domain execution engine of the first access domain.

30. The non-transitory computer readable medium of claim 25, wherein: The access request includes the address, size, and operation type, and wherein the non-transitory computer readable medium includes further instructions that, when executed by the one or more processors, cause the one or more processors to: The size and the operation type are sent to the MMU via the hardware identity emulator.

Images