Permission domain management method and system for multi-privilege-level processor resources

Abstract

The invention provides a permission domain management method and system for multi-privilege-level processor resources. The permission domain management method comprises the steps of instruction checking, register read-write checking, register bit field write-in checking and starting initialization. According to the ISA-Context, the step of starting initialization is executed, and the ID of the current permission domain is obtained; executing an instruction checking step according to the ID of the current permission domain; executing a register read-write inspection step according to the ID of the current permission domain; and according to the ID of the current permission domain, executing a register bit field write-in checking step. According to the method, the processor resources are isolated by using the permission domains, that is, a plurality of permission domains, specifically 256 permission domains, exist in operation, and the resources are isolated by using the granularity of a single instruction or a register bit field in each permission domain, so that the granularity of the permission isolation of the processor resources is finer.

Description

Technical Field

[0001] The present invention belongs to the field of network security technology, and in particular, relates to a permission domain management method and system for multi-privilege level processor resources, and more particularly, to a permission domain management architecture for multi-privilege level processor resources. Background Art

[0002] With the continuous emergence and development of cyber attacks, identity theft and malware, computer security issues have become an important issue that businesses and individuals must face. Computers need a trustworthy computing environment to ensure the security, integrity and reliability of sensitive data, and to ensure that the process and results of program execution will not be exploited and stolen by hackers.

[0003] Isolation is a basic mechanism in the field of computer security. By dividing software into different permission domains and limiting their access rights to different resources, the scope of attack propagation can be reduced, and the damage that malware and inevitable system vulnerabilities may cause to the system can be reduced; the isolation mechanism also provides the system with a more trusted and secure operating environment. The system's own security can be ensured by placing sensitive operations and key data in an isolated environment for processing.

[0004] Processor resources, namely ISA resources, instruction resources and register resources, are important hardware resources that affect system security. Processor resource vulnerabilities can be exploited by hackers to launch a variety of attacks, including: tampering with secure memory, stealing sensitive data from secure enclaves, and obtaining access to higher privileged data.

[0005] Existing hardware usually only provides a coarse-grained isolation mechanism based on privilege levels, which has a high risk of being attacked and the losses after being attacked. Take the ARM Cortex A53 as an example. The processor has hundreds of system instructions and registers, but only provides four privilege levels, and a large number of processor resources are located at the same privilege level. In EL1, that is, kernel mode, there are more than 100 instructions and registers that can be used for system control. For a macro kernel operating system such as Linux, which consists of multiple modules, all modules run in kernel mode. Any vulnerable module will cause all registers and instructions in kernel mode to be accessed by attackers, causing immeasurable losses.

[0006] Regarding privilege level-based technologies, modern commercial CPUs rely on privilege levels to control access to processor resources. The processor prohibits software at low privilege levels from accessing processor resources at high privilege levels. However, this approach does not conform to the principle of least privilege and is difficult to cope with increasingly severe attack methods.

[0007] Processor manufacturers are not unaware of the importance of processor resources to system security. They have implemented some protection mechanisms for specific registers or instructions on the CPU. For example, in order to mitigate side-channel attacks based on CPU frequency and voltage, Intel added patches to the BIOS and CPU microcode to allow users to configure whether to allow software to access the MS R0x150 register. However, although such mechanisms are very fine-grained, they are limited to specific processor resources and cannot provide universal control over access to processor resources. They also have poor scalability.

[0008] Regarding virtualization-based technologies, virtualization mechanisms can also provide fine-grained control over processor resources. Virtualization extensions in modern processors support trap and emulation technology, namely trap-and-emulate technology. Using privileged instructions and touching privileged registers will cause a trap into the virtualization management program, namely the hypervisor. The hypervisor can then check whether the current permission domain allows the execution of the instruction or the access to the register.

[0009] There are two disadvantages of the virtualization method: First, this capture needs to be trapped to a higher privilege level for processing, which has many cycles of delay. Even an empty virtualization call requires about 1700 cycles, and the privilege check after the trap is implemented by the virtualization manager, which is not hardware optimized, resulting in performance problems. Second, for non-sensitive instructions and registers, that is, instructions and registers that cannot be captured by the virtual machine monitor, such as Intel MPK and Intel PKS related instructions, the virtualization method cannot provide control, which leads to the limitations of the virtualization mechanism.

[0010] Regarding the technology based on software rewriting, the software rewriting-based method scans the binary file to find possible illegal permission instructions, and rewrites and replaces them to achieve fine-grained processor resource control. ERIM attempts to use binary scanning and rewriting to remove malicious wrpkru instructions. This process is complicated because directly rewriting binary code requires code disassembly, and the new instruction sequence may be longer than the original instruction sequence. Therefore, the control flow instructions must also be rewritten. Methods such as ERIM do not prove the correctness and completeness of the rewriting strategy.

[0011] From the above solutions, it can be seen that the current processor resource isolation solution has the disadvantages of coarse isolation granularity, poor scalability, and high runtime overhead, which is not enough to ensure the security of the system. In order to implement the principle of least privilege, a solution with finer isolation granularity is needed; in order to adapt to the huge scale and rapid changes of processor resources, a solution with higher scalability and better flexibility is needed; in order to reduce isolation costs, a solution with lower runtime overhead is needed.

[0012] Patent document CN116644414A discloses a processing method, system, electronic system and storage medium. The processing method of the scheme includes: providing a first execution domain in the system, wherein the first execution domain runs in a first mode and serves as an operating environment for a security monitor; the first mode is a machine mode in a non-extended situation; creating at least one second execution domain in the system, wherein each second execution domain runs based on the first execution domain and runs in a correspondingly set second mode, wherein the permissions of the second mode are lower than those of the machine mode. The scheme can provide a rich privileged mode for the execution domain, thereby facilitating the construction of a flexible and rich security business model. However, it cannot reduce the isolation cost and solve the problem of low flexibility. This problem needs to be solved urgently. Summary of the invention

[0013] In view of the defects in the prior art, the object of the present invention is to provide a permission domain management method and system for multi-privilege level processor resources.

[0014] A permission domain management method for multi-privilege level processor resources provided by the present invention includes: an instruction inspection step, a register read and write inspection step, a register bit field write inspection step, and a startup initialization step;

[0015] According to the ISA-Context, a startup initialization step is performed to obtain the ID of the current permission domain; according to the ID of the current permission domain, an instruction verification step is performed; according to the ID of the current permission domain, a register read and write verification step is performed; according to the ID of the current permission domain, a register bit field write verification step is performed.

[0016] Preferably, the ISA-Context is a processor resource permission context; the ISA-Context includes an ID register, HPT and SGT of a current permission domain; the permission domain is a set of permissions;

[0017] The startup initialization step includes:

[0018] Step D1: According to ISA-Context, reset the processor and set the permission domain to Domain-0;

[0019] Step D2: Create a permission domain and a conversion gate of the conversion gate, and switch the conversion gate to the Domain-0, and enter the entrance of the registration function through the permission domain; the function is used to create a domain and a gate;

[0020] Step D3: Create a gate capable of entering Domain-Basic according to the function;

[0021] Step D4: Switch to Domain-Basic; the Domain-Basic is the basic permission domain; the basic permission domain is the set of permissions required to execute the target task.

[0022] Preferably, the instruction checking step comprises:

[0023] Step A1: Read the ID of the current authority domain; the current authority domain is the basic authority domain;

[0024] Step A2: Retrieve the corresponding bitmap in the HPT from the bit array according to the ID; the bitmap is the instruction permission bitmap of the current permission domain;

[0025] Step A3: query the corresponding permission bit according to the bitmap; determine whether the permission bit is 1, if yes, mark the instruction to be detected as "instruction permission check passed"; if no, throw a hardware exception.

[0026] Preferably, the register read and write verification step includes:

[0027] Step B1: Read the ID of the current authority domain; the current authority domain is the basic authority domain;

[0028] Step B2: According to the ID of the permission domain, retrieve the corresponding bitmap in the HPT from the bitmap array;

[0029] Step B3: Retrieve the corresponding permission bit in the bitmap according to the index of the register to be tested, and determine whether the permission bit is 1. If the result is yes, mark "register read and write check permission passed"; if the result is no, throw a hardware exception;

[0030] The register bit field write verification step includes:

[0031] Step C1: Read the ID of the current authority domain; the current authority domain is the basic authority domain;

[0032] Step C2: Retrieve the corresponding mask array and the mask corresponding to the register to be detected according to the ID of the permission domain;

[0033] Step C3: Let the original value of the register to be detected be V0, and let the value to be written into the register to be detected be V w , let the mask value of the register to be detected be M, and judge Is it equal to zero? If the result is yes, the test succeeds; if the result is no, the test fails and a hardware exception is thrown. means no; ∧ means and; ⊕ means exclusive or.

[0034] Preferably, the ISA-Context management steps include:

[0035] Step E1: Enter the fork function and create the ISA-Context of the child process;

[0036] Step E2: Prepare the ISA-Context of the child process using the ISA-Context of the parent process as a template;

[0037] Step E3: Execute the exec function or the switch function; if the exec function is executed, the ISA-Context is reset, that is, the existing permission domain and the switch gate are cancelled, and only a basic permission domain is retained; if the switch function is executed, the registers related to the ISA-Context of the previous process are saved to the thread_struct, and the related registers are restored from the thread_struct of the next process;

[0038] In the step E3, the ISA-Context related registers of the previous process, namely the base address register of HPT, the base address register of SGT and the cur_domain register;

[0039] In step E3, when the process is destroyed, Domain-U is made to recycle and clear the ISA-Context related to the process;

[0040] The Domain-U is used to manage the Domain in the ISA-Context; the Domain is the authority domain.

[0041] According to the present invention, a permission domain management system for multi-privilege level processor resources includes: an instruction inspection module, a register read and write inspection module, a register bit field write inspection module, and a startup initialization module;

[0042] According to ISA-Context, the startup initialization module is triggered to obtain the ID of the current permission domain; according to the ID of the current permission domain, the instruction verification module is triggered to work; according to the ID of the current permission domain, the register read and write verification module is triggered to work; according to the ID of the current permission domain, the register bit field write verification module is triggered to work.

[0043] Preferably, the ISA-Context is a processor resource permission context; the ISA-Context includes an ID register, HPT and SGT of a current permission domain; the permission domain is a set of permissions;

[0044] The startup initialization module includes:

[0045] Module D1: According to ISA-Context, reset the processor and set the permission domain to Domain-0;

[0046] Module D2: Create a permission domain and a conversion gate of the conversion gate, and switch the conversion gate to the Domain-0, and enter the entrance of the registration function through the permission domain; the function is used to create a domain and a gate;

[0047] Module D3: Create a gate capable of entering Domain-Basic according to the function;

[0048] Module D4: Switch to Domain-Basic; Domain-Basic is the basic permission domain; the basic permission domain is the set of permissions required to execute the target task.

[0049] Preferably, the instruction checking module comprises:

[0050] Module A1: Read the ID of the current permission domain; the current permission domain is the basic permission domain;

[0051] Module A2: Retrieve the corresponding bitmap in the HPT from the bit array according to the ID; the bitmap is the instruction permission bitmap of the current permission domain;

[0052] Module A3: query the corresponding permission bit according to the bitmap; determine whether the permission bit is 1, if the result is yes, mark the instruction to be detected as "instruction permission check passed"; if the result is no, throw a hardware exception.

[0053] Preferably, the register read-write verification module includes:

[0054] Module B1: Read the ID of the current permission domain; the current permission domain is the basic permission domain;

[0055] Module B2: Retrieve the corresponding bitmap in the HPT from the bitmap array according to the ID of the permission domain;

[0056] Module B3: retrieve the corresponding permission bit in the bitmap according to the index of the register to be tested, and determine whether the permission bit is 1. If the result is yes, mark "register read and write check permission passed"; if the result is no, throw a hardware exception;

[0057] The register bit field write verification module includes:

[0058] Module C1: read the ID of the current permission domain; the current permission domain is the basic permission domain;

[0059] Module C2: retrieve the corresponding mask array and the mask corresponding to the register to be detected according to the ID of the permission domain;

[0060] Module C3: Let the original value of the register to be detected be V0, and let the value to be written into the register to be detected be V w , let the mask value of the register to be detected be M, and judge Is it equal to zero? If the result is yes, the test succeeds; if the result is no, the test fails and a hardware exception is thrown. means no; ∧ means and; ⊕ means exclusive or.

[0061] Preferably, it also includes: an ISA-Context management module, including:

[0062] Module E1: Enter the fork function and create the ISA-Context of the child process;

[0063] Module E2: Prepare the ISA-Context of the child process using the ISA-Context of the parent process as a template;

[0064] Module E3: Execute the exec function or the switch function; if the exec function is executed, the ISA-Context is reset, that is, the existing permission domain and switch gate are cancelled, and only a basic permission domain is retained; if the switch function is executed, the ISA-Context-related registers of the previous process are saved to the thread_struct, and the related registers are restored from the thread_struct of the next process;

[0065] In the module E3, the ISA-Context related registers of the previous process, namely the base address register of HPT, the base address register of SGT and the cur_domain register;

[0066] In the module E3, when a process is destroyed, Domain-U is made to recycle and clear the ISA-Context related to the process;

[0067] The Domain-U is used to manage the Domain in the ISA-Context; the Domain is the authority domain.

[0068] Compared with the prior art, the present invention has the following beneficial effects:

[0069] 1. The present invention uses permission domains to isolate processor resources, that is, there are multiple permission domains, specifically 256 permission domains, and resources are isolated at the granularity of a single instruction or register bit field in each permission domain, so that the granularity of processor resource permission isolation is finer.

[0070] 2. The present invention uses a bitmap to describe the permission domain, and is configurable at runtime. It can provide isolation for up to 512 instructions and 512 registers, so it can meet the needs of large-scale and rapidly growing processor resources and implement a highly flexible and scalable isolation solution.

[0071] 3. The present invention uses a hardware detection unit to monitor the pipeline and uses Cache to optimize memory access, with acceptable performance overhead; specifically, on the test platform, the switch of the permission domain requires 30 cycles, which saves 2000% of the time overhead compared to the more than 600 cycles required for the traditional privilege level switch. In the real scene test, compared with the non-isolation, it will introduce less than 5% performance overhead. BRIEF DESCRIPTION OF THE DRAWINGS

[0072] Other features, objects and advantages of the present invention will become more apparent from the detailed description of non-limiting embodiments made with reference to the following drawings:

[0073] Figure 1 A schematic diagram of the system provided by the present invention;

[0074] Figure 2 A schematic diagram of the instruction inspection process provided by the present invention;

[0075] Figure 3 A schematic diagram of a register read and write test flow provided by the present invention;

[0076] Figure 4 A schematic diagram of a register bit field write check process provided by the present invention;

[0077] Figure 5 A schematic diagram of the startup initialization process provided by the present invention;

[0078] Figure 6 A schematic diagram of the ISA-Context management process provided by the present invention. DETAILED DESCRIPTION

[0079] The present invention is described in detail below in conjunction with specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but are not intended to limit the present invention in any form. It should be noted that, for those of ordinary skill in the art, several changes and improvements can also be made without departing from the concept of the present invention. These all belong to the protection scope of the present invention.

[0080] The core innovations and subordinate innovations of the present invention include:

[0081] Core innovation 1: Hardware mechanism applicable to multiple privilege levels;

[0082] Subordinate innovation point 1.1: Different privilege levels correspond to different register groups.

[0083] Subordinate innovation point 1.2: Functional units PCU and DSU will perform corresponding functions according to their privilege levels.

[0084] Subordinate innovation point 1.3: Kernel state and user state correspond to different trusted memories.

[0085] Core innovation 2: Software and hardware collaborative rights management architecture;

[0086] Subordinate innovation 2.1: The hardware extends the ISA to provide the isacall jump instruction and related registers.

[0087] Subordinate Innovation 2.2: The hardware provides Domain-0 as a permission domain that can directly access trusted memory.

[0088] Subordinate Innovation 2.3: Software developers use isacall and privilege domains to isolate software into components with different processor resource privileges and switch them securely.

[0089] Subordinate Innovation 2.4: Software developers use Domain-0 to proxy the registration and configuration of other permission domains and switch gates.

[0090] Subordinate Innovation 2.5: Software developers maintain ISA-Context abstraction during the process declaration lifecycle.

[0091] Permission domain, which is a collection of permissions;

[0092] The basic permission domain is the set of permissions required to perform the target task.

[0093] The key points of protection of the claims of the present invention include:

[0094] A hardware mechanism that supports multiple privilege levels, including independent register groups corresponding to different privilege levels, and a hardware unit that implements corresponding functional adjustments according to changes in privilege levels, and is suitable for trusted memory at different privilege levels.

[0095] Definitions of Abbreviations and Key Terms:

[0096] Processor resources, or ISA resources: hardware resources represented by the interface between the computer processor and the program, including instruction resources and register resources. Instruction set resources vary depending on the architecture instruction set. Processor resource vulnerabilities can lead to serious computer system security issues.

[0097] The principle of least privilege, or PoLP, is a design principle in information security, computer science, and other fields that requires that in a specific abstraction layer of a computing environment, each module, such as a process, user, or program, can access only the information and resources required for its legitimate purpose.

[0098] The method proposed in the present invention can effectively solve the problems encountered in previous solutions, including:

[0099] 1. The coarse-grained problem of processor resource management: processor resources are isolated only by a limited number of privilege levels, and each privilege level corresponds to a large number of processor resources, which does not conform to the principle of the least privilege level. Once the attack is successful, it will lead to the leakage of a large number of resources.

[0100] 2. Scalability of management mechanisms: Processor resources are large and change rapidly. Technologies targeting specific processor resources will soon be obsolete when processor resources evolve with architecture iterations.

[0101] 3. Isolation and management of permission domain overhead: Technologies based on virtualization or software rewriting will have a lot of pre-processing or running overhead, which leads to a narrow application of these technologies.

[0102] The present invention proposes a permission domain management architecture for processor resources with software and hardware collaboration. This architecture can provide fine-grained permission control and a secure domain switching method for processor resources in user mode and kernel mode, including instruction and register resources. While providing a fine-grained isolation mechanism for processor resources, it has an acceptable performance overhead.

[0103] The specific device embodiment of the present invention is as follows Figure 1 It has two main functions: to perform permission check and switch between different permission domains. Structurally, it can be divided into four parts: Privilege Check Unit, PCU for short, Domain Switch Unit, DSU for short, Trust Memory, and software coordination part.

[0104] Permission checking unit, or PCU: checks the processor resources involved in each instruction in the CPU pipeline. The use of processor resources must comply with the provisions of the permission domain in which the software is currently located. If an instruction accesses processor resources that are prohibited by the current permission domain, the PCU will throw a hardware exception after detecting it.

[0105] Domain Switching Unit, or DSU: Provides secure, unforgeable permission domain switching for this architecture. When the software uses the domain switching instruction of this architecture, DSU will perform domain switching according to the switching gate specified in the instruction, and will perform relevant tests before switching to determine whether the switch is safe. If the test fails, then DSU will throw a hardware exception.

[0106] Software collaboration: This architecture is applicable to kernel-mode and user-mode permission management. The implementation of hardware functions requires the collaboration of software. Each process in user mode has different permission configurations and switching schemes. The operating system needs to maintain these contexts to ensure the correct operation of hardware component functions.

[0107] Trusted memory: records the processor resource permission domain configuration information and switching metadata of the framework. Under normal circumstances, entities other than the PCU and DSU are prohibited from accessing this memory, ensuring the security and credibility of the data.

[0108] This section will elaborate on the specific implementation of each module in the present invention:

[0109] Regarding the permission check unit PCU, the PCU's inspection is divided into instruction inspection and register inspection. Each instruction needs to pass the PCU's permission inspection after entering the pipeline. Specifically, each instruction will send its own instructions and the register information used to the PCU in the Fetch stage, and the PCU will use this information to perform permission inspection. If the permission check is completed and passed, the instruction will be marked as "passed", and if the permission check fails, a hardware exception will be thrown.

[0110] For register verification, there are two granularities: overall read and write verification and bit field write verification. The former is used to verify whether the register as a whole is readable and writable, and the latter is used to verify whether each bit field of the register has write permission. For register bit field write verification, the PCU uses a mask two-dimensional array to record the write permission of register bit fields under different permission domains. Each register that requires bit field access control corresponds to a mask of the same length. This mask indicates which bit fields in this register can be modified. Setting the bits in the mask will make the corresponding bits in the corresponding register modifiable.

[0111] The reason for starting the detection in the Fetch stage and confirming the detection results in the Commit stage is to make full use of the time difference caused by the difference in pipeline levels to provide enough time for permission detection. At the same time, most detection functions can complete the inspection using only the instruction machine code obtained in the Fetch stage, and do not need more information provided by the later pipeline stages.

[0112] The permission information that the PCU test relies on is described in the form of a bitmap. Instruction testing requires the use of instruction permission bitmaps, each bit of which indicates whether a certain instruction has execution permission in the current permission domain; register testing requires the use of register read permission bitmaps, register write permission bitmaps, and register bit field bitmaps, which respectively indicate whether a certain register has read permission, write permission, and write permission for a specific bit field in the current permission domain.

[0113] These permission bitmaps are collectively called the hybrid permission table, namely the Hyperid Privilege Table, or HPT for short, which is stored in trusted memory.

[0114] Regarding the Domain Switching Unit (DSU), the Domain Switching Unit provides an unforgeable permission domain switching method to enhance security when domains change. This method provides developers with domain switching instructions and ensures that:

[0115] 1. The injected malicious domain switching instructions cannot be used to switch the authority domain.

[0116] 2. Maliciously constructed domain switching instructions cannot switch permission domains.

[0117] 3. Valid switching instructions cannot be abused to switch to any permission domain.

[0118] DSU achieves these security goals by allowing software to register multiple unforgeable switching gates. Each gate corresponds to a legal switch to a permission domain. The Switching Gate Table, or SGT, is used to store all registered gates. The gates have the following characteristics:

[0119] 1. Each door can only be called at a fixed address.

[0120] 2. Each gate jumps to a fixed address.

[0121] 3. Each gate switches to a fixed authority domain.

[0122] 4. Unregistered doors are not allowed to be used.

[0123] DSU provides software developers with a dedicated domain switching instruction isacall. isacall uses a specific switching gate to change the domain and transfer the control flow to a pre-registered target address. isacall itself can be executed by all privileged domains. However, before using it, any gate must be registered first. For the registration of a gate, the corresponding entry in SGT needs to be configured. Each entry in SGT contains a gate address, target address, and target domain of a gate. The entry index of the gate is also used as its gate ID. Each isacall instruction must specify the gate ID it needs at runtime.

[0124] Regarding software collaboration, the hardware units in this architecture require the collaboration of upper-layer software to function properly. This is mainly reflected in two aspects:

[0125] The first point: initialization and configuration of rights metadata; the rights metadata includes: HPT and SGT.

[0126] The second point: switching between different processor permission contexts.

[0127] Use the special permission domain Domain-0 to complete the initial configuration of HPT and SGT. Other permission domains must configure permission metadata through the proxy of Domain-0. Limiting only one permission domain to configure permission metadata can reduce the attack surface and comply with the principle of least privilege.

[0128] When the processor restarts, it automatically enters Domain-0. No permission check is performed in this permission domain. The software needs to complete the initialization of Argus in this domain. Initialization includes opening up a trusted address space and writing the correct values ​​to the relevant registers. In addition, Domain-0 also needs to create conversion gates for registering new permission domains and conversion gates. These gates switch to Domain-0 and jump to the entry of the registration function, which is used to create domains and gates. This gate is valid for all kernel components, allowing them to call it for registration.

[0129] User processes do not have Domain-0 or an initial permission domain similar to Domain-0. Instead, system calls are used to let the kernel proxy exercise the function of registering and configuring relevant permission data structures. The proxy permission domain in the kernel, which this framework calls Domain-U, is similar to Domain-0 and also has the ability to read and write trusted memory. It should be emphasized that Domain-U only acts as an agent for the registration and configuration of permission domains and switch gates, and does not act as an agent for permission verification and domain switching, so there will be no huge context switching overhead caused by frequent system calls.

[0130] In order to solve the problem of different processor resource isolation requirements for different user processes and kernels, this framework proposes the concept of processor resource permission context, namely ISA-Context. The ISA-Context includes the ID register, HPT and SGT of the current permission domain; each running context, whether it is a kernel or a user process, corresponds to an ISA-Context. Each ISA-Context corresponds to a unique hybrid permission table, namely HPT and domain switch gate table, namely SGT and other data structures. When the system switches context, the software needs to switch ISA-Context accordingly, which allows different processes to use different resource management solutions.

[0131] Trusted Memory refers to a memory area with special protection and security mechanisms, which is used to store and process sensitive security information or data. In this architecture, trusted memory is used to store the processor permission bitmap and switch gate table required for the PCU and DSU to perform normal functions, preventing attackers from stealing and modifying these metadata.

[0132] This architecture uses a clear and architecture-independent design to implement trusted memory. A specific range of physical memory is reserved as trusted memory. Two dedicated registers are used to specify the range and are set in the initialization permission domain. Memory access instructions can only access the trusted memory area in the initialization permission domain, that is, in Domain 0. In other permission domains, only the PCU and DSU can access this memory area, and accessing trusted memory using memory access instructions will trigger an exception. By forcing the trusted memory to be a power of two size and aligned, the boundary checking overhead can be minimized.

[0133] The instruction checking step provided by the present invention includes:

[0134] Step A1: The PCU reads the ID of the current permission domain from the cur_domain register.

[0135] Step A2: The PCU retrieves the corresponding bitmap from the bitmap array according to the ID, that is, the instruction permission bitmap of the current permission domain.

[0136] Step A3: The PCU searches the bitmap for the corresponding permission bit according to the opcode of the instruction to be detected; determines whether the permission bit is 1, and if so, executes step A4; if not, executes step A5.

[0137] Step A4: If the permission bit is 1, it means that the instruction to be detected is allowed to be executed in the current permission domain, and it is marked as "instruction permission check passed";

[0138] Step A5: If the permission bit is 0, it means that the instruction to be detected is not allowed to be executed in the current permission domain, and the PCU throws a hardware exception.

[0139] The register read and write verification step provided by the present invention includes:

[0140] Step B1: The PCU will first determine whether the register to be tested is about to be written or read based on the position of the register in the instruction, which determines which bitmap the PCU uses to complete the test.

[0141] Step B2: The PCU reads the ID of the current permission domain from the cur_domain register.

[0142] Step B3: The PCU retrieves the corresponding bitmap from the bitmap array according to the ID.

[0143] Step B4: The PCU will search the corresponding permission bit in the bitmap according to the index of the register to be detected; determine whether the permission bit is 1. If the result is yes, execute step B5; if the result is no, execute step B6.

[0144] Step B5: If the permission bit is 1, it means that the register to be tested is allowed to read / write in the current permission domain, and it is marked as "register read / write test permission passed;"

[0145] Step B6: If the permission bit is 0, it means that the register to be detected is not allowed to be read / written in the current permission domain, and the PCU throws a hardware exception.

[0146] The register bit field write verification step provided by the present invention includes:

[0147] Step C1: The PCU determines whether the register requires a bit field write check based on the position of the register in the instruction.

[0148] Step C2: PCU reads the ID of the current permission domain from the cur_domain register. The cur_domain register is a register storing the permission domain ID of the current system, corresponding to the DomainID register in the framework diagram.

[0149] Step C3: The PCU finds the corresponding mask array according to the ID of the current permission domain, and finds the mask corresponding to the register to be detected according to the relevant index.

[0150] Step C4: According to the original value of the register to be detected, V0 is written into the register. w , the mask value of the register is M, and the test is performed; Is it equal to zero? If yes, go to step C5; if no, go to step C6.

[0151] Step C5: If The test is successful. means no; ∧ means and; ⊕ means exclusive or.

[0152] Step C6: If If the test fails, the PCU throws a hardware exception.

[0153] The startup initialization step provided according to the present invention includes:

[0154] Step D1: The processor is reset and the permission domain it is in is Domain-0.

[0155] Step D2: Select a piece of physical memory as trusted memory, and set related memory permissions and related registers.

[0156] Specifically, in the specific implementation of the patent, there are two registers that specify the range of trusted memory. By modifying the hardware, domain-0 can directly access this memory using memory access instructions, while other domains must access it through the PCU.

[0157] Step D3: Create transition gates for registering new permission domains and transition gates. These gates switch to Domain-0 and jump to the entry of the registration function; the function is used to create domains and gates. The creation is implemented by a programming language.

[0158] Specifically, in step D3, the information of the conversion gate and domain will be stored in the trusted memory; when performing related operations, that is, when switching the permission domain through the gate, the information stored in the trusted memory will be accessed.

[0159] Step D4: Create a basic permission domain without special permissions for kernel execution, and create a gate to enter the basic permission domain, namely Domain-Basic;

[0160] Step D5: Switch to the basic authority domain by switching the gate.

[0161] The management steps of the ISA-Context include:

[0162] Step E1: Enter the fork function and create the ISA-Context of the child process;

[0163] Step E2: Prepare the ISA-Context of the child process using the ISA-Context of the parent process as a template;

[0164] Step E3: Execute the exec function or the switch function; if the exec function is executed, the ISA-Context is reset, that is, the existing permission domain and the switch gate are cancelled, and only a basic permission domain is retained; if the switch function is executed, the registers related to the ISA-Context of the previous process are saved to the thread_struct, and the related registers are restored from the thread_struct of the next process;

[0165] In the step E3, the ISA-Context related registers of the previous process, namely the base address register of HPT, the base address register of SGT and the cur_domain register;

[0166] In step E3, when the process is destroyed, Domain-U is made to recycle and clear the ISA-Context related to the process;

[0167] The Domain-U is used to manage the Domain in the ISA-Context; the Domain is the authority domain.

[0168] The present invention also provides a permission domain management system for multi-privilege-level processor resources. The permission domain management system for multi-privilege-level processor resources can be implemented by executing the process steps of the permission domain management method for multi-privilege-level processor resources, that is, those skilled in the art can understand the permission domain management method for multi-privilege-level processor resources as a preferred implementation of the permission domain management system for multi-privilege-level processor resources.

[0169] According to the present invention, a permission domain management system for multi-privilege level processor resources includes: an instruction inspection module, a register read and write inspection module, a register bit field write inspection module, and a startup initialization module;

[0170] According to ISA-Context, the startup initialization module is triggered to obtain the ID of the current permission domain; according to the ID of the current permission domain, the instruction verification module is triggered to work; according to the ID of the current permission domain, the register read and write verification module is triggered to work; according to the ID of the current permission domain, the register bit field write verification module is triggered to work.

[0171] In subsequent work, we can explore the privilege level where the virtual machine monitor is located. There are a lot of processor resources under this privilege level, which requires fine-grained isolation. Similarly, when different virtual machines are switched, context maintenance is also required. The virtual machine monitor should be extended to support this part of the function.

[0172] When switching permission domains, consistency issues need to be considered at the microarchitecture level. There are two types of consistency issues that need to be considered. One is the permission domain switching caused by isacall, and the other is the change in permission level, which leads to the selection of different registers. Both of these problems are currently solved in Argus by forced serialization, but forced serialization of out-of-order CPUs will increase performance overhead. In the future, we can consider optimizing them in combination with specific microarchitectures.

[0173] Those skilled in the art know that, in addition to realizing the system and its various devices, modules, and units provided by the present invention in a purely computer-readable program code, it is entirely possible to realize the same functions in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, the system and its various devices, modules, and units provided by the present invention can be considered as a hardware component, and the devices, modules, and units included therein for realizing various functions can also be regarded as structures within the hardware component; the devices, modules, and units for realizing various functions can also be regarded as both software modules for realizing the method and structures within the hardware component.

[0174] The above describes the specific embodiments of the present invention. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. In the absence of conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A permission domain management method for multi-privilege level processor resources, characterized in that: include: Instruction inspection step, register read and write inspection step, register bit field write inspection step, startup initialization step; According to ISA-Context, execute the startup initialization step to obtain the ID of the current permission domain; Execute the instruction verification step according to the ID of the current authority domain; According to the ID of the current permission domain, a register read and write verification step is performed; according to the ID of the current permission domain, a register bit field write verification step is performed.

2. The permission domain management method for multi-privilege level processor resources according to claim 1, characterized in that: The ISA-Context is a processor resource permission context; The ISA-Context includes the ID register, HPT and SGT of the current permission domain; The permission domain is a set of permissions; The startup initialization step includes: Step D1: According to ISA-Context, reset the processor and set the permission domain to Domain-0; Step D2: Create a permission domain and a conversion gate of the conversion gate, and switch the conversion gate to the Domain-0, and enter the entrance of the registration function through the permission domain; the function is used to create a domain and a gate; Step D3: Create a gate capable of entering Domain-Basic according to the function; Step D4: Switch to Domain-Basic; the Domain-Basic is the basic permission domain; the basic permission domain is the set of permissions required to execute the target task.

3. The permission domain management method for multi-privilege level processor resources according to claim 2, characterized in that: The instruction checking step comprises: Step A1: Read the ID of the current authority domain; the current authority domain is the basic authority domain; Step A2: Retrieve the corresponding bitmap in the HPT from the bit array according to the ID; the bitmap is the instruction permission bitmap of the current permission domain; Step A3: query the corresponding permission bit according to the bitmap; determine whether the permission bit is 1, if the result is yes, mark the instruction to be detected as "instruction permission check passed"; if the result is no, throw a hardware exception.

4. The permission domain management method for multi-privilege level processor resources according to claim 2, characterized in that: The register read and write verification step includes: Step B1: Read the ID of the current authority domain; the current authority domain is the basic authority domain; Step B2: According to the ID of the permission domain, retrieve the corresponding bitmap in the HPT from the bitmap array; Step B3: Retrieve the corresponding permission bit in the bitmap according to the index of the register to be tested, and determine whether the permission bit is 1. If the result is yes, mark "register read and write check permission passed"; if the result is no, throw a hardware exception; The register bit field write verification step includes: Step C1: Read the ID of the current authority domain; the current authority domain is the basic authority domain; Step C2: Retrieve the corresponding mask array and the mask corresponding to the register to be detected according to the ID of the permission domain; Step C3: Let the original value of the register to be detected be V0, and let the value to be written into the register to be detected be V w , let the mask value of the register to be detected be M, and judge Is it equal to zero? If the result is yes, the test succeeds; if the result is no, the test fails and a hardware exception is thrown. means no; ∧ means and; Represents exclusive OR.

5. The permission domain management method for multi-privilege level processor resources according to claim 2, characterized in that: The management steps of the ISA-Context include: Step E1: Enter the fork function and create the ISA-Context of the child process; Step E2: Prepare the ISA-Context of the child process using the ISA-Context of the parent process as a template; Step E3: Execute the exec function or the switch function; if the exec function is executed, the ISA-Context is reset, that is, the existing permission domain and the switch gate are cancelled, and only a basic permission domain is retained; if the switch function is executed, the registers related to the ISA-Context of the previous process are saved to the thread_struct, and the related registers are restored from the thread_struct of the next process; In the step E3, the ISA-Context related registers of the previous process, namely the base address register of HPT, the base address register of SGT and the cur_domain register; In step E3, when the process is destroyed, Domain-U is made to recycle and clear the ISA-Context related to the process; The Domain-U is used to manage the Domain in the ISA-Context; the Domain is the authority domain.

6. A permission domain management system for multi-privilege level processor resources, characterized in that: include: Instruction inspection module, register read and write inspection module, register bit field write inspection module, startup initialization module; According to ISA-Context, trigger the initialization module to get the ID of the current permission domain; According to the ID of the current authority domain, trigger the instruction verification module to work; According to the ID of the current permission domain, trigger the register read and write verification module to work; According to the ID of the current permission domain, the register bit field write check module is triggered to work.

7. The permission domain management system for multi-privilege level processor resources according to claim 6, characterized in that: The ISA-Context is a processor resource permission context; The ISA-Context includes the ID register, HPT and SGT of the current permission domain; The permission domain is a set of permissions; The startup initialization module includes: Module D1: According to ISA-Context, reset the processor and set the permission domain to Domain-0; Module D2: Create a permission domain and a conversion gate of the conversion gate, and switch the conversion gate to the Domain-0, and enter the entrance of the registration function through the permission domain; the function is used to create a domain and a gate; Module D3: Create a gate capable of entering Domain-Basic according to the function; Module D4: Switch to Domain-Basic; Domain-Basic is the basic permission domain; the basic permission domain is the set of permissions required to execute the target task.

8. The permission domain management system for multi-privilege level processor resources according to claim 7, characterized in that: The instruction checking module comprises: Module A1: Read the ID of the current permission domain; the current permission domain is the basic permission domain; Module A2: Retrieve the corresponding bitmap in the HPT from the bit array according to the ID; the bitmap is the instruction permission bitmap of the current permission domain; Module A3: query the corresponding permission bit according to the bitmap; determine whether the permission bit is 1, if the result is yes, mark the instruction to be detected as "instruction permission check passed"; if the result is no, throw a hardware exception.

9. The permission domain management system for multi-privilege level processor resources according to claim 7, characterized in that: The register read-write verification module comprises: Module B1: Read the ID of the current permission domain; the current permission domain is the basic permission domain; Module B2: Retrieve the corresponding bitmap in the HPT from the bitmap array according to the ID of the permission domain; Module B3: retrieve the corresponding permission bit in the bitmap according to the index of the register to be tested, and determine whether the permission bit is 1. If the result is yes, mark "register read and write check permission passed"; if the result is no, throw a hardware exception; The register bit field write verification module includes: Module C1: read the ID of the current permission domain; the current permission domain is the basic permission domain; Module C2: retrieve the corresponding mask array and the mask corresponding to the register to be detected according to the ID of the permission domain; Module C3: Let the original value of the register to be detected be V0, and let the value to be written into the register to be detected be V w , let the mask value of the register to be detected be M, and judge Is it equal to zero? If the result is yes, the test succeeds; if the result is no, the test fails and a hardware exception is thrown. means no; ∧ means and; ⊕ means exclusive or.

10. The permission domain management system for multi-privilege level processor resources according to claim 6, characterized in that: Also includes: ISA-Context management modules include: Module E1: Enter the fork function and create the ISA-Context of the child process; Module E2: Prepare the ISA-Context of the child process using the ISA-Context of the parent process as a template; Module E3: Execute the exec function or the switch function; if the exec function is executed, the ISA-Context is reset, that is, the existing permission domain and switch gate are cancelled, and only a basic permission domain is retained; if the switch function is executed, the ISA-Context-related registers of the previous process are saved to the thread_struct, and the related registers are restored from the thread_struct of the next process; In the module E3, the ISA-Context related registers of the previous process, namely the base address register of HPT, the base address register of SGT and the cur_domain register; In the module E3, when a process is destroyed, Domain-U is made to recycle and clear the ISA-Context related to the process; The Domain-U is used to manage the Domain in the ISA-Context; the Domain is the authority domain.

Images