Method and system for multi-modal security access control based on security situation details

Abstract

Methods and systems for multi-modal secure access control of a system on a chip (SoC) are disclosed herein. In an example embodiment, a method includes providing a secure bay including a plurality of bus master and a sentinel resource domain controller (SRDC), and receiving a request for access control, assets, or resources. The method additionally includes evaluating a plurality of attributes, the plurality of attributes including each of: a first attribute that is a privilege mode attribute; a second attribute relating to applicability or non-applicability of a runtime root of trust (RRoT) mode; a third attribute related to the bus master type; and a fourth attribute related to the security state. The method additionally includes determining whether to grant or reject the request based on the attribute; and based on the determination, making the control, asset or resource for which the request is directed accessible or inaccessible.

Description

Technical Field

[0001] The present disclosure relates to processing methods and systems, and more particularly, to methods and systems for providing or achieving a desired or enhanced level of security with respect to access to controls, resources or assets of a processing device, such as a central processing unit or other computer systems and devices. Background Art

[0002] Computer processing devices such as systems on a chip (SoC) often operate relative to or within a variety of sensitive controls or assets. Whether to grant access to such controls or assets is an important consideration based on whether the SoC can operate in a manner that achieves a desired level of security and / or achieves other performance goals.

[0003] Conventional SoCs often operate to determine whether access to sensitive controls and assets can be granted by operating in a single central processing unit (CPU) security mode that distinguishes the trust level of access permissions to all types of sensitive controls or assets within the SoC. This trust level is based solely on the execution sequence on a specific CPU. The execution monitor determines that the CPU logically follows a specific sequence and then establishes a security, monitoring, or normal access control credential. The establishment of trust in the SoC provides a single security credential with one, two, or three security levels from the least privileged to the most privileged. This credential is then carried over all subsequent bus transactions so that bus access control can allow bus transactions initiated from the CPU to have or not have access to resources or assets depending on the CPU security mode.

[0004] For at least one or more reasons, it would be advantageous if new or improved processing methods and / or systems could be developed to solve one or more problems or provide one or more benefits. Summary of the invention

[0005] According to a first aspect of the present invention, there is provided a method for multimodal secure access control of a system on chip (SoC), the method comprising:

[0006] Providing a secure enclave including multiple bus masters and a Sentinel Resource Domain Controller (SRDC);

[0007] receiving a request from a first bus master of the plurality of bus masters to access a control, asset, or resource;

[0008] A plurality of attributes associated with the request are evaluated, wherein the plurality of attributes include each of:

[0009] The first attribute is the permission mode attribute;

[0010] The second property, which relates to the applicability or non-applicability of the Runtime Root of Trust (RRoT) model;

[0011] A third attribute, which is related to the bus master type; and

[0012] The fourth attribute is related to the security status;

[0013] determining whether to grant or deny the access request based on the plurality of attributes associated with the request; and

[0014] The control, asset, or resource targeted by the access request is made accessible or inaccessible based on the determination.

[0015] In one or more embodiments, the plurality of attributes that are evaluated additionally include a fifth attribute related to a visit location.

[0016] In one or more embodiments, the fifth attribute has a higher sensitivity value when the control, asset, or resource targeted by the request is in an internal location, and has a lower sensitivity value when the control, asset, or resource targeted by the request is in an external location.

[0017] In one or more embodiments, the plurality of attributes additionally includes access type items such as read (R), write (W), or execute (X) characteristics.

[0018] In one or more embodiments, the plurality of attributes being evaluated additionally includes a fifth attribute, the fifth attribute being a domain identifier (DID) or ring number attribute.

[0019] In one or more embodiments, the permission mode attribute is one of a machine mode group, a monitor mode group, or a user mode group.

[0020] In one or more embodiments, the first bus master is a central processing unit (CPU).

[0021] In one or more embodiments, the bus master type relates to one of a CPU, a secure direct memory access (DMA), and a runtime integrity checker (RTIC).

[0022] In one or more embodiments, the security state is one of an unknown state, a secure state, a failed state, and a debug state.

[0023] In one or more embodiments, the fourth attribute related to the security state is at least partially determined by a state machine at least indirectly based on one or more of debug or test detection information, local environment information received from one or more sensors, and chip lifecycle information.

[0024] In one or more embodiments, the request or further requests are received via an off-platform trusted bus or an off-platform common bus.

[0025] In one or more embodiments, first information regarding at least some of the plurality of attributes is received by a crossbar switch, which in turn transmits the first information or second information based on the first information for receipt by the SRDC.

[0026] In one or more embodiments, the determination of whether to grant or deny the request further considers which of a plurality of local access control policies within a permission mode group corresponding to the permission mode attribute is applicable, wherein the permission mode attribute further corresponds to a specified domain identifier (DID) associated with the address space descriptor.

[0027] In one or more embodiments, the request can be granted in each of the following situations: a first situation, in which a first attribute of the multiple attributes indicates that a higher security threshold should be met when a second attribute of the multiple attributes indicates that only a lower security threshold needs to be met; and a second situation, in which even if the second attribute of the multiple attributes indicates that the higher security threshold should be met, the first attribute of the multiple attributes indicates that only the lower security threshold needs to be met.

[0028] In one or more embodiments, the method additionally includes sharing trust information between a first subsystem and a second subsystem including the secure enclave.

[0029] According to a second aspect of the present invention, there is provided a method for multimodal secure access control of a system on chip (SoC), the method comprising:

[0030] providing a secure enclave including a plurality of bus masters and a sentinel resource domain controller (SRDC), wherein the plurality of bus masters includes a first bus master, the first bus master being a central processing unit (CPU);

[0031] receiving a request from the first bus master to access a control, asset, or resource;

[0032] A plurality of attributes associated with the request are evaluated, wherein the plurality of attributes include each of:

[0033] A first attribute, which is a domain identifier (DID) attribute;

[0034] The second attribute is the ring number attribute;

[0035] The third attribute is the permission mode attribute;

[0036] a fourth property, which relates to the applicability or non-applicability of the Runtime Root of Trust (RRoT) model;

[0037] a fifth attribute, which is related to the bus master type; and

[0038] The sixth attribute is related to the security status;

[0039] determining whether to grant or deny the access request based on the plurality of attributes associated with the request; and

[0040] The control, asset, or resource targeted by the access request is made accessible or inaccessible based on the determination.

[0041] In one or more embodiments, any of the following is true:

[0042] The additional request is received via an off-platform trusted bus or an off-platform public bus; or

[0043] The control, asset, or resource targeted by the request is made at least indirectly accessible via a communication signal sent by the secure enclave onto the off-platform trusted bus or off-platform common bus.

[0044] In one or more embodiments, the fourth attribute related to the security state is at least partially determined by a state machine at least indirectly based on one or more of debug or test detection information, local environment information received from one or more sensors, and chip lifecycle information.

[0045] According to a third aspect of the present invention, there is provided a system for providing multimodal secure access control to a system on chip (SoC), the system comprising:

[0046] a secure enclave comprising a plurality of bus masters, a sentinel resource domain controller (SRDC) at least indirectly coupled to the plurality of bus masters, and at least one port by which the secure enclave can be coupled to at least one external bus,

[0047] The SRDC is configured as follows:

[0048] receiving, at least indirectly from a first bus master of the plurality of bus masters, a request to access a control, an asset, or a resource;

[0049] evaluating a plurality of attributes associated with the request, wherein the plurality of attributes include each of: a first attribute that is a permission mode attribute; a second attribute that relates to applicability or non-applicability of a Runtime Root of Trust (RRoT) mode; a third attribute that is related to a bus master type; and a fourth attribute that is related to a security state;

[0050] making a determination as to whether to grant or deny the access request based on the plurality of attributes associated with the request; and

[0051] The control, asset, or resource targeted by the access request is made accessible or inaccessible based on the determination.

[0052] In one or more embodiments, the SRDC includes an SRDC enhanced access rights control mechanism having an SRDC trust factor attribute section and a fabric switch section, and a destination SRDC,

[0053] The secure enclave has a hardware security state machine, wherein the plurality of bus masters include a central processing unit (CPU) and a memory processing unit (MPU), and

[0054] The SRDC is distributed across multiple sub-modules instantiated throughout the system.

[0055] These and other aspects of the invention will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] Figure 1 is a schematic diagram illustrating a system (or secure enclave) according to example embodiments contemplated herein, the system operating according to a multimodal access control architecture and specifically employing a Sentinel (Security) Resource Domain Controller (SRDC);

[0057] Figure 2 is a schematic diagram illustrating a process according to example embodiments covered herein, by which: Figure 1 The SRDC of the partition is configured to combine access control items to implement bus transaction identity;

[0058] Figure 3 is a schematic diagram illustrating an example multimodal access control architecture according to example embodiments covered herein, and in particular illustrating aspects of a security subsystem with multimodal trust attributes;

[0059] Figure 4 is a schematic diagram showing the process by which Figure 1 SRDC of the partition performs SRDC access control policy selection; and

[0060] Figure 5 is a schematic diagram illustrating a combined system having multiple security subsystems that operate together based on shared trust attribute information. DETAILED DESCRIPTION

[0061] Although conventional SoCs are configured to determine whether access to sensitive controls or assets may be granted and employ methods for determining whether access to sensitive controls or assets may be granted, conventional arrangements are often disadvantageous in certain respects. Specifically, such existing systems and methods are often inefficient because access to sensitive controls or assets may only be granted in limited circumstances, or access to sensitive controls or assets may be prohibited too frequently. For example, there is the concept of a security violation that may occur during the operation of the SoC and indicate that something has gone wrong. However, when the SoC access control system in a conventional SoC detects this condition, it simply "panics" and the system's only reaction is to stop all security functions and SoC access to protected resources and assets, and wait for a reset so that it can restart again in the appropriate sequence and continue again in one of its CPU security modes.

[0062] The inventors have recognized that a significant problem associated with conventional processing methods or systems for governing access to sensitive controls or assets, such as those implemented in or relative to a SoC, is that such methods or systems are overly simplistic in that they rely only on a single security mode in determining trust levels or establishing SoC access control configurations.

[0063] More specifically, the inventors have recognized that conventional methods or systems that determine trust, access, or security by employing a single-mode SoC security that may be based on the CPU execution state of a single core are inadequate because a SoC security violation that occurs in such methods or systems typically indicates only one type of security failure, but is typically caused by the aggregation of signals from numerous security event detection sources with different sensing capabilities, ranges, and physical locations. Such conventional methods or systems are limited in effectiveness because such conventional methods or systems only provide a SoC access control system that expresses all trustworthiness based on one of its CPU execution states and reacts to all security events as if all security is compromised given only that one security mode. In scenarios where a security violation indicates something went wrong, regardless of what was determined to be the problem (e.g., which sensor detected a threat condition), there is currently no way to express this as a type of factor to modify access control accordingly. That is, when a violation occurs, CPU execution must stop, but in reality only one aspect of trustworthiness may be compromised, which one aspect may be independent of the CPU execution state, and the CPU security mode may continue in the presence of a security event.

[0064] The inventors have further particularly recognized that the actual trustworthiness of a SoC involves more factors within the SoC than just the measurement results of the logical execution flow from a particular CPU. In fact, the inventors have recognized that there are a considerable number of factors that may affect the trustworthiness of the SoC (or the trustworthiness in the SoC), and in addition, the type of trust desired may also vary depending on the current set of SoC conditions. For example, the state of memory contents may affect trustworthiness. In addition, other factors that may affect trustworthiness may include physical operating environments such as voltage stability or levels, clock frequencies, and temperatures. In addition, another factor may be whether the execution sequence is initiated by immutable software or loadable firmware. And, for example, pin configuration and state may affect the susceptibility of the SoC (and is simpler and more robust than complex execution flows). In addition, the desired security level and trustworthiness level may vary depending on the type of operating environment or context. For example, some execution environments are designed and built for robust, trusted, predictable, and limited behavior, while other execution environments with the same SoC may be quite open and feature-rich and varied for high performance of a variety of applications of interest.

[0065] In view of these considerations, the inventors have additionally recognized that there is a need for an improved method or system for implementing in (or with respect to) a processing device such as a SoC for: assessing trustworthiness; determining whether access to a sensitive control, resource, or asset should be granted; and thereby providing security in a more desirable and enhanced manner than conventional methods or systems. The inventors have further recognized that this improved method or system for implementing in (or with respect to) a processing device such as a SoC can be implemented in at least some of the embodiments covered herein by adopting a set of more optimized and different security modes. This improved method or system adopting a set of more optimized and different security modes can, for example, operate to provide access to corresponding controls, resources, or assets depending on the type of security violation or event that may occur or where such security violation or event is located (e.g., what location is at the highest risk), and can also allow continued use and safe operation of an environment for which risk has not increased due to the detection of a security violation or event. This improved method or system may further allow for an overall more capable and robust SoC that can handle security issues as they occur and restrict access to only those controls, resources, and / or assets that are threatened.

[0066] The inventors have further recognized that this improved method or system for implementation in (or relative to) a processing device such as a SoC can be implemented in at least some embodiments covered herein by adopting a method of parsing different types of security conditions into a set of bus access controls. And, the inventors have recognized that this improved method or system can be implemented in at least some embodiments covered herein as a security system within a SoC that uses multiple security events and security status indications to enter one of multiple security modes and / or uses a set of access controls combined at access points to allow or deny access to various resources and controls such as memory partitions, passwords, keys, security functions, etc. Different security conditions can provide different elevated or reduced permissions.

[0067] The inventors further recognize that in at least some embodiments covered herein, an improved method or system for determining whether access to sensitive controls, resources, or assets should be granted and for providing security therewith in a more desirable and enhanced manner may be operated by adopting a multimodal security access control that takes into account various details of the security situation. In some such embodiments, the system may include a secure enclave, and the method may include providing a secure enclave, the secure enclave including multiple bus masters and a sentinel resource domain controller (SRDC). The SRDC may include an SRDC enhanced access rights control mechanism having an SRDC trust factor attribute segment and a structural switch segment, and a destination SRDC. Furthermore, the secure enclave may have a hardware security state machine. The system is operable to receive a request to access one or more controls, assets, or resources from a bus master, and the method may include receiving a request to access one or more controls, assets, or resources from a bus master. Furthermore, the system is operable to evaluate multiple attributes associated with the request, and the method may include evaluating multiple attributes associated with the request. Such attributes may take any of a variety of forms, such as a permission mode attribute (whether Runtime Root of Trust (RRoT) mode is applicable), an attribute about the bus master type, an attribute about the security state, an attribute about the domain identifier (DID), or a ring number attribute. Based on any of such attributes, a request to access a control, asset, or resource may be granted or denied, and if granted, access to the control, asset, or resource may be permitted or facilitated.

[0068] See also Figure 1, a schematic diagram 100 is provided to graphically illustrate a system referred to as a secure enclave (or simply an enclave) 102 that employs a variety of access control modes to partition its memory map and protect controls, resources, and / or assets (e.g., code, data, and control) under different circumstances and capabilities. The enclave 102 includes a plurality of bus masters 104, including a central processing unit (CPU) 106 (other example bus masters are further described below). Depending on the embodiment, the CPU 106 may also include, or may operate in combination with, a memory protection unit (MPU) 108, shown in dashed lines. The enclave 102 operates to grant or deny access to any of a variety of controls, assets, and / or resources including, but not limited to, for example, code, data, control, peripherals, or memory locations (e.g., the first 4K of a memory location).

[0069] To achieve this operation, in the current embodiment, the partition 102 includes a Sentinel Resource Domain Controller (SRDC) 110, which is an integrated scalable architectural framework for access control, Sentinel memory protection, and peripheral device isolation. It provides mapping of CPU privilege modes, SRDC states, and LMDA (Lifecycle Management and Debug Authentication) states to protection modes, rings, and domains. The access control scheme defined by SRDC 110 supports a 4-level hierarchical ring definition, where: Ring0>Ring1>Ring2>Ring3. In addition, in addition to adopting the aforementioned architectural framework, SRDC 110 also adds another layer of access control, namely a three-level privilege mode including machine mode, monitor mode, and user mode, where: machine mode>monitor mode>user mode. In addition, different access control policies based on read, write, and execute (R / W / X) references are supported. Together with the permission (PRIV) and ring (RING) attributes, a domainID (DID) is generated for each transaction, and the domainID forms the hardware basis for the access control mechanism for implementing SRDC.

[0070] Further with respect to the present example embodiment, the SRDC 110 operates in a manner in which there is an assignment of chip resources to processing "domains". In this regard, each bus master is assigned a unique domain identifier (DID) for each of the four LMDA states (RROT / unknown, debug, secure, disabled), where the DID is an attribute associated with each system bus transaction, and is used in conjunction with a ring number attribute generated based on the SRDC software mode and the LMDA state. Also, a privilege mode (e.g., of the CPU 106) is also attached to each bus transaction. For non-CPU masters, the privilege mode is inherited from the privileges of the master that programmed it, or is programmed in the SRDC DAC registers. This mode of operation provides a three-dimensional array of programmable access control rights (PRIV, DID, Ring), which is built based on a four-level hierarchical access control model (again, where Ring0>Ring1>Ring2>Ring3) with three permission modes (again, where machine mode (MM)>monitor mode (SM)>user mode (UM)) defined by multiple user-programmable R / W / X (read, write, execute) flag sets per access state.

[0071] In addition, in the current embodiment, there may be access control to the slave address space using a memory checker. More specifically, in this regard, there may be three types of SRDC memory checkers: (a) a memory block checker (MBC) having fixed-size blocks for DMEM and IMEM; (b) a memory slot checker (MRC) having a user-defined area for ROM, PKCDMEM, and memory space outside the security subsystem; and (c) a peripheral slot checker (PSC) having a fixed-size block for peripherals. In addition, in the current embodiment, the programming model and hardware implementation are distributed over multiple sub-modules that support a wide range of largely configurable architectural definitions and support effective mechanisms for mode and state changes. In addition, in the current embodiment, SRDC includes a programmable software mode that allows the core to control entry and exit of operating modes. In addition, in the current embodiment, there may be an option to generate an interrupt request to the sentinel CPU in the event of an access violation.

[0072] In at least some embodiments, the SRDC implementation may be distributed across multiple submodules instantiated throughout a device or system. For example, in one example embodiment, SRDC may include each of the following SRDC submodules: (1) SRDC_MGR-Manager (MGR) submodule coordinates all programming model reads and writes; (2) SRDC_DAC-Domain Assignment Controller (DAC) handles the generation of domain identifiers and ring numbers for each master; (3) SRDC_MRC-Memory Region Checker (MRC) implements access control for on-chip internal and external memory based on pre-programmed descriptor registers; (4) SRDC_MBC-Memory Block Checker (MBC) implements access control for on-chip internal memory based on a fixed block size format; and (5) SRDC_PSC-Peripheral Device Slot Checker (PSC) implements access control for sentinel peripherals based on pre-programmed slot descriptor registers. Also, in at least some embodiments, the SRDC submodules only support the AMBA-AHB (Advanced Microcontroller Bus Architecture-High Performance Bus) bus protocol for bus access and IPS for programming model access.

[0073] It should also be noted that, in at least some embodiments, the SRDC module does not directly support any external interface. For example, the internal interface may include a standard 32-bit slave bus for all programming model accesses, a connection to the address phase signal associated with the AHB system bus, and a connection to the slave peripheral bus. In addition, with respect to the memory map / register definition, in at least some embodiments, the SRDC module may support a large number of architecturally defined program-visible registers distributed across several (e.g., three or four kilobytes) address slots. The actual registers present in any given device are dedicated. In addition, the register resources of the SRDC programming model can be accessed based on the ring number. In some embodiments, the programming model registers can be accessed via 8, 16, or 32-bit read and 32-bit write references, with Ring0 or Ring1 and machine mode attributes. Unless otherwise noted, attempts to access in different operating modes using unsupported write data sizes, writes to read-only resources, or writes to reserved space are all errors.

[0074] And, in at least some embodiments, access to the SRDC programming model may be further restricted by programming the SRDC slots on the PSC. The SRDC slot assignments may be different for each implementation. For example, the SRDC programming model may be partitioned into four register groups: (a) basic hardware control and configuration; (b) domain errors: location and details; (c) domain and attribute assignments; and (d) memory regions / blocks and peripheral checkers. It should be noted that many programming model registers in SRDC may be organized as 2-dimensional or 3-dimensional data structures. For 2-dimensional structures, the general array contains "m" words representing "columns", and "n" instances of the structure representing "rows". These may be described as structure [n][m], and may appear in the address space of the programming model memory map in a standard C language row-first layout - that is, the "m" words representing "columns" appear sequentially as the entire row is copied "n" times. The SRDC register structure may, for example, use the naming convention SRDC_ <regname>_Wm_n, where the column number "m" appears as a numeric suffix on the W (32-bit word) identifier, and the row identifier "n" appears as the final numeric suffix. The programming model for the memory region checker and the memory block checker is the same. In this section MC, memory checker is used to describe the two types of checkers, MBC and MRC.

[0075] It should be appreciated that although an architectural definition of the SRDC programming model is presented herein, each embodiment or implementation may be SoC specific and largely depends on the device requirements.

[0076] In the current embodiment, the set of modes available to various processes in partition 102 depends on several attributes (or, factors or characteristics), including: (1) CPU privilege mode or RISC-V mode (Reduced Instruction Set Computer-V mode); (2) Runtime Root of Trust (RRoT) mode (whether in the said mode); (3) modes related to bus master type (e.g., CPU, secure DMA, runtime integrity checker (RTIC)); (4) modes related to security state (LMDA, state); and (5) modes related to access location (e.g., internal or external).

[0077] More specifically, with respect to the CPU privilege mode (RISC-V mode), in the current embodiment, CPU 106 is (or includes) a RISC-V core, which supports three CPU privilege modes: machine mode, monitor mode, and user mode. Machine mode has more privileges than monitor mode. User mode has the lowest privileges. Table 1 shows the characteristics of these three CPU privilege modes in more detail.

[0078] Table 1. CPU privilege modes

[0079]

[0080] Relative to RROT mode, this is a special access right granted by the hardware root of trust of CPU 106 (or partition 102). A specific entry sequence to instructions in the immutable ROM code is required, which is monitored by the hardware (LMDA). When the hardware determines that the proper sequence has been followed, then partition 102 enters RROT mode, making particularly sensitive secrets or information temporarily available for one or more specific purposes (e.g., for authenticating partition loadable firmware).

[0081] One of the factors required for RROT entry is that the RISC-V core of CPU 106 must be in machine mode (of the CPU privilege mode discussed above) during the sequence, but once the RROT mode has been implemented, the RROT mode is independent of the CPU operating mode. This enables the CPU 106 to run complex RROT functions when operating in RROT mode even when the CPU is operating in a less privileged CPU mode, and can reduce the risk of widespread corruption or leakage. Table 2 shows in more detail the characteristics of the RROT mode relative to the situation when the system is in non-RROT mode (i.e., when the system is not operating in RROT mode).

[0082] Table 2. RROT / non-RROT (LDMA) mode features / use cases

[0083]

[0084] For the mode related to the bus master type, the partition 102 includes a variety of different bus masters shown in Table 3. As shown, the bus masters in the current embodiment include (for example) CPU instruction bus masters, CPU data bus masters, secure direct memory access (DMA) bus masters, external DMA bus masters (or burst DMA bus masters), PKC (public key cryptography) bus masters, RTIC bus masters, and USM bus masters (or ICU bus masters), and fast boot bus masters. Each of these corresponding bus masters has different inherent capabilities. Determining access rights based on these capabilities helps to provide more fine-grained access rights with less complex hardware and less areas.

[0085] For example, a CPU bus master will have an MPU with fine granularity segmentation, while a DMA does not have an MPU and therefore uses the RDC mechanism to isolate memory mappings in very coarse chunks. Thus, memory regions can be allocated exclusively to the CPU, which is more efficient for the specialized memory allocation methods commonly used by software. As another example, an RTIC is a read-only integrity checking bus master that only hashes data and therefore may be given more access to memory mappings across multiple zones of different CPU operating modes and outside of partitions. Both the RTIC and the USM / ICU (Universal Sequence Manager) (which may operate as a ZM (zeroized memory or zeroizer) emphasize that the respective hardware functions of each of these bus masters may present different types of problems or threats (e.g., relative to the reading of confidentiality in the case of the RTIC, or relative to the corruption of data in the case of the USM / ICU), and therefore may be allowed to access memory under significantly different security conditions (factors).

[0086] Relative to the mode associated with the security state of the partition 102, the partition has a hardware security state machine that represents the authenticity and integrity of the loadable firmware and the trustworthiness of the operating environment. At startup, when the non-patchable ROM code is running and no operational hazards such as out-of-range voltage or temperature are detected, the security state machine is placed in a secure state. Next, the ROM patch is loaded and verified. If the ROM patch verification passes (is successfully verified), the security state remains (i.e., the partition 102 remains in the secure state) and the ROM code can jump to the patchable section of the ROM code. Then the loadable firmware is loaded and verified. If the loadable firmware passes authentication (or is successfully verified), the security state remains (i.e., the partition 102 remains in the secure state) and execution can jump to the firmware.

[0087] Table 3. Bus Master Mode Features / Use Cases (and Corresponding Ports)

[0088]

[0089] If at any time conditions change such that the integrity of the operation cannot be verified, the state machine is triggered and it moves from the secure state into the failed state. Alternatively, the secure state code may authenticate the debug request token. If this verification passes (i.e., the debug request token is verified), the partition 102 operating in the secure state prepares the execution environment for the dangerous code and then moves the state machine into the debug state. When in the debug state, the loadable software is not trusted but is allowed to run without access to any real secrets, i.e., only copied (fake) secrets are available in the debug state or mode. Table 4 describes the various security state modes of the partition 102 in more detail, including the aforementioned security states as well as the unknown (check) state, and the corresponding characteristics / use cases of those security state modes.

[0090] Table 4. Security posture model features / use cases

[0091]

[0092] Compartment 102 is (conceptually) intended to be a closed system with very restricted access to the SoC, with respect to patterns related to access location (specifically, internal and external access). Some operations of Compartment 102 are extremely security sensitive, and if firewalls are not in place during operation, any malfunction of the operation, whether due to an attack or a vulnerability, can result in leakage or corruption. Therefore, Compartment 102 provides a discretionary mechanism for partitioning the partition memory map according to internal and external leakage, which are referred to herein as red (internal) and black (external) leakage, respectively.

[0093] As an example (on the one hand), because all RROT operations are extremely sensitive, RROT memory locations should all be designated as internal (red). In this case, if (e.g., for whatever unintended reason) a given RROT bus transaction attempts to access an external location, the access will be denied. Secure DMA also falls into this category. As another example (on the other hand), it is expected that customer code will perform many external accesses to perform cryptographic operations on behalf of the SoC application. Customer partitions should be set up so that external accesses can only be performed in black mode, and internal accesses can only be performed in red mode.

[0094] Notwithstanding the above examples, almost all DMA accesses will include both internal and external accesses while reading from one location and writing to another. In this way, access control can create a shared internal memory buffer so that black external accesses and black internal accesses are allowed and switch to red internal accesses, where the buffer data can be safely checked and moved to a safer location before operating on it. Table 5 describes the access locations of partition 102 in more detail, and the corresponding characteristics / use cases of those access locations.

[0095] Table 5. Access Location Mode Features / Use Cases

[0096]

[0097]

[0098] For completeness, another item that affects access permissions is the access type such as read (R), write (W), or execute (X) (more generally, R / W / X). A ROM patch or instruction code memory area can be set to read and execute regardless of what accesses it to prevent corruption of information that does not need to be changed.

[0099] In at least some embodiments, the SRDC operating mode may be determined based on a combination of the LMDA state and the SRDC software mode, which may include any of the following: (1) RROT(c)-Runtime Root of Trust Confidentiality; (2) Security Red; (3) Security Black; (4) ROT(i)-Runtime Root of Trust Integrity; (5) Debug Red; (6) Debug Black; (7) Failure. In addition, there may be three additional privilege modes used in conjunction with the SRDC mode: (a) Machine mode; (b) Monitor mode; and (c) User mode. SRDC and PRIV modes are communicated through the system via the PRIV, DID, and RING number attributes. For a given access, permissions, domainID, and ring values ​​are generated per master access, sent via the bus structure, and then used in access evaluation in the checker.

[0100] See also Figure 2 , a block diagram 200 is provided schematically illustrating a process according to which, in the current embodiment, various access control items are combined into a bus transaction identity. That is, block diagram 200 illustrates a process by which a bus transaction identity is developed taking into account the various factors described above, namely: (1) CPU privilege mode (RISC-V mode); (2) Runtime Root of Trust (RRoT) mode (whether in the mode); (3) mode related to bus master type (e.g., CPU, secure DMA, RTIC); (4) mode related to security state (LMDA); and (5) mode related to access location (e.g., internal or external).

[0101] As shown, in the current embodiment, the SRDC autonomous access control (DAC) bus master type (or more simply referred to as "bus master") block 202 operates based on several types of mode information arriving from several sources. As shown, the bus master block 202 receives a first information transmission 204 from the Risc-V Zen block 206. The first information transmission 204 specifically includes CPU privilege mode (RISC-V mode) information. And, the bus master block 202 receives each of a second information transmission 210 including RROT information and a third information transmission 212 including security state information (i.e., indicating whether the bus master state should be considered unknown, secure, failed or debug) from the LMDA block 208. In addition, the bus master block 202 receives a fourth information transmission 214 regarding access location information (e.g., regarding an internal (red) or external (black) state).

[0102] And, at the Risc-V Zen block 206, a read / write / execute (R / W / X) address is determined. The permission mode and the R / W / X address are provided as fifth information transmission 216 and sixth information transmission 218, respectively, to the AXBS xbar (crossbar switch) block 220. In addition, a seventh information transmission 222 is also provided from the bus master block 202 to the AXBS xbar block 220, wherein the seventh information transmission relates to SRDC domain identifier (DID) information.

[0103] As also shown, the AXBS xbar block 220 also communicates with each of the SRDC M{B,R}C block 224 and the SRDC PSC (Peripheral Device Slot Checker) block 226. The AXBS xbar block 220 transmits an eighth information transmission 228, a ninth information transmission 230, and a tenth information transmission 232, respectively, to the SRDC M{B,R}C block 224, and transmits an eleventh information transmission 234, a twelfth information transmission 236, and a thirteenth information transmission 238, respectively, to the SRDC PSC block 226. It should be appreciated that each of the eighth information transmission 228 and the eleventh information transmission 234 contains the R / W / X address information also transmitted by the sixth information transmission 218, each of the ninth information transmission 230 and the twelfth information transmission 236 contains the permission mode information transmitted by the fifth information transmission 216, and each of the tenth information transmission 232 and the thirteenth information transmission 238 contains the SRDCDID information transmitted by the seventh information transmission 222.

[0104] In addition, the SRDC M{B,R}C block 224 outputs a fourteenth information transmission 240 and a fifteenth information transmission 242, respectively, and the SRDC PSC block 226 outputs a sixteenth information transmission 244 and a seventeenth information transmission 246, respectively. Each of the fourteenth information transmission 240 and the sixteenth information transmission 244 transmits R / W / X address information (which may be the same as the address information received by the eighth information transmission 228 and the eleventh information transmission 234, respectively), and each of the fifteenth information transmission 242 and the seventeenth information transmission 246 transmits corresponding access error information. With respect to the above discussion, it should be further recognized that the non-CPU master will inherit its privilege level during setup. In addition, it should be noted that this concept permits (allows) transactions with different privilege levels in the system at the same time (it should also be noted that the RISC core has the same privilege / CPU privilege).

[0105] In the current embodiment, memory access control occurs primarily at the Sentinel (Secure) Resource Domain Controller (SRDC). Memory access control is implemented as a dedicated IP external to the CPU because the functionality and flexibility of the MPU (Memory Protection Unit) with the CPU is not sufficient to handle the wide range of factors that affect the trustworthiness of the state of the compute base and the different levels of trustworthiness of the code sequences themselves (e.g., RROT code, signed code, debug code).

[0106] The CPU privilege mode of the CPU and other bus masters are not modified by the SRDC permission assignment module (DAC), but are bypassed. However, the JR value (indicating hierarchical permissions) is sent via the DAC, even if it is inherited when setting up DMA. Basically, the JR in SRDC can represent the trustworthiness of the execution environment represented by the security state and access location (internal or external) of the LMDA for RROT, and the DID can represent the bus master (CPU or eDMA, etc.). However, there may be exceptions. For example, the DID of a CPU in a non-failed state can represent a normal or debug mode, and a DID in a failed state can represent a bus master that can be cleared or cannot be cleared.

[0107] In at least some embodiments covered herein, the system determines whether to grant or deny access to a control, asset, or resource based on one or more attributes, and typically multiple (or two or more) attributes. In practice, there are multiple attributes that may indicate security and may be considered in granting or denying access. Depending on the embodiment or implementation, the system may consider one of the various attributes or combinations of attributes in any of a variety of ways to determine whether to grant or deny access to any given control, asset, or resource (or determine a decoding that determines whether to grant or deny access to any given control, asset, or resource). For example, in at least some such embodiments, the attributes of interest may include, for example, any one or more of the following: (1) access; (2) DID; (3) RING; and / or (4) permissions. It should be appreciated that in such embodiments, permissions are not the only attributes that are important; in fact, the system employs multiple types, levels, or layers of security attributes, such as those established in DIDs and RINGs.

[0108] Furthermore, to the extent that multiple types, levels, or layers of attributes may be considered in determining whether to grant or deny access to a given control, asset, or resource, depending on the embodiment or situation, the attributes of the different types, levels, or layers may, but need not, be hierarchical. That is, even though different types, levels, or layers of attributes may be considered, one or more of these different types, levels, or layers may not (or need not necessarily) be considered superior or inferior (or, more or less rare) relative to another(s) of the attributes of the types, levels, or layers. Accordingly, even though different types, levels, or layers of attributes may be considered with respect to granting or denying access to a given control, asset, or resource, it is not necessarily the case that determining whether an attribute of a first type, level, or layer is satisfied will require a higher level of authorization or a greater level of approval in all situations or relative to all different controls, assets, or resources than determining whether an attribute of a second type, level, or layer is satisfied. Rather, depending on the particular situation of the particular control, asset, or resource of interest, different ones of the attributes of the types, levels, or layers may vary relatively in their importance or in the degree of authorization or approval that may be required when those different ones of the attributes of the types, levels, or layers are satisfied.

[0109] The present disclosure encompasses many different embodiments in which any of a variety of different types, levels, or layers of attributes may be considered in determining whether to grant or deny access to any of a variety of different types of controls, assets, or resources. As an example, Table 6 is provided to illustrate an example SRDC identity for a combination of access permission items, and specifically to illustrate a RING number and a domain ID (DID) that may be generated for an SRDC bus master for each of the different LMDA states.

[0110] Table 6: SRDC table

[0111]

[0112] Regarding Table 6, several details are worth noting. First, it should be understood that the CPU privilege mode is not included in the table because this field is independent of the table and the {JR, DID} attribute. And, the CPU privilege mode does not change according to hardware and bus master conditions. In addition, it is a field that can be included in the SRDC programming model, where the owner of the SRDC assigns which CPU privilege modes are allowed for each zone. In addition, by default, each zone is assigned only a machine mode, but can be modified to allow any combination of three modes. In addition, each of these states may involve (or indicate) sensitivity relative to the red state compared to the black state, but the states may involve sensitivity in different ways for different attributes, resulting in different ways of access / permissions. As an analogy, although a government employee may be granted permission to view confidential / confidential documents, the government employee can only obtain permission to review the confidential / confidential documents when the employee enters a secure room where the employee cannot communicate with third parties-therefore, although one access method is expanded, the second access method is weakened.

[0113] In addition, relative to Table 6, it should be understood that for JR, in the event of a failure state, JR and DID are as in the table-immediately and directly proceed to the failure value, without synchronization. And, for JR and non-failure LMDASSSM state changes, JR is maintained for DMA and other programmable bus masters. Even if the JR value started by RROT can continue, the read-only memory (ROM) should stop all DMA processes before leaving RROT. If an unforeseen use case requiring RROT bus mastering occurs, the option to continue is available through hardware. But again, the ROM code should turn off its DMA process when leaving RROT. In addition, the peripheral devices of the AHB (Advanced Microcontroller Bus Architecture High Performance Bus) master ports such as DMA and PKC must latch their permission levels when they are activated. The latched permission level is usually (or may need to) be presented during AHB access to distinguish access rights. For example, if a DMA operation has been initiated from a non-secure privileged guest extension (NP), then every AHB access made by the DMA must indicate non-secure context 1, where HPROT[1] = 1 access - in which case the DMA will only be able to access memory areas that are restricted for DMA reading and / or writing and enabled for privilege context 1.

[0114] It should also be understood that the SRDC concept works closely with other access control mechanisms. Figure 1 As mentioned, in at least some embodiments, an MPU (e.g., MPU 108) may be present, and the MPU configuration may be configured to implement a flexible and optimized solution with respect to memory resources and performance. Figure 1 In at least some embodiments shown, the secure enclave 102 implements the following AHB masters for which access policies are defined by the MPU 108: CPU; DMA; secure DMA; PKC; external SoC; RTIC; and ICU. The MPU 108 is operable to assist a CPU (e.g., CPU 106) in executing an initial set of access controls for bus transactions leaving the CPU. This may be helpful in providing very fine granularity within the memory regions available to the CPU 106. Other bus masters that do not have the same granularity of access rights to the CPU privileges should not be allowed.

[0115] Furthermore, in this regard, SRDC is specifically configured to prevent non-MPU masters from accessing CPU memory that is further partitioned by the MPU. In this case, the memory region access control configuration (SRDC) simply ensures that the CPU identity is allowed only for the MPU-protected RAM (random access memory) access region. The entire RAM region that the CPU can access but the non-MPU bus master cannot access (because they cannot provide granularity) will be configured to allow any CPU privileges, but only from the CPU bus master, and the entire region may or may not require RROT or security status, black or red control. Those assignments remain separate and help illustrate the difference between the CPU privileged controlled region and the trust state of the entire execution environment.

[0116] And, in at least some embodiments covered herein, there are SoC level permissions. In this regard, service requests from a secure enclave external master that generates DMA transactions toward the secure enclave 102 should inherit the same ID as the master that issued the request. Accordingly, any access to the SoC memory space via the DMA output port should use the DID of the requester or the DID of the secure enclave 102 itself (provided that the service request does not trigger the transfer). To this end, the secure enclave 102 will output the MU identifier by which the service request has been received. There will be a number reserved for the secure enclave trigger request. This identifier will be translated by the MDAC, which is part of the system resource domain controller (RDC). The settings of this MDAC will be executed, checked, and locked during secure boot.

[0117] Next, see Figure 3 , providing a schematic diagram showing at least a portion of at least one embodiment covered herein. Figure 1 An example multimodal access control architecture 300 is provided for an implementation of a system. Figure 3 The multimodal access control architecture 300 includes an execution environment 302, a subsystem 304 including a CPU 306, and resources 308 for trusted operations. As shown, the execution environment 302 communicates with an off-platform trusted bus for receiving a first input signal (as represented by a first port 310), and communicates with an off-platform common bus for receiving a second input signal (as represented by a second port 312). In addition, the execution environment 302 communicates with an off-platform trusted bus for providing a first output signal (as represented by a third port 314), and communicates with an off-platform common bus for providing a second output signal (as represented by a fourth port 316).

[0118] Additionally, as shown, in the current example embodiment, the execution environment 302 includes an MPU 318, and also includes (or is in communication with) one or more sensors 320. The one or more sensors 320 may be configured to detect one or more characteristics or conditions of interest, such as voltage (e.g., a voltage out of range), current, frequency, signal (e.g., an electromagnetic signal detected by an antenna), temperature, or intrusion (e.g., tamper detection).

[0119] In addition, the execution environment 302 includes a state machine 322, which can be referred to as the integrity and authenticity state of the software state machine. The state machine 322 indicates a secure boot cycle from reset to current operation (startup and runtime). Different state processes indicate secure or non-secure processes. The CPU 306 has a privilege state for the most secure mode and the least secure mode, where the highest privilege task manages processes with lower privileges. In addition to the bus structure and the first port 310, the second port 312, the third port 314, and the fourth port 316 that act as input / output ports for off-platform access, the execution environment 302 also includes zones and peripherals 324 that may have various security sensitivities (e.g., integrity, confidentiality, authenticity, high, medium, and / or low). The zones and peripherals 324 may include ROM and RAM.

[0120] In addition, the execution environment 302 includes an SRDC enhanced access rights control mechanism (or simply SRDC) 326. The SRDC 326 operates to isolate memory regions based on CPU privileges and domain identities or bus master IDs. In addition, the SRDC 326 includes an SRDC trust factor attribute section (or trust attribute section) 328 and a fabric switch section 332. The SRDC trust attribute section 328 receives and includes security status, trust root status, sensors, intrusions, and other trust factors, some of which may also be referred to as environmental and / or measured trust factors, and some of which may be referred to as initiator-specific trust factors. The SRDC trust attribute section 328 may also be used to perform SRDC trust factor mapping and has a trust bus attribute remapping 330. The trust factor is encoded into the SRDC trust attribute section 328 assigned by the bus master side and transmitted by the fabric switch section 332 on the bus to the destination SRDC 334, which is shown as having a first portion 336 and a second portion 338. The destination SRDC 334 then determines, based on this additional information, whether access should be allowed or denied.

[0121] More specifically, if Figure 3 As shown, in the current embodiment, the SRDC trust attribute section 328 receives source trust identifier (ID) information 340, off-platform SRDC trust attribute information 342, CPU privilege mode information 344, and bus information 346, which are received at terminal / pin T0 through the first port 310. Based on these types of received information 340, 342, 344, and 346, the SRDC trust attribute section 328 can perform / prepare for trust bus attribute remapping 330.

[0122] Also, the SRDC trust attribute section 328 receives CPU privilege mode information 348 and address and data (R / W / X) information 350 at terminal / pin M0 through the second port 312. As indicated by arrow 352, this information is external and has (inherently) a black (external) state. In addition, the SRDC trust attribute section 328 also receives CPU privilege mode information 354 from the CPU 306, and receives instruction bus information 356 and data bus information 358 from the MPU 318, which in turn receives instruction bus information 356 and data bus information 358 from the CPU 306. These various types of information received directly or indirectly (via the MPU 318) from the CPU 306 may be received at any of a plurality of terminals / pins Mn (e.g., M1, M2 ... Mn). As indicated by the box and arrow 360, this information (or different portions of this information) may have a red (internal) or black (external) state.

[0123] It should also be appreciated that the CPU 306 may be referred to as an initiator (CPU, DMA, etc.) and consider (or receive) the measured RROT factor 362 and receive interrupt / exception information as represented by arrow 364. In addition, the state machine 322 receives debug / test detection information as represented by arrow 366, receives local environment information provided by the one or more sensors 320 as represented by arrow 368, and receives chip lifecycle information as represented by arrow 370. Based on this received debug / test detection, local environment, and chip lifecycle information, the state machine 322 generates and outputs local software authenticity and integrity state information 372. Both the state information 372 and the RROT state information as represented by box and arrow 374 are received at the SRDC trust attribute section 328 as environmental and / or measured trust factors.

[0124] Further reading Figure 3 , the fabric switch 332 of the SRDC 326 generates output signals based on the various types of information (i.e., information 340, 342, 344, 346, 348, 350, 354, 356, 358, 372, and 374) received by the SRDC trust attribute section 328 as described above. First, the fabric switch 332 generates first SRDC trust attribute information 376, first CPU privilege state information 378, and first bus information 380, as well as second SRDC trust attribute information 382, ​​second CPU privilege state information 384, and second bus information 386, all types of information being transmitted to the second portion 338 of the destination SRDC 334. In addition, the fabric switch 332 generates third SRDC trust attribute information 388, third CPU privilege state information 390, and third bus information 392, all types of information being transmitted to the first portion 336 of the destination SRDC 334.

[0125] Based on the information received at the second portion 338 of the destination SRDC 334 (information 376, 378, 390, 382, ​​384, and 386), the second portion makes an access control configuration or determination. Then, the second portion 338 of the destination SRDC 334 provides source trust identification information 394, SRDC trust attribute information 396, CPU privilege information 398, and bus information 298 for reception by the first port 314, and also provides CPU privilege state information 296 and bus information 294 for reception by the second port 316. In addition, based on the information received at the first portion 336 of the destination SRDC 334 (information 388, 390, and 392), the first portion also makes an access control configuration or determination. Then, the first portion 336 of the destination SRDC 334 provides output information 292 for reception by the zone or peripheral device 324. Also, it should be appreciated that RROT state information 290 and possibly subsystem configuration information 288 are generated based on fuse and pin configuration information represented by box and arrow 286 and based on measured RROT factors as represented by box and arrow 284 .

[0126] Steering Figure 4 , in Figure 1 and Figure 3 In the embodiment shown, specifically, it is the SRDC 110, the SRDC enhanced access rights control mechanism (or simply SRDC) 326, and the destination SRDC 334 that evaluate or perform the resolution of various trust attributes or the resolution between various trust attributes, or the access control policy selection. In this regard, the Figure 4 to illustrate an example access control policy selection. In this example, the transaction has the following attributes: DID=1, RING=2, PRIV=MACHINE. If the transaction is a read, it will be allowed to continue. If it is a write or execute, the outcome of the access is a bus error. In addition, it should be noted that in the current embodiment, SRDC includes (or even overloads) the items DID and RING to map new trust attributes for both mutually suspicious equal permissions (DID) and hierarchical permissions (JR). Moreover, in the current embodiment involving a multimodal access control architecture, these attributes also represent the trust root detection and trust state of the environment of the secure enclave.

[0127] More specifically, Figure 4 In particular, a schematic diagram 400 is provided that illustrates how the various types of attributes described above are organized, configured, and considered by the SRDC 110 (and SRDC 326 / destination SRDC 334) during the process of access control policy selection. As shown, there may be multiple address space descriptors (ASDs) 402. In the current example, there are four of the ASDs 402, namely, ASDs 472, 474, 476, and 478, respectively, but there may be any arbitrary number of ASDs. In the current embodiment, each of the ASDs 402 includes eight (8) domains 404, each of which corresponds to a different DID (domain identifier), such as ACSD0, ACSD1, ACSD2, ACSD3, ACSD4, ACSD5, ACSD6, and ACSD7, respectively. For ease of illustration, the first domain 408 of the eight domains 404 is shown as being selected.

[0128] Each of the eight domains 404 has three CPU privilege mode groups 406 associated therewith, namely, a machine mode group 410 , a monitor group 430 , and a user mode group 450 . Figure 4 Specifically, three CPU privilege mode groups 406 of a first domain 408 of the eight domains are shown, but it should be understood that each of the eight domains 404 has three of the CPU privilege mode groups. In addition, each of the CPU privilege mode groups 406 of each of the eight domains 404 includes eight corresponding local access control policies 480 (which can be identified by the names LOC AC0, LOC AC1, LOC AC2, LOC AC3, LOC AC4, LOC AC5, LOCAC6, and LOC AC7, respectively). That is, with respect to Figure 4 In the first domain 408 of the eight domains shown, the machine mode group 410 includes local access control policies 412, 414, 416, 418, 420, 422, 424 and 426; the monitoring group 430 includes local access control policies 432, 434, 436, 438, 440, 442, 444 and 446; and the user mode group 450 includes local access control policies 452, 454, 456, 458, 460, 462, 464 and 466.

[0129] Furthermore, as shown, each of the local access control policies 480 includes four RING numbers (associated with a 4-level RING model), and Figure 4 In particular, a first RING number 482, a second RING number 484, a third RING number 486, and a fourth RING number 488 (having names RING0, RING1, RING2, and RING3, respectively) of the local access control policy 416 of the machine mode group 410 of the first domain 408 of the eight domains 404 are respectively shown. Also as shown, each of the RING numbers 482, 484, 486, and 488 includes corresponding R / W / X information, wherein as an example, the RING number 484 has a R / W / X value, wherein R=1, W=0, and X=0.

[0130] Given these characteristics, it should be understood that Figure 4 In the current example represented, access control policy selection may be understood to be performed in the following manner. Specifically, the domainID of the current transaction may select an appropriate 3-bit ACSDx (access control selection for domain "X") from the selected descriptor register. The ACSDx field selects an [m]_LOC_AC[p] access control policy register that defines access rights based on a 4-level ring model. In addition, the permission mode of the current transaction may select an appropriate set of [m]_LOC_AC[p] registers, where mode [m] = mm (machine mode), sm (monitor mode), um (user mode) and local access policy [p] = 0-7 (policy). In addition, as previously described, the resulting hierarchical access control model specifies that machine mode>monitor mode>user mode, and Ring0>Ring1>Ring2>Ring3.

[0131] After the appropriate access policy has been selected, the next function is the actual access evaluation. In addition, after the access control policy (ACP) evaluation is completed and the access error signal is generated, if the transaction has sufficient access rights, the transaction is allowed to continue, otherwise the access is aborted and the address and attribute information is captured in the appropriate error registers.

[0132] It should also be understood that, relative to Figure 4 For example, the operation of SRDC relies heavily on the actual access violation checking performed by the memory checker (MBC / MRC) and the peripheral slot checker (PSC). The domain assignment mechanism and the tracking of domain identifiers and ring numbers as address attributes through the system bus switch structure are important. In addition, as transactions arrive at slave memories and peripheral controllers, the address is used to select the appropriate address space descriptor.

[0133] In addition, see Figure 5 It should be appreciated that the implementation of SRDC and the use of trust attributes may be extended to other security systems / subsystems, including to multiple security subsystems. Figure 5 In the architecture 500 shown in FIG. 5 , there is a trust bus 502 having a first trust bus connection 504 and a second trust bus connection 506, respectively, which link / connect a first security subsystem 508 and a second security subsystem 510. As pictorially shown, the first trust bus connection 504 of the trust bus 502 transmits or communicates a first trust attribute 512 along with a first trust source ID 514 of the first security subsystem 508, and the second trust bus connection 506 of the trust bus 502 transmits or communicates a second trust attribute 516 along with a second trust source ID 518 of the second security subsystem 510. Based on this, the destination subsystem can determine the trustworthiness of the originating subsystem and map it to the local security attribute with an added column of the SRDC access control matrix. When the source subsystem is trusted, it can be allowed to access more sensitive areas in the destination subsystem.

[0134] In this regard, it should be noted that incoming common bus transactions are usually always downgraded and may be given few (if any) access rights. But sometimes, some access to isolated memory locations is useful. Of course, the trustworthiness of sources on the common bus will not be high, and so the SRDC determines the attributes of the bus transactions accordingly.

[0135] Notwithstanding the above description, the present disclosure is intended to cover numerous embodiments including those disclosed herein as well as a variety of alternative embodiments.At least some of the embodiments covered herein may be used on a multi-core SoC using access control and having a variety of security measures.

[0136] In addition, in at least one exemplary embodiment, the present disclosure relates to a method for multimodal secure access control of a system on a chip (SoC). The method includes providing a secure enclave including multiple bus masters and a sentinel resource domain controller (SRDC). The method also includes receiving a request for access control, an asset, or a resource from a first bus master of the multiple bus masters. The method further includes evaluating a plurality of attributes associated with the request, wherein the plurality of attributes include each of the following: a first attribute, which is a permission mode attribute; a second attribute, which relates to the applicability or non-applicability of a runtime root of trust (RRoT) mode; a third attribute, which is related to a bus master type; and a fourth attribute, which is related to a security state. The method further includes determining whether to grant or deny the access request based on the plurality of attributes associated with the request. The method also includes making the control, asset, or resource targeted by the access request accessible or inaccessible based on the determination.

[0137] In addition, in at least one further example embodiment, the present disclosure relates to a method for multimodal secure access control of a system on a chip (SoC). The method includes providing a secure enclave including a plurality of bus masters and a sentinel resource domain controller (SRDC), wherein the plurality of bus masters include a first bus master, the first bus master being a central processing unit (CPU). The method also includes receiving a request for access control, an asset, or a resource from the first bus master. The method further includes evaluating a plurality of attributes associated with the request, wherein the plurality of attributes include each of the following: a first attribute, which is a domain identifier (DID) attribute; a second attribute, which is a ring number attribute; a third attribute, which is a permission mode attribute; a fourth attribute, which relates to the applicability or non-applicability of a runtime root of trust (RRoT) mode; a fifth attribute, which is related to a bus master type; and a sixth attribute, which is related to a security state. The method also includes determining whether to grant or deny the access request based on the plurality of attributes associated with the request. The method also includes making the control, asset, or resource for which the access request is directed accessible or inaccessible based on the determination.

[0138] In addition, in at least one further example embodiment, the present disclosure relates to a system for providing multimodal secure access control to a system on a chip (SoC). The system includes a secure enclave, the secure enclave including a plurality of bus masters, a sentinel resource domain controller (SRDC) at least indirectly coupled to the plurality of bus masters, and at least one port by which the secure enclave can be coupled to at least one external bus. In addition, the SRDC is configured to: receive a request for access control, an asset, or a resource at least indirectly from a first bus master of the plurality of bus masters; and evaluate a plurality of attributes associated with the request. The plurality of attributes include each of the following: a first attribute, which is a permission mode attribute; a second attribute, which relates to the applicability or non-applicability of a runtime root of trust (RRoT) mode; a third attribute, which is related to a bus master type; and a fourth attribute, which is related to a security state. In addition, the SRDC is configured to: make a determination as to whether to grant or deny the access request based on the plurality of attributes associated with the request; and make the control, asset, or resource for which the access request is directed accessible or inaccessible based on the determination. In at least some such embodiments, the SRDC includes an SRDC enhanced access rights control mechanism having an SRDC trust factor attribute section and a fabric switch section, and a destination SRDC.

[0139] One or more embodiments covered herein may be advantageous in any of a variety of aspects. For example, at least some systems or methods disclosed herein are advantageous because such systems or methods provide a way to govern access to (or deny access to) a control, asset, or resource (or sensitive information) by taking into account one (or two) or more of a variety of different attributes, characteristics, or considerations in a nuanced manner. Thus, the present disclosure contemplates embodiments that operate such that, for example, a request to access a given control, asset, or resource may be granted in each of the following scenarios: a first scenario, when a first attribute of a plurality of attributes indicates that a higher security threshold should be satisfied when a second attribute of the plurality of attributes indicates that only a lower security threshold needs to be satisfied; and a second scenario, when the first attribute of the plurality of attributes indicates that only a lower security threshold (or another lower security threshold) needs to be satisfied even if the second attribute of the plurality of attributes indicates that a higher security threshold (or another higher security threshold) should be satisfied.

[0140] Although the principles of the present invention have been described above in conjunction with specific devices, it should be clearly understood that this description is only by way of example and is not intended to limit the scope of the present invention. It is particularly desirable that the present invention is not limited to the embodiments and illustrations contained herein, but includes modified forms of those embodiments, including combinations of elements of the embodiments and different embodiments within the scope of the appended claims.< / regname>

Claims

1. A method for multimodal secure access control of a system on a chip (SoC), characterized in that: The method comprises: Providing a secure enclave including multiple bus masters and a Sentinel Resource Domain Controller (SRDC); receiving a request from a first bus master of the plurality of bus masters to access a control, asset, or resource; A plurality of attributes associated with the request are evaluated, wherein the plurality of attributes include each of: The first attribute is the permission mode attribute; The second property, which relates to the applicability or non-applicability of the Runtime Root of Trust (RRoT) model; A third attribute, which is related to the bus master type; and The fourth attribute is related to the security status; determining whether to grant or deny the access request based on the plurality of attributes associated with the request; and The control, asset, or resource targeted by the access request is made accessible or inaccessible based on the determination.

2. The method according to claim 1, characterized in that The plurality of attributes that are evaluated additionally include a fifth attribute related to a visited location.

3. The method according to claim 1, characterized in that The plurality of attributes being evaluated additionally includes a fifth attribute, the fifth attribute being a domain identifier (DID) or ring number attribute.

4. The method according to claim 1, characterized in that: The bus master type relates to one of a CPU, a secure direct memory access (DMA), and a runtime integrity checker (RTIC).

5. The method according to claim 1, characterized in that The fourth attribute related to the security state is determined at least in part by a state machine based at least indirectly on one or more of debug or test detection information, local environment information received from one or more sensors, and chip lifecycle information.

6. The method according to claim 1, characterized in that First information regarding at least some of the plurality of attributes is received by a crossbar switch, which in turn transmits the first information or second information based on the first information for receipt by the SRDC.

7. The method according to claim 1, characterized in that The determination of whether to grant or deny the request further considers which of a plurality of local access control policies within a permission mode group corresponding to the permission mode attribute is applicable, wherein the permission mode attribute further corresponds to a specified domain identifier (DID) associated with the address space descriptor.

8. The method according to claim 1, characterized in that The request can be granted in each of the following situations: a first situation when a first attribute of the plurality of attributes indicates that a higher security threshold should be satisfied when a second attribute of the plurality of attributes indicates that only a lower security threshold needs to be satisfied; And a second situation, at this time, even if the second attribute of the multiple attributes indicates that the higher security threshold should be met, the first attribute of the multiple attributes indicates that only the lower security threshold needs to be met.

9. A method for multimodal secure access control of a system on a chip (SoC), characterized in that: The method comprises: providing a secure enclave including a plurality of bus masters and a sentinel resource domain controller (SRDC), wherein the plurality of bus masters includes a first bus master, the first bus master being a central processing unit (CPU); receiving a request from the first bus master to access a control, asset, or resource; A plurality of attributes associated with the request are evaluated, wherein the plurality of attributes include each of: A first attribute, which is a domain identifier (DID) attribute; The second attribute is the ring number attribute; The third attribute is the permission mode attribute; a fourth property, which relates to the applicability or non-applicability of the Runtime Root of Trust (RRoT) model; a fifth attribute, which is related to the bus master type; and The sixth attribute is related to the security status; determining whether to grant or deny the access request based on the plurality of attributes associated with the request; and The control, asset, or resource targeted by the access request is made accessible or inaccessible based on the determination.

10. A system for providing multimodal secure access control to a system on chip (SoC), characterized in that: The system comprises: a secure enclave comprising a plurality of bus masters, a sentinel resource domain controller (SRDC) at least indirectly coupled to the plurality of bus masters, and at least one port by which the secure enclave can be coupled to at least one external bus, The SRDC is configured as follows: receiving, at least indirectly from a first bus master of the plurality of bus masters, a request to access a control, an asset, or a resource; evaluating a plurality of attributes associated with the request, wherein the plurality of attributes include each of: a first attribute that is a permission mode attribute; a second attribute that relates to applicability or non-applicability of a Runtime Root of Trust (RRoT) mode; a third attribute that is related to a bus master type; and a fourth attribute that is related to a security state; making a determination as to whether to grant or deny the access request based on the plurality of attributes associated with the request; and The control, asset, or resource targeted by the access request is made accessible or inaccessible based on the determination.

Images