Security resource access method and apparatus for integrated circuit, and electronic device

Abstract

To disclose a security resource access method and apparatus for an integrated circuit and an electronic device, relating to a technical field of integrated circuits.SOLUTION: A method includes the steps of: determining, on an integrated circuit, a processor core corresponding to each operating system domain of a plurality of operating system domains; running a first preset-state operating system or a second preset-state operating system in the operating system domain by the processor core corresponding to the operating system domain; and processing a security resource access request of the second preset-state operating system in the operating system domain based on the first preset-state operating system in the operating system domain.SELECTED DRAWING: Figure 4

Description

[Technical Field]

[0001] The present disclosure relates to the field of integrated circuit technology, and more particularly to a method, apparatus and electronic device for secure resource access in an integrated circuit. [Background technology]

[0002] With the development of semiconductor technology, an integrated circuit (System on Chip, SoC) may include multiple processor cores. To take advantage of the advantages of multiple processor cores, different processor cores can run different operating systems (OS), thereby allowing multiple operating systems to run on the integrated circuit.

[0003] To improve the security of an integrated circuit, one secure state operating system (e.g., Secure World OS) and multiple non-secure state operating systems are generally executed on the integrated circuit. When a non-secure state operating system needs to access a secure resource in the secure state operating system, a security monitoring program (e.g., Secure monitor) located on the integrated circuit can send a secure resource access request to the secure state operating system, and the access result returned from the secure state operating system by the security monitoring program can be fed back to the non-secure state operating system. Summary of the Invention [Problem to be solved by the invention]

[0004] If multiple non-secure state operating systems can all access all secure resources in the secure state operating system, this is detrimental to resource isolation, and if a failure occurs in the secure state operating system, all non-secure state operating systems will be unable to successfully request secure resources. [Means for solving the problem]

[0005] To solve the above technical problems, the present disclosure provides a method, device and electronic device for accessing secure resources in an integrated circuit, which can solve the problem that a failure occurs in the secure state operating system, causing all non-secure state operating systems to be unable to successfully request secure resources.

[0006] A first aspect of the present disclosure provides a secure resource access method for an integrated circuit, the method including the steps of determining a processor core corresponding to each operating system domain among a plurality of operating system domains on the integrated circuit, executing a first preset state operating system or a second preset state operating system in the operating system domain by the processor core corresponding to the operating system domain, and processing a secure resource access request of the second preset state operating system in the operating system domain based on the first preset state operating system in the operating system domain.

[0007] A second aspect of the present disclosure provides a secure resource access device for an integrated circuit, the device including: a determination module for determining a processor core corresponding to each operating system domain among a plurality of operating system domains on the integrated circuit; an execution module for executing a first preset state operating system or a second preset state operating system in the operating system domain by the processor core corresponding to the operating system domain; and a processing module for processing a secure resource access request of the second preset state operating system in the operating system domain based on the first preset state operating system in the operating system domain.

[0008] A third aspect of the present disclosure provides a computer-readable storage medium having stored thereon a computer program for executing the secure resource access method for an integrated circuit according to the first aspect.

[0009] A fourth aspect of the present disclosure provides an electronic device, the electronic device including a processor and a memory for storing processor-executable instructions, the processor being adapted to read the executable instructions from the memory and execute the instructions to implement the secure resource access method for an integrated circuit according to the first aspect above.

[0010] A fifth aspect of the present disclosure provides a computer program product, the instructions of which, when executed by a processor, perform the secure resource access method for an integrated circuit according to the first aspect above. [Effects of the Invention]

[0011] Based on the secure resource access method for an integrated circuit disclosed herein, by executing each operating system domain on a processor core corresponding to that operating system domain, and the first preset state operating system in each operating system domain can only process the secure resource access requests of the second preset state operating system in that operating system domain, resources between different operating system domains can be isolated, and if a failure occurs in the first preset state operating system in one of the operating system domains, it will not affect the secure resource access actions in the other operating system domains, thereby greatly improving the security of multiple operating systems. [Brief explanation of the drawings]

[0012] [Figure 1] FIG. 2 is a software architecture diagram of a system-on-chip according to an exemplary embodiment of the present disclosure. [Figure 2A] FIG. 1 is an architectural diagram of an integrated circuit according to an exemplary embodiment of the present disclosure. [Figure 2B] FIG. 2 is an architecture diagram of an integrated circuit according to another exemplary embodiment of the present disclosure. [Figure 3] FIG. 2 is an architecture diagram of an integrated circuit according to another exemplary embodiment of the present disclosure. [Figure 4] 1 is a flowchart of a method for secure resource access in an integrated circuit according to an exemplary embodiment of the present disclosure. [Figure 5] 10 is a flowchart of a method for secure resource access in an integrated circuit according to another exemplary embodiment of the present disclosure. [Figure 6] 10 is a flowchart of a method for accessing a secure resource in an integrated circuit according to yet another exemplary embodiment of the present disclosure. [Figure 7]10 is a flowchart of a method for accessing a secure resource in an integrated circuit according to yet another exemplary embodiment of the present disclosure. [Figure 8] 10 is a flowchart of a method for accessing a secure resource in an integrated circuit according to yet another exemplary embodiment of the present disclosure. [Figure 9] 10 is a flowchart of a method for accessing a secure resource in an integrated circuit according to yet another exemplary embodiment of the present disclosure. [Figure 10] 10 is a flowchart of a method for accessing a secure resource in an integrated circuit according to yet another exemplary embodiment of the present disclosure. [Figure 11] 1 is a schematic diagram of the structure of a secure resource access device of an integrated circuit according to an exemplary embodiment of the present disclosure; [Figure 12] FIG. 2 is a schematic diagram of the structure of a secure resource access device in an integrated circuit according to another exemplary embodiment of the present disclosure; [Figure 13] FIG. 2 is a schematic diagram of the structure of a secure resource access device in an integrated circuit according to another exemplary embodiment of the present disclosure; [Figure 14] FIG. 2 is a schematic diagram of the structure of a secure resource access device in an integrated circuit according to another exemplary embodiment of the present disclosure; [Figure 15] 1 is a schematic diagram of a structure of an electronic device according to an exemplary embodiment of the present disclosure. Modes for carrying out the invention

[0013] In order to understand the present disclosure, exemplary embodiments of the present disclosure will be described in detail below with reference to the drawings. Obviously, it should be understood that the described embodiments are only a part of the embodiments of the present disclosure, not all of the embodiments, and the present disclosure is not limited to the exemplary embodiments.

[0014] Unless otherwise specifically stated, the relative arrangement of components and steps, formulas and numerical values ​​described in these examples do not limit the scope of the present disclosure. Summary of the application

[0015] As chip functionality becomes increasingly powerful, multiple operating systems can be executed on integrated circuits (e.g., system on chip (SoC)), and the multiple operating systems can be executed on different processor cores of the SoC. To improve the security of the SoC, the hardware and software resources of the SoC can be divided into a secure world and a non-secure world (normal world), where security-related operations (e.g., fingerprint recognition, password processing, data encryption / decryption, security authentication, etc.) can be executed in the secure world and other non-security-related operations can be executed in the normal world, and the secure world and the normal world can be switched by a security monitoring program (e.g., secure monitor).

[0016] Generally, multiple operating systems can be executed on an SoC, including a secure world operating system (Secure World OS) and a non-secure world operating system (Normal World OS), where the secure world operating system runs in the secure world and the non-secure world operating system runs in the non-secure world. When the non-secure world operating system needs to access a secure resource in the secure world, it sends a secure resource access request to the secure world operating system through a security monitoring program (e.g., Secure Monitor) located on the SoC, and the security monitoring program feeds back the access result returned from the secure world operating system to the non-secure world operating system. The non-secure world may be called the normal world, and the non-secure world operating system may be called the normal operating system.

[0017] 1 is a software architecture diagram of a system-on-chip according to an exemplary embodiment of the present disclosure. As shown in FIG. 1, the system-on-chip runs two non-secure state operating systems OS0 and OS1, one secure state operating system Secure World OS, and one security monitoring program Secure Monitor. When OS0 or OS1 needs to request a resource from the secure world, it needs to send a secure resource access request to the Secure World OS through the Secure Monitor, switch the non-secure world to the secure world through the Secure Monitor, and switch the secure world back to the non-secure world after accessing the resource in the secure world.

[0018] However, if the above architecture is adopted, both OS 0 and OS 1 in Figure 1 can access all secure resources in the Secure World OS, which is disadvantageous for resource isolation. Furthermore, if a failure occurs in the Secure World OS, all non-secure state operating systems (e.g., OS 0 and OS 1) will not be able to successfully request secure resources.

[0019] In order to solve the above technical problems, an embodiment of the present disclosure provides a secure resource access method for an integrated circuit, which executes a secure state operating system or a non-secure state operating system in each operating system domain on a processor core corresponding to each operating system domain, and the secure state operating system in each operating system domain can only process the secure resource access requests of the non-secure state operating system in that operating system domain, thereby ensuring a significant isolation of resources between different operating system domains, and if a failure occurs in the secure state operating system in one operating system domain, it will not affect secure resource access in other operating system domains, thereby greatly improving system security. Exemplary System

[0020] An embodiment of the present disclosure provides an integrated circuit, which, as shown in FIG. 2A , includes a plurality of processor cores 10, on which a plurality of operating system domains 20 can be executed, each of the plurality of operating system domains 20 including a first preset state operating system 21 and a second preset state operating system 22, and each of the plurality of operating system domains 20 can be executed on a different processor core.

[0021] In some embodiments, the first preset state operating system 21 may include a secure state operating system, and the second preset state operating system 22 may include a non-secure state operating system, and each operating system domain 20 may include one secure state operating system and at least one non-secure state operating system. When an operating system domain includes multiple non-secure state operating systems, each non-secure state operating system in the operating system domain can access secure resources in the secure state operating system in the operating system domain. In other words, the secure state operating system in the operating system domain can process secure resource access requests of each non-secure state operating system in the operating system domain. The embodiments of the present disclosure do not limit the number of non-secure state operating systems included in an operating system domain, and the following embodiments will be described for illustrative purposes using an operating system domain including one non-secure state operating system.

[0022] 2B is an architecture diagram of an integrated circuit according to an exemplary embodiment of the present disclosure. As shown in FIG. 2B, the integrated circuit includes multiple processor cores, each of which is cpu 11 through cpu 1(N+M). For example, two operating system domains, operating system domain 20A and operating system domain 20B, run on the integrated circuit. The processor cores corresponding to operating system domain 20A are cpu 11 through cpu 1N, and the processor cores corresponding to operating system domain 20B are cpu 1(N+1) through cpu 1(N+M). Operating system domain 20A includes a secure-state operating system (Secure world OS) 21A and a non-secure-state operating system (OS) 22A. Operating system domain 20B includes a secure-state operating system (Secure world OS) 21B and a non-secure-state operating system (OS) 22B.

[0023] 2B , a secure world OS 21A or an OS 22A can be executed in the operating system domain 20A through processor cores cpu11 to cpu1N, and a secure world OS 21B or an OS 22B can be executed in the operating system domain 20B through processor cores cpu1(N+1) to cpu1(N+M). When the OS 22A in the operating system domain 20A needs to access a resource in the secure world, the secure resource access request of the OS 22A in the operating system domain 20A can be processed by the secure world OS 21A in the operating system domain 20A. When the OS 22B in the operating system domain 20B needs to access a resource in the secure world, the secure resource access request of the OS 22B in the operating system domain 20B can be processed by the secure world OS 21B in the operating system domain 20B.

[0024] In some embodiments, when a first preset state operating system in an operating system domain processes a secure resource access request of each second preset state operating system in the operating system domain, the second preset state operating system running on the processor core corresponding to the operating system domain can be switched to the first preset state operating system based on a security monitoring program (e.g., Secure Monitor) corresponding to the operating system domain, and the secure resource access request of the second preset state operating system can be processed based on the first preset state operating system.

[0025] In some examples, the security monitoring program is used to ensure secure communication and secure interaction between the non-secure world and the secure world so as to maintain overall system security. Multiple operating system domains may correspond to the same security monitoring program, or each operating system domain of multiple operating system domains may correspond to a respective security monitoring program.

[0026] 2B , for example, operating system domain 20A and operating system domain 20B correspond to the same Secure Monitor 30. When OS 22A in operating system domain 20A needs to access a secure resource in the secure world, it sends a secure resource access request to Secure world OS 21A in operating system domain 20A through Secure monitor 30, and the access result returned from Secure world OS 21A can be fed back to OS 22A through Secure monitor 30. Similarly, Secure world OS 21B in operating system domain 20B can also process the secure resource access request of OS 22B through Secure monitor 30.

[0027] 3, operating system domain 20A and operating system domain 20B correspond to different secure monitors, where operating system domain 20A corresponds to secure monitor 30A and operating system domain 20B corresponds to secure monitor 30B. When OS 22A in operating system domain 20A needs to access a secure resource in the secure world, it sends a secure resource access request to secure world OS 21A in operating system domain 20A through secure monitor 30A, and the access result returned from secure world OS 21A can be fed back to OS 22A through secure monitor 30A. Similarly, secure world OS 21B in operating system domain 20B can process the secure resource access request of OS 22B through secure monitor 30B.

[0028] It should be understood that when multiple operating system domains correspond to the same security monitoring program, if the security monitoring program crashes, all non-secure state operating systems will be unable to access secure resources. When multiple operating system domains correspond to different security monitoring programs, if the security monitoring program corresponding to one operating system domain crashes, it will not affect the secure resource access of other operating system domains, thus further improving the security of the system.

[0029] In some embodiments, as shown in Figures 2B and 3, the integrated circuit further includes hardware modules such as a Generic Interrupt Controller (GIC) and a firewall. During the initialization phase, a connection relationship between the GIC and the processor cores can be flexibly set, allowing a secure-state operating system or a non-secure-state operating system in each operating system domain to be executed on the processor core corresponding to the operating system domain. The firewall can also set a different memory space for each operating system domain, allowing the operating system in each operating system domain to access only a specific memory space, thereby achieving memory isolation between different operating system domains. Exemplary Methods

[0030] 4 is a flowchart of a method for accessing a secure resource in an integrated circuit according to an exemplary embodiment of the present disclosure. This embodiment can be applied to electronic devices, and as shown in FIG. 4, the method includes the following steps 401 to 403.

[0031] In step 401, a processor core corresponding to each operating system domain of a plurality of operating system domains on an integrated circuit is determined.

[0032] For example, an integrated circuit may include multiple processor cores (e.g., CPU cores), and a first preset state operating system or a second preset state operating system among multiple operating system domains may be executed on the multiple processor cores. The embodiments of the present disclosure do not limit the number of processor cores included on the integrated circuit and the number of operating system domains executable on the integrated circuit.

[0033] In some examples, each operating system domain includes a first preset state operating system and at least one second preset state operating system. The first preset state operating system may be an operating system running in the secure world and may be referred to as a secure state operating system, and the second preset state operating system may be an operating system running in the non-secure world and may be referred to as a non-secure state operating system. Each operating system domain may include one non-secure state operating system or multiple non-secure state operating systems, and embodiments of the present disclosure do not limit the number of non-secure state operating systems included in each operating system domain.

[0034] For example, the number of non-secure state operating systems included in different operating system domains among the plurality of operating system domains may be the same or different, and the embodiments of the present disclosure are not limited thereto. In the following embodiment, a case where the number of non-secure state operating systems included in the plurality of operating system domains is the same is described as an example.

[0035] Because an integrated circuit may include multiple processor cores, before executing an operating system on the integrated circuit, it is first necessary to determine the processor cores on the integrated circuit that correspond to each operating system domain, and the processor cores corresponding to each operating system domain are used to execute the secure state operating system or the non-secure state operating system in that operating system domain.

[0036] For example, the number of processor cores corresponding to each operating system domain may be one or more, the number of processor cores corresponding to different operating system domains may be the same or different, and the embodiments of the present disclosure do not limit the number of processor cores corresponding to each operating system domain.

[0037] In some embodiments, different processor cores may correspond to different operating system domains. That is, operating systems in different operating system domains may run on different processor cores, so that if a processor core running one operating system domain experiences an abnormality, it will not affect the normal execution of other operating system domains. Running operating systems in different operating system domains on different processor cores can isolate the hardware resources running the different operating system domains, improving system security.

[0038] In some examples, an integrated circuit may include multiple interrupt controllers corresponding to multiple operating system domains, and the processor core that executes the operating system in the operating system domain corresponding to each interrupt controller may be determined based on the connection relationship between each interrupt controller and each processor core on the integrated circuit, and the processor core corresponding to each operating system domain may be determined based on a software configuration program, and embodiments of the present disclosure are not limited to a specific form for determining the processor core corresponding to each operating system domain.

[0039] In step 402, a first preset state operating system or a second preset state operating system in an operating system domain is executed by a processor core corresponding to the operating system domain.

[0040] For example, after determining the processor core corresponding to each operating system domain, the secure state operating system or the non-secure state operating system in the operating system domain may be executed on the processor core corresponding to the operating system domain.

[0041] In some examples, a processor core corresponding to an operating system domain may execute a secure-state operating system and a non-secure-state operating system in the operating system domain in a time-sharing manner. For example, when access to secure resources is not required, the non-secure-state operating system may be executed on the processor core corresponding to the operating system domain, and when access to secure resources is required, the non-secure-state operating system may be switched to the secure-state operating system to achieve access to the secure resources.

[0042] In step 403, process a secure resource access request of a second preset state operating system in the operating system domain based on a first preset state operating system in the operating system domain.

[0043] For example, when a non-secure state operating system needs to access a secure resource, the secure resource access request of the non-secure state operating system in the operating system domain may be processed based on the secure state operating system in the operating system domain.

[0044] In some embodiments, when multiple operating system domains are executed on an integrated circuit, a first preset state operating system in one operating system domain can only process secure resource access requests of a second preset state operating system in that operating system domain, but cannot process secure resource access requests of second preset state operating systems in other operating system domains, so as to ensure resource isolation between the multiple operating system domains. In this way, if a failure occurs in the first preset state operating system in any operating system domain, it only affects access to secure resources in that operating system domain, but not in other operating system domains, thereby significantly improving the security of the multiple operating systems.

[0045] For example, as shown in FIG. 2B , operating system domain 20A corresponds to processor cores cpu11 through cpu1N, and operating system domain 20B corresponds to processor cores cpu1(N+1) through cpu1(N+M). Secure world OS 21A in operating system domain 20A can only process secure resource access requests from OS 22A in operating system domain 20A, but cannot process secure resource access requests from OS 22B in operating system domain 20B. This ensures that the resources of operating system domain 20A and operating system domain 20B are largely isolated. A failure in secure world OS 21A in operating system domain 20A only affects the secure resource access requests of OS 22A in operating system domain 20A, not the secure resource access requests of OS 22B in operating system domain 20B. Secure world OS 21B in operating system domain 20B can still process secure resource access requests from OS 22B in operating system domain 20B.

[0046] The secure resource access method according to the embodiment of the present disclosure can ensure mutual isolation between hardware resources corresponding to different operating system domains by determining a processor core corresponding to each operating system domain on an integrated circuit, and can ensure that resources between different operating system domains are largely isolated by processing a secure resource access request of a second preset state operating system in the operating system domain by a first preset state operating system in the operating system domain. Therefore, even if a failure occurs in the first preset state operating system in any operating system domain, it will not affect the access to secure resources in other operating system domains, and the security of multiple operating systems can be greatly improved.

[0047] In some embodiments, as shown in FIG. 5, based on the embodiment shown in FIG. 4, the above step 401 may include steps 4011 to 4012.

[0048] In step 4011, the connection relationship between each of the plurality of interrupt controllers of the integrated circuit and the plurality of processor cores of the integrated circuit is determined.

[0049] Illustratively, an integrated circuit may include multiple interrupt controllers, and embodiments of the present disclosure do not limit the number of interrupt controllers included on an integrated circuit. In some examples, the number of interrupt controllers included on an integrated circuit is the same as the number of operating system domains executable on the integrated circuit.

[0050] Each interrupt controller on an integrated circuit can be connected to at least one processor core, and different interrupt controllers can be connected to different processor cores, i.e., one processor core can be connected to one interrupt controller.

[0051] For example, as shown in FIG. 2B, an integrated circuit includes two interrupt controllers, GIC 40A and GIC 40B, where GIC 40A is the interrupt controller corresponding to operating system domain 20A and GIC 40B is the interrupt controller corresponding to operating system domain 20B. In this case, it can be determined that the connection relationship of GIC 40A is that GIC 40A is connected to cpu 11 to cpu 1N, and the connection relationship of GIC 40B is that GIC 40B is connected to cpu 1(N+1) to cpu 1(N+M).

[0052] In some examples, at least one selector may be included on the integrated circuit, each selector being located between a processor core and each interrupt controller, and through the selector, it is possible to select which processor core on the integrated circuit to connect the interrupt controller corresponding to each operating system domain to.

[0053] In some embodiments, the connection relationship between each interrupt controller and the processor core can be established by software or hardware. For example, the connection relationship between the interrupt controller and the processor core can be established during the startup process of a security monitoring program. After the connection relationship between the interrupt controller and the processor core is established, the processor core corresponding to each operating system domain can be determined based on the connection relationship.

[0054] In step 4012, the processor core corresponding to each operating system domain is determined based on the connection relationship.

[0055] Here, the processor core corresponding to the operating system domain is connected to a corresponding interrupt controller.

[0056] For example, since one interrupt controller corresponds to one operating system domain, a group of processor cores connected to the interrupt controllers may be determined based on the connection relationship between the interrupt controllers and the processor cores, and then the group of processor cores connected to the interrupt controllers may be determined as processor cores corresponding to one operating system domain, i.e., the group of processor cores connected to the interrupt controller corresponding to the operating system domain are used to run the secure-state operating system or the non-secure-state operating system in the operating system domain.

[0057] 2B , take an integrated circuit including two interrupt controllers, GIC 40A and GIC 40B, where GIC 40A may be connected to cpu 11 through cpu 1N by a selector, and GIC 40B may be connected to cpu 1(N+1) through cpu 1(N+M) by a selector. Because GIC 40A and GIC 40B correspond to operating system domain 20A and operating system domain 20B, respectively, after determining that the group of processor cores connected to GIC 40A are cpu 11 through cpu 1N, processor cores cpu 11 through cpu 1N can be determined as processor cores corresponding to operating system domain 20A, and thereby Secure World OS 21A or OS 22A in operating system domain 20A can be executed on cpu 11 through cpu 1N. After determining that the group of processor cores connected to GIC 40B are cpu 1(N+1) to cpu 1(N+M), cpu 1(N+1) to cpu 1(N+M) can be determined as the processor cores corresponding to operating system domain 20B, thereby allowing Secure world OS 21B or OS 22B in operating system domain 20B to be executed on cpu 1(N+1) to cpu 1(N+M).

[0058] A secure resource access method according to an embodiment of the present disclosure determines a processor core corresponding to each operating system domain based on the connection relationship between the interrupt controller and the processor core, and thereby enables a first preset state operating system and a second preset state operating system in each operating system domain to be executed on the processor core corresponding to each operating system domain. Since different interrupt controllers are connected to different processor cores, operating systems in different operating system domains can be executed on different processor cores, thereby ensuring mutual isolation between hardware resources corresponding to different operating system domains and further improving system security.

[0059] In some embodiments, as shown in FIG. 6, based on the embodiment shown in FIG. 4, the above step 403 may include steps 4031 to 4032.

[0060] In step 4031, based on a security monitoring program corresponding to the operating system domain, the second preset state operating system running on the processor core corresponding to the operating system domain is switched to the first preset state operating system.

[0061] For example, when a non-secure state operating system needs to access a secure resource, it may send a secure resource access request to a corresponding security monitoring program (Secure Monitor). After receiving the secure resource access request, the Secure Monitor performs verification to confirm the validity of the request. After the verification is passed, the Secure Monitor can switch the non-secure world to the secure world, and in the secure world, the secure state operating system can process the secure resource access request.

[0062] In some embodiments, multiple operating system domains executing on an integrated circuit may correspond to the same security monitoring program or different security monitoring programs, and if the multiple operating system domains correspond to different security monitoring programs, each operating system domain of the multiple operating system domains may correspond to a respective security monitoring program.

[0063] When multiple operating system domains correspond to the same security monitoring program, the security monitoring program can switch the second preset state operating system running on the processor core corresponding to each operating system domain to the first preset state operating system.

[0064] For example, as shown in FIG. 2B, operating system domain 20A and operating system domain 20B correspond to the same Secure monitor 30, and the Secure monitor 30 can switch OS 22A in operating system domain 20A running on cpu 11 to cpu 1N to Secure world OS 21A, and the Secure monitor 30 can switch OS 22B in operating system domain 20B running on cpu 1(N+1) to cpu 1(N+M) to Secure world OS 21B.

[0065] When each operating system domain among the multiple operating system domains corresponds to one security monitoring program, the security monitoring program corresponding to each operating system domain can switch the second preset state operating system running on the processor core corresponding to the operating system domain to the first preset state operating system.

[0066] For example, as shown in FIG. 3, operating system domain 20A corresponds to Secure monitor 30A, and operating system domain 20B corresponds to Secure monitor 30B, and Secure monitor 30A can switch OS 22A in operating system domain 20A running on cpu 11 to cpu 1N to Secure world OS 21A, and Secure monitor 30B can switch OS 22B in operating system domain 20B running on cpu 1(N+1) to cpu 1(N+M) to Secure world OS 21B.

[0067] It is understood that when multiple operating system domains correspond to different security monitoring programs, compared to when multiple operating system domains correspond to the same security monitoring program, if the security monitoring program corresponding to one operating system domain crashes, it will not affect the secure resource access of other operating system domains, and therefore the security of the system can be further improved.

[0068] In step 4032, process the secure resource access request of the second preset state operating system based on the first preset state operating system.

[0069] Illustratively, after the Secure Monitor switches the non-secure world to the secure world, in the secure world, a first preset state operating system (e.g., the secure state operating system) processes the secure resource access request (e.g., performs operations such as encryption / decryption, security authentication, etc.), and the Secure Monitor can feed back the access result to a second preset state operating system (e.g., the non-secure state operating system). When the access result is communicated to the second preset state operating system, the Secure Monitor can switch the secure world back to the non-secure world, and the second preset state operating system can perform other operations not related to security in the non-secure world.

[0070] A secure resource access method according to an embodiment of the present disclosure can switch a second preset state operating system running on a processor core corresponding to an operating system domain to a first preset state operating system by a security monitoring program corresponding to the operating system domain, thereby processing a secure resource access request. Because different operating system domains correspond to different security monitoring programs, if the security monitoring program corresponding to one operating system domain crashes, it will not affect the secure resource access of other operating system domains, thereby further improving system security.

[0071] In some embodiments, as shown in FIG. 7, based on the embodiment shown in FIG. 4, the above-mentioned integrated circuit secure resource access method may further include steps 701 to 702.

[0072] In step 701, a first security monitoring program corresponding to a first operating system domain among the plurality of operating system domains is started, and during the starting process of the first security monitoring program, a hardware setting module of an integrated circuit is initialized.

[0073] For example, the plurality of operating system domains may include a first operating system domain and a second operating system domain, and the first operating system domain and the second operating system domain correspond to different security monitoring programs, respectively, for example, the first operating system domain may correspond to the first security monitoring program, and the second operating system domain may correspond to the second security monitoring program. The first operating system domain may be any one of the plurality of operating system domains.

[0074] In some examples, the multiple operating system domains executing on the integrated circuit may include a master operating system domain and at least one slave operating system domain, where the first operating system domain is the master operating system domain and the second operating system domain is the slave operating system domain.

[0075] When the integrated circuit is started, the first security monitoring program and the second security monitoring program may be loaded into different locations in memory, and during the startup process of one Secure Monitor (e.g., the first security monitoring program), the Secure Monitor may initialize the hardware setting module of the integrated circuit, and then another Secure Monitor (e.g., the second security monitoring program) may be started. It is understood that when multiple Secure Monitors are started, only the startup process of the first Secure Monitor needs to initialize the common hardware (e.g., the hardware setting module), and subsequent Secure Monitors do not need to initialize the common hardware.

[0076] Illustratively, the hardware configuration module may include modules such as a hardware firewall, an interrupt controller, and the like.

[0077] In step 702, a second security monitoring program corresponding to a second operating system domain of the plurality of operating system domains is launched.

[0078] Illustratively, when a Secure Monitor corresponding to a second operating system domain among the multiple operating system domains is started, it is not necessary to reinitialize the hardware configuration module of the integrated circuit, thereby preventing subsequently started Secure Monitors from repeatedly initializing hardware resources, thereby improving start-up efficiency.

[0079] In some embodiments, as shown in FIG. 8, based on the embodiment shown in FIG. 7 above, step 701 may include steps 7011 to 7012.

[0080] In step 7011, a first security monitoring program corresponding to a first operating system domain among the multiple operating system domains is launched, and during the launch process of the first security monitoring program, a different memory space is set for each operating system domain by a firewall in the hardware setting module.

[0081] For example, during the startup process of the first security monitoring program, memory spaces accessible to each of the multiple operating system domains may be set. In some examples, the memory spaces accessible to different operating system domains may be different, for example, the memory spaces accessible to different operating system domains may partially overlap or may not completely overlap. If the memory spaces accessible to different operating system domains do not completely overlap, memory isolation between the different operating system domains can be achieved, thereby further improving the security of the system.

[0082] In some embodiments, after the hardware firewall sets the memory space accessible to each operating system domain, the firewall configuration information can be locked to ensure that the memory space already set accessible to each operating system domain is not changed.

[0083] In step 7012, during the start-up process of the first security monitoring program, the connection relationship between each interrupt controller and the processor core is set by the interrupt selector in the hardware setting module.

[0084] For example, during the startup process of the first security monitoring program, the connection relationship between each interrupt controller and the processor core may be set by, for example, an interrupt selector in an integrated circuit.

[0085] In some examples, when an interrupt selector is used to set the connection relationship between each interrupt controller and a processor core, one processor core may be connected to only one interrupt controller, thereby ensuring that the operating system domains corresponding to each interrupt controller are executed on different processor cores, thereby realizing hardware resource isolation between multiple operating system domains.

[0086] The secure resource access method according to the embodiment of the present disclosure can achieve memory isolation between different operating system domains by setting different memory spaces for each operating system domain during the startup process of the first security monitoring program, and can achieve hardware resource isolation between multiple operating system domains by setting a connection relationship between each interrupt controller and a processor core, thereby further improving the security of the system.

[0087] In some embodiments, as shown in FIG. 9, based on the embodiment shown in FIG. 4, the above-mentioned integrated circuit secure resource access method may further include steps 901 to 903.

[0088] In step 901, data to be transmitted is written into a shared memory space between the first operating system domain and the second operating system domain through a second preset state operating system in the first operating system domain.

[0089] For example, the memory space accessible by a first operating system domain set by a firewall is the first memory space, the memory space accessible by a second operating system domain is the second memory space, and the second memory space is a part of the first memory space. The common memory space between the first memory space and the second memory space may be called a shared memory space, and this shared memory space is a memory space accessible by both the first operating system domain and the second operating system domain.

[0090] When realizing inter-core communication between different operating system domains, data to be transmitted can be written to the shared memory space through a second preset state operating system in a first operating system domain. Exemplarily, the first operating system domain may be a master operating system domain, and the second preset state operating system in the first operating system domain may be a master OS.

[0091] In step 902, notification information is transmitted through a second preset state operating system in a first operating system domain to a second preset state operating system in a second operating system domain.

[0092] The notification information is used to indicate that data readable by a second preset state operating system in a second operating system domain is stored in the shared memory space.

[0093] For example, the first operating system domain and the second operating system domain may communicate via a hardware mailbox, and after the second preset state operating system in the first operating system domain writes the data to be transmitted to the shared memory space, it may generate notification information and transmit the notification information to the second preset state operating system in the second operating system domain via the mailbox, so as to inform the second preset state operating system in the second operating system domain that readable data is stored in the shared memory space.

[0094] 3, the OS 22A in the operating system domain 20A may write data to be transmitted to a shared memory space accessible by both the operating system domain 20A and the operating system domain 20B, generate a notification message, and then send the notification message to the OS 22B in the operating system domain 20B via a mailbox to inform the OS 22B that the readable data is stored in the shared memory space. That is, based on the mailbox, communication between the second preset state operating system in the first operating system domain and the second preset state operating system in the second operating system domain can be realized.

[0095] In some examples, a second preset state operating system in a first operating system domain can access actual physical devices, while a second preset state operating system in a second operating system domain cannot access actual physical devices and can only access emulated devices.

[0096] In step 903, according to the notification information, the data to be transmitted is read in the shared memory space through a second preset state operating system in a second operating system domain.

[0097] For example, after receiving the notification information, the second preset state operating system in the second operating system domain may read the data to be transmitted in the shared memory according to the notification information.

[0098] The secure resource access method according to the embodiment of the present disclosure writes data to be transmitted to a shared memory space through a second preset state operating system in a first operating system domain, and sends notification information indicating that readable data is stored in the shared memory space to the second preset state operating system in the second operating system domain via a mailbox, so that the second preset state operating system in the second operating system domain can read the data in the shared memory space. In this way, inter-core communication between different operating system domains is realized, and the problem of inter-core communication between multiple OSes in a scenario without a hypervisor can be solved.

[0099] In some embodiments, as shown in FIG. 10, based on the embodiment shown in FIG. 4, the above-mentioned integrated circuit secure resource access method may further include steps 1001 to 1002.

[0100] In step 1001, an interrupt request is received through an interrupt controller corresponding to each operating system domain.

[0101] For example, one operating system domain corresponds to one interrupt controller, and therefore, interrupt requests can be received through the interrupt controller corresponding to each operating system domain, and the operating systems in each operating system domain can only process interrupt requests received by the interrupt controller corresponding to each operating system domain, and cannot process interrupt requests received by interrupt controllers corresponding to other operating system domains, thereby ensuring that interrupt processing between different operating system domains does not interfere with each other, and further improving system security.

[0102] In step 1002, based on the interrupt request, the first preset state operating system or the second preset state operating system in the operating system domain is controlled to execute an interrupt processing program through an interrupt controller corresponding to each operating system domain.

[0103] Illustratively, after an interrupt controller receives an interrupt request, the interrupt can be processed only through the secure state operating system or the non-secure state operating system in the operating system domain corresponding to the interrupt controller.

[0104] 3, after GIC 40A corresponding to operating system domain 20A receives interrupt request a, OS 22A or Secure world OS 21A in operating system domain 20A processes interrupt request a received by GIC 40A, while OS 22B or Secure world OS 21B in operating system domain 20B cannot detect interrupt request a. In other words, the secure state operating system or non-secure state operating system in each operating system domain can only process interrupt requests received by the interrupt controller corresponding to that operating system domain, and does not detect interrupt requests received by interrupt controllers corresponding to other operating system domains.

[0105] In some examples, if an interrupt request received by an interrupt controller is an interrupt request for the secure world, the interrupt request is processed by a secure state operating system in an operating system domain corresponding to the interrupt controller, and if an interrupt request received by an interrupt controller is an interrupt request for the non-secure world, the interrupt request is processed by a non-secure state operating system in an operating system domain corresponding to the interrupt controller.

[0106] The secure resource access method according to the embodiment of the present disclosure processes the interrupt request received by each interrupt controller through the secure state operating system or the non-secure state operating system in the operating system domain corresponding to the interrupt controller, thereby ensuring that the interrupt processing between different operating system domains does not interfere with each other, further improving the security of the system. Exemplary Apparatus

[0107] FIG. 11 illustrates a secure resource access device in an integrated circuit according to an embodiment of the present disclosure. As shown in FIG. 11, the secure resource access device 1100 includes a determination module 1101, an execution module 1102, and a processing module 1103.

[0108] The determination module 1101 is used to determine a processor core corresponding to each operating system domain among a plurality of operating system domains on an integrated circuit.

[0109] The execution module 1102 is used to execute the first preset state operating system or the second preset state operating system in the operating system domain through a processor core corresponding to the operating system domain.

[0110] The processing module 1103 is used for processing a secure resource access request of a second preset state operating system in the operating system domain based on a first preset state operating system in the operating system domain.

[0111] In some embodiments, as shown in FIG. 12, the determination module 1101 includes a first sub-determination module 11011 and a second sub-determination module 11012.

[0112] The first sub-determination module 11011 is used to determine the connection relationship between each of the multiple interrupt controllers of the integrated circuit and the multiple processor cores of the integrated circuit.

[0113] The second sub-determination module 11012 is used to determine the processor core corresponding to each operating system domain based on the connection relationship, and the processor core corresponding to the operating system domain is connected to the corresponding interrupt controller.

[0114] In some embodiments, the processing module 1103 is used to switch the second preset state operating system running on the processor core corresponding to the operating system domain to the first preset state operating system based on a security monitoring program corresponding to the operating system domain, and process a secure resource access request of the second preset state operating system based on the first preset state operating system.

[0115] In some examples, multiple operating system domains correspond to the same security monitoring program, or each operating system domain of the multiple operating system domains corresponds to a respective security monitoring program.

[0116] In some embodiments, as shown in FIG. 13, the secure resource access device 1100 further includes an initialization module 1104 and a startup module 1105 .

[0117] The startup module 1105 is used to start a first security monitoring program corresponding to a first operating system domain in the plurality of operating system domains, and the initialization module 1104 is used to initialize a hardware setting module of the integrated circuit in the process of the startup module 1105 starting the first security monitoring program.

[0118] The launch module 1105 is further used for launching a second security monitoring program corresponding to a second operating system domain of the plurality of operating system domains.

[0119] In some embodiments, the startup module 1105 is used to set different memory spaces for each operating system domain through the firewall of the hardware setting module during the startup process of the first security monitoring program, and to set the connection relationship between each interrupt controller and a processor core through the interrupt selector in the hardware setting module during the startup process of the first security monitoring program.

[0120] In some embodiments, as shown in FIG. 14, the secure resource access device 1100 further includes a data writing module 1106, a transmitting module 1107 and a data reading module 1108.

[0121] The data writing module 1106 is used to write data to be transmitted to the shared memory space between the first operating system domain and the second operating system domain through a second preset state operating system in the first operating system domain.

[0122] The transmission module 1107 is used to transmit notification information to a second preset state operating system in a second operating system domain through a second preset state operating system in a first operating system domain, and the notification information is used to indicate that data readable by the second preset state operating system in the second operating system domain is stored in the shared memory space.

[0123] The data reading module 1108 is used for reading the data to be transmitted in the shared memory space through the second preset state operating system in the second operating system domain according to the notification information.

[0124] In some embodiments, as shown in FIG. 14, the secure resource access device 1100 further includes an interrupt processing module.

[0125] The interrupt processing module is used to receive an interrupt request through an interrupt controller corresponding to each operating system domain, and based on the interrupt request, to control the first preset state operating system or the second preset state operating system in the operating system domain to execute an interrupt processing program through the interrupt controller corresponding to each operating system domain.

[0126] The beneficial technical effects corresponding to the exemplary embodiment of the secure resource access device 1100 can be referred to the beneficial technical effects corresponding to the exemplary method part, and redundant description will be omitted here. Exemplary Electronic Devices

[0127] FIG. 15 is a structural diagram of an electronic device 150 according to an embodiment of the present disclosure, which includes at least one processor 151 and a memory 152 .

[0128] Processor 151 may be a central processing unit (CPU) or other form of processing device having data processing and / or instruction execution capabilities, and may control other components in electronic device 150 to perform desired functions.

[0129] The memory 152 may include one or more computer program products, which may include various forms of computer-readable storage media, such as, for example, volatile memory and / or non-volatile memory. Volatile memory may include, for example, random access memory (RAM) and / or cache memory. Non-volatile memory may include, for example, read-only memory (ROM), a hard disk, flash memory, etc. One or more computer program instructions may be stored in the computer-readable storage medium, and the processor 151 may execute the one or more computer program instructions to implement the secure resource access method and / or other desired functions of the integrated circuit of each embodiment of the present disclosure described above.

[0130] As an example, electronic device 150 may further include input devices 153 and output devices 154, with these components interconnected via a bus system and / or other form of connection (not shown).

[0131] The input device 153 may further include, for example, a keyboard, a mouse, and the like.

[0132] The output device 154 can output various information to the outside, and may include, for example, a display, a speaker, a printer, a communication network, and remote output devices connected thereto.

[0133] 15 shows only some of the components of the electronic device 150 that are relevant to the present disclosure, and omits components such as buses, input / output interfaces, etc. In addition, the electronic device 150 may further include any other appropriate components depending on the specific application. Exemplary Computer Program Products and Computer-Readable Storage Media

[0134] In addition to the above methods and apparatus, embodiments of the present disclosure may further provide a computer program product including computer program instructions that, when executed by a processor, cause the processor to perform steps in the integrated circuit secure resource access methods of various embodiments of the present disclosure described in the "Exemplary Method" section above.

[0135] The computer program product may be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, C++, and the like, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0136] Furthermore, an embodiment of the present disclosure may be a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, cause the processor to perform steps in the secure resource access method for an integrated circuit of various embodiments of the present disclosure described in the "Exemplary Method" section above.

[0137] The computer-readable storage medium can be any combination of one or more readable media. The readable medium can be a readable signal medium or a readable storage medium. The readable medium may include, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include an electrical connection having one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above.

[0138] Although the basic principles of the present disclosure have been described above with reference to specific embodiments, the benefits, advantages, and effects mentioned in the present disclosure are not limiting but merely illustrative and are not to be considered as being necessarily included in each embodiment of the present disclosure. Furthermore, the specific details disclosed above are not limiting but are merely for illustration and ease of understanding, and the above details do not limit the present disclosure to be realized with the above specific details.

[0139] Those skilled in the art can make various modifications and variations to the present disclosure without departing from the spirit and scope of the present disclosure. Thus, if these modifications and variations of the present disclosure fall within the scope of the claims of the present disclosure and their equivalent technologies, the present disclosure also intends to include these modifications and variations.

Claims

1. A method for secure resource access in an integrated circuit, comprising: determining a processor core on the integrated circuit corresponding to each operating system domain of a plurality of operating system domains; executing, by a processor core corresponding to the operating system domain, a first preset state operating system or a second preset state operating system in the operating system domain; and processing a secure resource access request of the second preset state operating system in the operating system domain based on a first preset state operating system in the operating system domain.

2. The step of determining a processor core corresponding to each operating system domain of a plurality of operating system domains on the integrated circuit comprises: determining a connection relationship between each of the plurality of interrupt controllers of the integrated circuit and the plurality of processor cores of the integrated circuit; 2. The method of claim 1, further comprising: determining a processor core corresponding to each of the operating system domains based on the connection relationship, wherein the processor core corresponding to the operating system domain is connected to a corresponding one of the interrupt controllers.

3. The step of processing a secure resource access request of the second preset state operating system in the operating system domain based on a first preset state operating system in the operating system domain includes: switching the second preset state operating system running on the processor core corresponding to the operating system domain to the first preset state operating system based on a security monitoring program corresponding to the operating system domain; and processing a secure resource access request of the second preset state operating system based on the first preset state operating system.

4. The method of claim 3 , wherein the plurality of operating system domains correspond to the same security monitoring program, or each operating system domain of the plurality of operating system domains corresponds to a respective one of the security monitoring programs.

5. booting a first security monitoring program corresponding to a first operating system domain among the plurality of operating system domains, and initializing a hardware setting module of the integrated circuit during the booting process of the first security monitoring program; 4. The method of claim 3, further comprising: launching a second security monitoring program corresponding to a second operating system domain of the plurality of operating system domains.

6. In the process of starting the first security monitoring program, the step of initializing a hardware setting module of the integrated circuit includes: During the startup of the first security monitoring program, setting different memory spaces for each operating system domain through a firewall in the hardware setting module; 6. The method according to claim 5, further comprising the step of: during the process of starting the first security monitoring program, setting a connection relationship between each of the interrupt controllers and the processor core through an interrupt selector in the hardware setting module.

7. writing data to be transmitted to a shared memory space between the first operating system domain and the second operating system domain by a second preset state operating system in the first operating system domain; transmitting notification information by a second preset state operating system in the first operating system domain to a second preset state operating system in the second operating system domain, the notification information being used to indicate that data readable by the second preset state operating system in the second operating system domain is stored in the shared memory space; The method of any one of claims 1 to 6, further comprising the step of reading the data to be transmitted from the shared memory space by a second preset state operating system in the second operating system domain in response to the notification information.

8. receiving an interrupt request through an interrupt controller corresponding to each of said operating system domains; The method according to any one of claims 1 to 6, further comprising the step of controlling, based on the interrupt request, a first preset state operating system or a second preset state operating system in the operating system domain through an interrupt controller corresponding to each of the operating system domains to execute an interrupt processing program.

9. 1. An integrated circuit secure resource access device, comprising: a determination module for determining a processor core corresponding to each operating system domain of a plurality of operating system domains on the integrated circuit; an execution module for executing, by a processor core corresponding to the operating system domain, a first preset state operating system or a second preset state operating system in the operating system domain; a processing module for processing a secure resource access request of the second preset state operating system in the operating system domain based on a first preset state operating system in the operating system domain.

10. A computer-readable storage medium having stored thereon a computer program that, when executed by a processor, implements the secure resource access method for an integrated circuit according to any one of claims 1 to 6.

11. An electronic device, a processor; a memory for storing instructions executable by the processor; An electronic device, wherein the processor is used to read the executable instructions from the memory and execute the instructions to implement the integrated circuit secure resource access method described in any one of claims 1 to 6.

Images