A secure isolation apparatus and method

Abstract

This application provides a secure isolation device and method, relating to the field of chip technology, which can solve the problem of insufficient isolation between different subsystems in the field of autonomous driving, and reduces isolation costs. The device can be a secure isolation device, comprising a first subsystem and a second subsystem applied to the same chip. The security level of a first physical resource included in the first subsystem is higher than the security level of a second physical resource included in the second subsystem. The first subsystem includes an interrupt controller for managing interrupts of peripherals in the second subsystem. Embodiments of this application are used for the isolation of subsystems with different security levels within a chip.

Description

Technical Field

[0001] This application relates to the field of chip technology, and in particular to a security isolation device and method. Background Technology

[0002] The field of autonomous driving requires meeting high functional safety indicators of the Automotive Safety Integration Level (ASIL). Systems in this field are quite complex, and the safety levels that subsystems can achieve can include multiple safety levels such as ASIL-B and ASIL-D. It can also include non-safety level systems such as quality management (QM). ASIL-D represents the highest level, while QM indicates that developing the system or function according to a quality management system is sufficient, without needing to consider any safety-related design aspects.

[0003] To prevent interference between different subsystems, the resources used by different subsystems need to be isolated. These resources can be, for example, accessible storage space or the cores used to run the subsystems. Currently, industry solutions for isolating different subsystems mainly involve virtualization isolation, multi-die packaging, combining multiple system-on-a-chip (SoC) chips, and redundancy degradation.

[0004] Virtualization isolation primarily relies on a hypervisor-based virtualization scheme to isolate different subsystems. This hypervisor can run multiple guest operating systems (OS), each running on a kernel with different security levels. However, hypervisor-based virtualization suffers from a single point of failure, leading to a common-cause failure risk. This results in incomplete isolation of guest OSes at different security levels, reducing the overall security level of the solution. For schemes that combine multiple System-on-Chips (SoCs) to isolate different subsystems, a combination of a main SoC and a microcontroller unit (MCU) is typically used. The main SoC can handle ASIL-B or QM level services, while the MCU can handle ASIL-D services. The main SoC communicates with the MCU via a communication line. However, the main SoC and MCU are two independent chips, resulting in a complex motherboard circuitry that increases motherboard area, cost, and complexity. Furthermore, communication between the main SoC and MCU via the intermediate communication line carries a high risk of line breakage, reducing reliability and slowing data transmission speeds. Summary of the Invention

[0005] This application provides a safety isolation device and method that solves the problem of insufficient isolation between different subsystems in the field of autonomous driving, and reduces isolation costs.

[0006] To achieve the above objectives, the embodiments of this application adopt the following technical solutions.

[0007] Firstly, a security isolation device is provided, comprising: a first subsystem and a second subsystem contained in the same chip, wherein the security level of a first physical resource included in the first subsystem is higher than the security level of a second physical resource included in the second subsystem, and the first subsystem includes an interrupt controller for managing interrupts of peripherals of the second subsystem. The peripherals of the second subsystem can be understood as a type of physical resource of the second subsystem, i.e., a second physical resource.

[0008] In this application, two subsystems can be configured within the same chip: a first subsystem and a second subsystem. The different subsystems include physical resources with different security levels. This application avoids the risk of common-cause failure due to a single point of failure in the hypervisor, which is often caused by existing technologies that use a hypervisor to run multiple virtual guest OSes on multiple cores with different security levels to achieve subsystem isolation. In other words, this application can directly configure the security levels of the physical resources of different subsystems to obtain subsystems with different security levels. Furthermore, the interrupt controller resides in the high-security-level first subsystem and manages interrupts from low-security-level peripherals. Thus, by achieving complete physical isolation between subsystems with different security levels, setting the interrupt controller to a high security level ensures the safety of the interrupt execution process.

[0009] In one possible design, the peripherals of the second subsystem include a second peripheral; the second peripheral is used to send an interrupt signal to the interrupt controller of the first subsystem; the interrupt controller, upon receiving an interrupt signal, controls the processor core in either the second or first subsystem to suspend the currently running program and execute the program indicated by the interrupt signal. That is, if the second subsystem, which does not include an interrupt controller, triggers an interrupt, it needs to send an interrupt signal to a higher-security subsystem that includes an interrupt controller. The interrupt controller in the higher-security subsystem then controls the processor core to run the program indicated by the interrupt signal. Thus, with a high-security interrupt controller, lower-security subsystems cannot arbitrarily execute interrupts; the interrupt controller of the higher-security subsystem must assist the lower-security subsystem in controlling the processor core to execute interrupts. This ensures interrupt security and provides security for the isolation device.

[0010] In one possible design, the first physical resource includes a first processor core, and the second physical resource includes an interrupt configuration register and a second processor core. The second processor core is further used to write interrupt information to the interrupt configuration register, the interrupt information including the interrupt attributes of an interrupt signal sent by a second peripheral device. The first processor core is used to read the interrupt information from the interrupt configuration register and configure the interrupt information in the interrupt controller, so that the interrupt controller controls the processor core in the second subsystem or the processor core in the first subsystem to execute the program indicated by the interrupt signal sent by the second peripheral device. That is, when a low-security-level subsystem needs to configure the interrupt controller, it must request configuration from a high-security-level subsystem that includes the interrupt controller. In this application, when there are multiple security-level subsystems, only the high-security-level subsystem can write access to the interrupt controller. If a non-high-security-level subsystem needs to configure the interrupt controller, it can only be done by the high-security-level subsystem assisting the low-security-level subsystem in performing the interrupt controller configuration, which can improve the security of interrupt configuration.

[0011] In one possible design, the first processor core is further configured to: retrieve an interrupt configuration request from the interrupt configuration register to trigger the first processor core to read interrupt information from the interrupt configuration register. For example, upon receiving an interrupt configuration request, the first processor core suspends the execution of the currently running program and reads the interrupt information from the interrupt configuration register; determines the register address and write value of the interrupt controller based on the interrupt information, the write value indicating the interrupt information; writes the write value to the register indicated by the register address of the interrupt controller, and then continues the execution of the currently running program. The interrupt configuration register can be a Mailbox. That is, when the first processor core in the high-security-level first subsystem receives a request to configure the interrupt controller, it can suspend the currently running program and configure the interrupt controller based on the interrupt information read from the Mailbox of the second subsystem. This method of configuring the interrupt controller by the high-security-level processor core improves the security of interrupt controller configuration and also enhances the security of the chip containing the security isolation device.

[0012] In one possible design, the first physical resource is configured with a first security level identifier, and the second physical resource is configured with a second security level identifier. That is, by configuring security level identifiers for physical resources to distinguish between physical resources of different security levels, this application effectively isolates physical resources of different security levels physically, resulting in a more thorough isolation.

[0013] In one possible design, the security isolation device further includes an authentication component. The first physical resource includes a first processor core, and the second physical resource includes a second processor core. The authentication component authenticates access requests initiated by the first processor core in the first subsystem or the second processor core in the second subsystem, and, upon successful authentication, sends the access request to the corresponding peripheral device within the chip. The authentication component in this application can be understood as a component that does not belong to any one subsystem but can communicate with any subsystem. When one subsystem wants to access the physical resources of another subsystem, it must be authenticated by the authentication component. This makes access between subsystems more secure, as only access requests successfully authenticated by the authentication component can be sent to the accessed subsystem.

[0014] In one possible design, the second physical resource includes a second peripheral device; a first processor core, configured to send a first access request to an authentication component, the first access request carrying a first security level identifier and the address of the second peripheral device to be accessed; and an authentication component, configured to receive the first access request, obtain the second security level identifier of the second peripheral device based on the address of the second peripheral device carried in the first access request, perform authentication based on the first security level identifier and the second security level identifier, and forward the first access request to the second peripheral device upon successful authentication.

[0015] Since each physical resource in each subsystem is configured with a security level identifier, when a physical resource in one subsystem wants to access a physical resource in another subsystem, the access request must carry the security level identifier of the physical resource. The authentication component can perform authentication based on the security level identifier carried in the access request and the security level identifier of the physical resource being accessed, in order to determine whether access is permitted. This ensures the security of subsystems with different security levels.

[0016] In one possible design, the authentication component is specifically used to: determine that authentication is successful if the security level of the first processor core corresponding to the first security level identifier is higher than the security level of the second peripheral device corresponding to the second security level identifier; wherein, the first access request is a write request or a read request.

[0017] In other words, the processor core in a high-security subsystem, including the interrupt controller, can perform write or read access to peripherals in a low-security subsystem, thereby enhancing the privileges of the high-security subsystem.

[0018] In one possible design, the first physical resource includes a first peripheral device; a second processor core, configured to send a second access request to an authentication component, the second access request carrying a second security level identifier and the address of the first peripheral device to be accessed; and an authentication component, configured to receive the second access request, obtain the first security level identifier of the first peripheral device based on the address of the first peripheral device carried in the second access request, perform authentication based on the first security level identifier and the second security level identifier, and forward the second access request to the first peripheral device upon successful authentication.

[0019] Similar to the design described above, the authentication component can perform authentication based on the security level identifier carried in the access request and the security level identifier of the physical resource being accessed, in order to determine whether access is permitted. This ensures the security of subsystems with different security levels.

[0020] In one possible design, the authentication component is specifically used to: determine successful authentication if the security level of the second processor core corresponding to the second security level identifier is lower than the security level of the first peripheral device corresponding to the first security level identifier, and the second access request is a read request. That is, if a lower-security-level subsystem needs to read from a higher-security-level subsystem, the authentication component can send the request from the lower-security-level subsystem to the higher-security-level subsystem for read access. If a lower-security-level subsystem needs to write to a higher-security-level subsystem, the authentication component determines that authentication has failed, meaning the lower-security-level subsystem does not have permission to write to the higher-security-level subsystem. This ensures higher security for the higher-security-level subsystem.

[0021] In one possible design, a first subsystem is used to handle first security level business, and a second subsystem is used to handle second security level business or non-security level business, wherein the first security level is higher than the second security level, the first and second security levels are the levels in the Vehicle Safety Integrity Level (ASIL), and the non-security level is the Quality Management (QM) level.

[0022] In one possible design, the interrupt controller is the only interrupt controller within the chip, meaning that the interrupt controller controls the interrupts of all peripherals within the chip.

[0023] Secondly, a security isolation method is provided, which is applied to a security isolation device. The security isolation device includes a first subsystem and a second subsystem contained in the same chip. The security level of a first physical resource included in the first subsystem is higher than the security level of a second physical resource included in the second subsystem. The first subsystem includes an interrupt controller for managing interrupts of peripherals in the second subsystem. The method includes:

[0024] The interrupt controller manages the interrupts of the peripherals in the second subsystem.

[0025] In one possible design, a second peripheral of the second subsystem sends an interrupt signal to the interrupt controller of the first subsystem; upon receiving the interrupt signal, the interrupt controller controls either the processor core of the second subsystem or the processor core of the first subsystem to suspend the running program and execute the program indicated by the interrupt signal.

[0026] In other words, when a lower-security-level subsystem needs to trigger an interrupt, it must send an interrupt signal to a higher-security-level subsystem, including the interrupt controller. The higher-security-level subsystem has the authority to instruct the processor core to suspend the currently running program and execute the interrupted program. In this way, not only are the physical resources of different security subsystems isolated, but the security of interrupts is also guaranteed.

[0027] In one possible design, the second physical resource includes a second processor core, and the first physical resource includes a first processor core; the interrupt controller, upon receiving the interrupt signal, controls the processor core of the second subsystem or the processor core of the first subsystem to suspend the running program and execute the program indicated by the interrupt signal, including: the interrupt controller sending the interrupt signal to the second processor core and controlling the second processor core to suspend the running program and execute the program indicated by the interrupt signal; or, the interrupt controller sending the interrupt signal to the first processor core and controlling the first processor core to suspend the running program and execute the program indicated by the interrupt signal.

[0028] In other words, if a second subsystem without an interrupt controller triggers an interrupt, it needs to send an interrupt signal to a higher-security subsystem that includes an interrupt controller. The interrupt controller in the higher-security subsystem then controls the processor core to execute the program indicated by the interrupt signal. Thus, with a high-security interrupt controller, lower-security subsystems cannot arbitrarily execute interrupts; the interrupt controller of the higher-security subsystem must assist the lower-security subsystem in controlling the processor core to execute interrupts. This ensures interrupt security and also provides security for the security isolation device.

[0029] In one possible design, the second physical resource further includes an interrupt configuration register and a second processor core, and the first physical resource includes a first processor core. Before the second peripheral of the second subsystem sends an interrupt signal to the interrupt controller of the first subsystem, the method further includes: the second processor core writing interrupt information to the interrupt configuration register, the interrupt information including the interrupt attributes of the interrupt signal sent by the second peripheral; the first processor core reading the interrupt information from the interrupt configuration register and configuring the interrupt information in the interrupt controller, so that the interrupt controller controls the processor core in the second subsystem or the processor core in the first subsystem to execute the program indicated by the interrupt signal sent by the second peripheral.

[0030] In other words, when a low-security-level subsystem needs to configure an interrupt controller, it must request configuration from a high-security-level subsystem that includes the interrupt controller. Therefore, in this application, when multiple security-level subsystems exist, only the high-security-level subsystem can write access to the interrupt controller. If a non-high-security-level subsystem needs to configure an interrupt controller, it can only do so through the assistance of a high-security-level subsystem, thus improving the security of interrupt configuration.

[0031] In one possible design, the first processor core reading interrupt information from the interrupt configuration register includes: the first processor core obtaining an interrupt configuration request from the interrupt configuration register to trigger the first processor core to read interrupt information from the interrupt configuration register. For example, when the first processor core receives an interrupt configuration request, it suspends the execution of the currently running program and reads the interrupt information from the interrupt configuration register; the first processor core determines the register address and write value of the interrupt controller based on the interrupt information, the write value being used to indicate the interrupt information; the first processor core writes the write value to the register indicated by the register address of the interrupt controller, and then controls the first processor core to continue executing the currently running program.

[0032] The terminal configuration register can be the Mailbox. That is, when the first processor core in the first subsystem with a high security level receives a request to configure the interrupt controller, it can pause the running program and configure the interrupt controller according to the interrupt information read from the Mailbox of the second subsystem. This method of configuring the interrupt controller by the processor core with a high security level can improve the security of configuring the interrupt controller and also improve the security of the chip where the security isolation device is located.

[0033] In one possible design, the security levels of the first and second physical resources are configured during the system initialization phase of the chip via firmware used for chip initialization. That is, the security levels can be set at the chip's factory. When the chip is running, the firmware can configure the security levels of the physical resources within the chip.

[0034] In one possible design, the first physical resource is configured with a first security level identifier, and the second physical resource is configured with a second security level identifier. That is, by configuring security level identifiers for physical resources to distinguish between physical resources of different security levels, this application effectively isolates physical resources of different security levels physically, resulting in a more thorough isolation.

[0035] In one possible design, the security isolation device further includes an authentication component; the first physical resource includes a first processor core, and the second physical resource includes a second processor core; the authentication component authenticates access requests initiated by the first processor core in the first subsystem or the second processor core in the second subsystem, and upon successful authentication, controls the authentication component to send the access request to the corresponding peripheral device within the chip. The authentication component in this application can be understood as a component that does not belong to any one subsystem but can communicate with any one subsystem. When a subsystem wants to access the physical resources of another subsystem, it must be authenticated by the authentication component. This makes access between subsystems more secure, as only access requests successfully authenticated by the authentication component can be sent to the accessed subsystem.

[0036] In one possible design, the second physical resource includes a second peripheral device; the authentication component authenticates access requests initiated by the first processor core in the first subsystem or the second processor core in the second subsystem, and when authentication is successful, the authentication component sends the access request to the corresponding peripheral device within the chip, including: the first processor core sending a first access request to the authentication component, the first access request carrying a first security level identifier and the address of the second peripheral device to be accessed; the authentication component obtaining the second security level identifier of the second peripheral device based on the address of the second peripheral device carried in the first access request, and performing authentication based on the first security level identifier and the second security level identifier; when authentication is successful, the authentication component forwards the first access request to the second peripheral device.

[0037] Since each physical resource in each subsystem is configured with a security level identifier, when a physical resource in one subsystem wants to access a physical resource in another subsystem, the access request must carry the security level identifier of the physical resource. The authentication component can perform authentication based on the security level identifier carried in the access request and the security level identifier of the physical resource being accessed, in order to determine whether access is permitted. This ensures the security of subsystems with different security levels.

[0038] In one possible design, authentication based on the first security level identifier and the second security level identifier includes:

[0039] If the security level of the first processor core corresponding to the first security level identifier is higher than the security level of the second peripheral device corresponding to the second security level identifier, then authentication is successful. Here, the first access request is either a write request or a read request. In other words, the processor core in a high-security-level subsystem, including the interrupt controller, can perform write or read access to the peripheral devices of a low-security-level subsystem, thus elevating the privileges of the high-security-level subsystem.

[0040] In one possible design, the first physical resource includes a first peripheral device; the authentication component authenticates the access request initiated by the first processor core in the first subsystem or the second processor core in the second subsystem, and when the authentication is successful, the authentication component sends the access request to the corresponding peripheral device in the chip, including: the second processor core sending a second access request to the authentication component, the second access request carrying a second security level identifier and the address of the first peripheral device to be accessed; the authentication component receiving the second access request, obtaining the first security level identifier of the first peripheral device according to the address of the first peripheral device carried in the second access request, and performing authentication according to the first security level identifier and the second security level identifier, and when the authentication is successful, forwarding the second access request to the first peripheral device.

[0041] Similar to the design described above, the authentication component can perform authentication based on the security level identifier carried in the access request and the security level identifier of the physical resource being accessed, in order to determine whether access is permitted. This ensures the security of subsystems with different security levels.

[0042] In one possible design, authentication based on the first security level identifier and the second security level identifier includes:

[0043] If the security level of the second processor core corresponding to the second security level identifier is lower than the security level of the first peripheral device corresponding to the first security level identifier, and the second access request is a read request, then authentication is successful.

[0044] In other words, if a lower-security-level subsystem needs to read from a higher-security-level subsystem, the authentication component can forward the request from the lower-security-level subsystem to the higher-security-level subsystem to allow read access. If the lower-security-level subsystem needs to write to the higher-security-level subsystem, the authentication component will determine that authentication has failed, meaning the lower-security-level subsystem does not have permission to write to the higher-security-level subsystem. This ensures that the higher-security-level subsystem has higher security.

[0045] In one possible design, the first subsystem handles first-level security services, and the second subsystem handles second-level security services or non-security-level services. The first security level is higher than the second security level. The first and second security levels are the levels in the Vehicle Safety Integrity Level (ASIL), and the non-security level is the Quality Management (QM) level.

[0046] In one possible design, the interrupt controller is the only interrupt controller on the chip.

[0047] Thirdly, a communication device is provided, which includes the security isolation device described in the first aspect or any possible design of the first aspect.

[0048] Fourthly, a terminal device is provided, which includes the communication device described in the third aspect. Attached Figure Description

[0049] Figure 1 A schematic diagram illustrating the isolation of different subsystems based on Hypervisor virtualization technology, provided as an embodiment of this application;

[0050] Figure 2 This is a schematic diagram illustrating a deployment scheme using multiple SoCs of different levels to achieve isolation of different subsystems, as provided in an embodiment of this application.

[0051] Figure 3 A schematic diagram of an MDC system in the field of autonomous driving provided for the purpose of this application embodiment;

[0052] Figure 4 This is a schematic diagram of the structure of a safety isolation device provided in an embodiment of this application;

[0053] Figure 5 A flowchart illustrating a secure isolation method provided in an embodiment of this application;

[0054] Figure 6 A schematic diagram illustrating the subsystem partitioning process for different security levels provided in this application embodiment;

[0055] Figure 7 A schematic diagram of a subsystem configured with two security levels is provided for an embodiment of this application;

[0056] Figure 8 A schematic diagram of a subsystem configured with three security levels provided in an embodiment of this application;

[0057] Figure 9 This is a schematic diagram illustrating how an authentication component, provided in an embodiment of this application, authenticates inter-system access.

[0058] Figure 10 This is a schematic diagram illustrating the process of configuring and triggering an interrupt in a second subsystem, as provided in an embodiment of this application. Detailed Implementation

[0059] The embodiments of this application will now be described with reference to the accompanying drawings.

[0060] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0061] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0062] First, some of the terms used in this application will be explained to facilitate understanding by those skilled in the art.

[0063] Interrupt Controller (IC): An IC is used to retrieve interrupts from external devices, prioritize the interrupts, and then pass them to the appropriate processor core. ICs are typically hardware resources. In this application, the IC can be a generic interrupt controller (GIC) of ARM (Advanced RISC (Reduced Instruction Set Computer) machines, or other types of interrupt controllers; this application does not limit the specific type of interrupt controller.

[0064] On-chip external devices: These can be simply referred to as peripherals or on-chip peripherals, and refer to the interface circuits and buses inside the chip used to connect to external devices outside the chip. In this application, "peripherals" refers to external devices inside the chip, and in this application, on-chip external devices are simply referred to as peripherals. In this application, the multiple subsystems included in the chip (such as the first system and the second subsystem) each contain various physical resources, and peripherals are one type of physical resource.

[0065] Hypervisor (also known as virtual machine monitor, VMM) is the software, firmware, or hardware used to create and run virtual machines. The computer used by the hypervisor to run one or more virtual machines is called the host machine, and the virtual machines are called guest machines. The hypervisor provides a virtual operating platform to run guest operating systems, which share virtualized hardware resources.

[0066] In the field of autonomous driving, due to the complexity of the systems, not all subsystems and modules can achieve a high safety level like ASIL-D. To achieve isolation between subsystems with different safety levels, the industry has proposed various isolation schemes, such as traditional virtualization isolation deployment schemes and deployment schemes combining multiple SoCs of different levels.

[0067] Virtualization isolation deployment solutions are based on Hypervisor virtualization technology to achieve isolation between different subsystems. For example... Figure 1 As shown, the software layer of this scheme can include a hypervisor and various guest OSs. These guest OSs can include, for example, virtual operating systems such as ASIL-B OS, ASIL-D OS, and QM OS, with different guest OSs running on different virtual central processing units (CPUs). The hardware layer can include multiple peripherals, such as... Figure 1 Peripheral 0, Peripheral 1, and Peripheral N, as well as the processor core and memory, are included. Among them:

[0068] The hypervisor runs on all processor cores and has access to all memory, while also managing all external devices;

[0069] The Hypervisor can be used to boot these three guest OSes (ASIL-D OS, ASIL-B OS, and QM OS). Each guest OS can communicate with the common virtualization base Hypervisor and run in isolation based on the Hypervisor.

[0070] Different services can be deployed on each guest OS. Depending on the security level required by the service, ASIL-D level services run on ASIL-D OS, ASIL-B level services run on ASIL-B OS, and QM level services run on QMOS. Because virtualization technology isolates each guest OS, each guest OS is unaware of the existence of other guest OSs and is also unaware of the Hypervisor layer.

[0071] When the guest OS wants to access a peripheral device, it first sends an access request to the hypervisor. The hypervisor then accesses the actual peripheral device according to the access request and returns the access result to the guest OS.

[0072] However, in this isolation scheme, although different guest OSes run on different virtual CPUs, the virtual CPUs may actually run on the same processor core, making the isolation between different guest OSes insufficient. Moreover, the hypervisor manages all hardware resources simultaneously and does not differentiate between the security levels of these resources. Furthermore, although multiple guest OSes can run services with different security levels, there is only one hypervisor. Thus, it is impossible to completely isolate the guest OSes in software, meaning that different security levels cannot be reflected in software, which leads to an overall reduction in the hypervisor's security level. In addition, since the hypervisor serves as a common foundation for all guest OSes, there is still a risk of common-cause failure due to a single point of failure in the hypervisor.

[0073] For deployment schemes combining multiple SoCs of different levels, such as Figure 2 As shown, this can be implemented using a chip architecture consisting of a main system-on-a-chip (mainSoC) and an MCU. Wherein:

[0074] The main SoC can handle services with lower security levels, such as those with ASIL-B or QM security levels. For example, ASIL-B or QM security level services are used to analyze camera data to identify various targets (such as people, non-motorized vehicles, motorized vehicles, traffic signs, traffic lights, etc.), as well as to process Global Positioning System (GPS) data and radar data.

[0075] MCUs can be used for high-security applications, such as those handling ASIL-D security level applications. For example, MCUs can receive vehicle data via the Controller Area Network (CAN) bus, and can also send commands to the vehicle via the CAN bus to control the vehicle (such as commands to indicate acceleration, deceleration, braking, and turning).

[0076] The main SoC can communicate with the MCU through communication lines, such as the Serial Peripheral Interface (SPI) bus or the Inter-Integrated Circuit (IIC) bus. Through the communication lines, the main SoC can send the detection results of various targets, GPS data, and radar data to the MCU. The MCU then sends control commands to the vehicle based on the detection results.

[0077] Because the main SoC and MCU are two separate chips, the motherboard circuitry is more complex and costly. Furthermore, when the main SoC and MCU communicate via an intermediate communication line, the risk of communication line failure is higher, and data transmission speed is slower.

[0078] Therefore, to address the above issues, this application proposes a scheme for hybrid deployment of systems with different security levels based on physical isolation within a single SoC. This scheme is applicable to scenarios that simultaneously have large-scale complex data computation and processing requirements and high functional safety requirements, such as aviation, railway, shipbuilding, drone, automation, advanced industrial control, industrial robots, and autonomous driving systems based on data reception and processing from various complex sensors, neural network intelligent computing, or big data computing. It is particularly applicable to fields such as assisted driving and autonomous driving where multiple different security levels exist.

[0079] In the field of autonomous driving, such as Figure 3 As shown, autonomous vehicles can include manufacturing data collection systems (MDC systems), generally referred to as machine tool monitoring and data acquisition systems. The MDC system can send vehicle control commands to the vehicle and also acquire vehicle information; it can also perform human-machine interface (HMI) interaction with the vehicle; and it can communicate with cloud servers to achieve vehicle-to-cloud connectivity.

[0080] This MDC system may include a main SoC and a backup SoC, such as... Figure 3 The system comprises a main SoC A and a backup SoC B. Main SoC A and backup SoC B can perform processes such as master-slave synchronization interconnection, anomaly information synchronization, and master-slave negotiation. Both the main SoC and backup SoC include a safety driving (SD) system and a data processing (DP) system. Typically, the SD system is used to run services with higher safety levels, such as those running ASIL-D safety levels, while the DP system is used to run services with lower safety levels, such as those running ASIL-B safety levels and QM services. This application can be applied to physically isolating the SD and DP systems within a single SoC, for example, physically isolating the SD and DP systems within the main SoC A, or physically isolating the SD and DP systems within the backup SoC B, to achieve physical isolation of multiple safety level systems within a single SoC. Of course, this application can also be applied to physically isolating multiple safety level systems within a single SoC in other scenarios.

[0081] Therefore, in this application's scheme for physically isolating systems with different security levels, a method of implementing physical isolation between subsystems within a single chip is proposed. This application provides a security isolation device that can be applied to multiple subsystems within the same chip. The physical resources of these subsystems are configured with various security levels, with a first physical resource included in one subsystem having a higher security level than any other physical resource included in any other subsystem. That is, the subsystem including the first physical resource has the highest security level. Furthermore, in this application, the subsystem including the first physical resource includes a unique interrupt controller within the chip, which manages interrupts from peripherals within the chip. It is understood that this application achieves physical isolation between systems by configuring different security levels for physical resources within a single chip. This not only achieves high-security isolation between physical resources but also reduces the cost of system isolation by integrating the physical resources of different subsystems within a single chip. This application also configures the interrupt controller in the subsystem with the highest security level, ensuring high security when the chip executes interrupts.

[0082] In some embodiments, such as Figure 4 As shown, the security isolation device of this application is applied to the first subsystem and the second subsystem of the same chip, and the security level of the first physical resource included in the first subsystem is higher than the security level of the second physical resource included in the second subsystem.

[0083] The first subsystem includes an interrupt controller, which manages the interrupts of the peripherals in the second subsystem.

[0084] In some embodiments, the interrupt controller is the only interrupt controller within the chip. That is, although the interrupt controller belongs to the first subsystem, it can control interrupts of peripherals including the first subsystem and the second subsystem.

[0085] In some embodiments, this application can obtain physical resources with multiple security levels by configuring multiple security level identifiers for each physical resource within the chip, and subsystems of the same security level include physical resources with the same security level identifier. For example, the first physical resource is configured as a first security level identifier, and the second physical resource is configured as a second security level identifier, wherein the security level of the physical resource identified by the first security level identifier is higher than the security level of the physical resource identified by the second security level identifier.

[0086] Through the configuration of the aforementioned security level identifiers, the chip's physical resources include a globally unique interrupt controller within the chip. This interrupt controller is configured to belong to the subsystem of the highest security level among at least two security levels. This means that within the entire single chip, there is only one interrupt controller, and this interrupt controller is located in the highest security level subsystem. It can be used to manage peripheral interrupts of all different security levels within the chip, making it an important hardware resource for the entire system. Therefore, this application classifies the interrupt controller into the highest security level subsystem. Subsystems with security levels lower than the highest security level cannot directly configure the interrupt controller and need to be relayed through a high-security level subsystem, i.e., the high-security level subsystem helps other security level subsystems configure the interrupt controller. In this way, while achieving complete physical isolation between subsystems of different security levels, setting the interrupt controller's security level to the highest security level also ensures the security of the interrupt execution process.

[0087] Based on the division of the physical resources within the chip into a first subsystem and a second subsystem according to different security levels in this application, in some embodiments, if the second physical resource includes a second peripheral device, and if the second peripheral device needs to trigger an interrupt:

[0088] The second peripheral device can be used to send interrupt signals to the interrupt controller of the first subsystem;

[0089] An interrupt controller is used to, upon receiving an interrupt signal, control the processor core in the second subsystem or the processor core in the first subsystem to suspend the running program and execute the program indicated by the interrupt signal.

[0090] In other words, when a second peripheral device in a low-security second subsystem needs to trigger an interrupt, it must send an interrupt signal to the interrupt controller in a high-security first subsystem. The interrupt controller then instructs either the processor core in the first subsystem or the processor core in the second subsystem to execute the program indicated by the interrupt signal.

[0091] It should be noted that when the interrupt controller receives an interrupt signal, the specific processor core to execute the program indicated by the interrupt signal can be pre-configured in the interrupt controller. The interrupt controller can then instruct the processor core to execute the program indicated by the interrupt signal according to the pre-configured settings.

[0092] In some embodiments, before any peripheral device triggers an interrupt, the interrupt attributes of the triggered interrupt need to be configured in the interrupt controller so that the interrupt controller can trigger the interrupt according to the configuration. Therefore, before the second peripheral device sends an interrupt signal, assuming that the first physical resource includes a first processor core and the second physical resource also includes an interrupt configuration register (e.g., a mailbox) and a second processor core, then:

[0093] The second processor core is also used to write interrupt information to the interrupt configuration register. The interrupt information includes the interrupt attributes of the interrupt signals sent by the second peripheral. Each peripheral can have multiple interrupt attributes. Before configuring each interrupt attribute in the interrupt controller, the second processor core needs to write the interrupt attribute and interrupt priority information into the Mailbox. After completing the interrupt configuration of the interrupt attribute of a peripheral, if it is necessary to perform interrupt configuration for other interrupt attributes of the same peripheral, the second processor core can write the interrupt information corresponding to the interrupt attribute to be configured this time into the Mailbox. The interrupt information previously written into the Mailbox is overwritten.

[0094] The first processor core reads interrupt information from the interrupt configuration register and configures the interrupt information in the interrupt controller. In other words, the first processor core of the first subsystem helps the second peripheral of the second subsystem configure the interrupt controller. Thus, the interrupt controller can control the processor core in the second subsystem or the processor core in the first subsystem to execute the program indicated by the interrupt signal sent by the second peripheral.

[0095] For example, after interrupt information is written to the interrupt controller, the first processor core can retrieve an interrupt configuration request from the interrupt configuration register to trigger the first processor core to read the interrupt information from the interrupt configuration register. Alternatively, the processor core of the second subsystem can send an interrupt configuration request to the interrupt controller through the interrupt configuration register. This interrupt configuration request requests the interrupt controller to perform interrupt configuration for the interrupt attributes of the second peripheral. The interrupt controller can send this interrupt configuration request to the first processor core, which can perform the interrupt configuration, according to a pre-configuration, so that the first processor core reads the interrupt information from the interrupt configuration register.

[0096] When the first processor core receives an interrupt configuration request, for example, the first processor core may specifically be used for:

[0097] Pause the execution of the currently running program and read the interrupt information from the interrupt configuration register;

[0098] The interrupt controller's register address and write value are determined based on the interrupt information. The write value is used to indicate the interrupt information. It can be understood that the interrupt controller includes multiple registers. When configuring the interrupt attribute, the first processor core can determine which register of the interrupt controller will store the information corresponding to the interrupt attribute based on the interrupt information read. The write value can be understood as another format of the interrupt information after the format has been converted.

[0099] Then, the write value is written to the register indicated by the interrupt controller's register address, and the currently running program continues execution. When the first processor core writes the write value to the register indicated by the interrupt controller's register address, the interrupt configuration of that interrupt attribute in the interrupt controller is complete. At this time, the second processor core can read the write value from the interrupt controller. If the read write value matches the configured interrupt attribute of the second peripheral, the second processor core considers the interrupt configuration successful; alternatively, the interrupt controller can send an interrupt configuration success indication to the second processor core so that the second processor core can proceed with the interrupt configuration of the next interrupt attribute.

[0100] In some embodiments, to ensure the security of a high-security-level subsystem, the security isolation device of this application may further include an authentication component. Assuming the first physical resource includes a first processor core and the second physical resource includes a second processor core, the authentication component can be used for:

[0101] The system authenticates access requests initiated by the first processor core in the first subsystem or the second processor core in the second subsystem, and sends the access request to the corresponding peripheral device within the chip when authentication is successful.

[0102] The authentication rules followed by the authentication component here could be: a high-security-level subsystem can perform read and write access to a low-security-level subsystem, and a low-security-level subsystem can perform read access to a high-security-level subsystem, but a low-security-level subsystem cannot perform write access to a high-security-level subsystem. In this way, the high-security-level subsystem has higher security, and the low-security-level subsystem cannot arbitrarily perform write access to the high-security-level subsystem, thus ensuring the security of the high-security-level subsystem. The authentication component in this application can be understood as a component that does not belong to any single subsystem.

[0103] As explained above, this application configures corresponding security level identifiers for physical resources of different subsystems. Therefore, when performing authentication, the authentication component can determine whether the authentication is successful based on the security level identifier of the physical resource to be accessed and the security level identifier of the physical resource being accessed.

[0104] For example, if the first subsystem needs to access the second subsystem, assume that the first physical resource includes a first processor core and the second physical resource includes a second peripheral device:

[0105] The first processor core is used to send a first access request to the authentication component. The first access request carries a first security level identifier and the address of the second peripheral device to be accessed.

[0106] The authentication component is used to receive a first access request, obtain the second security level identifier of the second peripheral device based on the address of the second peripheral device carried in the first access request, and perform authentication based on the first security level identifier and the second security level identifier. When the authentication is successful, the first access request is forwarded to the second peripheral device.

[0107] Specifically, the authentication component can be used for:

[0108] If, based on the first security level identifier and the second security level identifier, the security level of the first processor core corresponding to the first security level identifier is higher than the security level of the second peripheral device corresponding to the second security level identifier, then authentication is successful: wherein, the first access request is a write request or a read request.

[0109] For another example, if the second subsystem needs to access the first subsystem, suppose the first physical resource includes the first peripheral device, and the second physical resource includes the second processor core:

[0110] The second processor core is used to send a second access request to the authentication component. The second access request carries a second security level identifier and the address of the first peripheral to be accessed.

[0111] An authentication component is used to receive a second access request, obtain the first security level identifier of the first peripheral device based on the address of the first peripheral device carried in the second access request, and perform authentication based on the first security level identifier and the second security level identifier. If the authentication is successful, the second access request is forwarded to the first peripheral device.

[0112] Specifically, the authentication component can be used for:

[0113] If, based on the first security level identifier and the second security level identifier, the security level of the second processor core corresponding to the second security level identifier is lower than the security level of the first peripheral device corresponding to the first security level identifier, and the second access request is a read request, then authentication is successful. Conversely, if the second access request is a write request, authentication fails.

[0114] In some embodiments, the safety isolation device can be applied in a driving scenario. In this scenario, a first subsystem can be used to process services at a first safety level, and a second subsystem can be used to process services at a second safety level or a non-safety level. The first safety level is higher than the second safety level, and the first and second safety levels are ASIL levels, while the non-safety level is QM. This ensures high security for services at the first safety level in a driving scenario.

[0115] Therefore, based on the above explanation, this application configures the interrupt controller as a high-security-level subsystem. Other security-level subsystems, if they wish to perform interrupt configuration, must request interrupt configuration from the high-security-level subsystem. The high-security-level subsystem then assists other security-level subsystems in configuring the interrupt controller. When a peripheral device of another security-level subsystem triggers an interrupt, it needs to request an interrupt trigger from the interrupt controller of the high-security-level subsystem. The interrupt controller then instructs the processor core to execute the interrupt program. This ensures the high security of the interrupt controller and also guarantees the security of the high-security-level subsystem. Furthermore, the authentication component of this application allows high-security-level subsystems to perform read or write access to other security-level subsystems, while low-security-level subsystems can only perform read access to high-security-level subsystems, thus ensuring the security of the high-security level.

[0116] Corresponding to the security isolation device provided in this application, this application also provides a security isolation method, which can be applied to a first subsystem and a second subsystem of the same chip. The security level of the first physical resource included in the first subsystem is higher than the security level of the second physical resource included in the second subsystem. The first subsystem includes an interrupt controller, which manages the interrupts of the peripherals of the second subsystem. Figure 5 As shown, the method includes:

[0117] 501. Control the second peripheral device of the second subsystem to send an interrupt signal to the interrupt controller of the first subsystem.

[0118] 502. The interrupt controller triggers the processor core of the second subsystem or the processor core of the first subsystem to suspend the running program and execute the program indicated by the interrupt signal.

[0119] In some embodiments, assuming the second physical resource further includes a second processor core and the first physical resource further includes a first processor core, step 502 can be implemented as follows:

[0120] Control the interrupt controller to send an interrupt signal to the second processor core; control the second processor core to suspend the running program and execute the program indicated by the interrupt signal;

[0121] Alternatively, the interrupt controller can be controlled to send an interrupt signal to the first processor core; the first processor core can be controlled to suspend the running program and execute the program indicated by the interrupt signal.

[0122] Before the second peripheral device triggers an interrupt, the interrupt attributes of the triggered interrupt need to be configured in the interrupt controller. Only then can the interrupt controller trigger the processor core to execute the interrupt program. Therefore, assuming the second physical resource includes the interrupt configuration register and the second processor core, and the first physical resource includes the first processor core:

[0123] Before the second peripheral device controlling the second subsystem sends an interrupt signal to the interrupt controller of the first subsystem, the method may further include:

[0124] The second processor core is controlled to write interrupt information to the interrupt configuration register. The interrupt information includes the interrupt attributes of the interrupt signal sent by the second peripheral.

[0125] The first processor core is controlled to read interrupt information from the interrupt configuration register and configure the interrupt information in the interrupt controller so that the interrupt controller controls the processor core in the second subsystem or the processor core in the first subsystem to execute the program indicated by the interrupt signal sent by the second peripheral.

[0126] For example, the first processor core can be controlled to obtain an interrupt configuration request from the interrupt configuration register to trigger the first processor core to read interrupt information from the interrupt configuration register.

[0127] Alternatively, the second processor core can be controlled to generate an interrupt configuration request based on the interrupt information, and then the second processor core can be controlled to send the interrupt configuration request to the interrupt controller through the interrupt configuration register, and then the interrupt controller can be controlled to send the interrupt configuration request to the first processor core; the first processor core can be controlled to configure the interrupt controller according to the interrupt configuration request.

[0128] For example, when the first processor core receives an interrupt configuration request, it can be controlled to pause the execution of the running program and read the interrupt information from the interrupt configuration register; the first processor core can be controlled to determine the register address and write value of the interrupt controller according to the interrupt information, the write value is used to indicate the interrupt information; the first processor core can be controlled to write the write value to the register indicated by the register address of the interrupt controller, and then the first processor core can be controlled to continue executing the running program.

[0129] It should be noted that, in this application, the security levels of the first physical resource and the second physical resource are configured through the firmware of the system used to initialize the chip during the system initialization phase. For example, the first physical resource is configured as a first security level identifier, and the second physical resource is configured as a second security level identifier.

[0130] In some embodiments, the security isolation device further includes an authentication component; assuming the first physical resource includes a first processor core and the second physical resource includes a second processor core; the method may further include:

[0131] The control authentication component authenticates the access request initiated by the first processor core in the first subsystem or the second processor core in the second subsystem, and when the authentication is successful, the control authentication component sends the access request to the corresponding peripheral device in the chip.

[0132] For example, assuming the second physical resource includes a second peripheral device, the control authentication component authenticates the access request initiated by the first processor core in the first subsystem or the second processor core in the second subsystem, and when the authentication is successful, the control authentication component sends the access request to the corresponding peripheral device within the chip, which may include:

[0133] The first processor core is controlled to send a first access request to the authentication component. The first access request carries a first security level identifier and the address of the second peripheral device to be accessed.

[0134] The control authentication component obtains the second security level identifier of the second peripheral device based on the address of the second peripheral device carried in the first access request, and performs authentication based on the first security level identifier and the second security level identifier. When the authentication is successful, the control authentication component forwards the first access request to the second peripheral device.

[0135] Authentication based on the first security level identifier and the second security level identifier may include:

[0136] If the security level of the first processor core corresponding to the first security level identifier is higher than the security level of the second peripheral device corresponding to the second security level identifier, then the authentication is successful; wherein, the first access request is a write request or a read request.

[0137] For another example, suppose the first physical resource includes a first peripheral device; controlling the authentication component to authenticate access requests initiated by the first processor core in the first subsystem or the second processor core in the second subsystem, and when authentication is successful, controlling the authentication component to send the access request to the corresponding peripheral device within the chip may include:

[0138] The second processor core is controlled to send a second access request to the authentication component. The second access request carries a second security level identifier and the address of the first peripheral device to be accessed.

[0139] The control authentication component receives the second access request, obtains the first security level identifier of the first peripheral based on the address of the first peripheral carried in the second access request, and performs authentication based on the first security level identifier and the second security level identifier. If the authentication is successful, the second access request is forwarded to the first peripheral.

[0140] Authentication based on the first security level identifier and the second security level identifier may include:

[0141] If the security level of the second processor core corresponding to the second security level identifier is lower than the security level of the first peripheral device corresponding to the first security level identifier, and the second access request is a read request, then authentication is successful.

[0142] The beneficial effects of the security isolation method provided in this application can be referred to the beneficial effects of the security isolation device provided in this application, and will not be repeated here.

[0143] Based on the above description of the security isolation device and security isolation method provided in this application, the following will further explain the configuration of the security level, the process of executing interrupt configuration during the operation of the configured subsystem, and the process of peripheral devices triggering interrupts after executing interrupt configuration.

[0144] First, we will explain how to configure the security level identification of the physical resources within the chip. In other words, we will explain how to divide the security levels of the physical resources within the chip into multiple subsystems with different security levels, such as... Figure 6 As shown, the process may include:

[0145] 601. Firmware determines the physical resources in the chip.

[0146] The physical resources in a chip can include the processor core, memory, and input / output (I / O) devices. I / O devices include the interrupt controller and peripherals, namely the on-chip and off-chip devices mentioned above.

[0147] For example, when the chip is powered on, the firmware can first determine the various physical resources in the chip in order to execute the process of configuring security level identifiers for the physical resources in step 602.

[0148] This firmware can be understood as the underlying firmware, such as the Basic Input Output System (BIOS), the Unified Extensible Firmware Interface (UEFI), or the Boot Loader performing software initialization. The initialization process includes determining physical resources and configuring security levels for those resources. For example, when the chip powers on, the firmware can determine the physical resources and then configure their security levels. This security level configuration can also be understood as the process of allocating physical resources.

[0149] 602. The firmware configures security levels for the physical resources in the chip, resulting in subsystems with at least two security levels. The different subsystems include physical resources with different security levels. Among these physical resources, the unique interrupt controller within the chip belongs to the subsystem with the highest security level among the at least two security levels.

[0150] In some embodiments, the firmware can configure a security level identifier for each physical resource in the chip; different security level identifiers correspond to different physical resources with different security levels.

[0151] The above-mentioned physical resource configuration security level identifier can also be understood as the process by which firmware configures security level information for physical resources, and the security level information includes the security level identifier.

[0152] For example, when the chip powers on, the firmware can configure a security level identifier for each processor core in the chip, which can be stored in the register corresponding to the processor core. The firmware can also divide the memory resources in the chip, with different memory regions corresponding to different security level identifiers, which can be stored in the registers corresponding to those memory regions. Furthermore, the firmware can configure a security level identifier for each peripheral device within the chip, which can be stored in the register corresponding to that peripheral device. Specifically, the interrupt controller is configured with the highest security level, and the firmware can write the highest security level identifier into the register corresponding to the interrupt controller. In this way, the security level configuration for each physical resource is completed.

[0153] In this application, there are at least two security levels and at least two security level identifiers. Thus, by configuring the security levels, at least two security level subsystems can be obtained. Each security level subsystem includes a processor core, memory region, and peripherals of the corresponding security level. The highest security level subsystem also includes an interrupt controller.

[0154] For example, such as Figure 7 As shown, when the security level configured within the chip can be either high or low, the firmware configures security level identifiers for the chip's physical resources, including a high-security-level identifier and a low-security-level identifier. The high-security-level identifier indicates a high security level, and the low-security-level identifier indicates a low security level. The high-security-level identifier is written into the registers corresponding to physical resources at the high security level, and the low-security-level identifier is written into the registers corresponding to physical resources at the low security level. In this way, the physical resources within the chip are divided into high-security-level subsystems and low-security-level subsystems. Figure 7 The diagram illustrates a high-security-level subsystem comprising processor cores (e.g., processor core 0, processor core N), memory (e.g., memory 0), peripherals (e.g., peripheral 1, peripheral 2, and peripheral i), and an interrupt controller. It also illustrates a low-security-level subsystem comprising processor cores (processor core N+1 and processor core N+M), memory (memory 1), and peripherals (peripheral i+1, peripheral i+2, and peripheral i+j).

[0155] After dividing physical resources into subsystems of these two security levels, the high-security-level subsystem can boot and run the high-security-level OS, and the low-security-level subsystem can boot and run the low-security-level OS. The high-security-level OS corresponds to running high-security-level services, and the low-security-level OS corresponds to running low-security-level services.

[0156] In some embodiments, when configuring a security level identifier for each processor core, the firmware can also configure a lock-step mode for the processor core with the highest security level. In lock-step mode, the processor with the highest security level can employ lock-step core technology. Lock-step core technology can maintain precise synchronization between multiple processor cores and memory, executing the same instructions within the same clock cycle. This ensures that the high-security-level subsystem can detect any errors, and even if a brief error occurs, the subsystem can resume normal operation without interruption or data loss. Specifically, the implementation of a lock-step core may include: two processor cores in the highest-security-level subsystem running the same program (which can also be understood as one instruction being executed by two processor cores), obtaining the output results of the two processor cores, and inputting both output results into a comparison logic to compare whether the output results of the two processor cores are the same. If they are the same, the highest-security-level subsystem continues to run; otherwise, the comparison logic returns an error indication, and the subsystem needs to take certain measures, such as the two processor cores re-running the code that produced the different output results, comparing and checking the results after the re-run, or restarting the network device. It can be seen that although the lockstep core uses two processor cores, it actually only functions as one processor core.

[0157] In some embodiments, when classifying the memory resources in the chip for security levels, the firmware can also configure the memory in the subsystem with the highest security level as a mirror mode. Mirror mode can be understood as creating two copies of the data to be stored in memory, one in the main memory area and the other in the mirror memory area. Under normal operating conditions, when the subsystem needs to read data from memory, it only reads from the main memory area. Only when the main memory area fails, and even memory protection and Chipkill repair techniques cannot completely repair it, will the subsystem read data from the mirror memory area. If a fault occurs in the main memory area sufficient to trigger an alarm in the subsystem, the subsystem will report to the system administrator. Simultaneously, the chip will automatically switch to using the mirror memory area until the memory card in the failed main memory area is replaced. This avoids interruptions caused by failures in the main memory area, thus ensuring the stable operation of the subsystem. Since only one set of memory areas is actually used in mirror mode, with the other serving as a backup, only half of the total memory capacity of the subsystem is available.

[0158] Based on the above explanation, it can be understood that this application configures the security levels of physical resources within a single chip, resulting in at least two security-level subsystems. This means that within a single chip, system isolation can be achieved through physical resource partitioning. This avoids the problem in existing technologies where virtual CPUs of different subsystems may run on a single physical processor core, leading to insufficient isolation between different guest OSes. It also avoids the complexity and high cost associated with using a two-chip architecture for system isolation. Furthermore, this application places the interrupt controller in the highest security-level subsystem. When a lower security-level subsystem needs to configure the interrupt controller, it can only request configuration from the higher security-level subsystem. This ensures a higher security level for the interrupt controller and greater security for single-chip interrupt execution.

[0159] In some embodiments, in the above Figure 7 Based on the example configuration of two security levels, it can be understood that this application can be extended to more than two security levels, such as... Figure 8 As shown, when the chip has three security levels—high, medium, and low—the firmware configures security level identifiers for the chip's physical resources, including high, medium, and low security level identifiers. The high security level identifier indicates a high security level, the medium security level identifier indicates a medium security level, and the low security level identifier indicates a low security level. The security level hierarchy is: high security level is higher than medium security level, and medium security level is higher than low security level. Figure 7 Based on the example of the chip, a medium security level identifier is written into the registers corresponding to the physical resources at the medium security level within the chip. In this way, the physical resources within the chip are divided into high-security level subsystems, medium-security level subsystems, and low-security level subsystems.

[0160] Figure 8 The diagram illustrates a high-security-level subsystem comprising processor cores (e.g., processor core 0, processor core N), memory (memory 0), peripherals (peripheral 1, peripheral 2, and peripheral i), and an interrupt controller. It also illustrates a medium-security-level subsystem comprising processor cores (processor core N+1 and processor core N+M), memory (memory 1), and peripherals (peripheral i+1, peripheral i+2, and peripheral i+j). Finally, it illustrates a low-security-level subsystem comprising processor cores (processor core N+M+1 and processor core N+M+P), memory (memory 2), and peripherals (peripheral i+j+1, peripheral i+j+2, and peripheral i+j+m).

[0161] When there are three subsystems with different security levels, the interrupt controller still belongs to the highest security level subsystem. When a subsystem with a medium or low security level needs to configure an interrupt, it must request the interrupt configuration from the highest security level subsystem.

[0162] As explained above, in this application, there is only one interrupt controller within a single chip, and its security level is the highest. This interrupt controller can manage interrupts for all peripherals within the chip. Therefore, all subsystems of different security levels need to access this interrupt controller to control their respective peripheral interrupts. However, since the interrupt controller is a physical resource of the highest security level, only physical resources of the highest security level can directly write to it. Physical resources of other security levels can only read from it. Furthermore, write access to the interrupt controller by subsystems of other security levels can only be performed with the assistance of the highest security level subsystem. In other words, the interrupt configuration process can only be performed by the highest security level subsystem.

[0163] Furthermore, after configuring security level identifiers for all physical resources within the chip and dividing the entire chip's physical resources into subsystems with at least two security levels, the firmware can then boot the corresponding OS for each subsystem to run the services associated with that subsystem. Therefore, this method may also include:

[0164] 603. Firmware controls the startup of the corresponding OS for each security level subsystem to begin running the services of each security level subsystem.

[0165] by Figure 7 For example, the firmware can control a high-security-level subsystem to boot the OS and run high-security-level services, and control a low-security-level subsystem to boot the OS and run low-security-level services. For instance, high-security-level services include those at ASIL-D security level, and low-security-level services include those at ASIL-B security level or QM security level.

[0166] After the OS of each subsystem starts running, the subsystems can begin to communicate with each other. To ensure the security of high-security subsystems, in this application, low-security subsystems can read-access high-security sub-regions but cannot write-access them; high-security subsystems can read-access and write-access low-security subsystems. It is understandable that if... Figure 8For example, a high-security subsystem can perform read and write access to a medium-security subsystem and a low-security subsystem; however, a medium-security subsystem and a low-security subsystem can only perform read access to a high-security subsystem, not write access. Therefore, the method may also include:

[0167] 604. When the first processor core is about to access the first peripheral device, the authentication component determines whether to respond to the access request of the first processor core based on the security level identifier of the first processor core and the security level identifier of the first peripheral device.

[0168] Based on the authentication principles of the authentication components mentioned above:

[0169] When the security level of the first processor core is higher than or equal to the security level of the first peripheral, the authentication component determines to respond to the access request of the first processor; that is, the first processor core with a high security level can access the first peripheral with a low security level, and this access includes write access and read access.

[0170] When the security level of the first processor core is lower than that of the first peripheral, if the access request is a read access, the authentication component determines to respond to the read access; if the access request is a write access, the authentication component determines that the write access is invalid. That is, the first processor core with a lower security level can only perform read access to the first peripheral with a higher security level, but cannot perform write access.

[0171] For example, refer to Figure 9 Each subsystem's peripherals have corresponding authentication components. When a processor core from one subsystem wants to access a peripheral from another subsystem, the authentication component corresponding to that peripheral can determine whether the processor core can access the peripheral based on the access principles described above. (Reference) Figure 9 Suppose processor core A needs to access peripheral B. Processor core A sends an access request, which travels through the chip's bus to authentication component 0. The access request carries the security level identifier corresponding to processor core A and the address of peripheral B to be accessed. Upon receiving the access request, authentication component 0 extracts the security level identifier of processor core A from the request, reads the security level identifier corresponding to peripheral B based on its address, and then performs authentication according to the aforementioned authentication principles to determine whether processor core A can access peripheral B. If access is granted, authentication component 0 sends the access request to peripheral B for processing; if access is denied, authentication component 0 returns an access denied instruction to processor core A, and the access request ends.

[0172] Therefore, the security of high-security subsystems can be guaranteed under the authentication principles followed by the authentication components.

[0173] In addition, once the OS of each subsystem is started, the subsystems can not only communicate with each other through the authentication component, but also the low-security-level subsystems can request interrupt configurations from the high-security-level subsystems, including the interrupt controller. That is, only the high-security-level subsystems can write to the interrupt controller.

[0174] Assuming the aforementioned subsystems with different security levels include a first subsystem and a second subsystem, with the first subsystem having the highest security level (i.e., the first physical resource of the first subsystem includes an interrupt controller), the process of the second subsystem requesting interrupt configuration may include:

[0175] The second subsystem sends an interrupt configuration request to the first subsystem;

[0176] The first subsystem performs interrupt configuration for the second subsystem based on the interrupt configuration request.

[0177] It is understandable that the second subsystem can be Figure 7 or Figure 8 The example in the text is a low-security subsystem, or it could also be... Figure 8 The example illustrates a subsystem with a medium security level. When the second subsystem needs to perform interrupt configuration in the interrupt controller, it can send an interrupt configuration request to the first subsystem, allowing the first subsystem to assist in configuring the interrupt, i.e., to perform a write operation on the interrupt controller. After the interrupt configuration is complete, when a peripheral device of the second subsystem needs to generate an interrupt, the peripheral device can send an interrupt signal to the interrupt controller. The interrupt controller can then send this interrupt signal to the processor core, allowing the processor core to suspend the currently running program and execute the interrupt routine indicated by the interrupt signal.

[0178] The process of requesting interrupt configuration for the second subsystem is further explained below. This process may include:

[0179] 11. The first subsystem configures interrupt routing in the interrupt controller.

[0180] This process can be understood as follows: the interrupt controller is configured to perform interrupt configuration for peripherals in non-high-security subsystems by a processor core in a high-security subsystem. When the high-security subsystem determines that processor core B in the high-security subsystem will perform interrupt configuration for peripheral A, the high-security subsystem can perform a write operation on the interrupt controller. This write operation is used to instruct processor core B to perform the interrupt configuration operation when the interrupt controller determines that peripheral A needs to be configured for an interrupt.

[0181] Step 11 is equivalent to completing the preparatory work before the first subsystem helps the second subsystem configure the interrupt controller.

[0182] 12. The processor core of the second subsystem writes interrupt information to the interrupt configuration register of the second subsystem.

[0183] For example, such as Figure 10 As shown, the interrupt configuration register can be the Mailbox. When processor core A of the second subsystem needs to configure an interrupt for peripheral A in the interrupt controller, processor core A can write the interrupt information of the interrupt to be configured for peripheral A to the Mailbox in the second subsystem. This interrupt information can include the interrupt number, interrupt attributes, and interrupt attribute values. This step is equivalent to... Figure 10 Step ① in the process.

[0184] One interrupt number corresponds to one peripheral device, and one peripheral device can correspond to multiple interrupt attributes. Interrupt attributes can include interrupt priority, interrupt triggering method, and interrupt enable information, etc. The attribute value of the interrupt is the value of the interrupt priority, the value of the interrupt triggering method, and the value of the interrupt enable information, etc.

[0185] 13. The processor core of the first subsystem obtains the interrupt configuration request from the interrupt configuration register.

[0186] For example, refer to Figure 10 The processor core B of the first subsystem can obtain an interrupt configuration request from the interrupt configuration register through the interrupt controller. This process is equivalent to... Figure 10 Steps ② and ③ in the process. The interrupt configuration request is used to configure an interrupt for peripheral A's request.

[0187] Alternatively, processor core A of the second subsystem can generate an interrupt configuration request based on the interrupt information and send the interrupt configuration request to the interrupt controller via Mailbox. This process is equivalent to... Figure 10 Step ② in the process. When the interrupt controller receives the Mailbox's interrupt configuration request, it can send the interrupt configuration request to the processor core B of the first subsystem according to the interrupt route configured in step 11. This process is equivalent to Figure 10 Step ③ in the process.

[0188] 14. The processor core in the first subsystem suspends the execution of the running program, reads the interrupt information from the interrupt configuration register, determines the register address and write value of the interrupt controller based on the interrupt information, the write value is used to indicate the interrupt information, and writes the write value to the register indicated by the register address of the interrupt controller.

[0189] For example, refer to Figure 10When processor core B receives an interrupt configuration request from the interrupt controller, processor core B suspends the execution of the currently running program and reads the interrupt information of peripheral A in the Mailbox through hardware resources such as the bus and authentication components. This information includes the interrupt number, interrupt attributes, and attribute values. This process is equivalent to... Figure 10 Step ④ in the process. Then, processor core B can determine, based on the interrupt information, which register of the interrupt controller should be configured with the interrupt and the configuration information to be written. That is, processor core B determines the register address of the interrupt controller and the value to be written to the interrupt controller register based on the interrupt information. Once the register address of the interrupt controller is determined, processor core B can write the value to the register indicated by that address. This process is equivalent to... Figure 10 Step 5 in the process.

[0190] 15. The processor core of the first subsystem continues to execute the running program.

[0191] Once the processor of the first subsystem writes the specified value to the interrupt controller's register, the interrupt configuration process is complete. Processor core B of the first subsystem can then resume executing the program that was interrupted in step 14.

[0192] In some embodiments, processor core A of the second subsystem can also determine whether the interrupt configuration process is complete by reading the latest write value in the interrupt controller's register. If the write value matches the attribute value of the interrupt to be configured by the second subsystem, then processor core A of the second subsystem determines that the interrupt configuration process is complete.

[0193] Alternatively, after processor core B of the first subsystem writes the write value to the interrupt controller's register, processor core B of the first subsystem can send an acknowledge message to processor core A of the second subsystem, indicating that the interrupt configuration of peripheral A is complete. When processor core A of the second subsystem receives the acknowledge message, processor core A can read the write value in the interrupt controller's register to determine whether the write value matches the attribute value of the interrupt to be configured.

[0194] It should be noted that a peripheral device can correspond to multiple interrupt attributes. Steps 12-15 describe the process of configuring one interrupt attribute for a peripheral device. The configuration methods for multiple interrupt attributes of a peripheral device can all refer to the configuration process described in steps 12-15 above. After the peripheral device's interrupts are configured according to this process, if the peripheral device generates an interrupt, the interrupt controller can correctly handle the interrupt. For example, if interrupt N of peripheral A is configured in the interrupt controller, once peripheral A requests the interrupt controller to execute the interrupt N operation, the interrupt controller can determine whether interrupt preemption occurs and whether to run the processor core to handle interrupt N based on the priority of interrupt N configured in the register.

[0195] Therefore, after the above-described process of configuring the interrupt controller is completed, following step 15, if a peripheral device of the second subsystem triggers an interrupt, the interrupt controller's operation may include:

[0196] 16. The peripherals of the second subsystem send interrupt signals to the interrupt controller.

[0197] Based on the interrupt configuration performed for the peripherals of the second subsystem, if a peripheral of the second subsystem needs to trigger an interrupt, it can send an interrupt signal to the interrupt controller, indicating that the peripheral intends to trigger an interrupt. For example, refer to... Figure 10 The peripheral A of the second subsystem sends an interrupt signal to the interrupt controller. This process is equivalent to... Figure 10 Step 6 in the process.

[0198] It is understandable that the device containing the interrupt controller has multiple pins, each pin is connected to a peripheral device. When the level of a pin changes, it can be understood that the pin has received an interrupt signal from the peripheral device, and the interrupt controller determines that the peripheral device is about to trigger an interrupt.

[0199] 17. The interrupt controller sends an interrupt signal to the processor core of the second subsystem or the processor core of the first subsystem, so that the processor core of the second subsystem or the processor core of the first subsystem suspends the running program and executes the program indicated by the interrupt signal.

[0200] refer to Figure 10 When the interrupt controller receives an interrupt signal, if it determines that the interrupt attributes corresponding to the interrupt signal have been configured in the interrupt controller and the interrupt can be triggered, the interrupt controller can determine whether preemptive handling is required and whether the processor core should be run to handle the interrupt, based on information such as interrupt priority. If the interrupt controller determines that the processor core can handle the interrupt, in one approach, the interrupt controller sends the interrupt signal to the processor core of the second subsystem through an interface communicating with the processor core of the second subsystem, for example... Figure 10In step ⑦ shown, the interrupt controller instructs processor core A to execute the program corresponding to the interrupt signal. When processor core A receives an interrupt signal from the interrupt controller, it suspends the currently running program and executes the program indicated by the interrupt signal. In another embodiment, the interrupt controller may send an interrupt signal to a processor core of the first subsystem, instructing the processor core of the first subsystem to execute the program indicated by the interrupt signal.

[0201] The above describes the process of a low-security-level subsystem requesting interrupt configuration. The following describes the process of a high-security-level (highest security level) subsystem configuring its interrupt controller. This process may include (not shown in the accompanying drawings):

[0202] 81. The processor core in the first subsystem executes interrupt configuration to the interrupt controller.

[0203] refer to Figure 10 For example, before the first subsystem uses peripheral B to perform an interrupt operation, the first subsystem needs to configure the interrupt for peripheral B. Specifically, the processor core B of the first subsystem can directly write to the interrupt controller's register. This write operation is used to configure the interrupt priority attributes, routing attributes, and enable attributes, etc., for peripheral B.

[0204] Step 81 above describes the process of configuring the interrupt controller for the high-security subsystem. Subsequently, if a peripheral device of the high-security subsystem generates an interrupt, the method further includes:

[0205] 82. The peripherals of the first subsystem send an interrupt signal to the interrupt controller.

[0206] For example, refer to Figure 10 When peripheral B generates an interrupt, peripheral B can send an interrupt signal to the interrupt controller.

[0207] 83. The interrupt controller sends an interrupt signal to the processor core of the first subsystem or the processor core of the second subsystem to trigger the processor core to suspend the running program and execute the program indicated by the interrupt signal.

[0208] For example, refer to Figure 10 If the interrupt controller determines that the peripheral B has been configured for interrupt, then the interrupt controller can send an interrupt signal to the processor core that handles the interrupt according to the configured interrupt routing information.

[0209] The interrupt controller can send an interrupt signal to processor core B of the first subsystem according to the interrupt routing information. When processor core B receives the interrupt signal, it can pause the currently running program and execute the program corresponding to the interrupt signal. After the program finishes execution, processor core B resumes the previously paused program.

[0210] Alternatively, the interrupt controller can send an interrupt signal to processor core A of the second subsystem according to the interrupt routing information. When processor core A receives the interrupt signal, it can pause the currently running program and execute the program corresponding to the interrupt signal. After the program finishes execution, processor core A can resume the previously paused program.

[0211] In this way, by dividing the physical resources within a single chip into security levels, this application allows for multiple security-level subsystems on the chip, ensuring the security of high-security-level subsystems. Furthermore, when the interrupt controller's security level is set to high, only high-security-level subsystems can read from or write to the interrupt controller, or in other words, only high-security-level subsystems can configure it. Non-high-security-level subsystems can only read from the interrupt controller; if a non-high-security-level subsystem needs to configure the interrupt controller, it must do so through a high-security-level subsystem. This prevents non-high-security-level subsystems from arbitrarily writing to the interrupt controller, ensuring its security and thus improving the overall security of the single-chip system.

[0212] It should be noted that when the high security level in this application is ASIL-D, the low security level can be ASIL-C, ASIL-B or ASIL-A, or the low security level can be the non-security level QM.

[0213] Alternatively, when the high security level in this application is ASIL-C, the low security level can be ASIL-B or ASIL-A, or the low security level can be QM;

[0214] Alternatively, when the high security level in this application is ASIL-B, the low security level can be ASIL-A, or the low security level can be QM;

[0215] Alternatively, when the high security level in this application is ASIL-A, the low security level can be QM.

[0216] It should be noted that, in addition to using Mailbox as the interrupt configuration register to achieve interrupt configuration communication between subsystems of different security levels, this application can also use doolbell + shared memory. When the doolbell in the low-security-level subsystem requests interrupt configuration, the high-security-level subsystem can read the interrupt information from the shared memory between the high-security-level and low-security-level subsystems. The high-security-level subsystem determines the address and write value of the configuration interrupt controller register based on the interrupt information, and writes the write value to the register according to the register address, thus completing the interrupt configuration operation. It can be understood that any implementation that uses interrupts to send interrupt configuration requests to the high-security-level subsystem can be applied to this application.

[0217] In this application, if a low-security-level subsystem has only one service, then only one guest OS needs to be run in the low-security-level subsystem; if a low-security-level subsystem has multiple services to process, multiple guest OSes can be started through the hypervisor to process different services respectively.

[0218] Furthermore, as described above in this application, the security level can be configured through firmware (e.g., UEFI) to achieve physical resource partitioning, or the resource partitioning configuration can be fixed in hardware. That is, the security level of physical resources is fixed during hardware tape-out, which can eliminate the need for software configuration.

[0219] This application provides a communication device, which can be a chip, and the chip may include the security isolation device provided in this application.

[0220] This application also provides a control system, which can be, for example, the MDC system described above. The control system includes a chip, which may include the security isolation device provided in this application.

[0221] This application also provides a computer-readable storage medium including computer instructions that, when executed on an electronic device, cause the electronic device to perform the security isolation method provided in this application.

[0222] This application also provides a computer program product that, when run on a computer, causes an electronic device to execute the security isolation method provided in this application.

[0223] This application also provides a terminal device, which includes the security isolation device provided in this application.

[0224] Through the above description of the embodiments, those skilled in the art will understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above.

[0225] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0226] The units described as separate components may or may not be physically separate. A component shown as a unit can be one or more physical units; that is, it can be located in one place or distributed in multiple different locations. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0227] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0228] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially or in other words, the parts that contribute to the prior art, or all or part of the technical solutions, can be embodied in the form of a software product. This software product is stored in a storage medium and includes several instructions to cause a device (which may be a microcontroller, chip, etc.) or processor to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0229] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A safety isolation device, characterized in that, include: The first subsystem and the second subsystem are contained in the same chip. The security level of the first physical resource included in the first subsystem is higher than that of the second physical resource included in the second subsystem. The first physical resource includes a first processor core, and the second physical resource includes an interrupt configuration register and a second processor core. The first subsystem includes an interrupt controller for managing interrupts of peripherals in the second subsystem; the peripherals of the second subsystem include second peripherals. The second processor core is used to write interrupt information to the interrupt configuration register, the interrupt information including the interrupt attributes of the interrupt signal sent by the second peripheral device; The first processor core is configured to read the interrupt information from the interrupt configuration register and configure the interrupt information in the interrupt controller; The second peripheral device is used to send the interrupt signal to the interrupt controller of the first subsystem; The interrupt controller is configured to, upon receiving the interrupt signal, control the processor core in the second subsystem or the processor core in the first subsystem to suspend the running program and execute the program indicated by the interrupt signal.

2. The safety isolation device according to claim 1, characterized in that, The first processor core is also used for: An interrupt configuration request is obtained from the interrupt configuration register to trigger the first processor core to read the interrupt information from the interrupt configuration register.

3. The safety isolation device according to claim 1 or 2, characterized in that, The first physical resource is configured as a first security level identifier, and the second physical resource is configured as a second security level identifier.

4. The safety isolation device according to claim 3, characterized in that, The security isolation device includes an authentication component, the first physical resource includes a first processor core, and the second physical resource includes a second processor core and a second peripheral device. The first processor core is configured to send a first access request to the authentication component, wherein the first access request carries the first security level identifier and the address of the second peripheral device to be accessed; The authentication component is configured to receive the first access request, obtain the second security level identifier of the second peripheral device based on the address of the second peripheral device carried in the first access request, perform authentication based on the first security level identifier and the second security level identifier, and forward the first access request to the second peripheral device when the authentication is successful.

5. The safety isolation device according to claim 4, characterized in that, The authentication component is specifically used for: If the security level of the first processor core corresponding to the first security level identifier is higher than the security level of the second peripheral device corresponding to the second security level identifier, then the authentication is successful. The first access request is either a write request or a read request.

6. The safety isolation device according to claim 3, characterized in that, The security isolation device includes an authentication component, the first physical resource includes a first processor core and a first peripheral device, and the second physical resource includes a second processor core. The second processor core is used to send a second access request to the authentication component, the second access request carrying the second security level identifier and the address of the first peripheral device to be accessed; The authentication component is configured to receive the second access request, obtain the first security level identifier of the first peripheral device based on the address of the first peripheral device carried in the second access request, perform authentication based on the first security level identifier and the second security level identifier, and forward the second access request to the first peripheral device when the authentication is successful.

7. The safety isolation device according to claim 6, characterized in that, The authentication component is specifically used for: If the security level of the second processor core corresponding to the second security level identifier is lower than the security level of the first peripheral device corresponding to the first security level identifier, and the second access request is a read request, then authentication is successful.

8. The safety isolation device according to claim 1 or 2, characterized in that, The first subsystem is used to process first security level business, and the second subsystem is used to process second security level business or non-security level business, wherein the first security level is higher than the second security level, the first security level and the second security level are levels in the Vehicle Safety Integrity Level ASIL, and the non-security level is Quality Management (QM).

9. The safety isolation device according to claim 1 or 2, characterized in that, The interrupt controller is the only interrupt controller within the chip.

10. A secure isolation method, characterized in that, The method is applied to a security isolation device, which includes a first subsystem and a second subsystem contained in the same chip. The security level of a first physical resource included in the first subsystem is higher than the security level of a second physical resource included in the second subsystem. The first physical resource includes a first processor core, and the second physical resource includes an interrupt configuration register and a second processor core; The first subsystem includes an interrupt controller, and the method includes: The interrupt controller manages the interrupts of the peripherals of the second subsystem; The second processor core writes interrupt information to the interrupt configuration register, the interrupt information including the interrupt attributes of the interrupt signal sent by the second peripheral device; The first processor core reads the interrupt information from the interrupt configuration register and configures the interrupt information in the interrupt controller; The second peripheral device of the second subsystem sends an interrupt signal to the interrupt controller of the first subsystem; Upon receiving the interrupt signal, the interrupt controller controls either the processor core of the second subsystem or the processor core of the first subsystem to suspend the running program and execute the program indicated by the interrupt signal.

11. The method according to claim 10, characterized in that, The first processor core reads the interrupt information from the interrupt configuration register, including: The first processor core obtains an interrupt configuration request from the interrupt configuration register to trigger the first processor core to read the interrupt information from the interrupt configuration register.

12. The method according to claim 10 or 11, characterized in that, The security levels of the first physical resource and the second physical resource are configured by the firmware of the system used to initialize the chip during the system initialization phase.

13. The method according to claim 10 or 11, characterized in that, The first physical resource is configured as a first security level identifier, and the second physical resource is configured as a second security level identifier.

14. The method according to claim 13, characterized in that, The security isolation device includes an authentication component; the first physical resource includes a first processor core; the second physical resource includes a second processor core and a second peripheral device; the method further includes: The first processor core sends a first access request to the authentication component, the first access request carrying the first security level identifier and the address of the second peripheral device to be accessed; The authentication component obtains the second security level identifier of the second peripheral based on the address of the second peripheral carried in the first access request, and performs authentication based on the first security level identifier and the second security level identifier. When the authentication is successful, the authentication component forwards the first access request to the second peripheral.

15. The method according to claim 14, characterized in that, The authentication based on the first security level identifier and the second security level identifier includes: If the security level of the first processor core corresponding to the first security level identifier is higher than the security level of the second peripheral device corresponding to the second security level identifier, then the authentication is successful. The first access request is either a write request or a read request.

16. The method according to claim 13, characterized in that, The security isolation device includes an authentication component; the first physical resource includes a first processor core and a first peripheral device; the second physical resource includes a second processor core; the method further includes: The second processor core sends a second access request to the authentication component, the second access request carrying the second security level identifier and the address of the first peripheral device to be accessed; The authentication component receives the second access request, obtains the first security level identifier of the first peripheral based on the address of the first peripheral carried in the second access request, and performs authentication based on the first security level identifier and the second security level identifier. If the authentication is successful, the second access request is forwarded to the first peripheral.

17. The method according to claim 16, characterized in that, The authentication based on the first security level identifier and the second security level identifier includes: If the security level of the second processor core corresponding to the second security level identifier is lower than the security level of the first peripheral device corresponding to the first security level identifier, and the second access request is a read request, then authentication is successful.

18. The method according to claim 10 or 11, characterized in that, Also includes: The first subsystem processes services at the first security level. The second subsystem processes services of the second security level or non-security level, wherein the first security level is higher than the second security level, the first security level and the second security level are levels in the Vehicle Safety Integrity Level (ASIL), and the non-security level is Quality Management (QM).

19. The method according to claim 10 or 11, characterized in that, The interrupt controller is the only interrupt controller within the chip.

Images