Hierarchical hardware-software division and configuration

Abstract

Embodiments herein describe a hierarchical partitioning of hardware and software within a system on chip (SoC). In one embodiment, the hierarchy includes a three-level hardware-software configuration that allows for security and / or safety isolation across the three levels. The levels can cover processor subsystems with compute, memory, acceleration, and peripheral resources that are shared or partitioned across the three levels.

Description

[Technical field]

[0001] Embodiments of the present disclosure generally relate to partitioning hardware and software resources into different levels of hierarchy. [Background technology]

[0002] A typical embedded processor subsystem gives a hypervisor or operating system (OS) running on the subsystem permission to configure, allocate, or reconfigure or reallocate any hardware resources within the processor subsystem. For example, these resources managed by the hypervisor include computational resources such as central processing unit (CPU) cores, memory resources such as on-chip memory (OCM) or double data rate (DDR) memory, acceleration engines, programmable logic, and peripherals such as PCIe, Ethernet, Universal Serial Bus (USB), Universal Asynchronous Receiver Transmitter (UART), and Inter-Integrated Circuit (I2C).

[0003] In safety-critical deployments, it may be desirable for certain resources to remain inaccessible even to the hypervisor. There may be several reasons, such as (i) the ability to log and / or diagnose failures in the hypervisor domain - if the resources for logging or diagnosing the failures were part of the hypervisor domain, they would have been functionally dependent on the compromised resources, and (ii) system integrators (e.g., manufacturers of automobiles, boats, airplanes, etc.) may use hypervisors developed by third parties in their processing systems and may wish to have private system integrator resources that are inaccessible to the hypervisor.

[0004] In security-critical deployments, it may be desirable for certain resources to remain inaccessible even to the hypervisor. For example, a system integrator may be able to use its own (trusted) hypervisor, but may want to assure its customers that the device may store customer secrets, such as customer encryption keys, in a location that is not accessible to the system integrator via its hypervisor.

[0005] In safety or security critical deployments, allowing a hypervisor, which may be developed by a third party, to access the entire processor subsystem can lead to failures. In the best case, the hypervisor may be buggy and introduce an insecure state. In the worst case, the hypervisor may have security flaws that allow a malicious user to introduce an insecure state. Thus, for safety or security reasons, an operator may want to block trusted and untrusted / third party hypervisors or OS from accessing features or resources within the embedded processor that may introduce an insecure state or security flaw. Summary of the Invention

[0006] Techniques for partitioning hardware and software resources into different levels of a hierarchy are described. One embodiment is a system on a chip (SoC) including a first processing element configured to run a trusted operating system (OS) assigned to a first level in the hierarchy, a second processing element configured to run a first hypervisor or OS assigned to a second level in the hierarchy, a third processing element configured to run a second hypervisor or OS assigned to a third level in the hierarchy, and a memory, where a first portion of the memory is assigned to the first level, a second portion of the memory is assigned to the second level, and a third portion of the memory is assigned to the third level. Further, the trusted OS is authorized to manage the first, second, and third portions of the memory, the first hypervisor or OS is authorized to manage the second and third portions of the memory but not the first portion of the memory, and the second hypervisor or OS is authorized to manage only the third portion of the memory.

[0007] One embodiment described herein is a system-on-chip (SoC) including a first processing element configured to execute a trusted operating system (OS) assigned to a first level in the hierarchy, a processor subsystem including a first processor core configured to execute one of a safety-critical hypervisor or a TEE OS and assigned to a second level in the hierarchy, and a second processor core configured to execute one of a non-safety-critical hypervisor or a second OS not in the TEE and assigned to a third level in the hierarchy. Further, the trusted OS is authorized to manage hardware resources assigned to the first, second, and third levels, the safety-critical hypervisor or TEE OS is authorized to manage hardware resources assigned to the second and third levels but not the first level, and the non-safety-critical hypervisor or second OS is authorized to manage hardware resources assigned to the third level but not the first and second levels.

[0008] One embodiment described herein includes allocating level 1 resources in the SoC during secure boot of the SoC, allocating level 2 resources in the SoC using a level 1 trusted OS loaded during secure boot, the level 2 resources including a first hypervisor or OS that is held in reset while allocating the level 2 resources, and allocating level 3 resources in the SoC using the level 1 trusted OS, the level 3 resources including a second hypervisor or OS that is held in reset while allocating the level 3 resources. Further, the level 1 trusted OS is authorized to manage level 1, 2, and 3 resources, the level 2 resources are authorized to manage level 2 and 3 resources but not level 1 resources, and the level 3 resources are authorized to manage level 3 resources but not level 1 and level 2 resources. [Brief description of the drawings]

[0009] In a manner in which the above-recited features may be understood in detail, a more particular description briefly summarized above may be made by reference to exemplary implementations, some of which are illustrated in the accompanying drawings. It should be noted, however, that the accompanying drawings illustrate only typical exemplary implementations and therefore should not be considered as limiting the scope thereof. [Figure 1] 1 is a logical diagram of a hierarchically partitioned system-on-chip according to one embodiment. [Diagram 2] FIG. 2 is a logical diagram of a hierarchically partitioned system-on-chip, according to an embodiment. [Diagram 3] FIG. 1 is a block diagram of a hierarchically partitioned system-on-chip, according to one embodiment. [Figure 4] 1 is a hierarchically partitioned system-on-chip according to one embodiment. [Diagram 5]1 is a flow chart for partitioning resources in a system-on-chip to form a hierarchy, according to one embodiment.

[0010] For ease of understanding, wherever possible, identical reference numbers have been used to designate identical elements common to the figures. It is contemplated that elements of one embodiment may be beneficially incorporated in other embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0011] Various features are described below with reference to the drawings. It should be noted that the drawings may or may not be drawn to scale, and elements of similar structure or function are represented by similar reference numerals throughout the drawings. It should be noted that the drawings are intended only to facilitate the description of features. They are not intended as an exhaustive description of features or as limitations on the scope of the claims. In addition, an illustrated embodiment need not have all aspects or advantages shown. An aspect or advantage described in connection with a particular embodiment is not necessarily limited to that embodiment and can be implemented in any other embodiment, even if not so illustrated or explicitly described.

[0012] Embodiments herein describe a hierarchical partitioning of hardware and software within a system on chip (SoC). In one embodiment, the hierarchy includes three levels of hardware-software configurations that enable security and / or safety isolation across the three levels. The levels cover processor subsystems with compute, memory, acceleration, programmable logic, and peripheral resources that are shared or partitioned across the three levels.

[0013] In the following examples, the first level (Level 1) is the highest level (e.g., the most trusted or most secure level) controlled by the root of trust settings loaded by secure boot when the SoC is powered on. The first level dictates which resources can and cannot be accessed by the other two levels, even if the other levels are along the chain of trust. For example, a malicious actor (e.g., a disgruntled employee) cannot access resources in the first level, even if resources assigned to the second level are in the same chain of trust as resources in the first level (e.g., resources at Level 1 and Level 2 are operated or controlled by the same entity).

[0014] The second level (Level 2) can be a hypervisor, OS, or software that can reallocate processor subsystem resources. Level 2 can control resources at its level as well as resources at the third level (Level 3). In addition to Level 1 preventing Level 2 and Level 3 actors from accessing resources private to Level 1, Level 1 can also firewall Level 2 resources to prevent access by Level 3 actors. The three levels of security / safety can be applied to processor subsystems for safety applications (Automotive, Aerospace and Defense (A&D), Industrial) or security applications (A&D, Data Center).

[0015] Figure 1 is a logical diagram of a hierarchically partitioned SoC 100, according to one embodiment. The bottom portion of Figure 1 lists various hardware elements within SoC 100 that may be partitioned or assigned to different levels of hierarchy (i.e., levels 1, 2, and 3). These hardware elements include processor cores 105, input / output (I / O) 110, interconnect address map 115, memory 120, memory management unit (MMU) 125, general interrupt controller (GIC) 130, and accelerator engines 135.

[0016] In one embodiment, these hardware elements are within the processor subsystem of SoC 100. Although not shown, SoC 100 may also include other components such as a network on a chip (NoC), programmable logic, an array of data processing engines, and I / O interfaces that are not within the processor subsystem. These components may or may not be assigned to different levels in the hierarchy. That is, in one embodiment, only hardware and software elements within the processor subsystem of SoC 100 are assigned to levels in the hierarchy, but hardware and software elements within SoC 100 that are outside the processor subsystem are not assigned. In another embodiment, additional components within the SoC, as well as the processor subsystem, are partitioned into a hierarchy.

[0017] The boxes labeled Levels 1, 2, and 3 illustrate different portions of the hardware resources assigned to different levels. For example, since the boxes extend across a vertical area defined by the hardware elements, this means that each level is assigned at least one resource from each of the hardware resources, such as at least one core 105, an I / O device, a portion of the interconnect address map 115, a portion of the MMU 125, etc. However, this is not a requirement. For example, an entity assigned to Level 3 may not need to access the accelerator engine 135, and as a result, the Level 3 box may not extend to the accelerator engine 135. This indicates that the Level 3 resources (and any entity having software assigned to the Level 3 resources) cannot access the accelerator engine 135. Thus, in some embodiments, different hardware resources in SoC 100 may be assigned to some levels in the hierarchy but not to other levels.

[0018] As shown, the level 2 boxes are contained within the level 1 boxes, and the level 3 boxes are contained within the level 2 boxes. This nesting illustrates a hierarchy in which level 1 resources are authorized to configure, reconfigure, and manage level 2 and level 3 resources, and level 2 resources are authorized to configure, reconfigure, and manage level 3 resources. However, the reverse is not true. For example, level 3 resources cannot access or use level 1 or level 2 resources, and level 2 resources cannot access or use level 1 resources. As described below, this separation between layers can be controlled by access control circuitry within SoC 100. For example, access control circuitry can ensure that level 3 cores 105 can access level 3 memory 120, but cannot access level 1 and level 2 memory 120. As another example, level 3 accelerator engines 135 cannot access or use level 1 and level 2 I / O 110.

[0019] In one embodiment, Level 1 is the base level of hardware manufacturing. That is, Level 1 may be assigned for use by the manufacturer of the SoC 100. In one embodiment, Level 1 is created through a root of trust configuration loaded by the secure boot of the SoC. When the SoC is powered on, the secure boot loads a binary that can then control the functionality of the Level 1 resources.

[0020] Level 1 is the highest privilege level and can configure, access, or reconfigure resources at the base level and any of the next two levels. For example, management software and firmware running on the hardware resources of level 1, which can be loaded using binaries executed during secure boot, can then create levels 2 and 3. In one embodiment, level 1 can also be selected such that none of the resources, software, or hardware of level 2 or level 3 can access resources that are considered private to level 1 by the base level of hardware manufacture. In one embodiment, the configuration and management software of level 1 can be executed on a processing resource, such as processor core 105, in the processor subsystem of SoC 100. However, in another embodiment, the configuration and management software of level 1 can be executed in a Platform Management Controller (PMC) that is external to the processor subsystem in the SoC. The PMC can be a separate hardened processing element or programmable logic that executes the management software assigned to level 1, which then configures the resources of levels 2 and 3.

[0021] In one embodiment, Level 1 management software is approved by an audit process. Using the A&D arena as an example, a government agency may audit a hardware manufacturer's management software to ensure it meets certain security protocols. If so, the software is approved as Level 1. Because the Level 1 management software is loaded during secure boot, it is guaranteed to be the only Level 1 management software running on the SoC.

[0022] In one embodiment, Level 2 is a safety-critical level of Automotive Safety Integrity Level D (ASIL-D) or a security-critical level, depending on whether SoC 100 is used in an automotive / industrial safety arena or a data center / A&D security arena. Level 1 management software provides resources managed by Level 2. Level 2 can then provide resources private to Level 2 as well as resources shared with or private to Level 3. Level 2 resources can configure, access, or reconfigure resources within Level 2 or Level 3.

[0023] Level 2 is the next privilege level and may be managed by a safety-critical (ASIL-D) hypervisor or OS in a Trusted Execution Environment (TEE). Level 2 management software can configure, access, or reconfigure level 2 and level 3 resources. To achieve the safety or security properties of a level 2 software execution environment, the safety-critical ASIL-D hypervisor or TEE OS is locked to designated level 2 cores 105 for execution. In one embodiment, the ASIL-D hypervisor and TEE OS are locked to level 2 lockstep cores 105 that run the same executable, so that it can be easily detected if one core 105 malfunctions or a voltage glitch security attack causes one core 105 to behave differently than its lockstep partner.

[0024] In one embodiment, level 3 is an ASIL-C or ASIL-B safety level, or a non-security-critical OS or application execution level. Level 3 is the next privilege level after level 2, and software management of resources such as multiple cores 105 can be accomplished by an ASIL-B or ASIL-C hypervisor, or an untrusted commercial off-the-shelf or open source hypervisor or OS. As a result, level 3 software is firewalled from running on ASIL-D safety-critical or TEE lockstep cores 105 designated for level 2 management software, preventing unauthorized access to the safety-critical (ASIL-D) hypervisor or TEE OS. Level 3 configuration and control software (e.g., a hypervisor running on level 3 designated cores) can only configure, access, or reconfigure resources within level 3.

[0025] Figure 2 is a logical diagram of a hierarchically partitioned SoC 200, according to an embodiment. The bottom portion of Figure 2 lists the same hardware elements in SoC 200 that were in SoC 100 of Figure 1. These hardware elements are further partitioned or assigned to different levels of the hierarchy (i.e., levels 1, 2, and 3).

[0026] In addition to the hierarchy, FIG. 2 illustrates that resources at levels 1 and 2 may be accessible by resources in levels 2 and 3, respectively. In this example, a level 1 firewalled resource (e.g., a portion of memory 120) is accessible to a level 2 resource. For example, a portion of memory that is a level 1 firewalled resource may have data that is managed by level 1 management software, but a user wants to make accessible to level 2 management software (e.g., an ASIL-D hypervisor or TEE OS). The level 1 management software may firewall memory 120 such that the level 2 management software can, for example, read the memory, but cannot write or modify memory 120. For example, the firewalled memory may include an instruction footprint or binary. A level 2 and / or level 3 resource may be allowed to execute (ASIL-D or TEE) binaries, but then another level 1, 2, or 3 entity may not be allowed to execute and modify those binaries (maliciously or accidentally) to cause failures or create security holes. Thus, the portions of memory 120 defined as level 1 firewall protected resources, although allocated to level 1, are nevertheless level 2 accessible resources (i.e., can be read by level 2 resources), however this access is restricted such that only level 1 resources can write or modify data written to level 1 firewall protected resources.

[0027] As another example, a level 2 firewalled resource is accessible to a level 3 resource. In this example, the level 2 firewalled resource is an accelerator engine. For example, SoC 200 may include a crypto accelerator in its processor subsystem that is assigned to level 2. However, a level 3 resource may also want to use this accelerator. If there are multiple crypto accelerators in SoC 200, one accelerator may be assigned to level 2 and another accelerator may be assigned to level 3. However, since there may be only one crypto accelerator in SoC 200 or the level 3 resource may only use a small amount of the crypto accelerator, assigning the entire crypto accelerator to level 3 may be an inefficient use of the accelerator.

[0028] Instead, FIG. 2 illustrates allowing level 3 resources to access accelerators assigned to level 2. For example, a level 2 crypto accelerator may have four channels. Three of the channels may be firewalled such that they are only accessible to level 2 resources and the fourth channel is accessible to level 3 resources. Thus, both level 2 and level 3 resources may use the same crypto accelerator but still support the stringent safety and security protections afforded by using the hierarchy illustrated in FIGS. 1 and 2. From the perspective of the level 3 resource, think of the crypto accelerator as actually being a level 2 resource but dedicated to level 3. The level 2 resource can make application programming interface (API) calls to its three channels, but the level 3 resource can only make API calls to its one channel and cannot access the other three channels in the crypto accelerator because of the firewall.

[0029] Thus, FIG. 2 illustrates allowing hardware resources assigned to higher priority levels in the hierarchy to be accessible to lower priority levels. In one embodiment, this can only be set by the higher priority levels. That is, only level 1 management software can establish level 1 firewalled resources to be used by level 2. Similarly, level 2 management software can establish level 2 firewalled resources to be used by level 3. A level 3 OS or hypervisor cannot cause level 2 or level 1 resources to be shared with itself. Also, a level 2 ASIL-D hypervisor or TEE OS cannot cause level 1 to share resources with itself.

[0030] 3 is a block diagram of a hierarchically partitioned SoC 300, according to one embodiment. SoC 300 includes a processor subsystem 390, a PMC 305, and I / O peripherals 355. PMC 305 is tasked with running a trusted OS 310 (e.g., level 1 management software) that serves as level 1 management software of the hierarchy. PMC 305 may be a dedicated hardened processor or may be a soft processor implemented within programmable logic (e.g., programmable fabric) within SoC 300. However, in another embodiment, rather than running trusted OS 310 using hardware resources external to processor subsystem 390, OS 310 may run using resources within subsystem 390 (e.g., one of processor cores 105).

[0031] FIG. 3 includes a key linking different hatching to levels in the hierarchy. Components without hatching indicate that they are not divided into different levels and are accessible to hardware resources at all levels. Although not shown, SoC 300 may also include other components, such as NoCs, programmable logic, an array of data processing engines, and I / O interfaces. Some or all of these additional hardware components may be communicatively coupled to the hardware components illustrated in FIG. 3 and may (or may not) be partitioned into levels of the hierarchy.

[0032] The processor subsystem 390 includes an access control circuit 315A, a bridge 320, an I / O translation lookaside buffer (TLB) 325, an interconnect 330, a processor core 105, a switch 345, an access control circuit 315B, a full power domain configuration (FPD config) register 350, and a memory 360. The Level 1 PMC 305 and the trusted OS 310 can communicate with the processor subsystem 390 using a path that allows the OS 310 to configure the interconnect 330. This path flows through the access control circuit 315A, through the bridge 320, and to the interconnect 330. In one embodiment, the interconnect 330 is a coherent interconnect network (CIN). In addition to configuring the interconnect 330, the trusted OS 315 can use these paths to configure the access control circuits 315A and 315B to configure the firewall. These paths are the paths at the start of the day, such that the Level 1 Trusted OS 310 is the first software actor to configure the processor subsystem 390. In one embodiment, the Trusted OS 310 (i.e., the Level 1 management software) holds the Level 2 and Level 3 management software under reset so that they cannot configure the processor subsystem 390.

[0033] 3 also illustrates the control path from the remap registers to bridge 320. This path determines whether accesses from PMC 305 use a direct path between bridge 320 and interconnect 330 (e.g., the Advanced Peripheral Bus (APB) path) or an indirect path (e.g., the AXI4-MM path) that flows through TLB 325 to reach interconnect 330. In one embodiment, Trusted OS 310 and any other Level 1 management software are the only software actors that have access to the control registers that determine the control signals sent on the control path from the remap registers to bridge 320.

[0034] In one embodiment, the APB path between bridge 320 and interconnect 330 or the AXI4-MM path between TLB 325 and interconnect can be used to access CIN config registers 335 in interconnect 330. Trusted OS 310 can use either of these paths to set registers 335 that are only reachable via the APB or AXI4-MM path, such that when Level 2 or Level 3 management software enters operational mode, the Level 2 or Level 3 management software cannot set any of the CIN config registers 335. Thus, trusted OS 310 can block Level 2 and 3 resources from accessing CIN config registers 335.

[0035] By ensuring that only level 1 management software (e.g., trusted OS 310) can access the CIN configuration registers 335, the trusted OS 310 can lock access to the configuration paths to the CIN configuration registers 335 to allow level 1 only resources such as the PMC 305 to access these registers 335. More importantly, the CIN configuration of the interconnect 330 can be firewalled to prevent the core-CIN configuration registers from modifying base level settings, including settings that set up address routing attributes for level 2 or level 3 cores 105 to access memory 360, peripherals 355, or accelerator resources (not shown in FIG. 3). Thus, the exemplary CIN firewall protection for the interconnect 330 to achieve a mixed-criticality configuration of the FPD cannot be overridden even by a level 2 core 105A (e.g., a lockstep safety-critical core).

[0036] The level 1 trusted OS 310 in the PMC 305 can configure the access control circuits 315A and 315B (e.g., memory protection units) such that level 2 or level 3 software accessing the core 105 is firewalled from accessing any of the CIN configuration registers 335. Additionally, the trusted OS 310 can also configure the access control circuits 315A and 315B (e.g., memory protection units) such that the full power domain (FPD) configuration registers 350 accessed via the switch 345 and the interconnect 330 are only available to level 1 and level 2 management software. That is, the FPD configuration registers 350 have double hatching to indicate that some of the registers are assigned to level 1 and other registers are assigned to level 2. The level 1 FDP configuration registers 350 are accessible by a path from the PMC 305 to the registers 350, and the level 2 FDP configuration registers 350 are accessible to the hypervisor 365 or TEE OS 370 on the level 2 designated core 105A via the interconnect 330 and switch 345.

[0037] The trusted OS 310 can also configure the access control circuitry 315B such that a particular I / O peripheral 355 is only accessible to level 1 management software, level 2 management software, or level 3 management software. That is, the I / O peripheral 355 has three cross-hatchings to indicate that some of the peripheral 355 is assigned to level 1, some to level 2, and some to level 3. The access control circuitry 315B can ensure that level 3 resources (e.g., the hypervisor 375 and OS 380 in the level 3 designated core 105B) can only access the level 3 peripheral 355, and that level 2 resources (e.g., the hypervisor 365 and TEE OS 370 in the level 2 designated core 105A) can only access the level 2 or level 3 peripheral 355. A level 1 resource, such as the trusted OS 310, can manage level 1, level 2, and level 3 peripherals 355.

[0038] Level 1 trusted OS 310 can configure interconnect 330 using CIN configuration register 335 so that only certain portions of memory 360 are accessible to level 1 resources, level 2 resources, and level 3 resources. Memory 360 includes three cross-hatchings to indicate that some memory 360 is allocated to level 1, some to level 2, and some to level 3. Interconnect 330 can provide the same access control as described above, where level 3 resources can only access the portion of memory 360 allocated to level 3. Level 2 resources can access and manage the portions of memory 360 allocated to levels 2 and 3, but may not be able to access and manage the portion of memory 360 allocated to level 1. Level 1 resources can access and manage all of memory 360.

[0039] Although not illustrated, there may be a common memory path for accessing memory 360 using access control circuitry 315B configured by trusted OS 310 to ensure that only level 1, level 2, and level 3 resources can access their respective portions of memory 360. Similarly, SoC 300 may include dedicated I / O peripheral paths within interconnect 330, with trusted OS 310 configuring interconnect 330 such that level 1, level 2, and level 3 resources can access only their respective home I / O gateway paths within interconnect 330 to access their respective I / O peripherals 355.

[0040] In one embodiment, memory 360 may include different types of memory, such as OCM, DDR, and accelerator memory, which may be included in an accelerator engine (not shown) within processor subsystem 390.

[0041] 3, the Level 1 management software (e.g., Trusted OS 310) can then release the cores 105 from reset so that the Level 2 cores 105A, which may have either the ASIL-D hypervisor 365 or the TEE OS 370 locked to themselves, are firewalled blocked from accessing Level 1 resources such as the CIN configuration registers 335, the Level 1 FPD configuration registers 350, the Level 1 I / O peripherals 355, and the Level 1 memory 360. However, the Level 2 cores and hypervisor 365 and / or the TEE OS 370 can manage, configure, or reconfigure Level 2 resources such as the Level 2 FPD configuration registers 350, the Level 2 and 3 peripherals 355, and the Level 2 and 3 memory 360. Additionally, hypervisor 365 and TEE OS 370 (e.g., level 2 management software) can execute level 2 services for and communicate with level 3 hypervisor 375 and OS 380 (e.g., level 3 management software). In one embodiment, level 3 hypervisor 375 can be an ASIL-C / B hypervisor and level 3 OS 380 can be a non-TEE OS. This management software can only access level 3 resources, such as level 3 peripherals 355 and memory 360.

[0042] 3 illustrates level 2 core 105A having both hypervisor 365 and TEE OS 370, and level 3 core 105B having both hypervisor 375 and OS 380, SoC 300 may include one type of management software per level, depending on the application. For example, if SoC 300 is used in a safety-critical application, ASIL-D hypervisor 365 is fixed on core 105A, and an ASIL-C / B hypervisor is executed by core 105B. Alternatively, if SoC 300 is used in a security-critical application, TEE OS 370 is fixed on core 105A, and non-TEE OS 380 is executed on core 105B.

[0043] FIG. 3 illustrates a hierarchical approach from levels 1 to 3 for both hardware and software configuration. FIG. 3 illustrates a hierarchical approach executed in chronological order, where software for setting up the level 1 hierarchy is executed first, followed by software execution for setting up the level 2 (and level 3) hierarchy. However, FIG. 3 also illustrates a hierarchical approach in space where only the level 1, level 2, and level 3 software have access to their respective physical memory and I / O peripheral resources. This two-pronged approach deviates from other techniques where a hypervisor manages all resources in the processor subsystem, and also deviates from techniques where a hypervisor or secure execution privilege level can be invoked by all cores that have the ability to execute a hypervisor or secure execution privilege level, which is typical for multi-core systems built with multiple instances of the same core type. In other words, here only the specific core 105A can execute the safety-critical hypervisor 365 and the TEE OS 370.

[0044] A higher level of functional safety, debug, and security can be achieved by having a basic level 1 with its own private resources and delegating the ASIL-D / hypervisor or TEE OS to level 2, which cannot access any level 1 resources. Meanwhile, the level 2 ASIL-D / hypervisor or TEE OS is locked only to the level 2 cores, with dedicated physical or logical paths to the level 2 memory 360 and peripherals 355. Thus, even if the level 3 core 105B is capable of executing software at the hypervisor or secure execution privilege level, locking the level 2 software to the level 2 core 105A prevents the level 3 core 105B from invoking the hypervisor or secure execution privilege level, thereby improving security and / or safety. Improved security and / or safety may be provided on the level 2 assigned hardware through additional dedicated firewalls or trust attributes along the physical or logical paths to the level 2 memory 360 and peripherals 355.

[0045] Figure 4 illustrates an SoC 300, according to one embodiment. While Figure 3 illustrates the flow of data within SoC 300 from cores 105 to I / O peripherals 355 and memory 360, Figure 4 illustrates the flow of data within SoC 300 from I / O peripherals 355 and memory 360 to cores 105.

[0046] Like Figure 3, Figure 4 includes core 105, PMC 305, interconnect 330, I / O peripherals 355, and memory 360. However, Figure 4 also illustrates GIC 130, which is used to send interrupts to PMC 305 and core 105, and MMU 125, which transfers data from peripherals 355 to core 105 via the interconnect. Access to MMU 125 is controlled by access control circuitry 315C, which may be set by trusted OS 310 while hypervisor 365, TEE OS 370, hypervisor 375, and OS 380 are in reset. Access control circuitry 315C may ensure that lower level resources cannot access portions of MMU 125 that are allocated to higher levels.

[0047] Both GIC 130 and MMU 125 are partitioned and assigned to different levels in the hierarchy. That is, portions of GIC 130 and MMU 125, as well as I / O peripherals 355 and memory 360, are assigned to levels 1, 2, and 3. SoC 300 may include a firewall to prevent data from level 3 resources (e.g., level 3 peripherals 355) from accessing portions of MMU 125 assigned to level 2 or level 3. Similarly, a firewall may ensure that level 2 peripherals 355 cannot access portions of MMU 125 assigned to level 1.

[0048] 5 is a flow chart of a method 500 for partitioning resources in a system-on-chip to form a hierarchy, according to one embodiment. At block 505, the SoC allocates level 1 resources during secure boot. In one embodiment, level 1 is the highest level (e.g., the most trusted or most secure level) at which secure boot is controlled by a loaded root of trust configuration.

[0049] In one embodiment, secure boot loads a trusted OS (e.g., trusted OS 310 of FIG. 3A), which then allocates level 1 resources. During this time, level 2 and level 3 management software (e.g., hypervisor and OS) are held in reset. Additionally, the trusted OS can run on a hardware device (e.g., a PMC or dedicated core) that is either internal to the processor subsystem or external to the processor subsystem.

[0050] In one embodiment, a Level 1 trusted OS configures the interconnects (e.g., cache coherent interconnects) that couple the processor cores to other components in the processor subsystem. The OS may also configure a firewall using access control circuits.

[0051] In one embodiment, the Level 1 trusted OS sets the CIN configuration registers in the interconnect. Furthermore, these registers may only be accessible to Level 1 resources. Therefore, when Level 2 and Level 3 management software are released from reset, they cannot set the CIN configuration registers.

[0052] In one embodiment, the Level 1 trusted OS configures the FPD configuration space using FPD configuration registers 350 of Figure 3. In one example, the trusted OS configures the access control circuitry such that a portion of the FPD configuration registers is allocated to Level 1.

[0053] In block 510, the level 1 management software (e.g., a trusted OS) allocates level 2 resources. In one embodiment, the level 1 trusted OS configures the FPD configuration space to include level 2 FPD configuration registers in addition to the level 1 FPG configuration registers created in block 505. In one example, the trusted OS configures the access control circuitry such that a portion of the FPD configuration registers are allocated to level 2 resources.

[0054] In one embodiment, the trusted OS uses the access control circuitry of Figures 3 and 4 such that certain I / O peripherals 355, portions of memory 360, and portions of MMU 125 are assigned to level 2 and therefore accessible to level 2 resources, such as a hypervisor or OS.

[0055] Block 510 includes an optional sub-block 515 in which the level 1 OS pins the safety-critical hypervisor or TEE OS to a designated processor core of the level 2. That is, the level 1 resource selects a hardware resource (e.g., one of the processor cores in the processor subsystem) on which to run the level 2 management software. By pinning the safety-critical hypervisor or TEE OS to a specific core or cores, this prevents the software from migrating to a different core (e.g., a non-lockstep core) that may not operate in accordance with a particular safety or security standard. Thus, even if the level 3 cores are capable of running the software at the hypervisor or secure execution privilege level, pinning the level 2 management software to the level 2 cores prevents the level 3 cores from invoking the hypervisor or secure execution privilege level, thereby compromising security and / or safety. In addition to pinning the safety-critical software or TEE OS to the level 2 cores, the safety-critical hypervisor or TEE OS may have a dedicated physical or logical path to the level 2 I / O peripherals and memory.

[0056] In block 520, the level 1 trusted OS allocates level 3 resources. In one embodiment, the trusted OS uses the access control circuitry of Figures 3 and 4 to ensure that certain I / O peripherals 355, portions of memory 360, and portions of MMU 125 are allocated to level 3 and therefore accessible to level 3 resources, such as a hypervisor or OS.

[0057] Method 500 illustrates blocks 510 and 520 as successive steps, where the trusted OS can simultaneously create resources for levels 2 and 3. For example, at the same time that the trusted OS configures the access control circuitry to assign I / O peripherals 355, portions of memory 360, and portions of MMU 125 to level 2, the trusted OS can also configure the access control circuitry to assign I / O peripherals 355, portions of memory 360, and portions of MMU 125 to level 3.

[0058] Additionally, although not shown in method 500, level 2 management software can also help create level 3 resources. That is, a level 2 hypervisor or OS can determine how much memory or how many I / O peripherals are allocated for use by a level 3 hypervisor or OS. For example, a level 2 hypervisor, an ASIL-D OS, or a TEE OS can allocate level 3 resources, but within firewalled isolation from level 1 resources (as configured by the level 1 management software).

[0059] In block 525, the trusted OS releases the level 2 and level 3 management software. That is, once the level 2 and level 3 resources have been created, the level 2 and level 3 hypervisors or OSs are then released and can begin using their allocated resources to perform their corresponding functions. In one embodiment, the level 1 management software can release the level 2 and level 3 hypervisors or OSs. In another embodiment, the level 1 management source releases the level 2 hypervisor or OS, which releases the level 3 hypervisor or OS.

[0060] In the foregoing, reference is made to the embodiments presented in this disclosure. However, the scope of the disclosure is not limited to the specific described embodiments. Instead, any combination of the described features and elements, whether related to different embodiments or not, is contemplated for implementing and practicing the contemplated embodiments. Furthermore, the embodiments disclosed herein may achieve other possible solutions or advantages over the prior art, but whether or not a particular advantage is achieved by a given embodiment does not limit the scope of the disclosure. Thus, the above aspects, features, embodiments, and advantages are merely illustrative and are not considered elements or limitations of the appended claims unless expressly recited in the claims.

[0061] As will be appreciated by one of ordinary skill in the art, embodiments disclosed herein may be embodied as a system, method, or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, microcode, etc.), or an embodiment combining software and hardware aspects, all of which may be referred to generally herein as a "circuit," "module," or "system." Furthermore, aspects may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied therein.

[0062] Any combination of one or more computer readable media may be utilized. The computer readable medium may be a computer readable signal medium or a computer readable storage medium. The computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (non-exhaustive list) of computer readable storage media include an electrical connection having one or more wires, a portable computer floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this specification, a computer readable storage medium is any tangible medium that can contain or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0063] A computer-readable signal medium may include a propagated data signal in which computer-readable program code is embodied, for example, in baseband or as part of a carrier wave. Such a propagated signal may take any of a variety of forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A computer-readable signal medium is not a computer-readable storage medium but may be any computer-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0064] The program code embodied on the computer readable medium may be transmitted using any suitable medium, including but not limited to wireless, wireline, fiber optic cable, RF, etc., or any suitable combination of the foregoing.

[0065] Computer program code for carrying out operations of aspects of the present disclosure may be written in any combination of one or more programming languages, including, for example, object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages. The program code may execute completely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer, partially on a remote computer, or completely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider).

[0066] Aspects of the present disclosure are described below with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments presented in the present disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus such that the instructions, executed via a processor of the computer or other programmable data processing apparatus, cause a machine to create means for implementing the functions / acts specified in the blocks of the flowchart and / or block diagrams.

[0067] These computer program instructions may also be stored on a computer-readable storage medium, where the instructions stored on the computer-readable storage medium can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner to produce an article of manufacture including instructions that implement aspects of the functions / acts specified in the flowchart and / or block diagram blocks.

[0068] Computer program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be executed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, such that the instructions executing on the computer or other programmable apparatus provide a process for implementing the functions / acts specified in the flowchart and / or block diagram blocks.

[0069] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions described in the blocks may occur out of the order described in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, or the blocks may be executed in the reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, as well as combinations of blocks in the block diagrams and / or flowchart illustrations, may be executed by a dedicated hardware-based system that performs the specified functions or acts, or a combination of dedicated hardware and computer instructions.

[0070] The above disclosure may be expressed in terms of methods such as the following non-limiting examples.

[0071] In a first exemplary method, the method includes allocating level 1 resources within a SoC during secure boot of the SoC; allocating level 2 resources within the SoC using a level 1 trusted OS loaded during secure boot, where the level 2 resources include a first hypervisor or OS that is held in reset while allocating the level 2 resources; allocating level 3 resources within the SoC using the level 1 trusted OS, where the level 3 resources include a second hypervisor or OS that is held in reset while allocating the level 3 resources, where the level 1 trusted OS is authorized to manage levels 1, 2, and 3 resources, the level 2 resources are authorized to manage level 2 and 3 resources but not level 1 resources, and the level 3 resources are authorized to manage level 3 resources but not level 1 and level 2 resources, and releasing the first hypervisor or OS and the second hypervisor or OS from reset.

[0072] In a second embodiment based on the first embodiment, a first hypervisor or OS is pinned to a first processor core assigned to level 2 resources by a trusted OS such that the first hypervisor or OS cannot migrate to any processor core assigned to level 3 resources, and the first hypervisor or OS is one of a safety-critical hypervisor or a TEE OS.

[0073] In a third embodiment based on the second embodiment, the method further includes, after releasing the first hypervisor or OS, operating the first processor core in lockstep with a second processor core that is also assigned to level 2 resources.

[0074] In a fourth embodiment based on the second embodiment, at least one of (i) the first hypervisor or OS is an ASIL-D hypervisor and the second hypervisor or OS is at least one of an ASIL-B, ASIL-C, or untrusted hypervisor, or (ii) the first hypervisor or OS is a security-critical OS within a TEE and the second hypervisor or OS is a non-security-critical OS not within a TEE.

[0075] In a fifth embodiment based on the first embodiment, allocating level 1, 2, and 3 resources within the SoC further includes allocating a first portion of memory to the level 1 resources, allocating a second portion of memory to the level 2 resources, and allocating a third portion of memory to the level 3 resources, wherein a trusted OS is authorized to manage the first, second, and third portions of memory, a first hypervisor or OS is authorized to manage the second and third portions of memory but not the first portion of memory, and a second hypervisor or OS is authorized to manage only the third portion of memory.

[0076] While the forgoing is directed to specific embodiments, other and further embodiments can be devised without departing from the basic scope thereof, which is determined by the following claims.

Claims

1. A system on chip (SoC), comprising: a first processing element configured to execute a trusted operating system (OS) that is assigned to a first level in the hierarchy; a second processing element configured to execute a first hypervisor or OS assigned to a second level in the hierarchy; a third processing element configured to execute a second hypervisor or OS assigned to a third level in the hierarchy; a first portion of the memory assigned to the first level, a second portion of the memory assigned to the second level, and a third portion of the memory assigned to the third level, the trusted OS being authorized to manage the first, second, and third portions of the memory, the first hypervisor or OS being authorized to manage the second and third portions of the memory but not the first portion of the memory, and the second hypervisor or OS being authorized to manage only the third portion of the memory.

2. 2. The SoC of claim 1, wherein the first hypervisor or OS is pinned to the second processing element by the trusted OS such that the first hypervisor or OS cannot execute on the third processing element, and the first hypervisor or OS is one of a safety-critical hypervisor or an OS in a trusted execution environment (TEE).

3. The SoC of claim 2 , wherein the second processing element is configured to execute in lockstep with a fourth processing element in the second level.

4. 3. The SoC of claim 2, wherein the first hypervisor or OS is an Automotive Safety Integrity Level (ASIL)-D hypervisor and the second hypervisor or OS is at least one of an ASIL-B, ASIL-C, or Untrusted hypervisor.

5. The SoC of claim 2 , wherein the first hypervisor or OS is a security-critical OS in the TEE and the second hypervisor or OS is a non-security-critical OS not in the TEE.

6. 2. The SoC of claim 1 further comprising I / O peripherals, a first portion of the I / O peripherals assigned to the first level, a second portion of the I / O peripherals assigned to the second level, and a third portion of the I / O peripherals assigned to the third level, the trusted OS being authorized to manage the first, second, and third portions of the I / O peripherals, the first hypervisor or OS being authorized to manage the second and third portions of the I / O peripherals but not the first portion of the I / O peripherals, and the second hypervisor or OS being authorized to manage only the third portion of the I / O peripherals.

7. The SoC of claim 1 , further comprising a processor subsystem, the second processing element and the third processing element being respective processor cores within the processor subsystem.

8. 8. The SoC of claim 7, further comprising an interconnect forming a Coherent Interconnect Network (CIN) within the processor subsystem communicatively coupling each of the processor cores to the memory and I / O peripherals, the interconnect comprising CIN configuration registers that can be managed only by resources within the first level of the hierarchy.

9. 9. The SoC of claim 8, further comprising: a full power domain (FPD) configuration register within the processor subsystem, a first portion of the FPD configuration register assigned to the first level, a second portion of the FPD configuration register assigned to the second level, and none of the FPD configuration registers can access resources in the third level.

10. 2. The SoC of claim 1, further comprising level 2 firewall-protected resources assigned to the second level but accessible by resources in both the second and third levels, wherein the third level resources cannot access second level data in the level 2 firewall-protected resources.

11. a memory management unit (MMU) configured to allow I / O peripherals to send data to the first, second, and third processing elements, a first portion of the MMU being assigned to the first level, a second portion of the MMU being assigned to the second level, and a third portion of the MMU being assigned to the third level, the trusted OS being authorized to manage the first, second, and third portions of the MMU, the first hypervisor or OS being authorized to manage the second and third portions of the MMU but not the first portion of the MMU, and the second hypervisor or OS being authorized to manage only the third portion of the MMU; 2. The SoC of claim 1, further comprising: a generic interrupt controller (GIC) configured to send interrupts to the first, second, and third processing elements, wherein a first portion of the GIC is assigned to the first level, a second portion of the GIC is assigned to the second level, and a third portion of the GIC is assigned to the third level, the trusted OS is authorized to manage the first, second, and third portions of the GIC, the first hypervisor or OS is authorized to manage the second and third portions of the GIC but not the first portion of the GIC, and the second hypervisor or OS is authorized to manage only the third portion of the GIC.

12. A SoC, a first processing element configured to execute a trusted operating system (OS) that is assigned to a first level in the hierarchy; 1. A processor subsystem, comprising: a first processor core configured to execute one of a safety-critical hypervisor or a TEE OS, the first processor core being assigned to a second level within the hierarchy; and a processor subsystem comprising: a second processor core configured to execute one of a non-safety-critical hypervisor or a second OS that is not within a TEE, the second processor core being assigned to a third level within the hierarchy; the trusted OS is authorized to manage hardware resources assigned to the first, second, and third levels, the safety-critical hypervisor or the TEE OS is authorized to manage hardware resources assigned to the second and third levels but not to manage hardware resources assigned to the first level, and the non-safety-critical hypervisor or second OS is authorized to manage hardware resources assigned to the third level but not to manage hardware resources assigned to the first and second levels.

13. 13. The SoC of claim 12, wherein the safety-critical hypervisor or the TEE OS is pinned to the first processor core by the trusted OS such that the safety-critical hypervisor or the TEE OS cannot execute on the third processor core.

14. 13. The SoC of claim 12, wherein the first processor core is configured to execute in lockstep with a third processor core in the processor subsystem, the third processor core being assigned to the second level.

15. 13. The SoC of claim 12, wherein the first processing element includes programmable logic configured to load and run the trusted OS as part of a secure boot when the SoC is powered on, the programmable logic being external to the processor subsystem.

Images