Method and apparatus for security isolation of applications
Patent Information
- Application Number
- CN202610574972.4
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2025-04-29
- Filing Date
- 2026-04-28
- Publication Date
- 2026-10-30
Smart Images
Figure CN123013152A_ABST
Abstract
Description
Technical Field
[0001] This disclosure generally relates to the field of processors and central processing units (CPUs), and more particularly to an access control system for a processing system including one or more initiators sharing access to a target resource. Background Technology
[0002] Modern microcontroller units (MCUs) include system-on-chip (SoC) architectures, where interconnects control access to shared resources by one or more initiators (such as central processing units (CPUs), processing cores, virtual machines, etc.). Isolation between initiators' access to shared resources is a key characteristic of such architectures. Attached Figure Description
[0003] Examples of circuits, devices, and / or methods will be described below by way of example only. In such cases, reference will be made to the accompanying figures.
[0004] Figure 1A This is a diagram illustrating an example hierarchy of the power domain in an MCU based on the described aspects.
[0005] Figure 1B It is a block diagram of an example MCU architecture, including the root trust circuitry, based on the described aspects.
[0006] Figure 2 This is a block diagram of an example MCU architecture that utilizes Transaction Identifiers (TIDs) to implement isolation between transaction initiators based on the described aspects.
[0007] Figure 3 It is a block diagram of an example MCU architecture, including security isolation circuitry for verifying target access configuration, based on the described aspects.
[0008] Figure 4 This is a functional block diagram illustrating an example safety isolation circuit based on the described aspects.
[0009] Figure 5 This is a functional block diagram illustrating an example safety isolation circuit based on the described aspects.
[0010] Figure 6 This is a flowchart outlining example methods that can be performed by a safety isolation circuit based on the described aspects.
[0011] Figure 7 This is a flowchart outlining example methods that can be performed by a trust root circuit based on the described aspects. Detailed Implementation
[0012] This disclosure is described with reference to the accompanying drawings. Similar components in the various figures may be represented by similar reference characters. The figures are not drawn to scale and are provided merely for illustrating this disclosure. For illustration, several aspects of this disclosure are described below with reference to example applications. Numerous specific details, relationships, and methods are set forth to provide an understanding of this disclosure. This disclosure is not limited by the order of the illustrated actions or events, as some actions may occur in a different order and / or simultaneously with other actions or events. Furthermore, not all illustrated actions or events are necessary to implement the methods according to the chosen method of this disclosure.
[0013] Figure 1A This is a block diagram illustrating the concept of different power domains or modes in microcontroller 100. In the illustrated example, the microcontroller includes a low-power domain 102, a medium-power domain 104, and an active power domain 106. The power management system 108 selectively activates different power domains based on a number of different factors, including the current operating conditions of the microcontroller, the number or type of operations the microcontroller is invoked to perform, whether power saving is prioritized, and so on. Each power domain includes a set of microcontroller components, such as a central processing unit (CPU) or core, memory, peripheral devices, etc., which are powered on and placed in active mode when the microcontroller operates in the corresponding power mode.
[0014] For example, to enable the microcontroller 100 to operate in a low-power mode, the power management system 108 provides power to the low-power mode components associated with low-power domain 102. To enable the microprocessor to operate in a medium-power mode, the power management system 108 provides power to the low-power mode components associated with low-power domain 102 and the medium-power mode components associated with medium-power domain 104. To enable the microprocessor to operate in an active power mode, the power management system 108 provides power to the low-power mode components associated with low-power domain 102, the medium-power mode components associated with medium-power domain 104, and the active power mode components associated with active power domain 106.
[0015] Therefore, the power domain structure can be conceptualized as a hierarchy, in which the active power domain is the highest power domain or mode, where most or all microcontroller components are powered on and active, while the low power domain is the lowest power domain or mode, where the fewest microcontroller components are powered on and active. In other words, the medium power domain is a power domain lower than the active power domain but higher than the low power domain, and so on. Note that the terms low power domain, medium power domain, and active power domain are used in a general sense and generally indicate a hierarchical power domain. Depending on the microcontroller, these power domains or modes may be referred to as sleep, idle, standby, active, running, low, etc.
[0016] Multi-core microcontrollers can execute multiple independent software applications simultaneously, and software isolation between applications is generally desirable. Access protection mechanisms used by the microcontroller may need to meet ASILD requirements for applications with Automotive Safety Integrity Level D (ASILD) objectives, as well as security requirements for applications with safety objectives. Multiple applications with different safety and assurance objectives (e.g., ASILD, safety, QM, etc.) may be referred to herein as applications with mixed criticality.
[0017] Each application executing on a microcontroller uses a subset of the microcontroller's on-chip resources, such as CPU (e.g., cores, virtual machines) for software execution, memory, direct memory access (DMA), and so on. Different applications may have different requirements regarding the allocation of on-chip resources between applications and the allocation of on-chip resources to different subtasks associated with each individual application. In the sharing of hardware resources, it is desirable, or even required, for different applications to be isolated from each other. In some instances, different tasks or functions of the same application should be isolated from each other. In a general sense, isolation between two application tasks or functions means that each application task can be assigned its own separate access level to shared resources (also referred to herein as targets or transaction targets). For example, access level could be a read and / or write access level to a specific part or function of a target module. In this way, shared resources designated for use by a particular application task can be protected from unauthorized access by the application task.
[0018] Figure 1B This is a block diagram of a microcontroller 100, which includes multiple CPUs or cores 110 that share access to peripheral devices 170 via an interconnect system. In the illustrated example, this interconnect system includes an interconnect 150, a bridge 155, and a peripheral device bus. (As will be...) Figure 2 As described in more detail below, CPU 110 can be characterized as the transaction initiator, while peripheral device 170 can be characterized as the transaction target. CPU 110 communicates with memory and other resources (not shown) via interconnect 150. Interconnect 150 is coupled to peripheral device bus 160 via bridge 155. Root trust circuit 130 is a special initiator, isolated from other transaction initiators via bridge 155 (also shown as firewall 155 within the root trust circuit). Root trust circuit 130 operates in a separate protection domain and provides a secure computing platform or "root of trust." Root trust circuit 130 provides secure key storage, cryptographic operations, and other secure boot-related operations for the microcontroller. In other words, the root trust circuit is a service provider for cryptographic operations requested by any application executed through the microcontroller.
[0019] The illustrated root of trust circuit 130 includes a dedicated CPU 131, which may include a lockstep core, random access memory (RAM) 132, boot read-only memory (ROM) 133, encryption circuitry 134, random number generator 135, and timer circuitry 136. The CPU 131 is configured to execute secure boot instructions stored in the boot ROM 133 when the microcontroller is powered on or reset. Encryption circuitry 134 is dedicated hardware suitable for performing high-speed encryption and decryption operations. Encryption / decryption operations may be based on a key stored in RAM 132, boot ROM 133, other protected memory within root of trust circuitry 130, or external memory accessible only by root of trust circuitry 130. Encryption circuitry 134 may generate a key based on random numbers generated by random number generator 135 or other cores stored in RAM 132, boot ROM 133, other protected memory within root of trust circuitry 130, or external memory accessible only by root of trust circuitry 130.
[0020] A root of trust circuit is a general term for an isolated or protected hardware component that supports security-related operations on a microcontroller. Depending on the microcontroller, a root of trust circuit can be referred to by many different terms, including hardware security modules, etc. (See reference...) Figure 1A As discussed, different initiators and targets can be assigned to different power domains. For example, one CPU of CPU 110 can be assigned to the lowest power domain and configured to maintain minimal microcontroller functionality (e.g., the ability to monitor certain triggers and switch to a higher power mode in response to triggers). Other initiators and targets will be assigned to higher power domains. For example, due to its considerable power consumption, the root trust circuit 130 may not be assigned to the lowest power domain.
[0021] To provide isolation between applications, a transaction identifier (TID) can be included in a transaction provided by initiator 110 to interconnect 150 seeking access to target 170. Each TID is mapped to a specific application or function executed on a particular CPU. At the target, the TID is mapped to a specific type of access, such as read-only access or read and write access.
[0022] Figure 2This is a block diagram of an example microcontroller 200 that uses a TID-based approach to provide isolation between applications. The microcontroller 200 includes three transaction initiators 210, three transaction targets 270, and an interconnect 250 that controls the routing of transactions from initiators to targets. Example initiators include a CPU, an Ethernet controller, a System Direct Media Access (DMA) controller, a CAN XL module, a Fast Peripheral Component Interconnect (PCIe) module, an xGETH DMA module, a Gigabit Ethernet (GETH) DMA, and so on. Transaction targets (e.g., peripheral devices) 270 are associated with shared resources or services. Example transaction targets include Component Object Model (COM) interface control registers, Static Random Access Memory (SRAM), system target functions with control registers, and so on.
[0023] Each initiator includes several sub-modules that can be assigned to different applications. For example, a CPU can have sub-modules (e.g., groups of hardware components) corresponding to different permission modes, virtual machines, operating systems, etc., and each sub-module can be assigned to support different applications / application subtasks. Within a transaction, the different functions of the transaction initiator 210 can be uniquely identified by certain address phase attribute values (e.g., virtual machine (VM) ID, application-specific ID (ASID), machine permission level (M), supervisor permission level (S), user permission level (U), etc.). The transaction also includes opcodes that identify specific access requests (e.g., read or write) to a specific transaction target 270.
[0024] To implement isolation schemes among various applications executing in a microprocessor, an access control mechanism is created, in which different Trust Root IDs (TIDs) are assigned to applications and functions that need to be isolated from each other. The access control mechanism comprises three phases: configuration, execution, and enforcement. Trust root circuitry 230 can execute bootstrap instructions defining the isolation requirements between applications and / or interact with transaction initiators during the startup process to generate a trust root access configuration 285 for each transaction initiator. In initiator access configuration 225, TIDs are mapped to the corresponding applications and / or functions. In target access configuration 265, TIDs are mapped to the appropriate type of access to the transaction target. Access control configuration circuitry 280 provides initiator access configuration 225 and target access configuration 265 to initiator 210 and target 270 respectively (e.g., by transmitting them to initiator 210 and target 270 or otherwise making them accessible).
[0025] Access control enforcement circuitry 220 uses initiator access configuration 225 to select the TID to be attached to a transaction based on the application or function that generated the transaction. The corresponding access control enforcement circuitry 220 may be associated with the corresponding initiator or initiator group 210 and may be implemented in a component within initiator 210, within interconnect 250, or outside of both initiator 210 and interconnect 250.
[0026] In one example, the initiator access configuration 225 includes a set of TID dispatch registers (TARs), where each register maps a TID to one or more specific application subtasks associated with a specific combination of address phase attribute values. Based on the TAR register contents and the address phase attribute values, the access control execution circuitry 220 appends a TID to each transaction generated by the initiator 210.
[0027] Access control configuration circuitry 280 provides a target access configuration 265 for each transaction target. The target access configuration maps a TID to the type of access to the transaction target (e.g., read, read / write, neither read nor write). Different TIDs mapped to the same read / write access can be used to support configurable isolation between initiating submodules and functions, applications, tasks, etc. This highly fine-grained approach can be useful for isolation when there is mixed criticality between and within different applications. Access control enforcement circuitry 260 associated with transaction target 270 receives a transaction with an additional TID and, based on the target access configuration, allows transactions seeking permitted types of access or blocks transactions seeking unpermitted types of access to the transaction target.
[0028] In one example, target access configuration 265 includes a set of TARs, each register mapping access of type TID to a target. Based on the contents of the TAR registers and the transaction opcode (defining the type of access requested), access control enforcement circuitry 260 filters (e.g., allows or disallows) transactions. The corresponding access control enforcement circuitry 260 may be associated with a corresponding transaction target or target group 270 and implemented within the transaction target 270, within the interconnect 250, or in a component outside of both the transaction target and the interconnect 250.
[0029] While in the illustrated example, the root trust circuit 230 generates the initiator access configuration by mapping TIDs to the type of target access, in other examples, other entities may be responsible for assigning TIDs to applications and functions. In this case, the root trust circuit 230 generates the target access configuration, thereby assigning the target access level to each TID in a secure manner. Therefore, the root trust access configuration 285 may include the target access configuration 265 for the transaction target, but not the initiator access configuration 225. In other examples, the root trust access configuration 285 may also include the initiator access configuration 225.
[0030] Recall that, due to its power consumption, the root trust circuit 230 may not belong to the lowest power domain. When the microcontroller exits low-power mode, the root trust circuit 230 must be powered on and used to generate the initiator access configuration 225 and the target access configuration 265, because when the microcontroller is in low-power mode, there is uncertainty about whether the configuration has changed due to error or tampering. This power-on of the microcontroller to implement the isolation scheme delays the time when the microcontroller can begin executing transactions. Furthermore, the root trust circuit 230 must be included in any power domain, which may even include a limited number of components capable of generating or executing transactions including TIDs, increasing power consumption.
[0031] The solution disclosed herein is as follows: By implementing the isolation scheme in a secure isolation circuit, the implementation of a TID-based isolation scheme is allowed even in low-power modes, which belongs to a lower power mode than the root of trust circuit that implements the isolation scheme configuration.
[0032] Figure 3 This is a block diagram of an example microcontroller 300, which includes components related to a reference... Figure 2 The described components are similar to those reflected by reference characters having the same tens and units digits. The microcontroller 300 executes the TID-based access control configuration as described above, wherein the root trust circuit 330 generates and stores a root trust access configuration 385 that includes at least the target access configuration 365. The microcontroller 300 includes a security isolation circuit 390 that can operate in a lower power domain than the root trust circuit 330.
[0033] To extend the implementation of the isolation scheme to a power domain lower than the power domain of the root trust circuit 330, after generating the root trust access configuration 385, the access control configuration circuit 380 provides secure access configuration information 395 to the secure isolation circuit 390. The secure access configuration information 395 is based on the root trust access configuration 385. For example, the secure access configuration information may be a reference value calculated by the access control configuration circuit 380 based on a reference function performed on the target access configuration. When the target access configuration is stored in a TAR set, a reference function may be performed on the values of the bits stored in the TAR set. The reference function may be, for example, a hash function. Different reference values may be calculated for each target access configuration associated with different transaction targets. Alternatively or additionally, the secure access configuration information may include images (one or more) of the target access configurations. The images may provide the secure isolation circuit 390 with sufficient information to recover the target access configuration 365, as will be discussed below.
[0034] After the root trust circuit 330 has generated the root trust access configuration 385 and provided the security access configuration information to the security isolation circuit 390, the microcontroller can enter a lower power mode, in which the root trust circuit 330 can be placed in a shutdown or standby mode, in which the root trust circuit 330 is unable to generate or implement the target access configuration 365.
[0035] When the microcontroller 300 is in low-power mode, the security isolation circuit 390 is powered on and can implement the isolation scheme as follows: The security isolation circuit 390 periodically or in response to a trigger condition reads the target access configuration 365 and verifies it based on the security access configuration information. For example, if the security access configuration information 395 includes a reference value (e.g., a hash value) calculated based on a reference function, with the root trust access configuration 385 as input, the security isolation circuit 390 can perform the reference function on the current target access configuration 365 and compare the resulting value with the reference value. If the values match, it can be determined that the target access configuration 365 has been verified and the isolation scheme remains valid. In this way, even when the microcontroller is in low-power mode and the root trust circuit 330 is unable to implement the target access configuration 365, the security isolation circuit can confirm that the target access configuration 365 remains consistent with the configuration implemented by the root trust circuit.
[0036] Figure 4 This is a block diagram of an illustrated example of a security isolation circuit 490. The security isolation circuit 490 includes a processor (not shown) belonging to a low-power domain and a security memory 495 configured to store secure access configuration information. The security memory 495 may be located within a root trust circuit (e.g., behind a firewall) and / or include hardware- or firmware-based access protection that only allows writes to the root trust circuit. In the illustrated example, memory 495 is configured to store a reference value 496, and optionally, a reference function used by the root trust circuit to generate the reference value.
[0037] The security isolation circuit 490 verifies the target access configuration 365 as follows. The security isolation circuit monitors one or more verification triggers. For example, a verification trigger could be the expiration of a timer that sets a regular period for the verification operation. A verification trigger could be the occurrence of a triggering event, such as a microcontroller transitioning to a lower or higher power domain. In this way, when the microcontroller enters a higher power domain, the target access configuration 365 can be verified before the transaction is provided to the access control enforcement circuit 360. Verification triggers can be provided by external components that detect potential errors or fault conditions associated with the isolation scheme.
[0038] In response to a verification trigger, the security isolation circuit 490 reads the target access configuration 365 and, at 492, calculates a reference value based on the target access configuration. The reference function can be a hash function or any other function that produces a result based on the contents of the target access configuration (e.g., TAR set contents or bits). The reference function can be pre-configured and / or stored in memory 495. At 494, the security isolation circuit 490 compares the calculated reference value with a stored reference value 496. Recall that the stored reference value is received from the root of trust circuitry and is based on the root of trust access configuration. When the calculated reference value matches the stored reference value 496, it can be assumed that the microcontroller operates according to the isolation scheme / TID-based access control configured by the root of trust circuitry.
[0039] When the calculated reference value does not match the stored reference value 496, the safety isolation circuit 490 generates an alarm signal and / or performs other remedial actions. Remedial actions may include generating one or more interrupts, providing a reset command to the microcontroller, and / or, as in the case of resetting the reference value... Figure 5 In more detail, restore the target access configuration.
[0040] Figure 5 This is a block diagram of an example security isolation circuit 590. The security isolation circuit includes a processor (not shown) belonging to a lower power domain than the root trust circuit. The security isolation circuit 590 also includes a security memory 595 configured to store secure access configuration information. The security memory 595 may be located within the root trust circuit (e.g., behind a firewall) and / or include hardware- or firmware-based access protection that only allows writes to the root trust circuit. In the illustrated example, the memory 595 is configured to store an image 597 of the root trust access configuration, which is generated by the root trust circuit during the configuration of the access control mechanism. This image can provide the security isolation circuit 590 with sufficient information to recover the target access configuration 365 (e.g., set bit values in the TAR set). In some examples, the memory 595 may store more than one target access configuration image 597. Multiple images may correspond to different target access configurations associated with different transaction targets. Multiple images may include different images of the same target access configuration 365 corresponding to different Quality of Service (QoS) levels.
[0041] Security isolation circuitry 590 monitors one or more recovery triggers. For example, a recovery trigger could be the expiration of a timer that sets a rule period for the verification operation. A recovery trigger could be the occurrence of a triggering event, such as the microcontroller transitioning to a lower or higher power domain. In this way, when the microcontroller enters a higher power domain, the target access configuration 365 can be restored before the transaction is provided to access control enforcement circuitry 360. Recovery triggers can be provided by an external component that detects potential error or failure conditions related to the isolation scheme. Recovery triggers could be an indication that the Quality of Service (QoS) provided by the microcontroller has changed. In response to this trigger, security isolation circuitry 590 can select a target access configuration image 597 associated with the new QoS. Recovery triggers can correspond to remedial operations triggered by failed verification of the target access configuration, such as... Figure 4 As outlined in the document.
[0042] In response to a recovery trigger, the security isolation circuit 590 restores the target access configuration 365 based on the selected target access configuration image. This can be done, for example, by setting bits in the TAR set to the bit values corresponding to those in the image. In this way, the microcontroller can begin operation according to the isolation scheme configured by the root trust circuit without intervention from the root trust circuit.
[0043] Figure 6 This is a flowchart outlining an example method 600 that can be performed by a safety isolation circuit, such as, for example, […]. Figure 3 , Figure 4 and Figure 5 The safety isolation circuits are 390, 490, or 590. Execution of method 600 can be triggered by the occurrence of certain triggering events. Triggering events may include the controller exiting standby power mode or moving between power modes, a change in QoS provided by the controller, the expiration of a specific time period, etc.
[0044] Method 600 includes, at 610, verifying the target access configuration based on security access configuration information (e.g., see...). Figure 3 The target access configuration (365) is associated with a target device, such as, for example, a peripheral device or protected memory. The target access configuration may be stored, for example, in a TID dispatch register (TAR), which maps a TID to the appropriate type of access to the target device. Access types include read or write access. Security access configuration information can be received from the root trust circuitry, such as from Figure 1, etc. Figure 2 and Figure 3 The circuit 130, 230 or 330 receives the signal.
[0045] In one example, the security access configuration information includes a reference value calculated based on a reference function, using the target access configuration of the trust root as input. The reference function could be, for example, a hash function performed on the content of a TAR. In this example, the target access configuration can be verified by, for example, performing the reference function on the target access configuration (e.g., the content of the TAR set associated with the target) to generate the calculated reference value and comparing the calculated reference value with a reference value. When the calculated reference value matches the reference value, the target access configuration is considered verified, and the method terminates until it is triggered again.
[0046] Alternatively or additionally, the security access configuration information may include an image of the root trust access configuration. This image may correspond to, represent, or otherwise capture bit settings in the TAR associated with the target in a manner that allows the TAR associated with the target to be restored to the root trust access configuration using that image.
[0047] The method includes, at 620, performing one or more remedial actions in response to a failed verification. Remedial actions may include restoring the target access configuration based on security access configuration information. For example, when the security access configuration information includes an image of a trusted root access configuration, the content of the TAR for the target may be set based on that image. Remedial actions may include transmitting an alarm signal or triggering a controller reset.
[0048] Figure 7 This is a flowchart outlining example method 700, which can be executed by a root of trust circuit, such as those shown in Figure 1. Figure 2 and Figure 3 Circuits 130, 230, or 330 are executed. Method 700 includes, at 710, generating a target access configuration that maps the transaction initiator to an access level to the target. This target access configuration may be referred to herein as a root of trust access configuration. For example, as... Figure 2 As outlined herein, access configurations can be generated. Access configurations may include settings for the TAR associated with the target (e.g., ...). Figure 2 The information of the bit value in (265).
[0049] At 720, the method includes providing secure access configuration information to the secure isolation circuit, such as, for example, respectively Figure 3 , Figure 4 and Figure 5 The security isolation circuits are 390, 490, or 590. The security isolation operates in a lower power domain than the root trust circuit. Security access configuration information is generated by the root trust circuit based on the target access configuration. In some examples, the security access configuration information includes reference values calculated based on the target access configuration. In some examples, the security access configuration information additionally or alternatively includes a map of the target access configuration.
[0050] In this specification and the appended claims, the term "determine" is used when referring to entities (e.g., parameters, variables, etc.) in describing method steps or functions and should be interpreted broadly. For example, "determine" should be interpreted to cover, for example, receiving and parsing communications that encode entities or entity values. "Determine" should be interpreted to cover accessing and reading memory (e.g., lookup tables, registers, device memory, remote memory, etc.) that stores entities or entity values. "Determine" should be interpreted to cover calculating or deriving the value of an entity or entity based on other quantities or entities. "Determine" should be interpreted to cover any manner of inferring or identifying the value of an entity or entity.
[0051] As used herein, the term "identifier," when used with reference to an entity or the value of an entity, should be broadly interpreted to cover any manner in which an entity or the value of an entity is determined. For example, the term "identifier" should be interpreted to cover, for example, receiving and parsing communications that encode the value of an entity or entity. The term "identifier" should be interpreted to cover memory (e.g., device queue, lookup table, register, device memory, remote memory, etc.) that accesses and reads the value of an entity or entity.
[0052] As used herein, the term "indicator," when used to refer to an entity (e.g., a parameter or setting) or the value of an entity, should be broadly interpreted to encompass any manner in which an entity or the value of an entity is explicitly or implicitly transmitted. For example, bits within a transmitted message may be used to explicitly encode the indicated value, or may encode an index or other indicator mapped from a previous configuration to the indicated value. The absence of a field within a message may implicitly indicate the value of an entity based on a previous configuration.
[0053] While the invention has been described and illustrated with respect to one or more embodiments, changes and / or modifications may be made to the illustrated examples without departing from the spirit and scope of the appended claims. In particular, with respect to the various functions performed by the components or structures (assemblies, devices, circuits, systems, etc.) described above, unless otherwise indicated, the terminology used to describe such components (including references to “component”) is intended to correspond to any component or structure that performs the specified function of the described component (e.g., functionally equivalent), even if structurally not equivalent to the disclosed structures that perform the functions of the exemplary embodiments of the invention illustrated herein.
[0054] Examples may include subjects such as methods, components for performing the methods or blocks, and at least one machine-readable medium including instructions that, when executed by a machine, cause the machine to perform operations according to the embodiments and examples described herein.
[0055] Example Example 1 is a controller that includes a transaction target; access control enforcement circuitry; a root trust access control configuration circuitry; and a security isolation circuitry. The access control enforcement circuitry is configured to filter transactions requesting access to the transaction target based on the target access configuration. The root trust access control configuration circuitry is coupled to the transaction target and is configured to generate a root trust target access control configuration for the transaction target, wherein the root trust target access control configuration maps transaction initiators to access levels to the transaction target; and to provide the target access control configuration to the access control enforcement circuitry, wherein the target access control configuration is based on the root trust target access control configuration. The security isolation circuitry includes a memory for storing security access configuration information, wherein the security access configuration information is based on the root trust target access control configuration, and a processor. The processor is configured to receive the security access configuration information from the root trust access control configuration circuitry; verify the target access configuration based on the security access configuration information; and, in response to a failed verification of the target access configuration, perform one or more remedial operations.
[0056] Example 2 includes the subject matter of Example 1, including or omitting optional elements, wherein the security isolation circuit is in a lower power domain than the access control implementation circuit.
[0057] Example 3 includes the subject of Example 1, including or omitting optional elements, wherein the security isolation circuit is in a lower power domain than the trust root access control configuration circuit.
[0058] Example 4 includes the subject of Example 1, including or omitting optional elements, wherein the security access configuration information includes reference values calculated based on a reference function and a target access configuration of the root of trust; and the security isolation circuit is configured to execute a reference function on the target access configuration to generate the calculated reference values; and compare the calculated reference values with the reference values to verify the target access configuration.
[0059] Example 5 includes the subject of Example 1, including or omitting optional elements, wherein the security access configuration information includes a map of the target access configuration.
[0060] Example 6 includes the subject of Example 1, including or omitting optional elements, wherein the security isolation circuit is configured to verify the target access configuration in response to the controller entering different power modes.
[0061] Example 7 includes the subject of Example 1, including or omitting optional elements, wherein the security isolation circuit is configured to restore the target access configuration based on the security access configuration information in response to a recovery trigger.
[0062] Example 8 includes the subject of Example 7, including or omitting optional elements, where the recovery trigger includes the controller entering different power modes.
[0063] Example 9 includes the subject of Example 7, including or omitting optional elements, where the recovery trigger includes a target access configuration that does not correspond to the current Quality of Service (QoS) access control configuration.
[0064] Example 10 includes the subject of Example 1, including or omitting optional elements, wherein one or more remedial actions include transmitting an alarm signal, triggering a controller reset, or restoring the target access configuration.
[0065] Example 11 is a security isolation circuit including a memory configured to store security access configuration information; and a processor configured to verify a target access configuration associated with a transaction target based on the security access configuration information, and to perform one or more remedial operations in response to a failed verification.
[0066] Example 12 includes the subject of Example 11, including or omitting optional elements, wherein the processor is configured to receive secure access configuration information from the root trust circuit.
[0067] Example 13 includes the subject of Example 12, including or omitting optional elements, wherein the processor is configured to execute a reference function on the target access configuration to generate a computed reference value, and wherein the security access configuration information includes a reference value computed based on the trust root target access configuration.
[0068] Example 14 includes the subject of Example 11, including or omitting optional elements, wherein the security access configuration information includes an image of the trusted root access configuration.
[0069] Example 15 includes the subject of Example 11, including or omitting optional elements, wherein the processor is configured to verify the target access configuration in response to the controller changing the power mode.
[0070] Example 16 includes the subject of Example 11, including or omitting optional elements, wherein one or more remedial actions include restoring the target access configuration based on security access configuration information.
[0071] Example 17 includes the subject of Example 11, including or omitting optional elements, wherein one or more remedial actions include transmitting an alarm signal or triggering a controller reset.
[0072] Example 18 is a root trust circuit that includes a processor coupled to memory and is configured to, when executing instructions stored in memory, generate a target access configuration that maps transaction initiators to access levels to targets; and provide security access configuration information to a security isolation circuit operating in a lower power domain than the root trust circuit, the security access configuration information being generated based on the target access configuration.
[0073] Example 19 includes the subject of Example 18, including or omitting optional elements, wherein the security access configuration information includes reference values calculated based on the target access configuration.
[0074] Example 20 includes the subject of Example 18, including or omitting optional elements, wherein the security access configuration information includes an image of the target access configuration.
[0075] The various illustrative logics, logic blocks, modules, circuits, and circuits described in connection with the aspects disclosed herein can be implemented or performed using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. The general-purpose processor may be a microprocessor, but alternatively, the processor may be any conventional processor, controller, microcontroller, or state machine.
[0076] In this disclosure, similar reference numerals are always used to refer to similar elements, and the structures and devices illustrated herein are not necessarily drawn to scale. As used herein, the terms “module,” “component,” “system,” “circuit,” “circuitry,” “element,” “piece,” and the like are intended to refer to computer-related entities, hardware, software (e.g., in execution), and / or firmware. For example, a circuit or similar term can be a processor, a process running on a processor, a controller, an object, an executable program, a storage device, and / or a computer having processing equipment. By way of illustration, an application running on a server and a server can also be a circuit. One or more circuits may reside within a process, and circuits may be localized on one computer and / or distributed across two or more computers. Collections of elements or other collections of circuits may be described herein, wherein the term “collection” can be interpreted as “one or more.”
[0077] As another example, a circuit or similar term can be a device having specific functionality provided by mechanical parts operated by electrical or electronic circuitry, wherein the electrical or electronic circuitry can be operated by a software application or firmware application executed by one or more processors. The one or more processors can be internal or external to the device and can execute at least a portion of the software or firmware application. As yet another example, a circuit can be a device providing specific functionality through electronic components without mechanical parts; the electronic components can include field gates, logic components, hardware-coded logic, register transfer logic, wherein one or more processors are used to execute software and / or firmware that at least partially endow the electronic components with functionality.
[0078] The term “exemplary” is used to present concepts in a specific manner. The terms used herein are for the purpose of describing particular examples only and are not intended to limit the examples. As used herein, the singular forms “a,” “one,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises,” “comprising,” “includes,” and / or “including,” as used herein, specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. As used herein, the term “or” includes options for all elements associated with the word “or.” For example, A or B should be interpreted as including only A, only B, and both A and B. Additionally, the phrase “one or more of…” followed by A, B, or C should be interpreted as including A, B, C, AB, AC, BC, and ABC.
Claims
1. A controller, comprising: Transaction objective; Access control enforcement circuitry is configured to filter transactions requesting access to the target transaction based on the target access configuration; The root trust access control configuration circuit, coupled to the transaction target, is configured as follows: Generate a trust root target access control configuration for the transaction target, where the trust root target access control configuration maps the transaction initiator to the access level to the transaction target; and Provide a target access control configuration to the access control enforcement circuitry, wherein the target access control configuration is based on the root trust target access control configuration; as well as Safety isolation circuit, including: A memory for storing security access configuration information, which is based on a root trust target access control configuration. as well as The processor is configured as follows: Receive security access configuration information from the root trust access control configuration circuitry; Verify the target access configuration based on the security access configuration information; and In response to a failed verification of the target access configuration, perform one or more remedial actions.
2. The controller of claim 1, wherein the security isolation circuit is in a lower power domain than the access control implementation circuit.
3. The controller of claim 1, wherein the security isolation circuit is in a lower power domain than the root trust access control configuration circuit.
4. The controller according to claim 1, wherein The security access configuration information includes reference values calculated based on the reference function and the trust root target access configuration; as well as The safety isolation circuit is configured as follows: Execute a reference function on the target access configuration to generate a calculated reference value; as well as The calculated reference value is compared with the reference value to verify the target access configuration.
5. The controller of claim 1, wherein the security access configuration information includes an image of the target access configuration.
6. The controller of claim 1, wherein the security isolation circuit is configured to verify the target access configuration in response to the controller entering different power modes.
7. The controller of claim 1, wherein the security isolation circuit is configured to restore the target access configuration based on the security access configuration information in response to a recovery trigger.
8. The controller of claim 7, wherein the recovery trigger includes the controller entering a different power mode.
9. The controller of claim 7, wherein the recovery trigger includes the target access configuration not corresponding to the current Quality of Service (QoS) access control configuration.
10. The controller of claim 1, wherein the one or more remedial actions include transmitting an alarm signal, triggering the controller to reset or restore the target access configuration.
11. Safety isolation circuit, including: The memory is configured to store secure access configuration information; as well as The processor is configured to verify the target access configuration associated with the transaction target based on security access configuration information, and to perform one or more remedial operations in response to failed verification.
12. The security isolation circuit of claim 11, wherein the processor is configured to receive security access configuration information from the root trust circuit.
13. The security isolation circuit of claim 12, wherein the processor is configured to execute a reference function on the target access configuration to generate a calculated reference value, and wherein the security access configuration information includes a reference value calculated based on the root trust target access configuration.
14. The security isolation circuit of claim 11, wherein the security access configuration information includes a map of the root trust access configuration.
15. The security isolation circuit of claim 11, wherein the processor is configured to verify the target access configuration in response to a change in power mode by the controller.
16. The security isolation circuit of claim 11, wherein the one or more remedial operations include restoring the target access configuration based on security access configuration information.
17. The security isolation circuit of claim 11, wherein the one or more remedial operations include transmitting an alarm signal or triggering a controller reset.
18. A root trust circuit, comprising a processor coupled to memory, and the processor being configured to, when executing instructions stored in memory, Generate target access configurations that map transaction initiators to access levels on the target; and Security access configuration information is provided to security isolation circuits operating in a lower power domain than the root trust circuit. The security access configuration information is generated based on the target access configuration.
19. The root trust circuit of claim 18, wherein the secure access configuration information includes reference values calculated based on the target access configuration.
20. The root trust circuit of claim 18, wherein the secure access configuration information includes an image of the target access configuration.