Patent Description:
Maintaining security against unauthorized access of resources is an important consideration in SoC design. The complexity of an SoC raises conflicting security requirements. For example, on one hand, a high-level operating system ("HLOS") running on a processor in the SoC may need to be able to limit access to resources from entities running on other SoC processors. On the other hand, an SoC vendor may wish to limit access by the HLOS to such other SoC processors, as such access could potentially expose the SoC vendor's intellectual property. The main or system memory is generally the most substantial or significant resource, and commonly, the HLOS manages the entire system memory. A need may also exist for entities in different security domains to collaborate, and carving out the system memory map to dedicate portions of system memory to different security domains may be undesirable.

Security is commonly provided in an SoC-based device in one of two general ways. One way is to provide SoC hardware that controls security across all subsystems. A drawback of this approach is that it is not scalable. It is not flexible to add new security domains, and it may comprise subsystems security. Another way is to enable the HLOS to control security across all subsystems by providing a form of super-user entity. A drawback of this approach is that the security may be exposed to open source and may be compromised. Neither of these conventional solutions address the conflicting security concerns described above. Attention is drawn to <CIT> relating to providing a secure execution environment with a hosted computer. A security-enabled processor establishes a hardware-protected memory area with an activation state that executes only software identified by a client system. The hardware- protected memory area is inaccessible by code that executes outside the hardware-protected memory area. A certification is transmitted to the client system to indicate that the secure execution environment is established, in its activation state, with only the software identified by the request.

Systems, methods and computer program products are disclosed for resource access control in an SoC.

An exemplary method for resource access control in an SoC may include allocating a resource comprising a memory region to an access domain. An agent, such as an HLOS, may control or perform such allocation. The method may also include loading a software image associated with the access domain into the memory region. The HLOS or other agent may control or perform such loading. The method may further include locking the resource against access by any entity other than the access domain. A trust management engine may control or perform such locking. The method may still further include authenticating the software image associated with the access domain. The trust management engine may control or perform such authentication. The method may yet further include initiating booting of the access domain in response to a successful authentication of the software image. The trust management engine may initiate the booting.

An exemplary system for resource access control in an SoC may include an agent executing on a processor and a trust management engine. The agent may be configured to allocate a resource comprising a memory region to an access domain and to load a software image associated with the access domain into the memory region. The trust management engine may be configured to lock the resource against access by any entity other than the access domain, to authenticate the software image associated with the access domain, and to initiate booting of the access domain in response to a successful authentication of the software image associated with the access domain.

Another exemplary system for resource access control in an SoC may include means for allocating a resource comprising a memory region to an access domain and for loading a software image associated with the access domain into the memory region. The exemplary system may further include means for locking the resource against access by any entity other than the access domain, for authenticating the software image associated with the access domain, and for initiating booting of the access domain in response to a successful authentication of the software image.

An exemplary computer program product for resource access control in an SoC may comprise a computer-readable medium having stored thereon instructions that when executed on one or more processors of the SoC control a method. The method may include allocating a resource comprising a memory region to an access domain. The method may also include loading a software image associated with the access domain into the memory region. The method may further include locking the resource against access by any entity other than the access domain. The method may still further include authenticating the software image associated with the access domain. The method may yet further include initiating booting of the access domain in response to a successful authentication of the software image.

" The word "illustrative" may be used herein synonymously with "exemplary.

As illustrated in <FIG>, in an illustrative or exemplary embodiment, a PCD <NUM> may include an SoC <NUM>. The SoC <NUM> may include one or more processors <NUM> and one or more other bus masters <NUM>. Although a bus or similar system interconnect is not shown in <FIG> for purposes of clarity, the term "bus master" is used in this disclosure to mean any component that is capable of initiating a bus transaction. A group of one or more bus masters may be referred to in this disclosure as an access domain or "AD. " For example, the group of two bus masters <NUM> in <FIG> may form an AD <NUM>.

The PCD <NUM> is intended only as an example of a device in which the SoC <NUM> may be included. More generally, examples of devices that may include an SoC in accordance with the present disclosure include: a computing system (e.g., server, datacenter, desktop computer), a mobile or portable computing device (e.g., laptop, cell phone, vehicle, etc.), an Internet of Things ("IoT") device, a virtual reality ("VR") system, an augmented reality ("AR") system, etc..

The processor <NUM> may also be referred to as a CPU, an application processor, etc., because in this exemplary embodiment the processor <NUM> may execute, among other software elements (not shown for purposes of clarity), a high-level operating system ("HLOS") <NUM>. The term "HLOS" as used in this disclosure is intended to broadly encompass not only an HLOS but also a hypervisor, an HLOS in combination with a hypervisor, etc. An action performed or controlled by the processor <NUM> under the control of, or configured by, execution of the HLOS <NUM> may, for brevity of description, be referred to in this disclosure as an action performed by the HLOS <NUM>. Similarly, an action performed or controlled by other processing hardware under the control of, or configured by, execution of any other software entity may, for brevity of description, be referred to in this disclosure as an action performed by such other software entity. Also, although for purposes of clarity the HLOS <NUM> is shown in <FIG> separately from other bus masters <NUM>, it should be noted that the HLOS <NUM> is also a bus master (and thus is also a type of AD).

The SoC <NUM> may include system resources <NUM>. The system resources <NUM> include the components and portions thereof of the PCD <NUM> to which a bus master, such as the HLOS <NUM>, other bus masters <NUM>, etc., may direct bus transactions. Stated another way, a "bus transaction," as the term is used in this disclosure, relates to a request for a system resource <NUM>, such as a read request or a write request. Accordingly, the system resources <NUM> may be identified by addresses or address ranges within a system address space. Although for purposes of clarity in <FIG> the system resources <NUM> are depicted as being within the SoC <NUM>, in other embodiments any or all such system resources may be external to an SoC. The system resources <NUM> may include, for example, dynamic random-access memory ("DRAM"), such as double data-rate DRAM ("DDR-DRAM"). Such DDR-DRAM (or, for brevity, "DDR") may provide the main system memory of the PCD <NUM>, and a CPU or other processor <NUM> may execute applications (i.e., software) in such DDR. The system resources <NUM> may include other types of memory, such as, for example, flash memory, static RAM ("SRAM"), etc. The system resources <NUM> may include various registers, ports, and other addressable components. Note that as the system resources <NUM> are the subjects of transaction requests from bus masters, the system resources <NUM> may also be referred to as the subjects of transaction requests from ADs, as an AD is an entity comprising one or more bus masters.

For example, a first system resource 112A may comprise a first region of memory, a second system resource 112B may comprise a second region of memory, etc. Although only two system resources 112A and 112B are shown for purposes of example, any number of system resources <NUM> may be allocated in the system address space. Except as otherwise described in this disclosure, system resources <NUM> may be requested, allocated, and de-allocated in accordance with conventional computing principles well understood by one of ordinary skill in the art. For example, in response to certain operating conditions, a bus master <NUM> may initiate a request for a system resource <NUM>. The present disclosure relates to systems and methods for controlling access to such a system resource <NUM>, as conceptually indicated by the broken-line arrow in <FIG>.

A trust management engine ("TME") <NUM> is a component that is involved in the access control system and method. To promote security, the TME <NUM> may be primarily embodied in hardware separate from the processor <NUM> on which the HLOS <NUM> executes, such as another processor, read-only memory ("ROM"), etc. (not separately shown in <FIG>). The TME <NUM> may employ an authentication agent (not separately shown) that uses cryptographic methods to authenticate a software image. Such an authentication agent may be of a conventional type and is therefore not described in this disclosure. Although for purposes of clarity the TME <NUM> is shown in <FIG> separately from other bus masters <NUM> and the HLOS <NUM>, it should be noted that the TME <NUM> is also a bus master (and thus also a type of AD).

A protection unit <NUM> may be configured to selectively protect system resources <NUM>. There may be various types of protection units, each associated with a component capable of serving as or providing a resource. The term "xPU" may be used in this disclosure to refer broadly to any of a number of types ("x") of protection units associated with corresponding types of components. For example, an xPU associated with a memory may be referred to as a memory protection unit.

As illustrated in <FIG>, a system <NUM> may include two or more bus masters 202A, 202B, 202C, etc. While a portion of each of bus masters 202A, 202B, 202C, etc., may comprise hardware, one or more of bus masters 202A, 202B, 202C, etc., may also include a software portion. For example, a first bus master 202A may comprise a CPU 204A, which may execute a HLOS 206A. The CPU 204A may be an example of the above-described processor <NUM> (<FIG>). A second bus master 202B may, for example, comprise a hardware engine 204B and a software portion that may be referred to in this disclosure as an intelligent and trusted entity ("ITE") 206B. Similarly, a third bus master 202C may comprise a hardware engine 204C and a software portion 206C. The second and third bus masters 202B and 202C may together form an access domain or AD 208B, such as the AD <NUM> described above with regard to <FIG>. In an AD having two or more bus masters, the software portion of at least one of the bus masters is an ITE; software portions of other bus masters need not be ITEs. For example, the AD 208B may be a modem, where the bus masters 202B and 202C are scalar and vector modem cores, respectively. Although in this exemplary embodiment a modem comprises two bus masters 202B and 202C, in other embodiments a modem may, like other ADs, consist of only one bus master. Note that the first bus master 202A also forms an AD 208A. As the AD 208A is characterized by the HLOS 206A in execution, such an AD may be referred to for convenience in this disclosure as the HLOS, similarly to the HLOS <NUM> in <FIG>.

The bus masters 202A, 202B, 202C, etc., may be configured to access resources via corresponding memory management units ("xMMUs") 210A, 210B, 210C, etc. The term "xMMU" may be used in this disclosure to refer broadly to an MMU of any of a number of types ("x") of MMUs associated with corresponding types of components, such as, for example, system memory (in contrast with another level or type of memory). Although for purposes of clarity in <FIG> each of bus masters 202A, 202B, and 202C is shown coupled to exactly one corresponding xMMU 210A, 210B, and 210C, in other examples (not shown) there may be additional elements through which a bus master may access resources, such as two or more stages of xMMUs.

Each of a number of bus slaves <NUM>, such as bus slaves 212A and 212B, may serve as or provide corresponding system resources <NUM> (<FIG>), such as memory, registers, ports, etc. Although two bus slaves 212A and 212B are shown, the system <NUM> may include any number of bus slaves <NUM>. Each of the bus slaves 212A, 212B, etc., may be coupled to a system interconnect (e.g., a bus system) <NUM>. The above-described xMMUs 210A, 210B, 210C, etc., are also coupled to the system interconnect <NUM>. Each AD 208A, 208B, etc., may thus access a resource by participating in a bus transaction via the system interconnect <NUM>.

Each of the bus slaves <NUM> that may provide system resources <NUM> (<FIG>) is protected by a corresponding xPU <NUM>, such as xPUs 214A and 214B. An xPU <NUM> may be an example of the protection unit <NUM> described above with regard to <FIG>. An xPU <NUM> may be configured to protect or prevent access to system resources <NUM> provided by the bus slaves <NUM> in a manner described below.

As illustrated in <FIG>, a system memory map <NUM> represents regions in a system memory, which may be referred to in this disclosure as resource groups ("RG"s) <NUM>. A region in a system memory (e.g., DDR), is an example of a system resource <NUM> (<FIG>). Note that the terms "resource," "system resource," and "resource group" (or "RG") may be used essentially synonymously in this disclosure, with the term "resource group" (or "RG") being used in some instances to more specifically refer to a resource that has been allocated to an AD. As described below in further detail, an RG may be allocated to an AD by setting access permissions that allow the AD to access (i.e., complete a read or write transaction with) the RG. The term "owned by" (an AD) also may be used in this disclosure to refer to an RG that has been allocated to an AD. A resource that is owned by or allocated to an AD may also be referred to as belonging to, being part of, etc., the AD. As the term is used in this disclosure, "to allocate" an RG to an AD means not only to allocate the RG in a conventional sense (e.g., by defining or setting aside memory space) but also to make the AD an owner of the RG. An RG may only be accessed by an AD that owns that RG. An attempt to access an RG by any entity other than an owner of that RG is prevented or blocked by the associated xPU. In the exemplary embodiments described herein, a default or initial state (e.g., upon booting the PCD <NUM>) may be that the HLOS <NUM> (<FIG>) owns all system resources <NUM>; other ADs, including the TME <NUM>, cannot access any resources until such time as resources may be allocated to such other ADs.

In <FIG> the system memory map <NUM> illustrates an example in which various RGs 302A, 302B, etc., through 302N (collectively referred to as RGs <NUM>) have been allocated to ADs. The remainder of the system memory map <NUM> represents system resources that have not been explicitly allocated to ADs and therefore, in accordance with the exemplary embodiment described herein, remain owned by the HLOS. RGs <NUM> may be located anywhere in the memory address range, and the locations depicted in <FIG> are intended only as examples.

As illustrated in <FIG>, an xPU application program interface ("API") <NUM>, shown in conceptual form, represents an example of various configuration settings that an AD may provide to the xPU to configure or control how the xPU operates. The xPU API <NUM> may have two portions: a per-RG configuration portion <NUM> through which an AP may provide the xPU with configuration settings for (i.e., specific to ) each RG, and a global configuration portion <NUM> through which aspects of xPU operation not specific to any RG may be configured.

The per-RG configuration portion <NUM> provides or programs the xPU with an RG configuration <NUM> that configures the xPU for one of a number of RGs (e.g., "RG_0" through "RG_M," where M is a fixed number defining a maximum supported number (M+<NUM>) of RGs). Each RG configuration <NUM> may include an address range <NUM>, access permissions comprising read permissions <NUM> and write permissions <NUM>, and an RG enable setting <NUM>. In this exemplary embodiment, the xPU allows only the HLOS to set an RG configuration <NUM>, and such allowance is subject to the lock feature described below. The xPU in this embodiment blocks any attempt from any entity other than the HLOS to set an RG configuration <NUM>. For example, the xPU blocks any attempt by another AD, the TME, etc., to set an address range <NUM>, a read permission <NUM>, a write permission <NUM>, or the RG enable setting <NUM>. In other embodiments (not described herein), a feature may be provided to allow other ADs to set RG configurations. For example, although in the exemplary embodiment described herein the HLOS by default owns all unallocated system resources protected by the xPU, in other embodiments a mode setting may be provided in the global configuration portion <NUM> through which the HLOS may select whether such ownership occurs by default or must occur by explicit allocation of RGs to the HLOS.

Using an address range <NUM> provided by the HLOS, the xPU may identify or define an RG that the xPU is to protect. For example, the HLOS may define one of the RGs <NUM> described above with regard to <FIG> by providing a beginning address and ending address that the RG <NUM> spans.

The RG enable setting <NUM> may be a single bit that the HLOS may provide to enable the xPU to begin protecting the RG defined by the address range <NUM>. For example, an RG enable setting <NUM> having a value of "<NUM>" may enable the xPU to apply the permissions <NUM> and <NUM> as described below, while an RG enable setting <NUM> having a value of "<NUM>" may indicate to the xPU that the RG has been disabled, i.e., the permissions <NUM> and <NUM> are not (or are no longer) applicable. Also, the HLOS may, in effect, return an RG to a pool of available resources by setting the RG enable setting <NUM> to indicate that the permissions <NUM> and <NUM> are no longer applicable. In the exemplary embodiment described herein, an RG must be returned to the pool of available resources before the HLOS may allocate that RG to another AD.

The read permissions <NUM> and write permissions <NUM> may be provided in the form of one read-enable ("RD_EN") bit per AD and one write-enable ("WR EN") bit per AD, respectively. For example, the read permissions <NUM> for an RG may include bits "AD_0:RD_EN" through "AD_N:RD_EN" for the corresponding ADs (where N is a fixed number defining a maximum supported number (N+<NUM>) of ADs). Likewise, the write permissions <NUM> may include bits "AD_0:WR_EN" through "AD_N:WR_EN" for the corresponding ADs. For example, a read-enable bit having a value of "<NUM>" may configure the xPU to enable (or not prevent) completion of a read transaction initiated by the corresponding AD directed to the RG, and a read-enable bit having a value of "<NUM>" may configure the xPU to prevent completion of a read transaction initiated by the corresponding AD directed to the RG. Likewise, a write-enable bit having a value of "<NUM>" may configure the xPU to enable completion of a write transaction initiated by the corresponding AD directed to the RG, and a write-enable bit having a value of "<NUM>" may configure the xPU to prevent completion of a write transaction initiated by the corresponding AD directed to the RG.

An AD owns or has been allocated an RG if at least one bit in the read permissions <NUM> or at least one bit in the write permissions <NUM> indicates that the AD is permitted to access the RG. Note that through the read permissions <NUM> and write permissions <NUM> an AD may be provided with both read and write permission, read-only permission, etc., thereby controlling the type of access the AD may have to a particular RG.

Each transaction request that an AD generates may include an AD identifier, i.e., a value uniquely identifying that AD. The bits of the read and write permissions <NUM> and <NUM> may be indexed by the AD identifiers. When the xPU receives a transaction request, the xPU may compare the AD identifier included in a transaction request with the corresponding bit value in the read permission <NUM> or write permission1112, and then based on the comparison either enable or prevent completion of the requested transaction.

The per-RG configuration portion <NUM> further provides the xPU with RG configuration lock bit groups <NUM>. Each RG configuration lock bit group <NUM> corresponds to one of the above-described RG configurations <NUM>. Each RG configuration lock bit group <NUM> may consist of a number of lock bits <NUM> equal to the number of ADs. That is, each AD corresponds to one lock bit <NUM>. For example, a first lock bit <NUM> ("AD_0: LOCK") corresponds to a first AD, a second lock bit <NUM> ("AD_1: LOCK") corresponds to a second AD, etc., though an Nth lock bit ("AD_N: LOCK") that corresponds to an Nth AD. As the HLOS and TME are types of ADs, one of the lock bits <NUM>, such as, for example, the first lock bit <NUM>, may correspond to the HLOS, and another of the lock bits <NUM>, such as, for example, the second lock bit <NUM>, may correspond to the TME.

The xPU allows a lock bit <NUM> to be set only by the corresponding AD. That is, the xPU blocks or ignores any attempt to set a lock bit <NUM> by any entity other than the AD corresponding to that lock bit <NUM>. Each lock bit <NUM> can have a value indicating a state of "locked" or a state of "unlocked. " The terms "locked" and "unlocked" refer to the RG configuration <NUM>; setting one or more lock bits <NUM> in an RG configuration lock bit group <NUM> to a value indicating a "locked" state configures the xPU to prevent any entity from modifying the corresponding RG configuration <NUM>. That is, an RG configuration <NUM> is locked or cannot be modified when any one or more lock bits <NUM> in the group <NUM> corresponding to that RG configuration <NUM> are set. By setting its corresponding lock bit <NUM>, an AD can establish trust in an RG configuration <NUM> by preventing any other AD, including the HLOS, TME, etc. from thereafter modifying the RG configuration <NUM>.

The xPU allows a lock bit <NUM> in a group <NUM> to be set by the corresponding AD only if that AD owns the RG corresponding to that group <NUM>. If an AD attempts to lock an RG configuration <NUM> in which the AD has no permissions to access the RG, the xPU blocks the attempt from succeeding.

The SoC <NUM> (<FIG>) may perform a cold boot or hardware-based reset to become ready for normal or "mission-mode" operation, which may include providing resource access control in the manner described below. Such a cold boot may involve entities that are not directly relevant to the present disclosure, such as one or more bootloaders. Accordingly, such details are not described herein. Nevertheless, it may be useful to understand that the one or more bootloaders (which may be stored in ROM) are executed on the CPU <NUM> to load the HLOS <NUM> into a system memory (i.e., in system resources <NUM>) and boot the HLOS <NUM>. A bootloader may load the HLOS <NUM> into system memory by, for example, copying the HLOS <NUM> (software image) from flash or other non-volatile memory. As a result, the HLOS <NUM> begins to execute. In some examples, a bootloader may load a secure execution environment ("SEE") or other intermediary software, which in turn loads and boots the HLOS <NUM>. As understood by one of ordinary skill in the art, a SEE (sometimes referred to as a trusted execution environment or "TEE") comprises software that, generally in conjunction with secure processor hardware, isolates trusted applications running in the SEE from untrusted applications running on the main (untrusted) HLOS. Nevertheless, in the context of the present disclosure a SEE is mentioned only as an example of intermediary software that may be loaded before the HLOS is loaded, and embodiments need not include a SEE or other intermediary software. Then, as described below, the HLOS <NUM> in turn may load and boot one or more other ADs <NUM>. The TME <NUM> may boot contemporaneously with the HLOS <NUM>. It should be noted that the TME <NUM> (and any SEE) may take ownership of resources in essentially the same manner described below with regard to any other AD <NUM>. In this manner, the HLOS <NUM> may establish trust in the TME <NUM> (and any SEE).

As illustrated in <FIG>, a method <NUM> for resource access control in an SoC may comprise booting an AD, such as, for example, any of the above-described ADs <NUM> (<FIG>) or 208B (<FIG>). As indicated by block <NUM>, the HLOS <NUM> or other agent may allocate a resource to the AD. As described above, the resource may be, for example, a memory region in which the AD is to execute. In an exemplary embodiment, allocating a resource in accordance with block <NUM> may include configuring access permissions in an xPU protecting the resource to enable the AD to access the resource. For example, the access permissions may be configured to give an AD read permission, write permission, or both read and write permission. Allocating the resource may also include configuring the access permissions so that the TME <NUM> (<FIG>) has sufficient access permission (e.g., read-only) to perform the authentication described below. With this exception for the TME <NUM>, the access permissions are configured to prevent access to the resource by any AD other than the AD that is being booted.

Although in the exemplary embodiments described herein the agent that performs or controls the allocation of resources is the HLOS <NUM>, in other embodiments an agent other than an HLOS may perform or control the allocation of resources or a portion of such allocation. For example, in other embodiments an HLOS may perform some aspects of the resource allocation described herein, such as allocating address ranges, while another agent configures the access permissions.

As indicated by block <NUM>, the HLOS <NUM> or other agent may load a software image associated with the AD into the memory region (resource). The software image may be an ITE and may be obtained from ROM or another source.

As indicated by block <NUM>, the TME <NUM> (<FIG>) may then lock the resource against access by any entity other than the AD that is being booted, with the exception that the TME <NUM> may have sufficient access permission to perform the authentication described below. In an exemplary embodiment, locking the resource against access in accordance with block <NUM> may comprise locking a resource configuration by setting a lock bit in the xPU protecting the resource. As the access permissions may have been configured by the HLOS <NUM> or other agent as described above (block <NUM>), locking the resource configuration thereby locks the resource itself against access in accordance with those access permissions. Note that locking the resource configuration in this manner locks the access permissions against modification by the HLOS <NUM> (<FIG>).

As indicated by block <NUM>, the TME <NUM> may authenticate the software image associated with the AD that has been loaded into memory and locked. As indicated by block <NUM>, upon successful authentication of that software image, the TME <NUM> may initiate (or if booting has already begun, take no action to prevent continuation of) booting of the AD. As indicated by block <NUM>, the booting AD may then lock the resource against access by any entity other than itself. Thus the resource may be locked against access by the TME <NUM> and the HLOS <NUM>. In an exemplary method described below with regard to <FIG>, the AD locking the resource may be conditioned upon successful validation of the resource by the AD and upon removal of the TME's permission to access the resource.

In examples in which an AD includes two or more bus masters, each having a software portion, the operations described above with regard to blocks <NUM>-<NUM> may be performed upon the software image that is the ITE, such as the above-described ITE 206B (<FIG>). In such examples, booting the AD may result in the ITE 206B beginning to operate or execute on its associated hardware engine (where the ITE 206B and associated hardware engine 204B together function as the first bus master 202B), and the ITE in turn initiating booting of a second bus master 202C by performing the operations described above with regard to blocks <NUM>-<NUM> on a second software image. In an example in which the AD includes three bus masters (not shown), a second bus master may boot a third bus master, etc. Note that the second and third bus masters in such an example may boot independently of the TME; the TME need only boot the first bus master.

As illustrated in <FIG>, a method <NUM> for resource access control in an SoC may comprise booting an AD. The method <NUM> may be an example of the above-described method <NUM> (<FIG>).

As indicated by block <NUM>, the HLOS may read AD boot requirements, such as, for example, memory requirements for an AD (e.g., number of partitions and size of each partition), clock/power requirements for an AD, etc. As indicated by block <NUM>, the HLOS may allocate one memory partition for the AD. The memory partition is HLOS-owned at this time, and is physically contiguous. As indicated by block <NUM>, the HLOS may load (i.e., copy) the AD software image from a non-volatile memory into the AD memory partition. The HLOS may also load any bootloader associated with the AD into the memory partition.

An AD may or may not be of a type having a privacy characteristic. "Privacy" in this context refers to third-party content that only the AD should be able to read. This content may be stored in encrypted form in flash memory, and the HLOS may load the encrypted content into its dedicated partition in system memory. This region may be decrypted by the AD's primary bootloader after the AD has booted up. If the AD has privacy, then as indicated by block <NUM> the HLOS may create two RGs: one RG for the AD's primary boot loader, and another RG for the rest of the AD memory allocation. If the AD does not have privacy, then as indicated by block <NUM> the HLOS may create one RG for the AD's entire memory allocation.

As indicated by block <NUM>, the HLOS may then configure the AD's boot vector register. The HLOS may also configure the xPU(s) protecting the AD's register space. For example, the HLOS may use the xPU API <NUM> (<FIG>) to configure the xPU(s) with an RG configuration <NUM>. The RG configuration may include access permissions for the AD to have read and write access to the RG. The RG configuration may also include access permissions for the TME to have read access to the RG so that the TME can perform the authentication described below. As indicated by block <NUM>, the HLOS may then send a request to the TME to boot the AD. As described above, booting the AD encompasses booting all bus masters in the AD.

As indicated by block <NUM>, the TME locks the AD's one or more RG configurations by setting its lock bit in the corresponding xPUs. In the context of the locking feature, to "set" a lock bit means setting the RG configuration to a "locked" state, and to "clear" a lock bit means setting the RG configuration to an "unlocked" state. The TME may read the memory allocation information and confirm that the xPU configurations are correct. Note that setting the TME's lock bit prevents any entity, including the HLOS, the TME, etc., from modifying the RG configuration.

As indicated by block <NUM>, the TME may then authenticate the software image, such as, for example, by authenticating the software image's signature. The authentication may be performed in a conventional manner using cryptographic techniques (e.g., keys), as understood by one of ordinary skill in the art. If the TME determines that the authentication succeeded, the TME may initiate booting of the AD, as indicated by block <NUM>. This may include the TME enabling boot resources and releasing the AD from reset, so that the AD is enabled or allowed to boot. As described above, ADs commonly include subsystems with dedicated processors and clock/power domains. "Releasing an AD from reset" means doing all the necessary hardware configuration to bring the AD subsystem and processor out of a reset state. While hardware portions of the AD become active in the foregoing manner, the AD software image or software portion of the AD begins to boot or execute in the memory region or partition into which it was loaded.

As indicated by block <NUM>, once the AD starts executing, it may validate its one or more RGs by inspecting the RG configuration in the xPU. An AD is always permitted to inspect (i.e., read) RG configurations, such as the above-described RG configuration <NUM> (<FIG>), including RG access permissions. If the validation of an RG configuration is successful, the AD may set its corresponding lock bit. The validation is successful if the AD confirms that its RG access permissions conform to the AD's expectations. For example, an AD may generally expect the RG access permissions to indicate that the RG is owned by that AD only, i.e., no entity other than that AD is permitted to access that RG. If the RG access permissions allow an unexpected entity access to the RG, then the AD rejects the RG configuration as invalid (i.e., the validation fails) and halts the boot. As the AD in this example has just begun to boot (i.e., execute), the AD may expect the TME to still have read access (but not write access) to the RG.

On successful RG configuration validation, and after the AD has set its corresponding lock bit, the AD may notify the TME. As indicated by block <NUM>, the TME may clear its lock bit when it receives this notification from the AD. Clearing of the TME's lock bit for an RG may trigger the xPU to automatically (i.e., without intervention by the HLOS or other entity) also remove the TME's access permissions for that RG, as the TME's clearing of its lock bit indicates the TME no longer requires access to the RG. As the AD's lock bit remains set, the RG configuration is locked against access by the TME, the HLOS, and any other AD that does not own the RG. As indicated by block <NUM>, the AD may then continue booting.

If the TME determines (block <NUM>) that the authentication failed, the TME may unlock the one or more RG configurations associated with the RG containing the AD's software image, and signal the HLOS that the boot operation failed, as indicated by block <NUM>. The TME may also control a hardware reset signal (not shown) applied to the AD's hardware engine, and may only release the hardware reset signal if the authentication succeeds.

As illustrated in <FIG>, a method <NUM> for resource access control in an SoC may comprise allocating an additional resource to an AD, such as, for example, any of the above-described ADs <NUM> (<FIG>) or 208B (<FIG>). As indicated by block <NUM>, the AD may transmit a request for one or more additional resources to the HLOS. "Additional" in this context means in addition to the memory space in which the AD's software image resides and which was allocated to the AD when the AD was booted. As indicated by block <NUM>, the HLOS may then allocate the additional resource or resources to the requesting AD. As indicated by block <NUM>, the AD may then, by setting a lock bit of the corresponding xPU, lock the RG configuration associated with the additional resource against access by any entity other than the requesting AD. Note that locking the resource in this manner locks the resource against access by the HLOS, the TME, and any other entity other than the requesting AD.

As illustrated in <FIG>, a method <NUM> for resource access control in an SoC may comprise allocating an additional resource to an AD. The method <NUM> may be an example of the above-described method <NUM> (<FIG>).

As indicated by block <NUM>, the AD may transmit a request for one or more additional resources to the HLOS. The request may include, for example, an amount of memory space being requested, as well as access permissions being requested. As indicated by block <NUM>, the HLOS may determine if the requested resource is available. If the requested resource is not available, the HLOS may notify the AD that the request is rejected, as indicated by block <NUM>. If the requested resource is available, the HLOS may allocate a new RG, as indicated by block <NUM>. Allocating the new RG may include providing or programming the xPU protecting the resource with an RG configuration, which may include an RG address range, access permissions, etc. For example, the HLOS may use the xPU API <NUM> (<FIG>) to configure the xPU with an RG configuration <NUM>. Then, the HLOS may return a pointer to the newly created RG to the requesting AD, as indicated by block <NUM>.

As indicated by block <NUM>, the requesting AD may lock the RG and inspect the RG configuration to determine whether it is "valid" or "invalid. " As described above with regard to block <NUM> (<FIG>), an AD may consider an RG configuration to be valid if the RG access permissions are as per the AD's expectations. For example, if the AD expects no other entity to have access to the resource, then the RG access permissions should allow only that AD to have access to the resource. If the RG access permissions allow any other entity access to the resource, then AD rejects the RG configuration as invalid. If the RG configuration is "invalid," the AD may remove the lock and notify the HLOS that the RG is rejected, as indicated by block <NUM>. If the RG configuration is "valid," the AD may begin using the RG, as indicated by block <NUM>.

As illustrated in <FIG>, a method <NUM> for resource access control in an SoC may comprise de-allocating an additional resource that had been allocated to an AD, such as by the above-described method <NUM> (<FIG>) or <NUM> (<FIG>). As indicated by block <NUM>, an AD may unlock the resource. As indicated by block <NUM>, the AD may then notify the HLOS that the resource is now free.

As illustrated in <FIG>, a method <NUM> for resource access control in an SoC may comprise de-allocating an additional resource that had been allocated to an AD. The method <NUM> may be an example of the above-described method <NUM> (<FIG>).

As indicated by block <NUM>, an AD may zero out memory space that had been allocated for an RG. Zeroing out memory space erases data that could otherwise be susceptible to unauthorized access and thus provides additional security or privacy that may be desirable in some embodiments. As indicated by block <NUM>, the AD may unlock the RG. As indicated by block <NUM>, the AD may then notify the HLOS that the RG is now free and can be returned to the pool or list of "unused" RGs. As indicated by block <NUM>, the HLOS may disable the RG and return it to the pool. "Disabling an RG" means the xPU no longer uses this RG for access control. The HLOS may disable the RG using the RG enable setting <NUM> of the xPU API <NUM> (<FIG>).

As illustrated in <FIG>, exemplary embodiments of systems and methods for resource access control may be embodied in a PCD <NUM>. The PCD <NUM> includes an SoC <NUM>. The SoC <NUM> may include a CPU <NUM>, a GPU <NUM>, a DSP <NUM>, an analog signal processor <NUM>, or other processors. The CPU <NUM> may include multiple cores, such as a first core 1004A, a second core 1004B, etc., through an Nth core 1004N. The CPU <NUM> or any of its cores may be an example of the above-described processor <NUM> (<FIG>) or CPU 204A (<FIG>).

A display controller <NUM> and a touchscreen controller <NUM> may be coupled to the CPU <NUM>. A touchscreen display <NUM> external to the SoC <NUM> may be coupled to the display controller <NUM> and the touchscreen controller <NUM>. The PCD <NUM> may further include a video decoder <NUM> coupled to the CPU <NUM>. A video amplifier <NUM> may be coupled to the video decoder <NUM> and the touchscreen display <NUM>. A video port <NUM> may be coupled to the video amplifier <NUM>. A universal serial bus ("USB") controller <NUM> may also be coupled to CPU <NUM>, and a USB port <NUM> may be coupled to the USB controller <NUM>. A subscriber identity module ("SIM") card <NUM> may also be coupled to the CPU <NUM>.

One or more memories may be coupled to the CPU <NUM>. The one or more memories may include both volatile and non-volatile memories. Examples of volatile memories include static random access memory ("SRAM") <NUM> and dynamic RAMs ("DRAM"s) <NUM> and <NUM>. The DRAMs <NUM> and <NUM> or portions thereof may be examples of the above-described system memory <NUM> (<FIG>). Such memories may be external to the SoC <NUM>, such as the DRAM <NUM>, or internal to the SoC <NUM>, such as the DRAM <NUM>. A DRAM controller <NUM> coupled to the CPU <NUM> may control the writing of data to, and reading of data from, the DRAMs <NUM> and <NUM>. In other embodiments, such a DRAM controller may be included within a processor, such as the CPU <NUM>. The CPU <NUM> may execute an HLOS or other software that is stored in any of the aforementioned memories.

A stereo audio CODEC <NUM> may be coupled to the analog signal processor <NUM>. Further, an audio amplifier <NUM> may be coupled to the stereo audio CODEC <NUM>. First and second stereo speakers <NUM> and <NUM>, respectively, may be coupled to the audio amplifier <NUM>. In addition, a microphone amplifier <NUM> may be coupled to the stereo audio CODEC <NUM>, and a microphone <NUM> may be coupled to the microphone amplifier <NUM>. A frequency modulation ("FM") radio tuner <NUM> may be coupled to the stereo audio CODEC <NUM>. An FM antenna <NUM> may be coupled to the FM radio tuner <NUM>. Further, stereo headphones <NUM> may be coupled to the stereo audio CODEC <NUM>. Other devices that may be coupled to the CPU <NUM> include one or more digital (e.g., CCD or CMOS) cameras <NUM>.

A modem or RF transceiver <NUM> may be coupled to the analog signal processor <NUM>. The modem or RF transceiver <NUM> or a portion thereof may be an example of the above-described AD <NUM> (<FIG>) or 208B (<FIG>). An RF switch <NUM> may be coupled to the RF transceiver <NUM> and an RF antenna <NUM>. In addition, a keypad <NUM>, a mono headset with a microphone <NUM>, and a vibrator device <NUM> may be coupled to the analog signal processor <NUM>.

A power supply <NUM> may be coupled to the SoC <NUM> via a power management integrated circuit ("PMIC") <NUM>. The power supply <NUM> may include a rechargeable battery or a DC power supply that is derived from an AC-to-DC transformer connected to an AC power source.

The SoC <NUM> may have one or more internal or on-chip thermal sensors 1070A and may be coupled to one or more external or off-chip thermal sensors 1070B. An analog-to-digital converter ("ADC") controller <NUM> may convert voltage drops produced by the thermal sensors 1070A and 1070B to digital signals.

The touch screen display <NUM>, the video port <NUM>, the USB port <NUM>, the camera <NUM>, the first stereo speaker <NUM>, the second stereo speaker <NUM>, the microphone <NUM>, the FM antenna <NUM>, the stereo headphones <NUM>, the RF switch <NUM>, the RF antenna <NUM>, the keypad <NUM>, the mono headset <NUM>, the vibrator <NUM>, the thermal sensors 1050B, the ADC controller <NUM>, the PMIC <NUM>, the power supply <NUM>, the DRAM <NUM>, and the SIM card <NUM> are external to the SoC <NUM> in this exemplary embodiment. It will be understood, however, that in other embodiments one or more of these devices may be included in such an SoC.

The SoC <NUM> may include a TME <NUM>, which may be an example of the above-described TME <NUM> (<FIG>). The TME <NUM> may include processor hardware and accordingly may execute firmware or software to control portions of the methods described above.

Any of the components of the SoC <NUM> that are configured as bus masters may be examples of the above-described bus masters <NUM> (<FIG>), 202A, 202B or 202C (<FIG>). The modem <NUM> or a portion thereof is an example of a component that may serve as a bus master. The bus masters may include processor hardware and accordingly may execute firmware or software to control portions of the methods described above with regard to ADs. Similarly, any of the components of the SoC <NUM> that are configured as bus slaves may be examples of the above-described bus slaves <NUM> (<FIG>) that serve as or provide resources. Although not shown in <FIG> for purposes of clarity, the bus slaves may be coupled to xPUs. Although likewise not shown in <FIG>, the bus master, bus slave, and other components of the SoC <NUM> may communicate via an interconnect or bus system, as described above with regard to <FIG>.

Firmware or software may be stored in any of the above-described memories, such as DRAM <NUM> or <NUM>, SRAM <NUM>, etc., or may be stored in a local memory directly accessible by the processor hardware on which the software or firmware executes. Any such memory having firmware or software stored therein in computer-readable form for execution by processor hardware (e.g., CPU, TME, AD, etc.) may be an example of a "computer program product," "computer-readable medium," etc., as such terms are understood in the patent lexicon.

Claim 1:
A method for resource access control in a system-on-chip, SoC, comprising:
allocating (<NUM>) to an access domain (<NUM>), by an agent executing on a processor (<NUM>), a resource (<NUM>) comprising a memory region;
loading (<NUM>), by the agent, a software image associated with the access domain into the memory region;
locking (<NUM>), by a trust management engine (<NUM>), the resource against access by any entity other than the access domain and the trust management engine;
authenticating (<NUM>), by the trust management engine, the software image associated with the access domain;
initiating booting (<NUM>), by the trust management engine, of the access domain in response to a successful authentication of the software image associated with the access domain; and
the access domain, after booting, locking (<NUM>) the resource against access by the trust management engine.