An integrated circuit for executing instructions, a method of determining whether to allow or reject an access to a memory mapped resource for a memory request, and a method of transmitting a memory request

Abstract

A system and method for error management in a system-on-a-chip (SoC) with securely partitioned memory space are disclosed. For example, an integrated circuit (e.g., a processor) executing instructions includes: a world identifier checker circuit system configured to check memory requests for one or more memory-mapped resources identified by world identifiers received via a bus, to determine whether to allow or deny access based on the identified world identifier; a world identifier checker circuit system configured to compare the identified world identifier with a world list listing resources for which world identifiers supported by the integrated circuit are authorized to access the resources; and data storage configured to store world error data, including the identified world identifiers of memory requests denied by the world identifier checker circuit system.

Description

Technical Field

[0001] Cross-reference to related applications

[0002] This application claims priority and benefits from U.S. Provisional Patent Application No. 63 / 221,253, filed on July 13, 2021, the entire disclosure of which is incorporated herein by reference.

[0003] This disclosure relates to error management in a system-on-a-chip using secure partitioned memory space. Prior Technology

[0004] Software isolation is an important feature required by different enterprises. Given the increasing trend in code size, the different sources of code, and how they are combined, there is a significant risk that one part may intentionally or unintentionally impact another part.

[0005] If a programming error exists and the interference is unintentional, there is a safety issue: even if another part of the software running on the device has a programming error and enters an infinite loop or erratic behavior, the health-oriented device (e.g., medical device, car brake, nuclear power plant sensor) will still be able to maintain its primary function.

[0006] If weaknesses exist and the interference is intentional, security issues arise: credential guidance devices (payment terminals, badge control systems, DRM-equipped devices) will block or raise the flag without compromising the protection of any assets. It is advantageous to develop solutions that ensure the failure of one part of the software does not impact the correct and complete functionality of other parts running on the same platform.

[0007] In addition, it is advantageous to ensure that malicious or uncontrolled segments of the software cannot compromise the resources of another segment of the software running on the same platform. Compromising any resource can have a wide range of implications, from simply reading a portion of memory to modifying that portion or preventing the use of peripheral devices. Security requirements are often more stringent than general security requirements because the latter typically allows application code to change its privileged mode, while the former usually requires application code not to change its privileged mode. Therefore, security solutions based on conventional real-time operating systems often fail to meet security requirements; the reverse is often true. Summary of the Invention

[0008] none Simple Explanation of the Diagram

[0009] This disclosure is best understood from the following detailed description when read in conjunction with the accompanying drawings. It should be emphasized that, by convention, the various features in the drawings are not to scale. Instead, for clarity, the dimensions of the various features may be arbitrarily enlarged or reduced. Figure 1 is a block diagram of an example of an integrated circuit used for error management in a system-on-a-chip with securely partitioned memory space. Figure 2 is a block diagram of an example of a data storage device used to store world error data for rejected memory requests. Figure 3 is a block diagram of an example architecture for secure computing. Figure 4 is a block diagram of an example architecture for software isolation on a single core. Figure 5 is a flowchart illustrating an example of a technique for error management in a system-on-a-chip using securely partitioned memory space. Figure 6 is a flowchart illustrating an example of a technique that writes world error data to data storage using an approval field in response to a rejection of a new memory request. Figure 7 is a flowchart illustrating an example of a technique where the master controller uses different world identifiers to request world error information from a trusted world processor core. Implementation

[0010] [Overview] []

[0011] Hardware-enhanced multi-domain solutions (such as SiFive WorldGuard) protect against unauthorized access to memory / peripherals from software applications and / or other controllers. This solution is designed to provide hardware means to ensure strict and robust isolation between different software applications running on the same platform (e.g., single-core or multi-core) that access shared resources (e.g., memory or peripherals) (see, for example, “SiFive WorldGuard High-Level Specification”).

[0012] The hardware-enhanced multi-domain solution can be applied to a wide range of processors and software architectures. This solution proposes creating a "world" that aggregates applications running on the core and other master resources (such as DMA channels) and slave resources (such as memory or peripherals). The possible number of worlds is hardware-configurable, depending on the number of cores and masters, memory configuration, and software architecture. This solution does not replace Physical Memory Protection (PMP) mechanisms (which can be applied to a single core for memory), but extends them to multi-core, multi-software systems with other masters.

[0013] The principle is to collect controllers, memory regions, and peripherals from multiple sets of resources, referred to as "worlds." Worlds are distinct from one another, meaning that software running on a core belonging to world 1 cannot access resources belonging to world 2 (e.g., memory regions and peripherals), and more generally, cannot interface with other worlds. Of course, for inter-world communication, some memory regions may belong to more than one world (acting as shared memory). Therefore, a unique world identifier value is assigned to a world, and within that world, each controller belonging to that world is assigned the same world identifier value. This assignment is typically done on a per-controller basis, at the entire controller level. However, even finer granularity can be provided if the controller design supports it. This is the case for cores called WorldGuard-aware cores. On these cores, world differences can now also depend on privileged modes, allowing different world identifiers to be based on the privileged mode on the same core (e.g., M mode, S mode, U mode). (See, for example, "RISC-V Privileged Specification").

[0014] In some implementations, a debug world table is used, for which debug is selectively enabled. For example, when a world identifier (WID) cannot be debugged, debug interrupts and exceptions are not taken. In some implementations, when a debug interrupt is taken on a specific heart / core, in debug mode, the core jumps to an address in the debug ROM (e.g., 0x800). At this stage, after some initialization, the debug ROM code can execute AbstractCommand. The verification mechanism is based on the direct (CSR access) or indirect (data access) use of dcsr.prv. Therefore, the debug ROM code: (for CSRs) performs regular access to the CSR address for dcsr.prv except for authorized CSRs, allowing access only to that privileged address; and (for memory) performs regular address requests based on the core WID value, using the dcsr.prv register (instead of mstatus.prv). Therefore, access is granted if and only if the WID world accesses the requested address.

[0015] Please note: Because the RISC-V debugging specification allows "A debugger can change this value to change the hart's privilege level when exiting Debug Mode," the debugger may not be able to change dcsr.prv. For security-based debugging schemes, this WorldGuard enhanced debugger relies on firmware execution. Therefore, the robustness of this code (especially the parts being checked) should be satisfied if fault-based attacks are considered.

[0016] For example, the first technique is based on the current WID value and the debug-wid-list, and debug is considered to be authorized only if there is a debug interruption / exception and the current WID value authorizes debug.

[0017] The second technique focuses on the way the debug ROM code accesses controlled resources, CSRs, and resources; when the debug ROM code (executed during debugging) runs in debug mode (e.g., highest privilege mode), it does not use these privileges for access but instead uses the privilege mode and WID value used by the debug software. For example, access control can be assigned to dcsr.prv instead of mstatus.prv, meaning that access control is implemented based on rules applicable to the privilege mode and WID value of the debug software, rather than the rules of the debug software. This second technique significantly simplifies access verification because it reuses the WorldGuard mechanism and principles. Therefore, the debug ROM code can be small-scale, and the measures can be consistent with other WorldGuard mechanisms.

[0018] It applies to physical addresses. In the remainder of this document, wg can be used to represent WorldGuard.

[0019] WorldGuard is a hardware-enhanced multi-domain solution that protects against unauthorized memory / peripheral device access from software applications and / or other controllers (such as DMA). It is designed to provide robust hardware protection to ensure strict and strong isolation between different software applications running on the same platform (single-core or multi-core) that access shared resources (memory, peripheral devices).

[0020] For example, the circuit systems and techniques described in this paper can be applied to various processors with many different software architectures. For example, they can be implemented using the RISC-V instruction set architecture.

[0021] This solution proposes creating a "world" that aggregates applications running on the core and other host components (e.g., DMA channels) and resources (e.g., memory or peripherals). A world defines the permissions, overlap, and consistency of entity addresses within the system without affecting software-visible cache. Software isolation is achieved by restricting the world's access to specific entity addresses linked to different components in the system. WorldGuard enables worlds within the system or chip to be identified by a world identifier or WID.

[0022] The possible number of worlds is configurable in the hardware during the elaboration stage and should be determined by the number of cores and main controllers, memory configuration, and the main software architecture. Mechanics and Blocks

[0023] On the master controller side, wgMarker is used to "mark" requests issued by the master controller. The mark is based on the world to which the master controller belongs, and is called a world identifier, which is unique in each world. This marked request is sent to the resource / slave blocks (memory, peripherals).

[0024] On a resource / slave, wgChecker is positioned "in front" of the resource being checked for the requested resource.

[0025] wgChecker contains a configuration that defines access rules. For example, a memory rule defines a portion of the memory and a list of worlds that can access that portion, as well as the method (read or read-write). Therefore, verification of the tagged request from the master is performed by comparing the coupled request address-world identifier with the rules appearing in the wgChecker configuration.

[0026] wgChecker can also contain error registers and interrupt bit fields.

[0027] In some implementations, if the first rule matching the address also matches the world identifier and access method, then the approved and wgChecker-authorized request to be satisfied in the resource is verified. If the verification fails, an error exists.

[0028] The configuration of wgMarker and wgChecker can require certain privileges. In some implementations, it is possible to configure wgMarker and wgChecker independently of the kernel (e.g., DMA) solely through a trusted world. Kernel-dependent wgMarker can be configured through local-to-kernel privilege settings (e.g., machine mode, etc.). Error Management

[0029] When a marked request arrives at wgChecker, wgChecker compares the marked request with wgChecker rules. If the request does not match any rule, it can trigger two different events (optional and configurable for each wgChecker): the primary event is the acquisition (source) of an interrupt signal. This interrupt signal can be the source of an interrupt controller. In that case, the interrupt handler can run in the event of a violation. Theoretically, any core can register this interrupt signal. Preferably, the core running on a trusted world should register the interrupt signal, as this core can be dedicated to security monitoring.

[0030] As a second event, a rejection is sent back to the master controller source of the error. In the presence of a Bus Error Unit (BEU), this rejection can be converted into an interrupt signal. BEUs log error events and report them to their per-processor devices using PLIC (if available) or via heart-local interrupts. BEUs can be configured to generate an interrupt in the event of an ECC error (if ECC is included in the design) or a TileLink bus error. In some implementations, when an error occurs, the BEU retains the address of the error and the code describing it. The rejection message can also trigger a core exception.

[0031] The two events above lead to the following strategies. First, platform-wide interrupt signals are captured by an interrupt handler in trusted firmware responsible for security monitoring. This firmware can receive and manage violations regardless of their origin (as is its responsibility). Second, local kernel-level interrupt signals are captured by an interrupt handler in the firmware running on the kernel that caused the violation. If the violation stems from a program error, the source kernel can locally manage the problem and potentially correct it. For a single-kernel platform, the trusted kernel and the local kernel can be the same kernel.

[0032] If the breach originates from an attack, the source kernel may be under the attacker's control, and therefore cannot be trusted for any forensic efforts. This is why a trusted firmware interrupt handler is needed, which, due to its global interrupt capability, can also manage and investigate problems.

[0033] For a more in-depth investigation, some information about the violation can be obtained from the wgChecker error register (wgChecker may have its own error register): (1) the address contained in the request, (2) the world identifier associated with the request, and (3) the access mode (e.g., read, write, or execute). Note that in some implementations, this information is only accessible to trusted world firmware. Approval

[0034] The first violation is often followed by many other violations of the same type. However, it is often important to analyze the first violation, as it may be the most significant and provides the best clue as to what went wrong. Therefore, the error register also includes a bit field called ACK, which prevents the error register from being updated immediately after a new violation. The error register can only be updated with the latest violation information when the ACK bit field is set, that is, when the above information is considered acknowledged. Access rules

[0035] Especially when the attack context is uncertain (e.g., a fault attack), error information regarding violations can be very valuable to attackers. In some implementations, access to error information is restricted to the highest privileged world, the trusted world. This means that the world that caused the violation cannot directly access the error register.

[0036] Therefore, a trusted interrupt handler can access this information, while a local source-kernel interrupt handler cannot directly access it. If the latter wants these details, it will request the trusted interrupt handler to share this information. Then, the trusted firmware determines whether the source kernel firmware is trustworthy, and only then can the information be shared.

[0037] As used herein, the terms "circuit" and "circuit system" refer to an arrangement of electronic components (e.g., transistors, resistors, capacitors, and / or inductors) structured to perform one or more functions. For example, a circuit may include one or more transistors interconnected to form logic gates that collectively perform logic functions.

[0038] As used herein, the term "data storage" refers to a circuit system configured to store data, such as, for example, one or more registers, random access memory, flash memory, or one or more flip-flops. [Detailed Description] []

[0039] Figure 1 is a block diagram of an example of an integrated circuit 110 for error management in a system-on-a-chip using secure partitioned memory space. The integrated circuit 110 includes a processor core 120 configured to execute instructions. The integrated circuit 110 includes an external memory system 140 configured to store instructions and data and provide an interface with peripheral devices. The processor core 120 includes: a data memory 122 configured to store one or more world identifiers; and a world identifier marking circuitry configured to identify memory requests transmitted by the processor core 120 on bus 142 of the integrated circuit 110 using world identifiers from the data memory 122. Integrated circuit 110 includes world identifier checker circuit systems 150 and 160, which are configured to check memory requests for one or more memory-mapped resources identified by world identifiers received via bus 142, to determine whether to allow or deny access based on the identified world identifier. World identifier checker circuit system 150 is associated with one or more portions of memory. World identifier checker circuit system 160 is associated with one or more memory-mapped peripheral devices. World identifier checker circuit systems 150 and 160 include one or more data storage units (152 and 162) that store a world list listing which world identifiers supported by the integrated circuit are authorized to access the resources. World ID verification circuit systems 150 and 160 include one or more data storage units (154 and 164) configured to store world error data, including identified world IDs for memory requests rejected by the world ID verification circuit systems (150 or 160). Integrated circuit 110 includes a trusted world processor core 170, which performs write access to the data storage unit (e.g., a temporary register) storing the world ID through integrated circuit 110 used to identify and verify memory requests on one or more buses of integrated circuit 110. For example, integrated circuit 110 may be used in embodiment 500 of FIG. 5. For example, integrated circuit 110 may be used in embodiment 600 of FIG. 6. For example, integrated circuit 110 may be used in embodiment 700 of FIG. 7.

[0040] The integrated circuit 110 includes a processor core 120 configured to execute instructions. The processor core 120 includes a data memory 122 (e.g., one or more temporary registers) configured to store a first world identifier. For example, multiple world identifiers used by programs executed by the processor core 120 in different privileged modes may be stored in the data memory 122. In some implementations, the first world identifier is one of multiple world identifiers stored in the processor core 120, each associated with a different privileged mode (e.g., machine mode, supervisor mode, and user mode). For example, the integrated circuit 110 may implement the SiFive WorldGuard program-driven scheme. In some implementations, the world identifier (e.g., the first world identifier) ​​is associated with all programs executed by the processor core 120 (e.g., regardless of their privileged modes). For example, the integrated circuit 110 may implement the SiFive WorldGuard core-driven scheme. In some implementations, data memory 122 includes a temporary register for storing world identifiers, which are n bits wide, and the number of worlds supported by integrated circuit 110 is 2^n = (number of controllers + 2). This temporary register can be used to mark transactions initiated by the controllers. Data memory 122 can be written to by processor core 170 mapped to enable trusted worlds to allocate memory for one or more world identifiers to one or more controllers of processor core 120. In some implementations (not shown in FIG1), data memory 122 can be located outside of processor core 120. For example, data memory 122 can be accessed by processor core 120 via external lines extending outside of processor core 120.

[0041] Processor core 120 includes a world identifier tagging circuit system 124. The world identifier tagging circuit system 124 can be configured to identify a memory request sent by the processor core on a bus of integrated circuit 110 using a world identifier to confirm authorized access to a portion of the memory space addressed by the memory request. For example, the world identifier tagging circuit system 124 can be configured to identify a memory request sent by the processor core 120 on bus 142 of integrated circuit 110 using a first world identifier. For example, in the TileLink bus protocol, a userField field can be used to send a world identifier value with the request. For example, the world identifier tagging circuit system 124 may include logic to select a world identifier associated with the privileged mode of the currently running program on processor core 120, thereby identifying an access request for a resource (e.g., memory or peripheral device).

[0042] Integrated circuit 110 includes an external memory system 140 configured to store instructions and data. External memory system 140 may include one or more memory modules. External memory system 140 may include one or more layers of cache. External memory system 140 may include memory-mapped ports to one or more peripheral devices. Processor core 120 may be configured (e.g., using a world identifier tagger circuit system 124 and data storage 122 storing one or more world identifiers) to identify a memory request transmitted by processor core 120 on a bus (e.g., bus 142) of integrated circuit 110 with a world identifier (e.g., a first world identifier) ​​to confirm authorized access to a portion of the memory space addressed by the memory request.

[0043] Integrated circuit 110 includes a world identifier checker circuit system 150, which is configured to check memory requests for one or more memory-mapped resources identified by world identifiers received via bus 142 to determine whether access is allowed or denied based on the identified world identifier. In this example, the world identifier checker circuit system 150 is for memory (e.g., random access memory or flash memory). For example, the world identifier checker circuit system 150 for a resource (e.g., a portion of memory mapped to a range of addresses) may be configured to check against a stored list of one or more world identifiers authorized to access that resource against the world identifiers used to identify requests for that resource on bus 142. For example, a world list listing resource world identifiers or a set of world identifiers may be stored in data storage 152 within the world identifier checker circuitry 150 and may be configured by a trusted world processor core 170. Data storage 152 may be configured to store a world list listing which world identifiers supported by the integrated circuitry 110 are authorized to access the resources. The world identifier checker circuitry 150 may be configured to compare the identified world identifiers with the world list. In some implementations, the world list is a bitmask, and one bit is provided for each world identifier supported by the integrated circuitry. For example, the world identifier checker circuitry 150 may include a WorldGuard filter. For example, the world identifier checker circuitry 150 may include a WorldGuard PMP.

[0044] If a memory request is checked out (i.e., the world identifier used to identify the memory request is one of the world identifiers listed in the world inventory), the world identifier checker circuitry 150 may allow the memory request to proceed without any disruption to provide access to the resource. If the memory request check fails (i.e., the world identifier used to identify the memory request is not one of the world identifiers listed in the world inventory), the memory request may be rejected by the world identifier checker circuitry 150. For example, rejecting a memory request may cause the world identifier checker circuitry 150 to receive an interrupt signal in response to the rejection of the memory request for the resource; and, in response to the rejection of the memory request for the resource, to send a rejection message via bus 142 as a response to the memory request. For example, a trusted world processor core 170 may be configured to receive an interrupt signal.

[0045] The world identifier checker circuit system 150 includes a data memory 154 configured to store world error data, which includes a world identifier identified by a memory request that has been rejected by the world identifier checker circuit system 150. For example, the world error data stored in the data memory 154 may include the address of the memory request that has been rejected by the world identifier checker circuit system 150. For example, the world error data stored in the data memory 154 may include the access mode of the memory request that has been rejected by the world identifier checker circuit system 150. For example, the data memory 154 may include an approval bit field (e.g., a one-bit field) indicating whether the world error data stored in the data memory 154 has been read by an interrupt handling routine. The world identifier checker circuitry 150 can be configured to prevent writing world error data to data memory 154 in response to a rejection of a new memory request when the approval bit field indicates that the current contents of data memory 154 have not yet been read. For example, technique 600 of FIG6 can be used to update data memory 154 in response to a rejection of a memory request. In some implementations, access to data memory 154 is restricted to a trusted world processor core 170. For example, data memory 154 may include data memory 200 of FIG2. In this example, data memory 154 is part of world identifier checker circuitry 150. In some implementations (not shown in FIG1), data memory 154 may be located outside of the world identifier checker circuitry 150 associated with it.

[0046] In some implementations, access to data storage 152 is restricted to a trusted world processor core 170, and processor core 120 is configured to send a request for information stored in data storage 154 to the trusted world processor core 170 in response to a rejection message. For example, technique 700 of FIG7 may be implemented by processor core 120.

[0047] Integrated circuit 110 includes a world identifier checker circuit system 160, which is configured to check memory requests for one or more memory-mapped resources identified by world identifiers received via bus 142 to determine whether to allow or deny access based on the identified world identifier. In this example, the world identifier checker circuit system 160 is used for one or more peripheral devices (e.g., serial ports). For example, the world identifier checker circuit system 160 for a resource (e.g., a network adapter) may be configured to check against a stored world list listing one or more world identifiers authorized to access that resource against the world identifiers used to mark requests for that resource on bus 142. For example, the world identifiers listing resources or a world list of world identifiers may be stored in data storage 162 in the world identifier checker circuit system 160 and may be configured by a trusted world processor core 170. Data storage 162 can be configured to store a world list listing which world identifiers supported by integrated circuit 110 are authorized to access the resources. World identifier checker circuitry 160 can be configured to compare the identified world identifiers with the world list. In some implementations, the world list is a bit mask, and there is one bit for each world identifier supported by the integrated circuit. For example, world identifier checker circuitry 160 may include a WorldGuard filter.

[0048] If a memory request is checked out (i.e., the world identifier used to identify the memory request is one of the world identifiers listed in the world inventory), the world identifier checker circuitry 160 can allow the memory request to proceed without any disruption to provide access to the resource. If the memory request check fails (i.e., the world identifier used to identify the memory request is not one of the world identifiers listed in the world inventory), the memory request can be rejected by the world identifier checker circuitry 160. For example, rejecting a memory request can cause the world identifier checker circuitry 160 to receive an interrupt signal in response to the rejection of the memory request for the resource; and in response to the rejection of the memory request for the resource, to send a rejection message via bus 142 as a response to the memory request. For example, a trusted world processor core 170 can be configured to receive an interrupt signal.

[0049] World ID checker circuitry 160 includes a data memory 164 configured to store world error data, which includes a world ID identified by a memory request that has been rejected by the world ID checker circuitry 160. For example, the world error data stored in data memory 164 may include the address of a memory request that has been rejected by the world ID checker circuitry 160. For example, the world error data stored in data memory 164 may include the access mode of a memory request that has been rejected by the world ID checker circuitry 160. For example, data memory 164 may include an approval bit field (e.g., a single bit) indicating whether the world error data stored in data memory 164 has been read by an interrupt handling routine. The world ID checker circuitry 160 may be configured to prevent writing world error data to data memory 164 in response to the rejection of a new memory request when the approval bit field indicates that the current content of data memory 164 has not been read. For example, the technique 600 of FIG6 can be used to update data memory 164 in response to a rejection of a memory request. In some implementations, access to data memory 164 is restricted to a trusted world processor core 170. For example, data memory 164 may include data memory 200 of FIG2. In this example, data memory 164 is part of world identifier checker circuitry 160. In some implementations (not shown in FIG1), data memory 164 may be located outside of its associated world identifier checker circuitry 160.

[0050] In some implementations, access to data storage 162 is restricted to a trusted world processor core 170, and processor core 120 is configured to send a request for information stored in data storage 164 to the trusted world processor core 170 in response to a rejection message. For example, technique 700 of FIG7 may be implemented by processor core 120.

[0051] Integrated circuit 110 includes a trusted world processor core 170 that performs write access to data memory (e.g., a temporary register) storing world identifiers. This data memory stores world identifiers at various locations on integrated circuit 110 that are used to identify memory requests on one or more buses of integrated circuit 110. The trusted world processor core 170 can also perform write access to data memory in the world identifier checker circuitry (150 and 160). For example, a world list can be written to data memory 152 by the trusted world processor core 170. In some implementations, the trusted world processor core 170 is the sole master of the integrated circuits accessing these data memories (122, 152, 154, 162, and 164). For example, during the boot routine, the world list stored in data memory 152 can be set and locked.

[0052] In some implementations (not shown in Figure 1), processor core 120 may be a trusted world processor core of its integrated circuitry. For example, a trusted world processor core may simply be processor core 120 running some trusted software in a context of a trusted world. When the world changes (e.g., from a trusted world identifier to another world identifier), processor core 120 is not considered trusted because its state is not trusted.

[0053] Figure 2 is a block diagram of an example of a data storage 200 for storing world error data of a rejected memory request. A memory request may seek access to a memory-mapped resource (e.g., a portion of memory or a peripheral device). A memory request may have been rejected because its associated world identifier does not match the authorized world identifier of the resource. Data storage 200 includes circuitry 210 (e.g., bits of a register) configured to store the world identifier associated with (e.g., used for identification on a bus) the memory request. Data storage 200 includes circuitry 220 (e.g., bits of a register) configured to store the address of the memory request. Data storage 200 includes circuitry 230 (e.g., bits of a register) configured to store the access mode of the memory request (e.g., read or write).

[0054] Data storage 200 includes circuitry 240 (e.g., bits of a temporary register) configured to store an acknowledgement bit field indicating whether world error data stored in a third data storage has been read by an interrupt handling routine. For example, circuitry 240 may store a single bit indicating whether world error data stored in the third data storage has been read by an interrupt handling routine. In some implementations, the world error checker circuitry is configured to prevent writing world error data to data storage 200 in response to a rejection of a new memory request when the acknowledgement bit field in circuitry 240 indicates that the current contents of data storage 200 have not been read. For example, this feature may be useful if the first violation in a sequence violation is considered a more significant indication of what caused the sequence violation. In some implementations, access to data storage 200 may be restricted to a trusted world processor core (e.g., trusted world processor core 170).

[0055] Figure 3 is a block diagram of an example of a secure computing architecture 310. The example involves the core "managing" two worlds: world 1, which accesses the most sensitive assets (e.g., keys) and certain peripherals (e.g., fingerprint readers on smartphones), and world 2, which runs general-purpose applications. On the slave side, each memory or peripheral has an Access Control List (ACL) containing access rights for each world identifier. Each tagged request from the master is sent to the slave via a communication bus, and its ACL is analyzed against the host's ACL. These ACL checking circuits function very similarly to a PMP that uses the world identifier to be checked, WID, and fields used as additional fields. This tagging and checking strategy makes a very complex and rich architecture easily protected, as an incorrect or missing world identifier implies an immediate rejection of the request. There is no theoretical limit to the number of supported worlds for a specific platform, consistent with the software-only proposal above: the number of worlds that a system-on-a-chip (SoC) can support is application-dependent and can be determined by the application architecture.

[0056] Architecture 310 includes a rich execution environment 320 that operates in an insecure world. The rich execution environment 320 includes untrusted applications (324 and 326) running on a rich operating system 322.

[0057] Architecture 310 includes a trusted execution environment 330 operating in a secure world. The trusted execution environment 330 includes trusted applications (334 and 336) running on a trusted kernel 332.

[0058] Architecture 310 includes a security monitor 340. The security monitor 340 is responsible for managing the switching between secure and insecure states. The security monitor 340 manages context switching (e.g., saving and restoring). The security monitor 340 also handles interrupt handling. The security monitor 340 includes a scheduling module 342. Architecture 310 includes hardware 350, which may be a single processor core or multiple processor cores.

[0059] For example, untrusted applications (324 and 326) and rich operating system 322 may be associated with a first world identifier used to identify their resource (e.g., memory or peripheral device) access requests. For example, trusted applications (334 and 336) and trusted kernel 332 may be associated with a second world identifier used to identify their resource (e.g., memory or peripheral device) access requests.

[0060] Figure 4 is a block diagram of an example architecture 410 for software isolation on a single core. Architecture 410 includes a rich execution environment 420 running on an untrusted world. The rich execution environment 420 includes untrusted applications (424 and 426) running on a rich operating system 422.

[0061] Architecture 410 includes a security monitor 440. Security monitor 440 includes a scheduling module 442. Architecture 410 includes a root key 444, a secure boot module 446, and a root of trust 448. Architecture 410 includes hardware 450, which in this example is a single processor core.

[0062] Architecture 410 includes a first enclave 460, which includes an application 464 running on a runtime operating system 462. Architecture 410 also includes a second enclave 470, which includes the application 474 running on a runtime operating system 472.

[0063] Untrusted applications (424 and 426) and applications in specific address spaces (464 and 474) can use privileged mode in user mode. Rich operating system 422 and runtime operating system (462 and 472) can use privileged mode in supervisor mode. Security monitor 440, root key 444, security root module 446, and trust root 448 can use privileged mode in machine mode.

[0064] In some implementations, untrusted applications (424 and 426) and rich operating system 422 use a shared world identifier. For example, security monitor 440, root key 444, secure boot module 446, and root of trust 448 can all use a shared trusted world identifier. For example, each of the specified address space applications (464 and 474) and runtime operating system (462 and 472) can have its own unique world identifier.

[0065] Examples of the architecture are described in Figure 3 (REE / TEE architecture) and Figure 4 (Keystone specified address space solution). This approach is based on a security monitor capable of managing different independent fragments of the software. These fragments may be referred to as boxes, containers, or cubes, but the idea is not to have them manage privileged modes, as this functionality is only available to the security monitor 440. When a request comes from a box, box resources (memory, peripherals) and inter-box communication are also dynamically controlled and dispatched by the hypervisor.

[0066] On highly flexible platforms (e.g., RISC-V based products), it can be advantageous to group any critical function or task into a single container, separate from other containers: one container for cryptography, another for communication libraries, one for data sensors, and one for the main application. A software architecture paradigm is to use a security monitor control container that runs in machine mode (M mode). Each container consists of two parts: an operating system running in supervisor mode (S mode) and application tasks running in user mode (U mode).

[0067] The debugging mechanism can be adapted to conform to WorldGuard principles and platform configuration. If required, debugging of certain worlds, their software, and their resources (e.g., memory and peripherals) will be avoided. This scenario represents a typical software architecture where parts of the code (e.g., TEE or security-defined address space) are inaccessible to application developers and therefore unavailable to the debugging module, while the currently developed application will have access to the debugging module.

[0068] For example, the world associated with the rich execution environment is available for application debugging, while other worlds (security monitor, specified address space) are not available.

[0069] For example, consider the WorldGuard platform, which has the largest number of NWorlds worlds. A debugwid-list consisting of NWorlds bits can be configured, where each bit represents a WID value (among all possible world values) and the debugging module's ability to perform debugging operations on that WID value (i.e., the debugging software running on the kernel with that current WID value). Therefore, a function combining the wgMarker WID value and debugwid-list information produces the final debug-wg-authorized signal. This signal can then be combined with other signals to prevent debugging of unauthorized WIDs. This signal is used to allow or prevent a debugging interrupt from being triggered and to jump to the debug handler in the debug ROM. In some implementations, the debugging interrupt signal itself still reaches the kernel, but the debug-wg-authorized signal determines whether to trigger the interrupt or ignore it. As a result, when WID debugging is not authorized, the debug ROM code is not used.

[0070] Now, assuming debugging is authorized, and therefore a debugging interrupt has been initiated, the debugging operation can be accessing some CSRs and / or some data in memory. Therefore, it is advisable to grant access to these CSRs with their current WID values. Similarly, data access can be approved based on the consistency of the data address with the current WID value. However, since the debug ROM code runs in debug mode that approves any access, the privileged mode used for access control should be from dcsr.prv rather than mstatus.prv. This rule may imply some modifications and consequences. For example, one modification is that if mstatus.prv is in debug mode, the hardware logic in the processor core's CSR module can be modified to check the CSR number against dcsr.prv instead of mstatus.prv.

[0071] Figure 5 is a flowchart illustrating an example of a technique 500 for error management in a system-on-a-chip (SoC) with securely partitioned memory space. Technique 500 includes: receiving via a bus 510 a memory request for a memory-mapped resource identified by a first world identifier 510; comparing the first world identifier from the memory request with a world list associated with the memory-mapped resource 520; and determining, based on the comparison of the first world identifier and the world list, whether to allow or deny access to the resource for the memory request 530. At 535, if the memory request is allowed, technique 500 includes, in response to allowing the memory request, enabling 540 to complete the access requested by the memory request. At 535, if the memory request is denied, technique 500 includes, in response to denying access to the resource for the memory request, storing 550 world error data including the first world identifier in data storage (e.g., data storage 200). Technique 500 also includes receiving an interrupt signal 552 in response to the rejection of a memory request for a resource; and sending a rejection message 554 via a bus in response to the rejection of a memory request for a resource. For example, technique 500 can be implemented using the integrated circuit 110 of FIG1.

[0072] Technique 500 includes receiving 510 memory requests for memory-mapped resources (e.g., a portion of memory or peripheral devices) from a processor core via a bus. The memory request is identified using a world identifier (e.g., a first world identifier). In some implementations, the memory request is transmitted on the bus using a bus protocol (e.g., the TileLink bus protocol). For example, in the TileLink bus protocol, a userField field may be used to transmit the world identifier value with the request. For example, a world identifier associated with the privileged mode of the current program running on the processor core (e.g., processor core 120) has been selected to identify the access request to the resource. In some implementations, the world identifier is a unique world identifier used by the processor core. For example, the memory request may be received 510 by a slave (e.g., a memory controller) connected to the bus, and this slave may implement world identifier checker logic (e.g., using world identifier checker circuitry 150).

[0073] Technique 500 includes comparing a first world identifier from a memory request with a world list associated with the memory-mapped resource 520. The world list lists which world identifiers supported by the integrated circuit are authorized to access the resource. For example, the world list may be stored as a list of world identifiers, and by applying logic, the first world identifier may be compared 520 to determine whether the first world identifier is equal to one of the world identifiers stored in the world list. In some implementations, the world list is stored as a bit mask, and one bit for each world identifier supported by the integrated circuit, and by applying shift logic, the first world identifier may be compared 520 to determine whether the bits in the world list corresponding to the first world identifier are valid (high-state valid or low-state valid).

[0074] Technique 500 includes determining, based on a comparison between a first world identifier and a world list, whether to allow or deny access to the resource for a memory request. For example, if the comparison indicates that the first world identifier is a set of members in an authorized world encoded by the world list, then the memory request can be determined to be allowed (530). Otherwise, the memory request can be determined to be denied (530).

[0075] At 535, if the memory request is allowed, then technique 500 includes, in response to the allowance of the memory request, enabling 540 to complete the access requested by the memory request (e.g., writing to or reading from a resource).

[0076] At 535, if the memory request is denied, technique 500 includes storing world error data 550 in data storage (e.g., data storage 154 or data storage 164) in response to the denial of access to the resource for the memory request. The world error data may include a first world identifier from the memory request. For example, the world error data stored in data storage 550 may include the address of the memory request. For example, the world error data stored in data storage 550 may include the access mode of the memory request (e.g., read, write, or execute). For example, the world error data stored in data storage 550 may include an approval bit field (e.g., a single bit) indicating whether the world error data stored in the data storage has been read by an interrupt handling mode. The approval bit field may be used to hold the error data of the first violation in a sequence of violations until it can be accessed (e.g., by an interrupt handling mode). In some implementations, technique 500 includes preventing world error data from being written to the data memory in response to a rejection of a new memory request when an approval bit field indicates that the current contents of the data memory have not yet been read. For example, technique 600 of FIG6 can be implemented to selectively update the data memory (e.g., a temporary register) storing world error data. In some implementations, access to the data memory (e.g., data memory 162) is restricted to a trusted world processor core.

[0077] Technique 500 includes obtaining an interrupt signal 552 in response to the rejection of a memory request for a resource. For example, this interrupt signal could be the source of an interrupt controller. In that case, the interrupt handler can be executed in the event of a violation. Theoretically, any core can register this interrupt signal. Preferably, the core running on a trusted world processor registers the interrupt signal, as this core can be dedicated to security monitoring. For example, a trusted world processor core (e.g., trusted world processor core 170) can be configured to receive the interrupt signal. For a single-core platform, the trusted core and the local core can be the same core.

[0078] Technique 500 includes responding to a rejection of a memory request for a resource by sending a 554 Reject message via the bus. In some implementations, access to the data storage is restricted to a trusted world processor core, and technique 500 includes responding to receiving a rejection message by sending a request for information stored in the data storage to the trusted world processor core. For example, technique 700 of FIG7 can be implemented to request information stored in the data storage from a trusted world processor core.

[0079] Figure 6 is a flowchart of an example of technique 600 for writing world error data to data storage using an ACK field (e.g., in response to a rejection of a new memory request). For example, the data storage includes an ACK bit field indicating whether world error data stored in the data storage has been read by the interrupt handling routine. Many other violations of the same type may follow the first violation. However, it is often important to analyze the first violation, as it may be the most important and provides the best clue as to what went wrong. Therefore, the error register also includes a bit field called ACK, which prevents the error register from being updated immediately following a new violation. The error register can only be updated with the latest violation information when the ACK bit field is set, i.e., when the above information is considered acknowledged.

[0080] Technique 600 includes an acknowledge bit field for verifying world error data stored in data storage (e.g., a temporary register) by 610. For example, the acknowledge bit field can be initialized to indicate that the data has not been read in response to a rejection of a memory request when world error data is written to the data storage. For example, the acknowledge bit field can be updated to indicate that the data has been read when an interrupt handler reads a value stored in the data storage.

[0081] At 615, if the acknowledge bit field indicates that world error data has been read, then technique 600 includes continuing by writing the world error data to data storage at 620 (e.g., data storage 200) in response to the rejection of the new memory request.

[0082] At 615, if the acknowledge bit field indicates that world error data has not been read, then technique 600 includes responding to the rejection of the new memory request by preventing 630 from writing world error data to the data storage when the acknowledge bit field indicates that the current contents of the data storage have not been read.

[0083] Figure 7 is a flowchart illustrating an example of technique 700, where the master controller uses different world identifiers to request world error information from a trusted world processor core. Technique 700 includes transmitting 710 a memory request for a memory-mapped resource (e.g., a peripheral device or a portion of memory mapped to a range of addresses) from the processor core via a bus. The memory request can be identified using a first world identifier. The memory request is identified using a world identifier (e.g., a first world identifier). In some implementations, the memory request is transmitted 710 on the bus using a bus protocol (e.g., the TileLink bus protocol). For example, in the TileLink bus protocol, a userField field can be used to transmit a world identifier value with the request. For example, a world identifier associated with the privileged mode of the current program running on the processor core (e.g., processor core 120) has been selected to identify the access request to the resource. In some implementations, the world identifier is a unique world identifier used by the processor core.

[0084] Technique 700 includes receiving a rejection message at the processor core via a bus at 720 as a response to a memory request. For example, the world identifier checker circuitry of the memory controller (e.g., world identifier checker circuitry 150) has sent a rejection message in response to denying a memory request for the resource (because it has a world identifier not included in the world list).

[0085] Technique 700 includes responding to a rejection message by sending a request from a processor core for information stored in data memory to a trusted world processor core at 730. The data memory (e.g., data memory 200) stores world error data for the memory request, and access to the data memory is restricted to a trusted world processor core (e.g., trusted world processor core 170). A program running on the trusted world processor core can then determine whether to share the information in the data memory with the requesting processor core.

[0086] In the first state, the object described in this specification may be specifically implemented in an integrated circuit for executing instructions, the integrated circuit including: a processor core configured to execute instructions; a first data storage configured to store a first world identifier; a world identifier tagging circuit system configured to identify a memory request transmitted by the processor core on a bus of the integrated circuit using the first world identifier; and a world identifier checker circuit system configured to check the world identifier-identified memory mapping resources received via the bus for one or more memory mapping resources. The system comprises: a memory request, which determines whether access is allowed or denied based on the identified world identifier; a second data storage, configured to store a world list listing which world identifiers supported by the integrated circuit are authorized to access the resource, wherein a world identifier checker circuit system is configured to compare the identified world identifier with the world list; and a third data storage, configured to store world error data, including the identified world identifier of memory requests that have been denied by the world identifier checker circuit system.

[0087] In the first state, the world error data stored in the third data memory may include the address of a memory request that has been rejected by the world identifier checker circuitry. In the first state, the world error data stored in the third data memory may include the access mode of a memory request that has been rejected by the world identifier checker circuitry. In the first state, the third data memory may include an approval bit field indicating whether the world error data stored in the third data memory has been read by the interrupt handling routine. In the first state, the world identifier checker circuitry may be configured to respond to the rejection of a new memory request and prevent the world error data from being written to the third data memory when the approval bit field indicates that the current content of the third data memory has not been read. In the first state, access to the third data memory may be limited to trusted world processor cores. In the first state example, the world identifier checker circuitry can be configured to receive an interrupt signal in response to a rejection of a memory request for a resource; and, in response to a rejection of a memory request for a resource, to send a rejection message via a bus as a response to the memory request. In the first state example, the trusted world processor core can be configured to receive the interrupt signal. In the first state example, access to the third data storage can be limited to the trusted world processor core, and the processor core can be configured to send a request for information stored in the third data storage to the trusted world processor core in response to receiving a rejection message. In the first state example, the third data storage can be part of the world identifier checker circuitry.

[0088] In the second state, the object described in this specification may be implemented in a method comprising: receiving a memory request for a memory-mapped resource from a processor core via a bus, wherein the memory request is identified by a first world identifier; comparing the first world identifier from the memory request with a world list associated with the memory-mapped resource, wherein the world list lists which world identifiers supported by the integrated circuit are authorized to access the resource; determining, based on the comparison of the first world identifier and the world list, whether to allow or deny access to the resource for the memory request; and, in response to the denial of access to the resource for the memory request, storing world error data in a data storage, wherein the world error data includes the first world identifier from the memory request.

[0089] In the second state, the method may include receiving an interrupt signal in response to a rejection of a memory request for a resource; and sending a rejection message via a bus as a response to the rejection of the memory request for the resource. In the second state, the trusted world processor core may be configured to receive an interrupt signal. In the second state, access to the data memory may be limited to the trusted world processor core, and the method may include sending a request for information stored in the data memory to the trusted world processor core in response to receiving a rejection message. In the second state, world error data stored in the data memory may include the address of the memory request. In the second state, world error data stored in the data memory may include the access mode of the memory request. In the second state, the data memory may include an acknowledgement bit field indicating whether world error data stored in the data memory has been read by the interrupt handling mode. In the second state, the method may include responding to a rejection of a new memory request to prevent erroneous world data from being written to the data memory when an approval bit field indicates that the current contents of the data memory have not yet been read. In the second state, access to the data memory may be limited to trusted world processor cores.

[0090] In the third state, the object described in this specification may be embodied in a method comprising: transmitting a memory request for memory-mapped resources from a processor core via a bus, wherein the memory request is identified by a first world identifier; receiving, at the processor core, a rejection message as a response to the memory request via the bus; and, in response to receiving the rejection message, sending a request from the processor core for information stored in data storage to a trusted world processor core, wherein the data storage stores world error data of the memory request, and access to the data storage is limited to the trusted world processor core.

[0091] In the third state, the memory mapping resource can be a peripheral device. In the third state, the memory mapping resource can be a portion of memory mapped to a range of addresses.

[0092] Although this disclosure has been described in conjunction with certain embodiments, it should be understood that this disclosure is not limited to the disclosed embodiments, but rather is intended to cover various modifications and equivalent arrangements included within the scope of the appended claims, which is given the broadest interpretation to cover all such modifications and equivalent structures.

[0093] ACL: Access Control List 110: Integrated circuits 120: Processor Core 122, 152, 162, 154, 164, 200: Data storage [] 140: External Memory System 142: Busbar 150, 160:world identification code checker circuit system 170: Trusted World Processor Core 210, 220, 230, 240: Circuit System 310: Architecture for Secure Computing 320, 420: Enrich the execution environment 322, 422: Enrich the operating system 324, 326, 424, 426: Untrusted Applications 330: Trusted Execution Environment 332: The Core of Trust 334, 336: Trusted Applications 340, 440: Security Monitor 342, 442: Scheduling modules 350, 450: Hardware 410: Architecture 444: The Root Key 446: Safe Start Module 448: Root of Trust 460: First designated address space 462: Runtime Job System 464, 474: Specify address space application 472: Runtime Job System 700, 500, 600: Technology

Claims

1. An integrated circuit for executing instructions, comprising: A processor core configured to execute instructions; A first data storage device configured to store a first world identifier; a world identifier tagging circuit system configured to identify a memory request transmitted by the processor core on a bus of the integrated circuit using the first world identifier; and a world identifier checker circuit system configured to check a memory request for one or more memory-mapped resources identified by a world identifier received via the bus, to determine whether to allow or deny access based on the identified world identifier. A second data storage device configured to store a list of worlds for a resource, listing which world identifiers supported by the integrated circuit are authorized to access the resource, wherein the world identifier checker circuitry is configured to compare the identified world identifier with the world list; and a third data storage device configured to store world error data, including a memory request for the identified world identifier that has been rejected by the world identifier checker circuitry.

2. The integrated circuit as claimed in claim 1, wherein the world error data stored in the third data memory includes a bit address of the memory request that has been rejected by the world identifier checker circuit system.

3. The integrated circuit as claimed in claim 1, wherein the world error data stored in the third data storage includes an access mode of the memory request that has been rejected by the world identification code checker circuit system.

4. The integrated circuit as claimed in claim 1, wherein the third data storage includes an approval bit field indicating whether world error data stored in the third data storage has been read by an interrupt handling mode.

5. The integrated circuit as claimed in claim 4, wherein the world identifier checker circuit system is configured to respond to a rejection of a new memory request and prevent world error data from being written to the third data memory when the approval bit field indicates that the current content of the third data memory has not been read.

6. The integrated circuit as claimed in claim 1, wherein access to the third data storage is restricted to a trusted world processor core.

7. The integrated circuit as claimed in claim 1, wherein the world identifier checker circuit system is configured to: receive an interrupt signal in response to the rejection of the memory request for the resource; and, in response to the rejection of the memory request for the resource, send a rejection message via the bus as a response to the memory request.

8. The integrated circuit as described in claim 7, wherein a trusted world processor core is configured to receive the interrupt signal.

9. The integrated circuit as claimed in claim 7, wherein access to the third data storage is restricted to a trusted world processor core, and the processor core is configured to: in response to receiving the rejection message, send a request for information stored in the third data storage to the trusted world processor core.

10. The integrated circuit as claimed in claim 1, wherein the third data storage is part of the world identifier checker circuit system.

11. A method for determining whether to allow or deny access to a memory-mapped resource requested for a memory, comprising: The system receives a memory request for a memory-mapped resource from a processor core via a bus, wherein the memory request is identified by a first world identifier; compares the first world identifier from the memory request with a world list associated with the memory-mapped resource, wherein the world list lists which world identifiers supported by an integrated circuit are authorized to access the memory-mapped resource; based on the comparison between the first world identifier and the world list, determines whether to allow or deny access to the memory-mapped resource for the memory request; and in response to the denial of access to the memory-mapped resource for the memory request, stores world error data in a data storage, wherein the world error data includes the first world identifier from the memory request and a bit address of the memory request.

12. The method as described in claim 11, comprising: In response to the denial of the memory request for the resource, an interrupt signal is obtained; And in response to the rejection of the memory request for the resource, a rejection message is sent via the bus as a response to the memory request.

13. The method as described in claim 12, wherein a trusted world processor core is configured to receive the interrupt signal.

14. The method of claim 12, wherein access to the data storage is restricted to a trusted world processor core, and includes: In response to receiving the rejection message, a request for information stored in the data storage is sent to the trusted world processor core.

15. The method of claim 11, wherein the world error data stored in the data storage includes an access mode requested by the memory.

16. The method of claim 11, wherein the data storage includes an approval bit field indicating whether world error data stored in the data storage has been read by an interrupt handling routine.

17. The method as described in claim 16, comprising: When the approval bit field indicates that the current contents of the data storage have not been read, it responds to the rejection of a new memory request, preventing erroneous data from being written to the data storage.

18. The method of claim 11, wherein access to the data storage is restricted to a trusted world processor core.

19. A method for transmitting a memory request, comprising: A memory request for a memory-mapped resource is transmitted from a processor core via a bus, wherein the memory request is identified by a first world identifier; a rejection message is received at the processor core via the bus as a response to the memory request; and in response to receiving the rejection message, a request from the processor core for information stored in a data memory is sent to a trusted world processor core, wherein the data memory stores world error data of the memory request, and access to the data memory is restricted to the trusted world processor core, wherein the world error data includes the first world identifier from the memory request and a bit address of the memory request.

Images