Access control system and method for isolating mutually distrusting security domains

Abstract

Resource access control in a system on chip (SoC) can employ agents executing on processors of the SoC and a trust management engine of the SoC. An agent, such as, for example, an advanced operating system or hypervisor, can be configured to allocate a resource, including a memory region, to an access domain and load a software image associated with the access domain into the memory region. The trust management engine can be configured to lock the resource against access by any entity other than the access domain, to verify the software image associated with the access domain, and to initiate a launch of the access domain in response to successful verification of the software image associated with the access domain.

Description

Background Technology

[0001] Portable computing devices (“PCDs”) are becoming necessities for both individuals and professionals. These devices can include cellular phones, tablets, PDAs, portable digital assistants (“PDAs”), portable game consoles, and other portable electronic devices. A PCD typically contains an integrated circuit or system-on-a-chip (“SoC”), which comprises numerous components designed to work together to provide functionality to the user. For example, an SoC can contain any number of processing engines, such as a modem, a central processing unit (“CPU”) with multiple cores, a graphics processing unit (GPU), etc. An SoC can be coupled to other components within the PCD, such as system memory, wireless communication transceivers (also known as modems), cameras, microphones, speakers, etc. An SoC and other components can be coupled via one or more buses or other interconnects to provide data communication between them. The term “resource” can be used to refer to a component or part of a component that a processor can access via bus transactions, such as memory regions, registers, ports, etc.

[0002] In SoC design, maintaining security to prevent unauthorized access to resources is a critical consideration. The complexity of SoCs presents conflicting security requirements. For example, on one hand, the advanced operating system (“HLOS”) running on the processors within the SoC may need to be able to restrict access to resources from entities running on other SoC processors. On the other hand, SoC vendors may want to restrict HLOS access to such other SoC processors, as such access could expose the SoC vendor’s intellectual property. Main memory, or system memory, is often the most critical resource, and HLOS typically manages the entire system memory. Collaboration between entities in different security domains may also be required, and splitting the system memory mapping to dedicate portions of system memory to different security domains may be undesirable.

[0003] Security is typically provided in SoC-based devices in one of two common ways. One approach is to provide SoC hardware that controls security across all subsystems. A drawback of this approach is its lack of scalability. Adding new security domains is inflexible, and these domains may include subsystem security. The other approach is to enable HLOS to control security across all subsystems by providing a superuser entity. A drawback of this approach is that security may be exposed to open source and potentially compromised. Neither of these conventional solutions addresses the aforementioned conflicting security issues. Summary of the Invention

[0004] Systems, methods, and computer program products for resource access control in SoCs are disclosed.

[0005] An exemplary method for resource access control in a SoC may include allocating resources, including memory regions, to an access domain. An agent such as 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. HLOS or another agent may control or perform such loading. The method may further include locking the resource to prevent access by any entity other than the access domain. A trust management engine may control or perform such locking. The method may also include verifying the software image associated with the access domain. The trust management engine may control or perform such verification. The method may further include initiating booting of the access domain in response to successful verification of the software image. The trust management engine may initiate booting.

[0006] An exemplary system for resource access control in a SoC may include a trust management engine and an agent executing on the processor. The agent may be configured to allocate resources, including memory regions, to an access domain and load a software image associated with the access domain into the memory region. The trust management engine may be configured to: lock resources to prevent access by any entity other than the access domain; verify the software image associated with the access domain; and initiate the initiation of the access domain in response to successful verification of the software image associated with the access domain.

[0007] Another exemplary system for resource access control in a SoC may include means for allocating resources, including memory regions, to access domains and for loading a software image associated with an access domain into the memory regions. The exemplary system may also include means for locking resources to prevent access by any entity other than the access domain, for verifying the software image associated with the access domain, and for initiating the activation of the access domain in response to successful verification of the software image.

[0008] An exemplary computer program product for resource access control in a System-on-a-Chip (SoC) may include a computer-readable medium having instructions stored thereon that, when executed on one or more processors of the SoC, control methods. The method may include allocating resources, including memory regions, 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 to prevent access by any entity other than the access domain. The method may also include verifying the software image associated with the access domain. The method may further include initiating the activation of the access domain in response to successful verification of the software image. Attached Figure Description

[0009] In the figures, unless otherwise specified, similar reference numerals refer to similar parts in each figure. For reference numerals with letter character names (such as "102A" or "102B"), the letter character names can distinguish two similar parts or elements existing in the same figure. When the reference numerals are intended to cover all parts with the same reference numerals in all figures, the letter character names of the reference numerals may be omitted.

[0010] Figure 1 This is a block diagram of a SoC including a system for resource access control according to an exemplary embodiment.

[0011] Figure 2 This is a block diagram illustrating a bus master and a bus slave for resource access control in a system according to an exemplary embodiment.

[0012] Figure 3 This is a system memory mapping that illustrates an example of a resource group according to an exemplary embodiment.

[0013] Figure 4 This is a flowchart illustrating a method for resource access control related to an initiation access domain, according to an exemplary embodiment.

[0014] Figure 5 This is another flowchart illustrating a method for initiating an access domain according to an exemplary embodiment.

[0015] Figure 6 This is a flowchart illustrating a method for resource access control related to the allocation of additional resources according to an exemplary embodiment.

[0016] Figure 7 This is another flowchart illustrating a method for allocating additional resources according to an exemplary embodiment.

[0017] Figure 8 This is a flowchart illustrating a method for resource access control related to the cancellation of additional resources according to an exemplary embodiment.

[0018] Figure 9 This is another flowchart illustrating a method for cancelling additional resources according to an exemplary embodiment.

[0019] Figure 10 This is a block diagram of a PCD according to an exemplary embodiment.

[0020] Figure 11 This is a block diagram of an application programming interface for a protection unit according to an exemplary embodiment. Detailed Implementation

[0021] As used herein, the word “exemplary” means “serving as an example, instance, or illustration.” The word “illustrative” in this document may be used synonymously with “exemplary.” Any aspect described herein as “exemplary” is not necessarily to be construed as preferred over or advantageous to other aspects.

[0022] like Figure 1 As shown, in an illustrative or exemplary embodiment, PCD 100 may include SoC 102. SoC 102 may include one or more processors 104 and one or more other bus master devices 106. Although for clarity, Figure 1 Buses or similar system interconnect components are not shown, but the term "bus master" is used in this disclosure to refer to any component capable of initiating bus transactions. A group of one or more bus masters may be referred to as an access domain or "AD" in this disclosure. For example, Figure 1 The two bus master devices 106 in the group can form AD 108.

[0023] PCD 100 is merely an example of a device in which SoC 102 may be included. More generally, examples of devices that may include SoCs according to this disclosure include: computing systems (e.g., servers, data centers, desktop computers), mobile or portable computing devices (e.g., laptops, mobile phones, vehicles, etc.), Internet of Things (“IoT”) devices, virtual reality (“VR”) systems, augmented reality (“AR”) systems, and the like.

[0024] Processor 104 may also be referred to as a CPU, application processor, etc., because in this exemplary embodiment, processor 104 may execute an advanced operating system (“HLOS”) 110 and other software elements (not shown for clarity). The term “HLOS” as used in this disclosure is intended to encompass not only HLOS broadly, but also a hypervisor, HLOS combined with a hypervisor, etc. For the sake of brevity, in this disclosure, actions performed or controlled by processor 104 under the control of or configured by the execution of HLOS 110 may be referred to as actions performed by HLOS 110. Similarly, for the sake of brevity, actions performed or controlled by other processing hardware under the control of or configured by the execution of any other software entity may be referred to in this disclosure as actions performed by such other software entities. Furthermore, although for clarity, HLOS 110 is referred to as… Figure 1 It is shown separately from other bus master devices 106, but it should be noted that HLOS 110 is also a bus master device (and therefore also of the AD type).

[0025] SoC 102 may include system resource 112. System resource 112 includes components and portions of PCD 100, and bus masters (such as HLOS 110, other bus masters 106, etc.) can direct bus transactions to PCD 100. In other words, the term "bus transaction" as used in this disclosure refers to a request for system resource 112, such as a read request or a write request. Therefore, system resource 112 can be identified by an address or address range within the system address space. Although in Figure 1 For clarity, system resource 112 is depicted as being within SoC 102; however, in other embodiments, any or all such system resources may be external to the SoC. System resource 112 may include, for example, dynamic random access memory (“DRAM”), such as dual data rate DRAM (“DDR-DRAM”). Such DDR-DRAM (or, for brevity, “DDR”) can provide the main system memory of PCD 100, and the CPU or other processor 104 can execute applications (i.e., software) in such DDR. System resource 112 may include other types of memory, such as, for example, flash memory, static RAM (“SRAM”), etc. System resource 112 may include various registers, ports, and other addressable components. Note that since system resource 112 is the subject of transaction requests from bus master devices, system resource 112 may also be referred to as the subject of transaction requests from AD, since AD ​​is an entity comprising one or more bus master devices.

[0026] For example, the first system resource 112A may include a first memory region, and the second system resource 112B may include a second memory region, etc. Although only two system resources 112A and 112B are shown for illustrative purposes, any number of system resources 112 can be allocated in the system address space. Unless otherwise described in this disclosure, system resources 112 can be requested, allocated, and disposed of according to conventional computing principles well known to those skilled in the art. For example, in response to certain operating conditions, the bus master device 106 may initiate a request for system resources 112. This disclosure relates to... Figure 1 The dashed arrow in the middle conceptually indicates the system and method used to control access to such system resource 112.

[0027] The Trust Management Engine (“TME”) 116 is a component involved in the access control system and method. To enhance security, the TME 116 can be implemented primarily in hardware separate from the processor 104 on which HLOS 110 executes, such as another processor, read-only memory (“ROM”), etc. Figure 1(Not shown separately). TME 116 may employ a verification agent (not shown separately) that uses cryptographic methods to verify the software image. Such a verification agent can be of a conventional type and therefore is not described in this disclosure. Although for clarity, TME 116 in Figure 1 It is shown separately from other bus master devices 106 and HLOS 110, but it should be noted that TME 116 is also a bus master device (and therefore also an AD type).

[0028] Protection unit 118 can be configured to selectively protect system resources 112. Various types of protection units may exist, each associated with a component capable of acting as or providing a resource. The term "xPU" can be used broadly in this disclosure to refer to any of the various types ("x") of protection units associated with a corresponding type of component. For example, an xPU associated with memory may be referred to as a memory protection unit.

[0029] like Figure 2 As shown, system 200 may include two or more bus master devices 202A, 202B, 202C, etc. While a portion of each of the bus master devices 202A, 202B, 202C, etc., may include hardware, one or more of the bus master devices 202B, 202C, etc., may also include software components. For example, the first bus master device 202A may include a CPU 204A, which may execute HLOS 206A. CPU 204A may be the aforementioned processor 104 (…). Figure 1 Examples of bus master devices 202B include, for instance, a hardware engine 204B and a software component, which may be referred to herein as an Intelligent and Trusted Entity (“ITE”) 206B. Similarly, a third bus master device 202C may include a hardware engine 204C and a software component 206C. The second and third bus master devices 202B and 202C may together form an access domain or AD 208B, as described above. Figure 1The described AD 108. In an AD having two or more bus masters, at least one bus master's software portion is an ITE; the software portions of the other bus masters do not need to be ITEs. For example, AD 208B can be a modem, where bus masters 202B and 202C are scalar and vector modem cores, respectively. Although in this exemplary embodiment, the modem includes two bus masters 202B and 202C, in other embodiments, the modem can consist of only one bus master, like other ADs. Note that the first bus master 202A also forms AD 208A. Since AD ​​208A is characterized by an HLOS 206A in operation, for convenience, such an AD can be referred to as an HLOS in this disclosure, similar to... Figure 1 HLOS 110 in the middle.

[0030] Bus master devices 202A, 202B, 202C, etc., can be configured to access resources via corresponding memory management units (“xMMU”) 210A, 210B, 210C, etc. The term “xMMU” can broadly refer in this disclosure to any type of MMU among multiple types (“x”) of MMUs associated with a corresponding type of component (such as, for example, system memory (in contrast to another level or type of memory)). Although in Figure 2 For clarity, each of the bus masters 202A, 202B, and 202C is shown as coupled to exactly one corresponding xMMU 210A, 210B, and 210C. However, in other examples (not shown), there may be additional elements through which the bus masters can access resources, such as two or more levels of xMMUs.

[0031] Each of the multiple bus slave devices 212 (such as bus slave devices 212A and 212B) can act as or provide corresponding system resources 112. Figure 1 This includes, for example, memory, registers, ports, etc. Although two bus slave devices 212A and 212B are shown, system 200 may include any number of bus slave devices 212. Each bus slave device among bus slave devices 212A, 212B, etc., may be coupled to a system interconnect component (e.g., bus system) 216. The aforementioned xMMUs 210A, 210B, 210C, etc., are also coupled to system interconnect component 216. Each AD 208A, 208B, etc., can therefore access resources by participating in bus transactions via system interconnect component 216.

[0032] System resources 112 (can be provided) Figure 1Each bus slave device 212 is protected by a corresponding xPU 214 (such as xPU214A and 214B). The xPU 214 can be one of the above-mentioned... Figure 1 Example of the protection unit 118 described. The xPU 214 can be configured to protect or prevent access to system resources 112 provided by the bus slave device 212 in a manner described below.

[0033] like Figure 3 As shown, system memory mapping 300 represents a region in system memory, which may be referred to in this disclosure as resource group (“RG”) 302. A region in system memory (e.g., DDR) is system resource 112 (… Figure 1 Examples of ) are provided. Note that the terms “resource,” “system resource,” and “resource group” (or “RG”) are used substantially synonymously in this disclosure, although in some cases the term “resource group” (or “RG”) is used to refer more specifically to a resource allocated to the AD. As described in further detail below, an RG can be allocated to an AD by setting access permissions that allow the AD to access the RG (i.e., to complete read or write transactions with the RG). In this disclosure, the term “owned by…(AD)” can also be used to refer to an RG allocated to the AD. Resources owned by or allocated to the AD can also refer to resources belonging to the AD, being part of the AD, etc. As used in this disclosure, “allocating” an RG to the AD means not only allocating the RG in a conventional sense (e.g., by defining or reserving memory space), but also that the AD becomes the owner of the RG. The RG can only be accessed by the AD that owns the RG. Any attempt by any entity other than the owner of the RG to access the RG will be prevented or blocked by the associated xPU. In the exemplary embodiments described herein, the default or initial state (e.g., when the PCD 100 is started) can be HLOS 110 ( Figure 1 It possesses all system resources 112; other ADs, including TME 116, cannot access any resources until resources can be allocated to such other ADs.

[0034] exist Figure 3 In this illustration, system memory map 300 shows an example where various RG302A, 302B, etc., up to 302N (collectively referred to as RG 302) have been allocated to the AD. The remainder of system memory map 300 represents system resources not yet explicitly allocated to the AD, and therefore, according to the exemplary embodiments described herein, the system resources remain owned by HLOS. RG 302 can be located anywhere within the memory address range, and Figure 3 The locations shown are for illustrative purposes only.

[0035] like Figure 11As shown, the xPU application programming interface (“API”) 1100, illustrated in conceptual form, represents an example of various configuration settings that the AD can provide to the xPU to configure or control how the xPU operates. The xPU API 1100 may have two parts: a per-RG configuration section 1102 and a global configuration section 1104. The AP can provide configuration settings for each RG (i.e., specific to each RG) to the xPU through the per-RG configuration section 1102, and aspects of xPU operation that are not specific to any RG can be configured through the global configuration section 1104.

[0036] Each RG configuration section 1102 provides or utilizes RG configuration 1106 to program the xPU, RG configuration 1106 configuring the xPU for one of a plurality of RGs (e.g., "RG_0" to "RG_M", where M is a fixed number defining a maximum supported number of RGs (M+1)). Each RG configuration 1106 may include address range 1108, access permissions including read permission 1110 and write permission 1112, and RG enable setting 1114. In this exemplary embodiment, the xPU only allows HLOS to set RG configuration 1116, and this permission is subject to the locking features described below. The xPU in this embodiment prevents any attempt by any entity other than HLOS to set RG configuration 1106. For example, the xPU prevents any attempt by another AD, TME, etc. to set address range 1108, read permission 1110, write permission 1112, or RG enable setting 1114. In other embodiments (not described herein), features that allow other ADs to set RG configurations may be provided. For example, although in the exemplary embodiments described herein, HLOS owns all unallocated system resources protected by xPU by default, in other embodiments, mode settings may be provided in the global configuration section 1104, and HLOS may use mode settings to choose whether such ownership occurs by default or must occur by explicitly allocating RG to HLOS.

[0037] Using the address range 1108 provided by HLOS, the xPU can identify or define the RG that the xPU wants to protect. For example, HLOS can define the above-mentioned RG 302 span by providing the start and end addresses. Figure 3 One of the RG 302 described.

[0038] The RG enable setting 1114 can be a single bit, which the HLOS can provide to enable the xPU to begin protecting the RG defined by address range 1106. For example, a value of "1" for the RG enable setting 1114 can enable the xPU to apply licenses 1110 and 1112 as described below, while a value of "0" for the RG enable setting 1114 can indicate to the xPU that the RG has been disabled, i.e., licenses 1110 and 1112 are not applicable (or no longer applicable). Furthermore, the HLOS can also, in practice, indicate that licenses 1110 and 1112 are no longer applicable by setting the RG enable setting 1114, thereby returning the RG to the available resource pool. In the exemplary embodiments described herein, the RG must be returned to the available resource pool before the HLOS can allocate the RG to another AD.

[0039] Read permission 1110 and write permission 1112 can be provided as one read enable (“RD_EN”) bit per AD and one write enable (“WR_EN”) bit per AD, respectively. For example, read permission 1110 for RG may include bits “AD_0:RD_EN” to “AD_N:RD_EN” for the corresponding AD (where N is a fixed number that limits the maximum number of supported ADs (N+1)). Similarly, write permission 1112 may include bits “AD_0:WR_EN” to “AD_N:WR” for the corresponding AD. "R_EN". For example, a read enable bit with a value of "1" can configure the xPU to enable (or not prevent) read transactions initiated by the corresponding AD pointing to RG, and a read enable bit with a value of "0" can configure the xPU to prevent read transactions initiated by the corresponding AD pointing to RG. Similarly, a write enable bit with a value of "1" can configure the xPU to enable write transactions initiated by the corresponding AD pointing to RG, and a write enable bit with a value of "0" can configure the xPU to prevent write transactions initiated by the corresponding AD pointing to RG.

[0040] If at least one bit in read permission 1110 or at least one bit in write permission 1112 indicates that AD is allowed to access RG, then AD owns or has been assigned RG. Note that read permission 1110 and write permission 1112 can be used to provide AD with read and write permissions, read-only permissions, etc., thereby controlling the types of access that AD can make to a particular RG.

[0041] Each transaction request generated by AD can include an AD identifier, i.e., a value that uniquely identifies the AD. The bits of read and write permissions 1110 and 1112 can be indexed by the AD identifier. When the xPU receives a transaction request, the xPU can compare the AD identifier included in the transaction request with the corresponding bit value in read permission 1110 or write permission 1112, and then enable or prevent the completion of the requested transaction based on the comparison.

[0042] Each RG configuration section 1102 also provides an RG configuration lock bit group 1116 for the xPU. Each RG configuration lock bit group 1118 corresponds to one of the RG configurations 1106 described above. Each RG configuration lock bit group 1116 may consist of a number of lock bits 1118 equal to the number of ADs. That is, each AD corresponds to one lock bit 1118. For example, the first lock bit 1116 (“AD_0:LOCK”) corresponds to the first AD, the second lock bit 1117 (“AD_1:LOCK”) corresponds to the second AD, and so on, while the Nth lock bit (“AD_N:LOCK”) corresponds to the Nth AD. Since HLOS and TME are the types of ADs, one lock bit in the lock bits 1118 (such as, for example, the first lock bit 1114) may correspond to HLOS, and another lock bit in the lock bits 1118 (such as, for example, the second lock bit 1115) may correspond to TME.

[0043] The xPU allows lock bit 1118 to be set only by the corresponding AD. That is, the xPU prevents or ignores any attempt to set lock bit 1118 by any entity other than the AD corresponding to that lock bit 1118. Each lock bit 1118 can have a value indicating a "locked" or "unlocked" state. The terms "locked" and "unlocked" refer to RG configuration 1106; setting one or more lock bits 1118 in group 1116 of the RG configuration lock bit to a value indicating a "locked" state configures the xPU to prevent any entity from modifying the corresponding RG configuration 1106. That is, when any one or more lock bits 1108 in group 1116 corresponding to RG configuration 1116 are set, RG configuration 1126 is locked or cannot be modified. By setting its corresponding lock bit 1118, the AD can establish trust in the RG configuration by preventing any other AD (including HLOS, TME, etc.) from subsequently modifying RG configuration 1106.

[0044] The xPU allows the corresponding AD to set the lock bit 1118 in group 1116 only if the AD has the corresponding RG. If the AD attempts to lock the RG configuration 1106 in which the AD has no permission to access the RG, the xPU prevents the attempt from succeeding.

[0045] SoC 102 ( Figure 1A cold boot or hardware-based reset can be performed to prepare for normal or "task-mode" operation, which may include providing resource access control in a manner that is not directly related to this disclosure. Such a cold boot may involve entities not directly related to this disclosure, such as one or more bootloaders. Therefore, these details are not described herein. However, it may be useful to understand that one or more bootloaders (which may be stored in ROM) are executed on CPU 104 to load HLOS 110 into system memory (i.e., in system resource 112) and start HLOS 110. The bootloader can load HLOS 110 (software image) into system memory, for example, by copying HLOS 110 from flash memory or other non-volatile memory. As a result, HLOS 110 begins execution. In some examples, the bootloader may load a Secure Execution Environment ("SEE") or other intermediate software, which in turn loads and starts HLOS 110. As understood by those skilled in the art, a SEE (sometimes referred to as a Trusted Execution Environment or "TEE") includes software typically combined with secure processor hardware to isolate trusted applications running in the SEE from untrusted applications running on the main (untrusted) HLOS. However, in the context of this disclosure, the SEE is mentioned only as an example of intermediate software that may be loaded prior to the HLOS, and embodiments do not necessarily require the inclusion of a SEE or other intermediate software. The HLOS 110 can then load and start one or more other ADs 108, as described below. The TME 116 can start simultaneously with the HLOS 110. It should be noted that the TME 116 (and any SEE) can acquire ownership of resources in essentially the same manner as described below with respect to any other AD 108. In this way, the HLOS 110 can establish trust in the TME 116 (and any SEE).

[0046] like Figure 4 As shown, the method 400 for resource access control in a SoC may include activating an AD, such as, for example, the AD 108 described above. Figure 1 ) or 208B ( Figure 2 Any AD in ) . As shown in box 402, HLOS 110 or other agents can allocate resources to the AD. As described above, resources can be, for example, memory regions that the AD wants to perform. In one exemplary embodiment, allocating resources according to box 402 can include configuring access permissions in the xPU protecting the resources to enable the AD to access the resources. For example, access permissions can be configured to grant the AD read permission, write permission, or read and write permission. Allocating resources can also include configuring access permissions such that TME 116 ( Figure 1It has sufficient access permissions (e.g., read-only) to perform the authentication described below. For this exception in TME 116, access permissions are configured to prevent access to the resource from any Active Directory other than the Active Directory being started.

[0047] Although in the exemplary embodiments described herein, the agent performing or controlling resource allocation is HLOS 110, in other embodiments, an agent other than HLOS may perform or control resource allocation or a portion thereof. For example, in other embodiments, HLOS may perform some aspects of the resource allocation described herein, such as allocating address ranges, while another agent configures access permissions.

[0048] As shown in box 404, the HLOS 110 or other agent can load the software image associated with AD into a memory region (resource). The software image can be an ITE and can be obtained from ROM or other sources.

[0049] As shown in box 406, TME 116 ( Figure 1 The resource can then be locked to prevent access by any entity other than the AD being initiated, the difference being that the TME 116 can have sufficient access permissions to perform the verification described below. In one exemplary embodiment, locking the resource to prevent access according to block 406 may include locking the resource configuration by setting a lock bit in the xPU protecting the resource. Since access permissions may have been configured by HLOS 110 or other agents as described above (block 402), locking the resource configuration thereby locking the resource itself to prevent access based on these access permissions. Note that locking the resource configuration in this way locks the access permissions, thereby preventing access by HLOS 110 ( Figure 1 )Revise.

[0050] As shown in box 408, TME 116 can verify the software image associated with the AD that has been loaded into memory and locked. As shown in box 410, after successful verification of the software image, TME 116 can initiate (or, if startup has already started, take no action to prevent its continuation) the startup of the AD. As shown in box 412, the AD can then lock resources to prevent access by any entity other than itself. Therefore, resources can be locked to prevent access by both TME 116 and HLOS 110. (The following section discusses...) Figure 5 In the described exemplary method, the AD that locks the resource can be adjusted after the AD successfully verifies the resource and removes the TME's permission to access the resource.

[0051] In examples where the AD includes two or more bus masters, each bus master has a software portion, and the operations described above with respect to boxes 402-412 can be applied to the software image of the ITE (such as the ITE 206B mentioned above). Figure 2 In such an example, starting the AD can cause ITE 206B to begin operating or executing on its associated hardware engine (where ITE 206A and associated hardware engine 204B together serve as the first bus master 202B), and ITE then initiates the startup of the second bus master 202C by performing the operations described above with respect to boxes 402-412 on the second software image. In an example where the AD includes three bus masters (not shown), the second bus master can start the third bus master, etc. Note that in such an example, the second and third bus masters can be started independently of the TME; the TME only needs to start the first bus master.

[0052] like Figure 5 As shown, method 500 for resource access control in a SoC may include activating AD. Method 500 may be method 400 described above. Figure 4 Examples of ).

[0053] As shown in box 502, HLOS can read AD boot requirements, such as, for example, memory requirements for the AD (e.g., the number of partitions and the size of each partition), clock / power requirements for the AD, etc. As shown in box 504, HLOS can allocate a memory partition for the AD. At this point, the memory partition is owned by HLOS and is physically contiguous. As shown in box 506, HLOS can load (i.e., copy) the AD software image from non-volatile memory into the AD memory partition. HLOS can also load any bootloader associated with the AD into the memory partition.

[0054] An Active Directory (AD) may or may not be a privacy-sensitive type. In this context, "privacy" refers to third-party content that only the AD can read. This content may be stored in encrypted form in flash memory, and HLOS may load the encrypted content into a dedicated partition in system memory. This area can be decrypted by the AD's master bootloader after the AD has started. If the AD is privacy-sensitive, as shown in box 508, HLOS may create two Registered Storage Units (RGs): one RG for the AD's master bootloader and another RG for the remaining AD memory allocation. If the AD is not privacy-sensitive, as shown in box 510, HLOS may create one RG for the entire AD memory allocation.

[0055] As shown in box 512, HLOS can then configure the AD's startup vector register. HLOS can also configure one or more xPUs (xPUs) that protect the AD register space. For example, HLOS can use xPU API 1100 ( Figure 11 The RG configuration 1106 is used to configure one or more xPUs. 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, enabling the TME to perform the verifications described below. As shown in box 514, the HLOS can then send a request to the TME to start the AD. As described above, starting the AD encompasses starting all bus masters in the AD.

[0056] As shown in box 516, the TME locks one or more RG configurations of the AD by setting its lock bit in the corresponding xPU. In the context of the locking feature, "setting" the lock bit means setting the RG configuration to a "locked" state, and "clearing" the lock bit means setting the RG configuration to an "unlocked" state. The TME can read the memory allocation information and verify that the xPU configuration is correct. Note that setting the TME's lock bit prevents any entity (including HLOS, TME, etc.) from modifying the RG configuration.

[0057] As shown in box 518, the TME can then verify the software image, for example, by verifying the signature of the software image. As those skilled in the art will understand, verification can be performed in a conventional manner using cryptographic techniques (e.g., keys). If the TME determines that the verification is successful, then as shown in box 520, the TME can initiate the startup of the AD. This can include enabling the TME to start resources and release the AD from reset, thereby enabling or allowing the AD to start. As mentioned above, the AD typically includes a subsystem with a dedicated processor and clock / power domain. "Release the AD from reset" means performing all necessary hardware configurations to remove the AD subsystem and processor from the reset state. When the hardware portion of the AD becomes active in the manner described above, the AD software image or software portion of the AD begins to start or execute in the memory region or partition to which it is loaded.

[0058] As shown in box 522, once AD ​​starts execution, it can validate one or more of its RGs by inspecting the RG configuration in the xPU. AD is always allowed to inspect (i.e., read) RG configurations, such as the RG configuration 1106 mentioned above. Figure 11This includes RG access permissions. If the RG configuration is successfully verified, AD can set its corresponding lock bit. Verification is successful if AD confirms that its RG access permissions meet AD's expectations. For example, AD might typically expect RG access permissions to indicate that the RG is owned solely by that AD, meaning that no entity other than that AD is allowed to access the RG. If the RG access permissions allow unexpected entities to access the RG, AD will reject the RG configuration, deem it invalid (i.e., verification fails), and stop startup. Since AD ​​in this example has just started up (i.e., is executing), AD might expect TME to still have read access to the RG (but not write access).

[0059] After successful RG configuration verification and after the AD has set its corresponding lock bit, the AD can notify the TME. As shown in box 523, when the TME receives this notification from the AD, the TME can clear its lock bit. Clearing the TME's lock bit for the RG can trigger the xPU to automatically (i.e., without intervention from HLOS or other entities) delete the TME's access permission for that RG, as the TME's clearing of its lock bit indicates that the TME no longer needs to access the RG. Since the AD's lock bit remains set, the RG configuration is locked, disallowing access from the TME, HLOS, and any other AD that does not own the RG. As shown in box 524, the AD can then proceed with startup.

[0060] If the TME determines (box 518) that verification has failed, then as shown in box 526, the TME may unlock one or more RG configurations associated with the RG containing the AD software image and signal a boot operation failure to HLOS. The TME may also control the hardware reset signal (not shown) applied to the AD hardware engine and may only release the hardware reset signal if verification is successful.

[0061] like Figure 6 As shown, a method 600 for resource access control in a SoC may include allocating additional resources to an AD (such as, for example, AD 108 described above). Figure 1 ) or 208B ( Figure 2As shown in box 602, an AD can transmit a request for one or more additional resources to the HLOS. In this context, "additional" refers to the memory space where the software image attached to the AD resides, as well as the memory space allocated to the AD when it is started. As shown in box 604, the HLOS can then allocate one or more additional resources to the requesting AD. As shown in box 606, the AD can then lock the RG configuration associated with the additional resources by setting a lock bit for the corresponding xPU, preventing access by any entity other than the requesting AD. Note that locking resources in this way will lock the resources to prevent access by any entity other than the HLOS, TME, and the requesting AD.

[0062] like Figure 7 As shown, method 700 for resource access control in a SoC may include allocating additional resources to an AD. Method 700 may be method 600 described above. Figure 6 Examples of ).

[0063] As shown in box 702, AD can transmit a request for one or more additional resources to HLOS. For example, the request may include the requested amount of memory space and the requested access permissions. As shown in box 704, HLOS can determine whether the requested resource is available. If the requested resource is unavailable, HLOS can notify AD that the request is rejected, as shown in box 706. If the requested resource is available, HLOS can allocate a new RG, as shown in box 708. Allocating a new RG may include providing RG configuration for the xPU protecting the resource or programming the xPU protecting the resource using the RG configuration, which may include RG address ranges, access permissions, etc. For example, HLOS can use xPU API 1100 (… Figure 11 The xPU can then be configured using RG configuration 1106. Then, as shown in box 710, HLOS can return a pointer to the newly created RG to the request AD.

[0064] As shown in box 712, requesting AD can lock RG and check RG configuration to determine whether it is "valid" or "invalid". (See box 522 above...) Figure 5 As described above, if the RG access permission meets the AD's expectations, the AD can consider the RG configuration valid. For example, if the AD expects no other entity to be able to access the resource, the RG access permission should only allow the AD to access the resource. If the RG access permission allows any other entity to access the resource, the AD rejects the RG configuration and considers it invalid. If the RG configuration is "invalid," then as shown in box 716, the AD can remove the lock and notify HLOS that the RG has been rejected. If the RG configuration is "valid," then as shown in box 714, the AD can begin using the RG.

[0065] like Figure 8 As shown, the method 800 for resource access control in a SoC may include methods such as those described in method 600 above. Figure 6 ) or 700 Figure 7 The AD can then unlock additional resources that have been allocated to the AD. As shown in box 802, the AD can unlock the resource. As shown in box 804, the AD can then notify the HLOS that the resource is now free.

[0066] like Figure 9 As shown, method 900 for resource access control in a SoC may include unallocating additional resources already allocated to an AD. Method 900 may be method 800 described above. Figure 8 Examples of ).

[0067] As shown in box 902, the AD can zero out the memory space allocated to the RG. Zeroing out the memory space erases data that might otherwise be vulnerable to unauthorized access, thus providing additional security or privacy that might be desired in some embodiments. As shown in box 904, the AD can unlock the RG. As shown in box 906, the AD can then notify the HLOS that the RG is now free and can be returned to the pool or list of "unused" RGs. As shown in box 908, the HLOS can disable the RG and return it to the pool. "Disabling the RG" indicates that the xPU no longer uses the RG for access control. The HLOS can use xPU API 1100 ( Figure 11 RG enable setting 1114 to disable RG.

[0068] like Figure 10 As shown, exemplary embodiments of the system and method for resource access control can be implemented in PCD 1000. PCD 1000 includes SoC 1002. SoC 1002 may include CPU 1004, GPU 1006, DSP 1007, analog signal processor 1008, or other processors. CPU 1004 may include multiple cores, such as a first core 1004A, a second core 1004B, etc., up to an Nth core 1004N. CPU 1004 or any of its cores may be the aforementioned processor 104 (…). Figure 1 ) or CPU 204A ( Figure 2 Examples of ).

[0069] Display controller 1010 and touchscreen controller 1012 can be coupled to CPU 1004. A touchscreen display 1014 external to SoC 1002 can be coupled to display controller 1010 and touchscreen controller 1012. PCD 1000 may also include a video decoder 1016 coupled to CPU 1004. Video amplifier 1018 can be coupled to video decoder 1018 and touchscreen display 1014. Video port 1020 can be coupled to video amplifier 1018. Universal Serial Bus (“USB”) controller 1022 can also be coupled to CPU 1004, and USB port 1024 can be coupled to USB controller 1022. Subscriber Identity Module (“SIM”) card 1026 can also be coupled to CPU 1004.

[0070] One or more memories may be coupled to CPU 1004. The one or more memories may include volatile and non-volatile memories. Examples of volatile memories include static random access memory (“SRAM”) 1028 and dynamic RAM (“DRAM”) 1030 and 1031. DRAM 1030 and 1031, or portions thereof, may be the aforementioned system memory 112 (… Figure 1 Examples of such memory include DRAM 1030, which can be external to SoC 1002, or internal to SoC 1004, such as DRAM 1031. A DRAM controller 1032, coupled to CPU 1004, can control the writing of data to and from DRAMs 1030 and 1031. In other embodiments, such a DRAM controller can be included within a processor (such as CPU 1004). CPU 1004 can execute any HLOS or other software stored in the aforementioned memory.

[0071] A stereo audio CODEC 1034 can be coupled to an analog signal processor 1008. Additionally, an audio amplifier 1036 can be coupled to the stereo audio CODEC 1034. First and second stereo speakers 1038 and 1040 can be coupled to the audio amplifier 1036, respectively. Furthermore, a microphone amplifier 1042 can be coupled to the stereo audio CODEC 1034, and a microphone 1044 can be coupled to the microphone amplifier 1042. An FM radio tuner 1046 can be coupled to the stereo audio CODEC 1034. An FM antenna 1048 can be coupled to the FM radio tuner 1044. Additionally, stereo headphones 1050 can be coupled to the stereo audio CODEC 1034. Other devices that can be coupled to the CPU 1004 include one or more digital (e.g., CCD or CMOS) cameras 1052.

[0072] The modem or RF transceiver 1054 can be coupled to the analog signal processor 1008. The modem or RF transceiver 1054, or a portion thereof, can be the aforementioned AD 108. Figure 1 ) or 208B ( Figure 2 Examples of RF switches include RF switch 1056, which can be coupled to RF transceiver 1054 and RF antenna 1058. Additionally, a keypad 1060, a mono headset 1062 with a microphone, and a vibrator device 1064 can be coupled to analog signal processor 1008.

[0073] The power supply 1066 can be coupled to the SoC 1002 via a power management integrated circuit (“PMIC”) 1068. The power supply 1066 may include a rechargeable battery or a DC power source, with the DC power source derived from an AC-DC transformer coupled to an AC power source.

[0074] The SoC 1002 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. The analog-to-digital converter (“ADC”) controller 1072 may convert the voltage drop generated by the thermal sensors 1070A and 1070B into a digital signal.

[0075] In this exemplary embodiment, the touchscreen display 1014, video port 1020, USB port 1024, camera 1052, first stereo speaker 1038, second stereo speaker 1040, microphone 1044, FM antenna 1048, stereo headphones 1050, RF switch 1056, RF antenna 1058, keyboard 1060, mono headset 1062, vibrator 1064, thermal sensor 1050B, ADC controller 1052, PMIC 1068, power supply 1066, DRAM 1030, and SIM card 1026 are external to the SoC 1002. However, it should be understood that in other embodiments, one or more of these devices may be included in such an SoC.

[0076] SoC 1002 may include TME 1074, and TME 1074 may be the aforementioned TME 116 ( Figure 1 Examples of the above methods can be found here. The TME1074 may include processor hardware and therefore firmware or software can be executed to control the various parts of the methods described above.

[0077] Any component in SoC 1002 configured as a bus master can be the aforementioned bus master 106 ( Figure 1 ), 202A, 202B or 202C ( Figure 2Examples of modems 1054 and a portion thereof are examples of components that can be used as a bus master. A bus master may include processor hardware and, accordingly, may execute firmware or software to control portions of the methods described above regarding AD. Similarly, any component in SoC 1002 configured as a bus slave may be the aforementioned bus slave 212 (used to provide resources). Figure 2 Examples of ). Although for clarity in Figure 10 Not shown in the diagram, but bus slave devices can be coupled to the xPU. Although also not shown in... Figure 10 Not shown in the text, but as mentioned above... Figure 2 The bus master, bus slave and other components of the SoC 1002 can communicate via interconnect components or bus system.

[0078] Firmware or software may be stored in any of the aforementioned memories, such as DRAM 1030 or 1031, SRAM 1028, etc., or may be stored in local memory that can be directly accessed by the processor hardware executing the software or firmware. As understood in the patent lexicon, any such memory having firmware or software stored therein in a computer-readable form for execution by processor hardware (e.g., CPU, TME, AD, etc.) can be an example of a "computer program product," a "computer-readable medium," etc.

[0079] Alternative embodiments will become apparent to those skilled in the art to which this invention pertains without departing from its spirit and scope. Therefore, while selected aspects have been illustrated and described in detail, it should be understood that various substitutions and changes may be made therein without departing from the spirit and scope of the invention as defined by the appended claims.

Claims

1. A method for resource access control in a System-on-Chip (SoC), comprising: An agent executing on the processor allocates resources, including memory regions, within the on-chip system to access domains; The agent loads the software image associated with the access domain into the memory region; The trust management engine locks the resource to prevent access by any entity other than the access domain and the trust management engine by setting a resource group configuration in the protection unit, and the protection unit is coupled to and decoupled from the resource; The protection unit is coupled to the communication bus; the protection unit is separate from the processor; The protection unit includes programmable logic for supporting the configuration of the resource group; The trust management engine verifies the software image associated with the access domain; In response to successful verification of the software image associated with the access domain, the trust management engine initiates the startup of the access domain; The access domain checks the resource group configuration in the protection unit to determine whether the resource group configuration is valid; as well as If the access domain determines that the resource group configuration in the protection unit is valid, the access domain locks the resource to prevent access by the trust management engine.

2. The method of claim 1, wherein the agent comprises an advanced operating system.

3. The method of claim 2, wherein the access domain includes a modem.

4. The method of claim 1, wherein the access domain includes one or more bus master devices.

5. The method of claim 4, wherein initiation comprises: After the first bus master device in the access domain completes startup, the first bus master device initiates the startup of the second bus master device in the access domain, which starts independently of the trust management engine.

6. The method according to claim 1, further comprising: The access domain transmits requests to the high-level operating system HLOS for the allocation of additional resources, including additional memory regions. The HLOS will allocate the additional resources to the access domain; The additional resource is locked by the access domain to prevent access by any entity outside the access domain.

7. The method according to claim 6, further comprising: The access domain cancels the lock that prevents another entity from accessing the additional resource; as well as The access domain transmits an indication to the HLOS that the additional resource is available.

8. A system for resource access control in a System-on-Chip (SoC), comprising: The agent executes on the processor and is configured as follows: Allocate resources, including memory regions, within the system-on-a-chip to access domains; as well as The software image associated with the access domain is loaded into the memory region; as well as The trust management engine is configured as follows: The resource is locked by setting a resource group configuration in the protection unit to prevent access by any entity other than the access domain and the trust management engine; the protection unit is coupled to the resource and decoupled from the resource. The protection unit is coupled to the communication bus; the protection unit is separate from the processor; The protection unit includes programmable logic for supporting the configuration of the resource group; Verify the software image associated with the access domain; In response to successful verification of the software image associated with the access domain, the startup of the access domain is initiated; and The access domain is configured as follows: Check the resource group configuration in the protection unit to determine if the resource group configuration is valid; as well as If the access domain determines that the resource group configuration in the protection unit is valid, then the resource is locked to prevent access by the trust management engine.

9. The system of claim 8, wherein the agent comprises an advanced operating system.

10. The system of claim 9, wherein the access domain includes a modem.

11. The system of claim 8, wherein the access domain includes one or more bus master devices.

12. The system of claim 11, wherein startup comprises: After the first bus master device in the access domain completes startup, the first bus master device initiates the startup of the second bus master device in the access domain, which starts independently of the trust management engine.

13. The system according to claim 8, wherein: The access domain is also configured to transmit requests to the advanced operating system HLOS for the allocation of additional resources, including additional memory regions. The HLOS is configured to allocate the additional resources to the access domain; and The access domain is configured to lock the additional resource, preventing access by any entity other than the access domain.

14. The system of claim 13, wherein the access domain is further configured to: Remove the lock that prevents access to the additional resource by another entity; and Transmit an indication that the additional resource is available to the HLOS.

15. A computer program product for resource access control in a System-on-a-Chip (SoC), the computer program product comprising a non-transient computer-readable medium having instructions stored thereon, the instructions being executed on a processor of the SoC to control a method, the method comprising: An agent executing on the processor allocates resources, including memory regions, within the on-chip system to access domains; The agent loads the software image associated with the access domain into the memory region; The trust management engine locks the resource to prevent access by any entity other than the access domain and the trust management engine by setting a resource group configuration in the protection unit, and the protection unit is coupled to and decoupled from the resource; The protection unit is coupled to the communication bus; the protection unit is separate from the processor; The protection unit includes programmable logic for supporting the configuration of the resource group; The trust management engine verifies the software image associated with the access domain; In response to successful verification of the software image associated with the access domain, the startup of the access domain is initiated; The access domain checks the resource group configuration in the protection unit to determine whether the resource group configuration is valid; as well as If the access domain determines that the resource group configuration in the protection unit is valid, the access domain locks the resource to prevent access by the trust management engine.

16. The computer program product of claim 15, wherein the agent comprises an advanced operating system.

17. The computer program product of claim 15, wherein the access domain includes one or more bus master devices.

18. The computer program product according to claim 15, further comprising: The access domain transmits requests to the high-level operating system HLOS for the allocation of additional resources, including additional memory regions. The HLOS will allocate the additional resources to the access domain; The additional resource is locked by the access domain to prevent access by any entity outside the access domain.

19. The computer program product according to claim 18, further comprising: The access domain cancels the lock that prevents another entity from accessing the additional resource; as well as The access domain transmits an indication to the HLOS that the additional resource is available.

Images