System privilege-level architecture generation method and device and electronic equipment
By dynamically building a privilege-level architecture in a computer system, the problem that the privilege-level architecture fixed in the existing technology cannot adapt to different application scenarios is solved, and a more flexible and adaptable system privilege-level architecture generation is achieved.
Patent Information
- Application Number
- CN202311138793.9
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-09-01
- Publication Date
- 2025-03-04
AI Technical Summary
The existing privilege-level architecture has a fixed organizational form and cannot meet the actual needs of different application scenarios.
By calling software and hardware resources in the computer system, a system privilege-level architecture is built based on actual application needs. Specific steps include obtaining the system's available resources and application requirements data, outputting configuration information to represent the privileged topology, and loading the privileged software or user program based on the configuration information.
It realizes dynamic adjustment of privilege-level architecture according to different application scenarios, meets the needs of various scenarios, and improves the flexibility and adaptability of the system.
Smart Images

Figure CN119557002A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data processing technology, and in particular to a method and device for generating a system privilege level architecture, and an electronic device. Background Art
[0002] Existing computer systems composed of software and hardware are generally divided into different privilege levels. The privileged level-related part of the computer instruction set architecture (referred to as the privileged level architecture) is the basis for the operation of privileged software such as operating systems. In the field of general computing, the privileged level architecture is a key infrastructure that provides software and hardware interfaces for basic functions such as security isolation, resource management and reuse, underlying services and environmental services, process scheduling and preemption. Among them, the privileged level architecture divides the execution state of the system into different privilege levels and grants different permissions accordingly. Code running in a higher privilege state generally has the permission to access resources at a lower privilege level, and vice versa. However, the organizational form of the existing privileged level architecture is fixed and cannot meet the actual needs of different application scenarios. Summary of the invention
[0003] The embodiments of the present application provide a method and device for generating a system privileged level architecture, and an electronic device to solve the problem that the organization form of the existing privileged level architecture is fixed and cannot meet the actual needs of different application scenarios.
[0004] In order to solve the above problems, the technical solutions provided in the embodiments of the present application are as follows.
[0005] In a first aspect, a method for generating a system privileged level architecture is provided, which can call the software and hardware resources in a computer system, so as to build a system privileged level architecture according to actual application requirements. The execution process is as follows: First, the available resources and first data of the system can be obtained according to the configured path. Among them, the available resources include multiple privileged nodes available in the system and function groups associated with each privileged node. Each privileged node is used to run privileged software or user programs. The function group includes privileged instructions and register definitions. The first data is used to indicate the application requirements of the first scenario. Then, according to the above available resources and the first data, the first configuration information is output. Among them, the first configuration information is used to indicate the topological structure composed of privileged nodes of each privileged level in the first system privileged level architecture. The topological structure represents the corresponding relationship between the privileged node as the parent node and the privileged node as the child node in the system privileged level architecture. The application requirements of the above first scenario are the description of the privileged software stack under a certain application scenario. The application scenario can be any scenario that requires the use of the privileged level architecture. Through the above manner, compared with the current computer system that uses a fixed form of system privilege level architecture, the above method can use the system's available hardware and software resources in the form of function groups and privileged nodes to generate corresponding system privilege level architecture configuration information according to the application requirements of the current scenario, thereby realizing the reconstruction of software and hardware resources and more flexibly generating a system privilege level architecture according to the application requirements of the actual scenario.
[0006] In a possible implementation, the first configuration information includes a plurality of data, each of which is used to indicate a privileged node as a child node owned by a privileged node as a parent node among a plurality of privileged nodes. In this way, the relationship between the parent node and the child node can be described by a plurality of data, thereby showing the corresponding system privilege level architecture.
[0007] In a possible implementation, the first configuration information includes a plurality of data, each of which is used to indicate the arrangement order of all privileged nodes from a privileged node as a root node to a privileged node as a leaf node among a plurality of privileged nodes. In this way, each complete branch from the root node to the leaf node can be described by a plurality of data, thereby showing the corresponding system privilege level architecture.
[0008] In a possible implementation, the method further includes: loading corresponding privileged software or user programs for each privileged node according to the first configuration information. Based on this, corresponding privileged software or user programs can be flexibly loaded for each privileged node according to the privileged level architecture corresponding to the first configuration information, thereby better meeting the application requirements of various scenarios.
[0009] In a possible implementation, available resources are obtained through pre-configuration information. The pre-configuration information is used to indicate the correspondence between the available privileged nodes and the functional groups in the system. Based on this, the operator can set the above pre-configuration information according to the actual software and hardware of the system, so as to more conveniently obtain the correspondence between the available privileged nodes and the functional groups in the system during the execution process.
[0010] In a possible implementation, the method further includes: obtaining second data. The second data is used to indicate the application requirements of the second scenario. Then, based on the available resources and the second data, second configuration information is output. The second configuration information is used to indicate the topological structure composed of privileged nodes of each privileged level in the privileged level architecture of the second system. In a possible solution, the second data may be a variation of the first data, and accordingly, the method may also be used to adjust from the first configuration information to the second configuration information to achieve optimal adaptation from the application requirements of the first scenario to the application requirements of the second scenario. The first scenario and the second scenario may be the same application scenario, but the application requirements have changed. The first scenario and the second scenario may also be different application scenarios with different application requirements.
[0011] In a possible implementation manner, the topological structure of the first system privileged level architecture and the second system privileged level architecture is a tree topology.
[0012] In a second aspect, a device for generating a system privilege level architecture is provided, which includes: an acquisition module and a configuration module. The acquisition module is used to acquire available resources and first data of the system. The available resources include multiple privileged nodes available in the system and functional groups associated with each privileged node. Each privileged node is used to run privileged software or user programs. The functional group includes privileged instructions and register definitions. The first data is used to indicate application requirements of a first scenario. The configuration module outputs first configuration information based on the available resources and the first data. The first configuration information is used to indicate a topological structure composed of privileged nodes of each privilege level in the first system privilege level architecture.
[0013] In a possible implementation manner, the first configuration information includes a plurality of data, each of which is used to indicate a privileged node as a child node owned by a privileged node as a parent node among a plurality of privileged nodes.
[0014] In a possible implementation, the first configuration information includes a plurality of data; each data is used to indicate the arrangement order of all privileged nodes from a privileged node serving as a root node to a privileged node serving as a leaf node among the plurality of privileged nodes.
[0015] In a possible implementation, the generating device further includes a boot module, which is used to load corresponding privileged software or user program for each privileged node according to the first configuration information.
[0016] In a possible implementation manner, the above-mentioned available resources can be obtained through pre-configuration information; wherein the pre-configuration information is used to indicate the correspondence between the available privileged nodes and the functional groups in the system.
[0017] In a possible implementation, the acquisition module is further used to acquire second data. The second data is used to indicate the application requirements of the second scenario. The configuration module is further used to output second configuration information based on the available resources and the second data. The second configuration information is used to indicate a topological structure composed of privileged nodes of each privilege level in the privileged level architecture of the second system.
[0018] In a possible implementation manner, the topological structure of the first system privileged level architecture and the second system privileged level architecture is a tree topology.
[0019] In a third aspect, a computer-readable storage medium is provided, which stores computer program instructions, and when the computer program instructions are executed by a processor, the method in any possible implementation manner of the first aspect is implemented.
[0020] In a fourth aspect, an electronic device is provided, which includes a memory and a processor; the memory stores computer program instructions, and when the computer program instructions are executed by the processor, the method in any possible implementation manner of the first aspect described above is implemented.
[0021] In a fifth aspect, a computer program product is provided, which, when executed by a processor, implements the method in any possible implementation manner of the first aspect described above.
[0022] The technical effects brought about by the second to fifth aspects and possible implementation methods can be found in the description of the technical effects brought about by the first aspect and possible implementation methods mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS
[0023] Figure 1 A schematic diagram of the three-level privilege division in a classic computer system;
[0024] Figure 2 A schematic diagram of a privileged level architecture of an x86 architecture;
[0025] Figure 3 A schematic diagram of a privileged level architecture of the Armv8 architecture;
[0026] Figure 4A schematic diagram of a privileged level architecture of a RISC-V architecture;
[0027] Figure 5 A flowchart of a method for generating a system privilege level architecture provided in an embodiment of the present application;
[0028] Figure 6 A schematic diagram of a data structure of configuration information provided in an embodiment of the present application;
[0029] Figure 7 A schematic diagram of another data structure of configuration information provided in an embodiment of the present application;
[0030] Figure 8 A privilege transfer diagram of a privileged level architecture provided in an embodiment of the present application;
[0031] Fig. 9 A privilege description diagram of another privilege level architecture provided in an embodiment of the present application;
[0032] Fig.10 A data structure of configuration information provided in an embodiment of the present application and a privilege description diagram corresponding to the data structure;
[0033] Fig.11 Another data structure of configuration information provided in an embodiment of the present application and a privilege description diagram corresponding to the data structure;
[0034] Fig.12 A data structure of another configuration information provided in an embodiment of the present application and a privilege description diagram corresponding to the data structure;
[0035] Fig.13 A privilege description diagram of a non-virtualized architecture in a RISC-V architecture provided in an embodiment of the present application;
[0036] Fig.14 A privilege description diagram for enabling a virtualization architecture in a RISC-V architecture provided in an embodiment of the present application;
[0037] Fig.15 A privilege description diagram of an Armv8 architecture provided in an embodiment of the present application;
[0038] Fig.16 A schematic diagram of the structure of a privileged software stack for an in-vehicle system supporting driver security isolation provided in an embodiment of the present application;
[0039] Fig.17 A method provided in the embodiment of the present application Fig.16 The privilege description diagram corresponding to the privileged software stack shown;
[0040] Fig.18A schematic diagram of the structure of a device for generating a system privilege level architecture provided in an embodiment of the present application;
[0041] Fig.19 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0042] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.
[0043] In order to facilitate the clear description of the technical solutions of the embodiments of the present application, in the embodiments of the present application, the words "first", "second" and the like are used to distinguish the same items or similar items with substantially the same functions and effects. Those skilled in the art will understand that the words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like do not necessarily limit the differences. At the same time, in the embodiments of the present application, the words "exemplary" or "for example" are used to indicate examples, illustrations or explanations. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or design solutions. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a concrete manner for ease of understanding.
[0044] When describing some embodiments, the expressions "coupled" and "connected" and their derivatives may be used. For example, when describing some embodiments, the term "connected" may be used to indicate that two or more components are in direct physical contact or point contact with each other. For another example, when describing some embodiments, the term "coupled" may be used to indicate that two or more components are in direct physical contact or electrical contact. However, the term "coupled" or "communicatively coupled" may also refer to two or more components that are not in direct contact with each other, but still cooperate or interact with each other. The embodiments disclosed herein are not necessarily limited to the contents of this document.
[0045] In addition, for ease of understanding, the technical terms involved in the embodiments of the present application are first introduced below.
[0046] Privileged software: refers to the operating system kernel, hypervisor, and other software that uses the privileged architecture of the instruction set to provide basic functions. It is the opposite of user-mode software.
[0047] Privileged software stack: In a given computer system instance, the collection of all privileged software plus one or more user states that form an organic whole, including how they are constructed.
[0048] Privileged isolation: Privileged isolation is a one-way isolation between high-privilege level resources and low-privilege level code.
[0049] Privileged level organization: In a privileged level architecture, the privileged level organization specifically refers to the arrangement structure composed of privileged nodes of each privileged level. The privileged level architecture of existing instruction sets is usually a linear or two-dimensional arrangement structure, and the privileged organization of the present invention is a tree topology arrangement structure.
[0050] Privileged node, or access control ring (ACR): A privileged node is a node that executes different privileged software or user programs.
[0051] A function group (FG) is a standard or customized functional module inside a privileged node (ACR), which contains a set of instruction set architecture (ISA) resources. This set of ISA resources includes privileged instructions and register definitions, etc. It is designed to indicate the corresponding software and hardware resources in the form of an instruction set to serve specific privileged software functions and provide a standardized interface for the software in terms of architecture.
[0052] Privilege transfer arc: In the privilege transfer diagram, the privilege transfer arc indicates the direct transfer path from one privilege node to another privilege node. There are two types of privilege transfer arcs, where the arrow of the privilege rising arc (referred to as the rising arc) indicates the transfer from a privilege node with a lower privilege level to a privilege node with a higher privilege level; the arrow of the privilege falling arc (referred to as the falling arc) indicates the transfer from a privilege node with a higher privilege level to a privilege node with a lower privilege level.
[0053] Privilege description graph, or privilege graph for short: The privilege description graph can be seen as a simplified privilege transfer graph. In addition to privilege nodes, it describes the privilege relationship between privilege nodes with direct transfer relationships.
[0054] Directed edge of privilege (DEP): A directed edge of privilege is an edge in the privilege description graph that identifies the level of privilege. It always points from a node with a high privilege level to a node with a low privilege level.
[0055] The privilege level tree topology, or privilege level tree for short: The privilege level tree topology is a topological structure composed of privilege nodes of each privilege level represented by a tree structure in an instance of a system privilege level architecture.
[0056] The present application is described in detail below with reference to the accompanying drawings and embodiments:
[0057] At present, in order to improve security, the hardware of computer systems in many electronic devices provides different privilege levels for software to implement isolation and protection of resources and status. Among them, the privilege level-related part of the computer instruction set architecture (ISA) (referred to as the privilege level architecture) is the basis for the operation of privileged software such as operating systems. Figure 1 As shown, in a computer system, the processor is a core component, which can be divided into multiple execution environments, each with different privilege levels. User programs (user privilege level), operating system kernel (kernel privilege level) and firmware (bare metal privilege level) run at their respective privilege levels, using, managing and controlling access to resources and system states of different privilege levels. Among them, user programs can only access allocated resources, such as allocated registers. The operating system kernel can access all resources managed by it. Firmware can access resources used by special function registers, general registers, physical memory and physical devices on electronic devices. Cross-privilege control transfer is performed between software at each privilege level in a manner defined by the instruction set architecture.
[0058] Specifically, the privileged level architecture divides the execution state into different privilege levels and grants different permissions accordingly. Code running in a higher privilege state generally has the permission to access resources at a lower privilege level, and vice versa. Privileged isolation is the one-way isolation of high privilege level resources from low privilege level code, which can realize the operation of multiple instances at a low privilege level and ensure the isolation of these instances from each other, such as the isolation between processes in a multi-tasking operating system. Each instance has its own resource space, including architectural state and address space, where the architectural state is the sum of the states of various general registers and special function registers. For example, the process space includes the address space of the process and the states of all process-related registers. The transfer between privilege levels is asymmetric. The transfer from a low privilege level to a higher privilege level is generally divided into three situations, namely, triggering an exception instruction, triggering an interrupt instruction, and executing a system call instruction, and executing a system call instruction is generally considered to be a special type of exception. Returning from a high privilege level to a low privilege level usually only requires executing a special return instruction, called an exception or interrupt return (ERET). In this way, privileged software, such as operating system software, can obtain control to execute system code or schedule and wake up user processes. When there are multiple privilege levels in the system, one or more privileged software instances can run at each privilege level, and the ones running at the lowest privilege level are usually called user programs.
[0059] Among the many system privileged architectures, the current mainstream privileged architectures include x86 architecture, Armv8 architecture and RISC-V architecture. Figure 2As shown in the figure, the x86 architecture adopts a linear seven-ring privileged level architecture, which is a linear organization. The privilege levels are arranged linearly, and different types and permissions of software (Ring-3~Ring3) are run respectively. Among them, Ring0 is designated to run the operating system kernel; the two slightly lower privilege levels Ring1 and Ring2 are reserved for running device drivers; Ring3 is designated for user programs. These four privilege levels are presented by the current privilege level (CPL) / request privilege level (RPL) / descriptor privilege level (DPL) and other architectural states, while Ring-1, Ring-2, and Ring-3 are conceptual privilege levels. Among them, Ring-1 is introduced through VMX Root (host mode), runs hypervisor (virtual machine monitor), creates and manages virtual machines and runs them on Ring0 of VMX Non-root (virtual machine mode) (taking Type 1 virtualization as an example). Therefore, conceptually, Ring-1 controls the resources of Ring0 and provides virtualized environmental services for the virtual machines of Ring0. Ring-2 belongs to the system management mode (SMM), which is usually used by the firmware to perform related power and thermal management functions. Sometimes, the manufacturer's dedicated security software also runs in this mode. SMM has complete control over the CPU hardware, and its operation cannot be perceived by the previous privilege levels. Ring-3 is a more special privilege level, which belongs to the management engine ME (Management Engine). ME actually runs on the platform path controller hub (PCH), runs continuously and is not perceived by any software of the main processor. It can access all resources including SMM memory.
[0060] like Figure 3As shown in the figure, the Armv8 architecture is divided into four privilege levels from EL0 to EL3 in the vertical direction. EL0 runs user programs, EL1 runs the operating system kernel (such as a virtual machine operating system), EL2 manages virtualization, runs the virtual machine monitor (hypervisor), and EL3 is responsible for secure startup and runs the secure monitor (securemonitor). On this basis, the Armv8 architecture divides the non-secure world (normal world) and the secure world (secureworld), as shown by the dotted line. EL3 belongs to the secure world, while the original EL2, EL1, and EL0 are horizontally divided into the secure world and the non-secure world. The three privilege levels in the non-secure world remain as they are, and those in the secure world become sEL2, sEL1, and sEL0, respectively, on which the secure partition manager (SPM), the secure operating system (Secure operating system), and the user programs in the secure world are run respectively. The Armv8 architecture introduces the NS state to distinguish the two worlds, which is not only used as a CPU architecture state, but also used to isolate page tables, memory areas, and peripherals. The switch between the two worlds is completed by the secure monitor of EL3. The lower privilege levels on both sides use the secure monitor call instruction (SMC) and specially designated exceptions and interrupts to fall into EL3 for switching. The isolation between the two is one-way. The non-secure world cannot access the corresponding privileged resources of the secure world, but the secure world can access the corresponding privileged resources of the non-secure world by actively setting the NS bit, such as accessing its memory area through the page table of the non-secure world.
[0061] RISC-V architecture is divided into two forms: virtualization-enabled architecture and non-virtualization architecture. Figure 1 The three-layer structure shown. The privilege levels of each layer are called user mode (U-mode), supervisor mode (S-mode) and machine mode (M-mode) from low to high. Figure 4 As shown, the virtualization-enabled architecture is also a two-dimensional organizational structure, which distinguishes between virtualized environments and non-virtualized environments by adding a horizontal dimension. The original management mode (S-mode) is split into VS mode (VS-mode, V=1) and HS mode (HS-mode, V=0) due to the introduction of a virtualization state V, running the client operating system and the virtual machine monitor (hypervisor) respectively. Similarly, the user mode (U-mode) is also split into virtualized user mode (VU-mode, V=1) and non-virtualized user mode (U-mode, V=0), running client user programs and host user programs respectively.
[0062] Although privilege isolation can be achieved through the above three privileged level architectures, the rigid and fixed organizational form in the existing privileged level architecture usually indicates the system privileged level architecture through preset configuration information, and then loads privileged software or user programs for each privileged node in the privileged level architecture, which can only meet the actual usage needs of specific scenarios and cannot adapt to the needs of increasingly complex application environments.
[0063] In order to solve the above problems, Figure 5 As shown, the embodiment of the present application provides a method for generating a system privilege level architecture, which can be executed by a processor, and its specific execution process is as follows:
[0064] S51. Obtain available resources and first data of the system.
[0065] The available resources include multiple privileged nodes available in the system and function groups associated with each privileged node. The system is a computer system composed of software and hardware in an electronic device. Each privileged node is used to run privileged software or user programs with different permissions. The function group includes privileged instructions and register definitions, which indicate the software and hardware resources of each privileged node in the form of an instruction set. The first data is used to indicate the application requirements of the first scenario. Exemplarily, the privileged software running in the system includes but is not limited to firmware, operating system kernel, virtual machine monitor, and virtual machine operating system. In addition, considering that different scenarios have different application requirements, that is, different scenarios require different privileged level architectures, and their corresponding privileged software stacks are also different. In order to facilitate the description of application requirements of different scenarios, the first data can use a custom form to describe the privileged software stack. For example, a certain list is used to describe the privileged software stack in a certain scenario, so as to indicate the corresponding scenario requirements according to the privileged software stack. The register definition includes the register address corresponding to each privileged node, the data segment of each register, and the functions that can be realized when the data of each bit in each data segment is different, so as to achieve the adaptation of the hardware resources of the privileged node. The register includes various general registers and special function registers.
[0066] In one embodiment, the available resources and the first data of the system can be stored in a non-volatile memory, and the available resources and the first data of the system can be obtained from the corresponding storage address through the firmware after the processor is powered on. Exemplarily, the above-mentioned non-volatile memory can be a memory (i.e., memory) built into the processor. The available resources and the first data of the system can be stored in the memory of the processor, and after the processor is powered on, the firmware can directly read the available resources and the first data of the system from the corresponding storage address. Of course, the available resources and the first data of the system can also be selectively stored in an external memory coupled to the processor, and after the processor is powered on, the available resources and the first data of the system can be read from the external memory according to the corresponding storage address. Among them, the above-mentioned processor includes but is not limited to a central processing unit (CPU), a network processing unit (NPU), a graphics processing unit (GPU), or a digital signal processor (DSP) or a general-purpose processor. The non-volatile memory mentioned above may be a read-only memory (ROM), a programmable ROM (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM) or a flash memory.
[0067] In addition, in the system privilege level architecture, the function group can indicate the software and hardware resources of each privileged node in the form of an instruction set. Among them, the function groups in the system privilege level architecture may include but are not limited to the following:
[0068] RootACR: Root function group, which provides root privilege function interface for software with the highest permissions.
[0069] SfACR: Supervisor function group, which has general privileged management functions, including exception handling, environment call and interrupt handling. In the privileged node, SfACR can be considered as a basic function group.
[0070] UfACR: User function group, which is opposite to SfACR and has only user permissions.
[0071] HfACR: Hypervisor function group, which adds additional virtualization management functions based on SfACR.
[0072] In the system privilege level architecture, the functional groups of different privileged nodes are different. For example, the privileged node running the firmware is the root node, which contains the functional groups RootACR and SfACR. The privileged node running the virtual machine monitor can be a child node of the privileged node running the firmware, and the functional groups it contains are SfACR and HfACR. The privileged node running the operating system kernel can be a child node of the privileged node running the virtual machine monitor, and the functional group it contains is SfACR. The privileged node running the user program can be a child node of the privileged node running the operating system kernel, and the functional group it contains is UfACR.
[0073] In order to facilitate the confirmation of the functional groups of each privileged node, the above-mentioned available resources can be obtained through pre-configuration information. Among them, the pre-configuration information is used to indicate the correspondence between the privileged nodes available in the system and the functional groups. Exemplarily, the pre-configuration information can be set in the form of a lookup table and stored in the memory. After the processor is powered on, the firmware can read the lookup table from the corresponding storage address to obtain the privileged nodes available in the system and the functional groups associated with each privileged node.
[0074] Furthermore, the types of function groups in the system privilege level architecture can also be expanded according to actual needs. For example, in order to meet the use requirements of actual scenarios, the function groups in the system privilege level architecture can also include a function group that provides a secure enclave, a function group that provides secure calls, etc.
[0075] S52. Output first configuration information according to the available resources and the first data, wherein the first configuration information is used to indicate a topological structure composed of privileged nodes of each privileged level in the privileged level architecture of the first system.
[0076] In a possible implementation, S52 may be performed in the following manner.
[0077] S521. The processor confirms whether multiple privileged nodes available in the system meet the configuration requirements.
[0078] In a possible implementation, after the processor obtains the available resources of the system and the first data, it can first confirm the number of privileged nodes available in the system and whether the functional groups corresponding to each privileged node meet the configuration requirements of the first scenario according to the first data. If the configuration requirements can be met, S522 is executed. Otherwise, the error handling process is carried out. Among them, when executing the error handling process, a new privileged node can be allocated according to the requirements of the privileged node. Of course, if there is no privileged node to be allocated, the spare code of the privileged software can be selected to implement the alternative function by graceful degradation to meet the requirements of the system privilege level architecture. In addition, when executing the error handling process, if the above problem can be solved, the sub-nodes for the current privileged node will continue to be allocated. Otherwise, the process ends / the error information is output.
[0079] S522. The processor allocates a privileged node for executing the privileged software.
[0080] When the privileged nodes available in the system meet the demand, the privileged nodes of the current privilege level can be allocated according to the privileged software stack corresponding to the first data.
[0081] S523. The processor confirms, based on the first data, whether the current privileged node has any privileged nodes as child nodes.
[0082] The processor can determine whether the current privileged node has any other privileged nodes as child nodes according to the privileged software stack corresponding to the first data. If the current privileged node has any other privileged nodes as child nodes, S51 to S523 are executed again, otherwise, S524 is continued to be executed.
[0083] S524. The processor loads the required software program at the privilege node of the next privilege level.
[0084] When constructing the privileged level architecture of the system, if a privileged node has completed the configuration of its subnodes, it can send the software program required to configure the subnodes to the privileged nodes of the next level, thereby configuring its own subnodes through the privileged nodes of the next level.
[0085] S525. The processor performs control transfer and configures a privileged node as a child node for the privileged node at the next level.
[0086] After a privileged node has configured its own child nodes, it can transfer control according to the privileged software stack corresponding to the first data, and continue to execute the above software program through the privileged node of the next privilege level to configure its own child nodes. The specific configuration process can be performed with reference to S51 to S523, and the embodiment of the present application will not be described in detail here.
[0087] After all privileged nodes are configured according to the privileged software stack corresponding to the first data, the first configuration information can be obtained.
[0088] Furthermore, after completing the configuration of all privileged nodes starting from the root node, necessary exception and interrupt routes can be configured for privileged nodes of each privilege level through the root node, so that each child node can realize the transfer of the rising arc to the target privileged node through exceptions and interrupts. At the same time, starting from the root node, the child nodes of the next privilege level can be guided step by step, and the control can be transferred to each privileged software or user program in the privileged software stack in an orderly manner, so as to realize the loading of the corresponding privileged software or user program for each privileged node. The specific implementation method is to set the initialization context in the privileged software stack, trigger the descending arc by executing the exception call return instruction, and execute the initialization instance on the target privileged node.
[0089] In a possible implementation scheme, when the scenario changes, the processor can also obtain the second data. Then, according to the available resources of the system and the second data, the second configuration information is output. The second data is used to indicate the application requirements of the second scenario. The second configuration information is used to indicate the topological structure composed of privileged nodes of each privilege level in the privileged level architecture of the second system. The privileged level architecture of the second system is a tree topology. The specific generation process of the second configuration information can refer to the above S51-S525, and the embodiment of the present application is not repeated here. The second data can be a change of the first data, and accordingly, the above method can also be used for the adjustment from the first configuration information to the second configuration information to achieve the best adaptation from the application requirements of the first application scenario to the application requirements of the second scenario. The first scenario and the second scenario can be the same scenario, but the application requirements are different. For example, when the privileged level architecture configured by the first data needs to be updated in a certain application scenario, the operator can adjust part of the application requirements in the first data to obtain the second data, and then the processor generates the corresponding system privileged level architecture according to the second data with reference to the above method. Of course, the application requirements of the second data and the application requirements of the first data can also correspond to completely different scenarios, and the embodiment of the present application is not repeated here.
[0090] In this way, the processor can use the available software and hardware resources of the system to generate second configuration information corresponding to the second system privilege level architecture according to the application requirements of the second scenario, so as to better meet the requirements of various scenarios.
[0091] In a possible implementation, the first configuration information may include multiple data (0 to MAX_ACRNUM), where MAX_ACRNUM represents the maximum data number. Each data is used to indicate a privileged node as a child node owned by a privileged node as a parent node among multiple privileged nodes. For example, Figure 6As shown, the first configuration information can be represented by a set of architecture state arrays CHILDVEC, and the number of active elements (ie, the number of data) in the architecture state array is equal to the number of nodes in the system privileged level architecture implemented by the software and hardware. <n>Used to indicate the child nodes of the nth privileged node. If the number of nodes is less than the maximum number of nodes defined by the system privileged level architecture (MAX_ACRNUM+1), the elements between the two are filled with 0. For example, assuming that the maximum number of nodes in the system privileged level architecture is 16 (ACR0~ACR15), where the system privileged level architecture of a certain scenario only uses ACR0, ACR1 and ACR15, then the elements corresponding to the privileged nodes ACR2~ACR14 are all filled with 0. This filling can be hardwired to 0. Among them, each array element is a bitmap (bitvector), the 0th element is recorded as CHILDVEC_0, the nth element is recorded as CHILDVEC_ <n>. bitmap CHILDVEC_ <n>Each bit represents the privileged node ACR <n>The possible child nodes. For example, CHILDVEC_ <n>[6] = 1, which means that the privileged node ACR6 is the privileged node ACR <n>The child node of ACR, and the other bits are all 0, indicating the privileged node ACR <n>No other child nodes. If a privileged node cannot be a child of another privileged node, the corresponding bit in the latter's bitmap is permanently set to zero (i.e. hardwired to 0). <n>[0] is always zero because the privileged node ACR0 as the root node can never be a child node of other privileged nodes.
[0092] In another possible implementation, the first configuration information may include multiple data (0 to MAX_ACRNUM), where MAX_ACRNUM represents the maximum data number. Each data is used to indicate the arrangement order of all privileged nodes between the privileged node as the root node and the privileged node as the leaf node among the multiple privileged nodes. For example, Figure 7 As shown, the first configuration information can be represented by a set of architecture state arrays TBRANCH. The maximum number of elements in the array is represented by MAX_ACRNUM, that is, the maximum number of complete branches is one less than the maximum number of privileged nodes supported by the architecture (MAX_ACRNUM+1). Any element in the array, such as TBRANCH_ <n>, all represent a complete branch from the root node to the leaf node, and each level of the branch is represented by a variable LEVEL[m] that can hold the privileged node number. Figure 7 As shown. Since the complete branch always starts from the root node, each element in TBRANCH_ <n>LEVEL[0] in TBRANCH_0 is always 0, and the maximum possible value of m is MAX_ACRNUM. If a leaf node on a complete path appears at LEVEL[x], then when y>x, LEVEL[y] is always filled with the terminal value 0. For example, the complete branch ACR0→ACR3→ACR4 in TBRANCH_0 is represented by LEVEL[0]=0, LEVEL[1]=3, LEVEL[2]=4, LEVEL[3]=0, LEVEL[4]=0, ..., and so on.
[0093] In the above implementation process, Figure 6 and Figure 7 The data structure of the first configuration information is only for the convenience of understanding the exemplary scheme adopted by the embodiment of the present application when constructing the system privilege level architecture. The technicians in this field can refer to the configuration principle of the first configuration information and make corresponding adjustments in actual operation. The embodiment of the present application does not impose specific restrictions on the data structure of the first configuration information. In addition, the maximum number of nodes in the above-mentioned first configuration information is only an example provided by the embodiment of the present application. When used specifically, it can be adjusted according to the actual available software and hardware resources of the system.
[0094] The system privilege level architecture provided in the embodiment of the present application is a tree topology of privilege levels. In order to facilitate the standard description of various organizations of the privilege level architecture. Figure 8 As shown, the privileged level architecture of the system can be represented by using transfer arc representation. Figure 8 The representation in is similar to the State Transition Diagram, called the Privilege Transition Diagram. ACR0, ACR1 and ACR2 represent privileged nodes of three privilege levels, respectively, and the privilege levels decrease from top to bottom. Each privileged node is assigned a unique number. Next to each privileged node is the privileged software or user program running on the node under the privileged level architecture organization. All these software in the diagram constitute a specific privileged software stack. There are two types of privileged transfer arcs in the diagram, namely the privileged ascending arc and the privileged descending arc, or the ascending arc and the descending arc. The ascending arc represents the transfer from a low privilege level to a high privilege level. The specific way to achieve the transfer is usually to trigger an exception (synchronous) or an interrupt (asynchronous), or it can be achieved by triggering a special type of exception through the execution environment (system) call instruction. The software running on the starting privilege level of the ascending arc cannot independently determine the ending privilege level, which is indicated by a dotted arrow. The ascending arc reflects the relationship between privileged nodes in the system. The opposite of the rising arc is the falling arc, which represents the transfer from a high privilege level to a low privilege level. The transfer method is usually to execute an exception (or interrupt) return instruction, and the software running at the starting privilege level autonomously selects the ending privilege level. The falling arc is represented by a solid arrow. Note that due to the autonomy of the software, the falling arc is not unique and does not always appear in pairs with the rising arc.
[0095] exist Figure 8 Based on the further simplification of , we get the corresponding privilege description diagram, see Fig. 9 There are no ascending arcs or descending arcs. Instead, there are directed edges of privilege (DEP), represented by thick straight arrows. The direction of a directed privilege edge is always opposite to the corresponding ascending arc, pointing in the direction of decreasing privilege level. The privilege description graph can be referred to as the privilege graph.
[0096] In a possible implementation scheme, it is considered that the virtual machine space in the system privileged level architecture in some scenarios is divided into two types of privileged nodes: the secure kernel and the non-secure driver. At the same time, when cross-border access is performed between the secure kernel and the non-secure driver, it is necessary to automatically switch the virtual machine through a secure cross-world call instruction (secure cross-world call) to achieve control transfer and data transmission. Therefore, in order to meet the system privileged level architecture construction requirements in such scenarios, the generation method of the system privileged level architecture provided in the embodiment of the present application can also set the call relationship between the two privileged nodes according to the actual scenario requirements.
[0097] Furthermore, in order to more clearly understand the embodiments of the present application, the following embodiments are provided.
[0098] Embodiment 1
[0099] For example, the first configuration information uses the architecture state array CHILDVEC as an example. Assume that the number of privileged nodes available in the system is 7 (ACR0-ACR6), but the system privileged architecture used in the current scenario only requires 3 privileged nodes (such as Fig.10 The first bit of the CHILDVEC_0 element in the first configuration information generated by the above method is 1, and the remaining bits are 0, and the second bit of the CHILDVEC_1 element is 1, and the remaining bits are 0. At the same time, the privilege description diagram of the privilege level architecture of the privileged system corresponding to the first configuration information is as follows: Fig.10 As shown on the left side of the diagram, the corresponding functional group can be annotated on the left side of the privilege description diagram, and the corresponding privileged software or user program can be annotated on the right side.
[0100] Embodiment 2
[0101] For example, the first configuration information still uses the architecture state array CHILDVEC as an example. Assume that the number of privileged nodes available in the system is 7 (ACR0-ACR6), but the system privileged architecture used in the current scenario only requires 5 privileged nodes (such as Fig.11 ACR0~ACR4 in the first configuration information generated according to the above method). The first bit of the CHILDVEC_0 element in the first configuration information generated according to the above method is 1, and the remaining bits are all 0. The second and fourth bits of the CHILDVEC_1 element are 1, and the remaining bits are all 0. The third bit of the CHILDVEC_2 element is 1, and the remaining bits are all 0. At the same time, the privilege description diagram of the privilege level architecture of the privileged system corresponding to the first configuration information is as follows Fig.11 As shown on the left side of the diagram, the corresponding functional group can be annotated on the left side of the privilege description diagram, and the corresponding privileged software or user program can be annotated on the right side.
[0102] Embodiment 3
[0103] For example, the first configuration information still uses the architecture state array CHILDVEC as an example. Assume that the number of privileged nodes available in the system is 7 (ACR0-ACR6), and the system privileged architecture used in the current scenario requires 7 privileged nodes (such as Fig.12 As shown). The first bit of the CHILDVEC_0 element in the first configuration information generated according to the above method is 1, and the remaining bits are 0. The second and fifth bits of the CHILDVEC_1 element are 1, and the remaining bits are 0. The third and fourth bits of the CHILDVEC_2 element are 1, and the remaining bits are 0. The sixth bit of the CHILDVEC_5 element is 1, and the remaining bits are 0. The privilege description diagram of the privileged system privilege level architecture corresponding to the first configuration information is shown in FIG. Fig.12 As shown on the left side of the diagram, the corresponding functional group can be annotated on the left side of the privilege description diagram, and the corresponding privileged software or user program can be annotated on the right side.
[0104] Embodiment 4
[0105] Furthermore, the virtualization-enabled architecture and the non-virtualization architecture of the RISC-V architecture can also be constructed in the above manner. Fig.13 As shown, the firmware, operating system kernel and user program in the non-virtualized architecture can be divided into three privileged nodes (ACR0~ACR3) in turn. Among them, the corresponding privileged software stack of the architecture can be set as the first data according to the actual scenario. When the processor is powered on, the available resources and the first data of the system can be obtained. Then, the corresponding first configuration information is output according to the available resources and the first data of the system. Among them, the first configuration information can be used as follows Figure 6 or Figure 7 In addition, Fig.14 As shown, the firmware, virtual machine monitor, sub-operating system, sub-user program and main user program in the virtualization-enabled architecture of the RISC-V architecture can be divided into five privileged nodes (ACR0~ACR5) in turn. Among them, the corresponding privileged software stack of the architecture can be set as the first data according to the actual scenario. When the processor is powered on, the available resources and the first data of the system can be obtained. Then, the corresponding configuration information is output according to the available resources of the system and the first data. Among them, the configuration information can be used as follows Figure 6 or Figure 7 data structure.
[0106] Embodiment 5
[0107] Further, such as Fig.15 As shown, if the Armv8 architecture is needed in a certain scenario, it can also be constructed in the above manner. Among them, the four privilege levels EL0 to EL3 in the Armv8 architecture can be subdivided into seven privileged nodes such as ACR0~ACR6, wherein the corresponding privileged software stack can be set as the first data according to the architecture. When the processor is powered on, the available resources and the first data of the system can be obtained. Then, the corresponding configuration information is output according to the available resources of the system and the first data. Among them, the configuration information can be used as follows Figure 6 or Figure 7 data structure.
[0108] Embodiment 6
[0109] like Fig.16 As shown, the embodiment of the present application also provides a privileged level architecture in an in-vehicle system application scenario that supports driver security isolation. The privileged software stack corresponding to the privileged level architecture of the system includes firmware, a virtual machine monitor, a security kernel, and an unsafe driver, etc. Among them, the security kernel includes two operating states: kernel state and user state. The security kernel occupies a virtual machine space, and the user state on it may include N in-vehicle application process spaces running application processes. The unsafe driver runs in M isolated driver isolation spaces (such as virtual machines) in the virtual machine space. The driver proxy module set in the kernel state of the security kernel can automatically switch the virtual machine between the driver entry 1 and the driver entry M of the unsafe driver through a secure cross-border call instruction call to realize control transfer and data transfer. The data structure used in this call mechanism in the kernel state is created and maintained by the virtual machine monitor (hypervisor), but the execution call return does not need to be trapped from the virtual machine to the virtual machine monitor, ensuring safety while taking into account efficiency. When any of the M unsafe drivers crashes, since its virtual machine space is independent of the security kernel and other unsafe drivers, the virtual machine monitor only needs to repair or restart its virtual machine and notify the security kernel to retry.
[0110] like Fig.17 As shown, when you need to build Fig.16 In the system privilege level architecture in the scenario, the privileged node running the firmware can be used as ACR0. The privileged node running the virtual machine monitor can be used as ACR1. In the secure kernel, the privileged node in the kernel state can be used as ACR2, and the privileged node in the user state can be used as ACR3. The privileged node running the non-secure driver can be used as ACR4. Then, the corresponding first data is set according to the application requirements of the scenario to represent Fig.16 When the processor is powered on, the available resources of the system and the first data can be obtained. Then, the corresponding configuration information is output according to the available resources of the system and the first data. The configuration information can be used as follows: Figure 6 or Figure 7 data structure.
[0111] In one possible embodiment, Fig.18 As shown, the embodiment of the present application further provides a system privilege level architecture generation device 1800, which includes an acquisition module 1810 and a configuration module 1820. The system privilege level architecture generation device is used to implement the functions of the above processor.
[0112] The acquisition module 1810 is used to acquire the available resources of the system and the first data. The available resources include multiple privileged nodes available in the system and functional groups associated with each privileged node. Each privileged node is used to run a privileged software or user program functional group. The functional group includes privileged instructions and register definitions, indicating corresponding software and hardware resources. The first data is used to indicate the application requirements of the first scenario.
[0113] The acquisition module may acquire the above-mentioned available resources and the first data from the memory of the processor, or may choose to acquire the available resources and the first data from the memory coupled to the processor, and the embodiment of the present application does not impose specific restrictions on this. In addition, the acquisition module may also acquire the available resources and the first data from other types of storage devices. The storage device may be a flash memory, a read only memory (ROM), an erasable programmable read only memory (EPROM), an electrically erasable programmable read only memory (EEPROM), a register, a hard disk, a mobile hard disk, a CD-ROM, or any other form of storage medium known to those skilled in the art, and the embodiment of the present application does not impose specific restrictions on this.
[0114] The configuration module 1820 is used to output first configuration information according to the available resources and the first data, wherein the first configuration information is used to indicate a topological structure composed of privileged nodes of each privileged level in the privileged level architecture of the first system.
[0115] As a possible implementation manner, the first configuration information may include multiple data; each data is used to indicate a privileged node as a child node owned by a privileged node as a parent node among multiple privileged nodes.
[0116] As a possible implementation manner, the first configuration information may include multiple data; each data is used to indicate the arrangement order of all privileged nodes between the privileged node as the root node and the privileged node as the leaf node among the multiple privileged nodes.
[0117] As a possible implementation, the generating device further includes a guiding module 1830. The guiding module 1830 is used to load corresponding privileged software or user program for each privileged node according to the first configuration information.
[0118] As a possible implementation, available resources can be obtained through pre-configuration information; wherein the pre-configuration information is used to indicate the correspondence between the privileged nodes available in the system and the functional groups. Exemplarily, the pre-configuration information can be set in the form of a lookup table and stored in a memory. After the processor is powered on, the firmware can read the lookup table from the corresponding storage address to obtain the privileged nodes available in the system and the functional groups associated with each privileged node.
[0119] As a possible implementation, the acquisition module is further used to acquire second data. The second data is used to indicate the application requirements of the second scenario. The configuration module is further used to output second configuration information based on the available resources and the second data. The second configuration information is used to indicate a topological structure composed of privileged nodes of each privilege level in the privileged level architecture of the second system.
[0120] It should be understood that the generation device of the system privilege level architecture of the embodiment of the present application can be implemented by GPU, NPU, ASIC, or programmable logic device (PLD), and the above PLD can be a complex programmable logical device (CPLD), field programmable gate array (FPGA), generic array logic (GAL) or any combination thereof. When the above method is implemented by software, the generation device of the system privilege level architecture and its various modules can also be software modules.
[0121] In one possible embodiment, Fig.19 As shown, the embodiment of the present application also provides an electronic device 1900, which includes a processor 1910 and a memory 1920 coupled to the processor 1910. The memory 1920 stores computer program instructions, and when the computer program instructions are executed by the processor 1910, the above-mentioned method for generating a system privileged level architecture can be implemented. The above-mentioned processor 1910 includes but is not limited to a central processing unit (CPU), a network processing unit (NPU), a graphics processing unit (GPU), or a digital signal processor (DSP) or a general processor. The above-mentioned memory 1920 can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM) or a flash memory.
[0122] The method steps in this embodiment can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable ROM (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC. In addition, the ASIC can be located in a terminal device. Of course, the processor and the storage medium can also exist as discrete components in a network device or a terminal device.
[0123] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When a computer program or instruction is loaded and executed on a computer, the process or function of the embodiment of the present application is executed in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, a network device, a user device or other programmable device. The computer program or instruction can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer program or instruction can be transmitted from one website site, computer, server or data center to another website site, computer, server or data center by wired or wireless means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server, data center, etc. that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, a hard disk, or a tape; it can also be an optical medium, such as a digital video disc (DVD); it can also be a semiconductor medium, such as a solid state drive (SSD).
[0124] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in the present application, and these modifications or replacements should be included in the protection scope of the present application. Therefore, the protection scope of the present application shall be based on the protection scope of the claims.< / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n> < / n>
Claims
1. A method for generating a system privilege level architecture, characterized in that: include: Obtaining available resources and first data of the system; The available resources include a plurality of privileged nodes available in the system and a functional group associated with each of the privileged nodes; wherein each of the privileged nodes is used to run privileged software or user programs; the functional group includes privileged instructions and register definitions; the first data is used to indicate application requirements of a first scenario; First configuration information is output according to the available resources and the first data; the first configuration information is used to indicate a topological structure composed of privileged nodes of various privileged levels in a privileged level architecture of a first system.
2. The method according to claim 1, characterized in that: The first configuration information includes a plurality of data; each of the data is used to indicate a privileged node as a child node owned by a privileged node as a parent node among the plurality of privileged nodes.
3. The method according to claim 1, characterized in that The first configuration information includes a plurality of data; each of the data is used to indicate the arrangement order of all privileged nodes between a privileged node serving as a root node and a privileged node serving as a leaf node among the plurality of privileged nodes.
4. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: The corresponding privileged software or user program is loaded for each of the privileged nodes according to the first configuration information.
5. The method according to any one of claims 1 to 4, characterized in that: The available resources are acquired through pre-configuration information; wherein the pre-configuration information is used to indicate the correspondence between the available privileged nodes and the functional groups in the system.
6. The method according to any one of claims 1 to 5, characterized in that: The method further comprises: Acquire second data; the second data is used to indicate application requirements of the second scenario; Output second configuration information according to the available resources and the second data; the second configuration information is used to indicate a topological structure composed of privileged nodes of each privileged level in a privileged level architecture of a second system.
7. The method according to claim 6, characterized in that The topological structures of the first system privileged level architecture and the second system privileged level architecture are tree topologies.
8. A device for generating a system privilege level architecture, characterized in that: include: An acquisition module, used for acquiring available resources and first data of the system; The available resources include a plurality of privileged nodes available in the system and a functional group associated with each of the privileged nodes; wherein each of the privileged nodes is used to run privileged software or user programs; the functional group includes privileged instructions and register definitions; the first data is used to indicate application requirements of a first scenario; A configuration module is used to output first configuration information according to the available resources and the first data; the first configuration information is used to indicate a topological structure composed of privileged nodes of each privileged level in a privileged level architecture of a first system.
9. The generating device according to claim 8, characterized in that: The first configuration information includes a plurality of data; each of the data is used to indicate a privileged node as a child node owned by a privileged node as a parent node among the plurality of privileged nodes.
10. The generating device according to claim 8, characterized in that The first configuration information includes a plurality of data; each of the data is used to indicate the arrangement order of all privileged nodes between a privileged node serving as a root node and a privileged node serving as a leaf node among the plurality of privileged nodes.
11. The generating device according to any one of claims 8 to 10, characterized in that: Also includes: A boot module is used to load corresponding privileged software or user program for each privileged node according to the first configuration information.
12. The generating device according to any one of claims 8 to 11, characterized in that: The available resources are acquired through pre-configuration information; wherein the pre-configuration information is used to indicate the correspondence between the available privileged nodes and the functional groups in the system.
13. The generating device according to any one of claims 8 to 12, characterized in that: The acquisition module is further used to acquire second data; the second data is used to indicate application requirements of the second scenario; The configuration module is further used to output second configuration information according to the available resources and the second data; the second configuration information is used to indicate a topological structure composed of privileged nodes of each privileged level in a privileged level architecture of the second system.
14. The generating device according to claim 13, characterized in that: The topological structures of the first system privileged level architecture and the second system privileged level architecture are tree topologies.
15. A computer-readable storage medium, characterized in that: Computer program instructions are stored, and when the computer program instructions are executed by a processor, the method according to any one of claims 1 to 7 is implemented.
16. An electronic device, characterized in that: The method comprises a memory and a processor; the memory stores computer program instructions, and when the computer program instructions are executed by the processor, the method according to any one of claims 1 to 7 is implemented.