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

Abstract

The application provides a permission domain management method and system for a multi-privilege-level processor resource, which comprises the following steps: an instruction verification step, a register read-write verification step, a register bit field write verification step, and a start initialization step; the start initialization step is performed according to an ISA-Context, and the ID of a current permission domain is obtained; the instruction verification step is performed according to the ID of the current permission domain; the register read-write verification step is performed according to the ID of the current permission domain; and the register bit field write verification step is performed according to the ID of the current permission domain. The application uses permission domains to isolate the processor resources, that is, multiple permission domains, specifically 256 permission domains, exist, and the resources are isolated in the granularity of a single instruction or a register bit field in each permission domain, so that the granularity of the processor resource permission isolation is finer.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of network security, and specifically relates to a privilege domain management method and system for multi-privilege-level processor resources. BACKGROUND

[0002] With the continuous emergence and development of network attacks, identity theft and malicious software, computer security problems have become an important problem that enterprises and individuals must face. Computers need a reliable computing environment to ensure the security, integrity and reliability of sensitive data, and to ensure that the process and results of program execution cannot be exploited and stolen by hackers.

[0003] Isolation is a basic mechanism in the field of computer security. By dividing software into different privilege domains and limiting their access to different resources, the scope of attack propagation can be reduced, and the damage that malicious software and unavoidable system vulnerabilities can cause to the system can be reduced. The isolation mechanism also provides a more trusted and secure operating environment for the system. The security of sensitive operations and critical data of the system can be ensured by placing them in an isolated environment for processing.

[0004] Processor resources, i.e. ISA resources, i.e. instruction resources and register resources, are important hardware resources that affect system security. Processor resource vulnerabilities can be exploited by hackers and launched a variety of attacks, including tampering with secure memory, stealing sensitive data from secure enclaves, and gaining access to higher privilege level data.

[0005] Existing hardware usually only provides a coarse-grained isolation mechanism based on privilege levels, and the risk of being attacked and the loss after being attacked are relatively high. Taking 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 in the same privilege level. In EL1, i.e. kernel mode, there are more than 100 instructions and registers that can be used for system control. A macro-kernel operating system composed of multiple modules, such as Linux, all run in kernel mode, and any vulnerable module can cause all registers and instructions in the kernel mode to be accessed by attackers, causing incalculable losses.

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

[0007] Processor vendors are aware of the importance of processor resources for system security, and they implement some protection mechanisms on CPU for specific registers or instructions. For example, to mitigate CPU frequency and voltage based side-channel attacks, Intel added patches in BIOS and CPU microcode to allow users to configure whether to allow software to access MS R0x150 register. But such mechanisms, although fine-grained, are limited to specific processor resources and cannot make universal control of processor resources, and have poor scalability.

[0008] Regarding virtualization-based techniques, virtualization mechanisms can also provide fine-grained control of processor resources. The virtualization extensions in modern processors support trap-and-emulate technology. Using privileged instructions and accessing privileged registers will cause an inner into the hypervisor. Then, the hypervisor can check whether the current privilege 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 inner into a higher privilege level for processing, which has a delay of many cycles, even an empty virtualization call needs about 1700 cycles, and the privilege check after the inner is implemented by the virtualization management program, which is not optimized by hardware, causing performance problems. Second, for non-sensitive instructions and registers, that is, instructions and registers that the virtual machine monitor cannot capture, such as Intel MPK and Intel PKS related instructions, the virtualization method cannot provide control, which leads to the limitation of the virtualization mechanism.

[0010] Regarding software rewriting-based techniques, software rewriting-based methods find possible illegal permission instructions by scanning binary files, and replace them to achieve fine-grained processor resource control. ERIM attempts to use binary scanning and rewriting to remove malicious wrpkru instructions. This process is complex because direct rewriting of binary code requires code disassembly, and the new instruction sequence may be longer than the original instruction sequence. Therefore, control flow instructions must also be rewritten. The ERIM method does not prove the correctness and integrity of the rewriting strategy.

[0011] As can be seen from the above solutions, the current processor resource isolation scheme has the disadvantages of coarse isolation granularity, poor scalability, and large runtime overhead, which is not sufficient to guarantee the security of the system. In order to implement the principle of least privilege, a finer isolation granularity scheme is needed; in order to adapt to the huge scale and rapid changes of processor resources, a higher scalability and better flexibility scheme is needed; in order to reduce the isolation cost, a smaller runtime overhead scheme is needed.

[0012] Patent document CN116644414A discloses a processing method, system, electronic system and storage medium. The processing method of the scheme comprises: providing a first execution domain in the system, wherein the first execution domain runs in a first mode and serves as a running environment of a security monitor; the first mode is a machine mode in a non-expansion case; creating at least one second execution domain in the system, wherein each second execution domain is run based on the first execution domain and runs in a corresponding set second mode, wherein the authority of the second mode is lower than that of the machine mode. The scheme can provide rich privilege modes for execution domains, thereby facilitating the construction of flexible and rich security business models. However, it cannot reduce the isolation cost and solve the problem of low flexibility. This problem needs to be solved urgently. SUMMARY

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

[0014] According to the privilege domain management method for multi-privilege level processor resources provided by the present application, the method comprises: an instruction verification step, a register read-write verification step, a register bit field write verification step, and a start initialization step.

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

[0016] Preferably, the ISA-Context is a processor resource privilege context; the ISA-Context comprises an ID register of the current privilege domain, an HPT and an SGT; and the privilege domain is a set of authorities.

[0017] The start initialization step comprises:

[0018] Step D1: according to the ISA-Context, reset the processor to make the privilege domain Domain-0;

[0019] Step D2: create a translation gate of the privilege domain and the translation gate, and switch the translation gate to the Domain-0 to enter the entry of the registration function through the privilege domain; the function is used to create the domain and the gate.

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

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

[0022] Preferably, the instruction verification 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 bitmap array according to the ID; the bitmap is the instruction permission bitmap of the current authority domain;

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

[0026] Preferably, the register read-write verification step comprises:

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

[0028] Step B2: Retrieve the corresponding bitmap in the HPT from the bitmap array according to the ID of the authority domain;

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

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

[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 to-be-detected register according to the ID of the authority domain;

[0033] Step C3: Let the original value of the to-be-detected register be V0, let the value of the to-be-detected register that is about to be written be V w , and let the mask value of the to-be-detected register be M, determine whether it is equal to zero, and if yes, the verification is successful; if no, the verification fails, and a hardware exception is thrown; wherein, indicates no; ∧ indicates and; ⊕ indicates XOR.

[0034] Preferably, the ISA-Context management step comprises:

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

[0036] Step E2: prepare the ISA-Context of the child process by taking 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, reset the ISA-Context, i.e. cancel the existing permission domain and switching gate, and only keep a basic permission domain; if the switch function is executed, save the ISA-Context related registers of the previous process into the thread_struct, and restore the related registers from the thread_struct of the next process;

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

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

[0040] The Domain-U is used for managing the Domain in the ISA-Context; the Domain is a permission domain.

[0041] According to the application, a permission domain management system for a multi-privilege level processor resource is provided, which comprises an instruction verification module, a register read-write verification module, a register bit field write verification module, and a start initialization module.

[0042] According to the ISA-Context, the start initialization module is triggered to work 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-write verification module is triggered to work; and 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 comprises the ID register of the current permission domain, the HPT and the SGT; and the permission domain is a set of permissions.

[0044] The start initialization module comprises:

[0045] Module D1: according to the ISA-Context, reset the processor, and make the privilege domain Domain-0;

[0046] Module D2: create a translation gate of the privilege domain and the translation gate, and switch the translation gate to the Domain-0, and enter the entry of a register function through the privilege domain; the function is used for creating a domain and a gate;

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

[0048] Module D4: switch to the Domain-Basic; the Domain-Basic is a basic privilege domain; the basic privilege domain is a set of privileges required for executing a target task.

[0049] Preferably, the instruction checking module comprises:

[0050] Module A1: read the ID of the current privilege domain; the current privilege domain is a basic privilege domain;

[0051] Module A2: according to the ID, retrieve the corresponding bit map in the HPT from the bit array; the bit map is an instruction privilege bit map of the current privilege domain;

[0052] Module A3: according to the bit map, query the corresponding privilege bit; determine whether the privilege bit is 1, and if yes, mark the to-be-detected instruction as “instruction privilege checking passed”; if no, throw a hardware exception.

[0053] Preferably, the register read-write checking module comprises:

[0054] Module B1: read the ID of the current privilege domain; the current privilege domain is a basic privilege domain;

[0055] Module B2: according to the ID of the privilege domain, retrieve the corresponding bit map in the HPT from the bit map array;

[0056] Module B3: according to the index of the to-be-detected register, retrieve the corresponding privilege bit in the bit map, and determine whether the privilege bit is 1, and if yes, mark “register read-write checking privilege passed”; if no, throw a hardware exception;

[0057] The register bit field write checking module comprises:

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

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

[0060] Module C3: let the original value of the to-be-detected register be V0, let the value of the value to be written into the to-be-detected register be V w , let the mask value of the to-be-detected register be M, judge whether V0 is equal to zero, and the result is yes, then the test is successful, and the result is no, then the test fails, and a hardware exception is thrown, wherein, represents no, represents and, and represents XOR.

[0061] Preferably, it further comprises a management module of the ISA-Context, comprising:

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

[0063] Module E2: prepare the ISA-Context of the child process by taking 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 the switching gate are cancelled, and only a basic permission domain is reserved; if the switch function is executed, the ISA-Context-related registers of the previous process are saved into the thread_struct, and the related registers are recovered from the thread_struct of the next process;

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

[0066] In the module E3, when the process is destroyed, the Domain-U recycles and empties the ISA-Context related to the process;

[0067] The Domain-U is used for managing the Domain in the ISA-Context, and the Domain is a permission domain.

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

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

[0070] 2、The application uses bitmap to describe the permission domain, and is runtime configurable, and can provide isolation for 512 instructions and 512 registers at most, so that the large and rapidly developing processor resource can be satisfied, and the high flexibility and high expansibility isolation scheme can be implemented.

[0071] 3、The application uses the hardware detection unit to monitor the pipeline and uses the Cache to optimize the memory access, and has acceptable performance overhead, specifically, the switching of the permission domain needs 30 cycles on the test platform, compared with more than 600 cycles needed by the traditional privilege level switching, 2000% of time overhead is saved, and in the real scene test, compared with the non-isolation, less than 5% of performance overhead is introduced. BRIEF DESCRIPTION OF DRAWINGS

[0072] Other characteristics, objects and advantages of the application will become more apparent after reading the following detailed description of non-restrictive embodiments with reference to the following drawings:

[0073] Figure 1 The system schematic diagram provided by the application is shown in the figure;

[0074] Figure 2 The instruction verification flowchart provided by the application is shown in the figure;

[0075] Figure 3 The register read-write verification flowchart provided by the application is shown in the figure;

[0076] Figure 4 The register bit field write verification flowchart provided by the application is shown in the figure;

[0077] Figure 5 The start initialization flowchart provided by the application is shown in the figure;

[0078] Figure 6 The ISA-Context management flowchart provided by the application is shown in the figure. DETAILED DESCRIPTION

[0079] The application will be described in detail below with reference to specific embodiments. The following embodiments will help those skilled in the art to further understand the application, but do not limit the application in any form. It should be pointed out that, for those skilled in the art, without departing from the concept of the application, a number of changes and improvements can be made. These all belong to the protection scope of the application.

[0080] The core innovation points and dependent innovation points of the application include:

[0081] Core innovation point 1: the hardware mechanism suitable for multiple privilege levels;

[0082] Dependent innovative point 1.1: Different register groups correspond to different privilege levels.

[0083] Dependent innovative point 1.2: The function units PCU and DSU exercise corresponding functions according to the privilege level they are in.

[0084] Dependent innovative point 1.3: The kernel state and the user state correspond to different trusted memories respectively.

[0085] Core innovative point 2: A hardware-software collaborative permission management architecture.

[0086] Dependent innovative point 2.1: The hardware extends the ISA to provide the isacall jump instruction and related registers.

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

[0088] Dependent innovative point 2.3: Software developers use isacall and permission domains to isolate software into components with different processor resource permissions and securely switch between them.

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

[0090] Dependent innovative point 2.5: Software developers maintain the ISA-Context abstraction during the process declaration cycle.

[0091] Permission domain, i.e. a set of permissions.

[0092] Basic permission domain, i.e. a set of permissions required to perform a target task.

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

[0094] A hardware mechanism supporting multiple privilege levels, including independent register groups corresponding to different privilege levels, hardware units that adjust functions according to changes in privilege levels, and trusted memories suitable for different privilege levels.

[0095] Abbreviations and key terms:

[0096] Processor resource, i.e. ISA Resource: the hardware resources represented by the interface between computer processors and programs, including instruction resources and register resources. Instruction set resources differ due to differences in architecture instruction sets. Processor resource vulnerabilities can cause serious computer system security problems.

[0097] The Principle of Least Privilege, or PoLP for short, is a design principle in information security, computer science, and other fields. It requires that in a particular abstraction layer of a computing environment, each module, such as a process, user, or program, can only access the information and resources necessary for its legitimate purpose.

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

[0099] 1. Coarse granularity problem of processor resource management: Only relying on a limited number of privileged levels to isolate processor resources, each privileged level corresponds to a large number of processor resources, which does not comply with the principle of least privilege. Once successfully attacked, it will lead to a large amount of resource leakage.

[0100] 2. Scalability problem of management mechanism: Processor resources are large in scale and change rapidly. Techniques specific to processor resources will soon be eliminated when processor resources change with architecture iteration.

[0101] 3. Isolation and management of permission domain overhead: Techniques based on virtualization or software rewriting will have a lot of preprocessing or running overhead. This leads to a narrow application of these techniques.

[0102] The present application proposes a hardware-software collaborative permission domain management architecture for processor resources. This architecture provides fine-grained permission control and secure domain switching methods for user-mode and kernel-mode processor resources, including instruction and register resources. While providing a fine-grained isolation mechanism for processor resources, it has acceptable performance overhead.

[0103] The specific device embodiment of the present application is shown in Figure 1 It has two main functions: permission checking and switching between different permission domains. Structurally, it can be divided into four parts: Privilege Check Unit (PCU), Domain Switch Unit (DSU), Trust Memory, and software collaboration part.

[0104] Privilege Check Unit (PCU): Detects each instruction in the CPU pipeline that involves processor resources. The use of processor resources must comply with the regulations of the permission domain in which the software currently resides. If the instruction accesses processor resources prohibited by the current permission domain, the PCU will throw a hardware exception after detection.

[0105] Domain Switch Unit, DSU: provides secure, non-forged domain switching function for the architecture. When the software uses the domain switching instruction of the architecture, the DSU will switch the domain according to the switching gate specified in the instruction, and will also perform related detection before switching to determine whether the switching is safe. If the detection does not pass, the DSU will throw a hardware exception.

[0106] Software Cooperation: The architecture is suitable for permission management in the kernel state and the user state, and the implementation of the hardware function needs the cooperation of the software. Each process in the user state has different permission configuration and switching scheme, and the operating system needs to maintain these contexts to ensure the correct operation of the hardware element function.

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

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

[0109] Regarding the permission detection unit PCU, the PCU inspection includes instruction inspection and register inspection. Each instruction entering the pipeline needs to pass through the permission detection of the PCU. Specifically, each instruction will send its own instruction and register information used to the PCU in the Fetch stage, and the PCU will use this information for permission detection. If the permission inspection is completed and passed, the instruction will be marked as "inspection passed", and if the permission inspection is not passed, a hardware exception will be thrown.

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

[0111] The reason for choosing to detect at the beginning of the Fetch stage and confirm the detection result at the Commit stage is to fully utilize the time difference formed by the difference in pipeline levels to provide sufficient time for permission detection. At the same time, most of the detection functions can be completed using the instruction machine code available in the Fetch stage, and do not need more information provided by the later flow stages.

[0112] The permission information relied on by the PCU is described in the form of a bitmap. Instruction checking requires the use of an instruction permission bitmap, each bit of which indicates whether a certain instruction has execution permission in the current permission domain; register checking requires the use of a register read permission bitmap, a register write permission bitmap and a register bitfield bitmap, which respectively indicate whether a certain register has read permission, write permission and specific bitfield write permission in the current permission domain.

[0113] These permission bitmaps are collectively referred to as a hybrid privilege table, namely a Hyperid Privilege Table, HPT for short, and are stored in a trusted memory.

[0114] Regarding the domain switching unit DSU, the domain switching unit provides a non-forgery permission domain switching method to enhance security when the domain changes. This method provides domain switching instructions for developers and ensures that:

[0115] 1. Injected malicious domain switching instructions cannot be used to switch permission domains.

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

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

[0118] The DSU achieves these security goals by allowing software to register multiple non-forgery switching gates. Each gate corresponds to a legal switch to a permission domain. A switching gate table, SGT for short, is used to store all registered gates. The gates have the following characteristics:

[0119] 1. Each gate 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 permission domain.

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

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

[0124] Regarding software cooperation, the hardware units in this architecture need the cooperation of upper-layer software to function normally. This is mainly reflected in two points:

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

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

[0127] The special permission domain Domain-0 is used to complete the initialization and configuration of HPT and SGT, and other permission domains must go through the proxy of Domain-0 to configure permission metadata. Limiting only one permission domain to be able to configure permission metadata can reduce the attack surface and comply with the principle of least privilege.

[0128] When the processor restarts, it will automatically enter Domain-0, and no permission check will be performed in this permission domain. The software needs to complete the initialization of Argus in this domain. The initialization includes reserving a trusted address space and writing relevant registers to the correct values. In addition, Domain-0 also needs to create a translation gate for registering new permission domains and translation 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 effective for all kernel components, allowing them to call it for registration.

[0129] User processes do not exist in Domain-0 or similar initial permission domains. Instead, they use system calls to have the kernel proxy perform the functions of registering and configuring related permission data structures. The proxy permission domain in the kernel, referred to as Domain-U in this framework, is similar to Domain-0 and also has the ability to read and write trusted memory. It is important to note that Domain-U only proxies the registration and configuration of permission domains and switching gates, and does not proxy permission checks and domain switching, so there is no large context switching overhead caused by frequent system calls.

[0130] To address the issue that different user processes and kernels have different processor resource isolation needs, this framework proposes the concept of processor resource permission context, namely ISA-Context. The ISA-Context includes the ID register of the current permission domain, HPT, and SGT; 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 switching gate table, namely SGT, and other data structures. When the system switches contexts, the software needs to switch the ISA-Context, which allows different processes to use different resource management schemes.

[0131] Trusted Memory refers to a memory region that is specially protected and secured, and is used to store and process sensitive security information or data. In the present architecture, the Trusted Memory is used to hold the processor privilege bitmap and switch gate table that the PCU and DSU need to perform normal functions, so as to avoid theft and modification of these metadata by attackers.

[0132] The present architecture uses a clear and architecture-independent design to implement the Trusted Memory. A specific range of physical memory is reserved as the Trusted Memory. Two special registers are used to specify the range and are set in the initialization privilege domain. The memory access instruction can only access the Trusted Memory region in the initialization privilege domain, i.e., in Domain 0. In other privilege domains, only the PCU and the DSU can access the memory region, and using the memory access instruction to access the Trusted Memory will trigger an exception. By forcing the Trusted Memory to be a power of two in size and following the alignment method, the boundary check overhead can be minimized.

[0133] According to the instruction verification step provided by the present application, the step comprises:

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

[0135] Step A2: The PCU retrieves the corresponding bitmap, i.e., the instruction privilege bitmap of the current privilege domain, from the bitmap array according to the ID.

[0136] Step A3: The PCU queries the corresponding privilege bit in the bitmap according to the opcode of the to-be-detected instruction; if the privilege bit is 1, the result is yes, and step A4 is performed; if the privilege bit is 0, the result is no, and step A5 is performed.

[0137] Step A4: If the privilege bit is 1, it means that the to-be-detected instruction is allowed to be executed in the current privilege domain, and the instruction is marked as “instruction privilege verification passed”.

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

[0139] According to the register read / write verification step provided by the present application, the step comprises:

[0140] Step B1: The PCU first determines whether the to-be-detected register is about to be written or about to be read according to the position of the register in the instruction, which determines which bitmap the PCU uses to complete the verification.

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

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

[0143] Step B4: PCU retrieves the corresponding permission bit in the bitmap according to the index of the register to be detected; judges whether the permission bit is 1, and if yes, executes step B5; if no, executes step B6.

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

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

[0146] According to the register bit field write verification step provided by the application, comprising:

[0147] Step C1: PCU determines whether the register needs bit field write verification according to 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, which is a register storing the ID of the permission domain where the current system is located, corresponds to the DomainID register in the framework diagram.

[0149] Step C3: 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 V0 of the register to be detected, that is, the value V w , the mask value M of the register is verified; judges whether is equal to zero, and if yes, executes step C5; if no, executes step C6.

[0151] Step C5: If , the verification is successful. Wherein, indicates no; ∧ indicates and; ⊕ indicates exclusive or.

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

[0153] According to the start initialization step provided by the application, comprising:

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

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

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

[0157] Step D3: Create a translation gate for registering a new permission domain and a translation gate. These gates switch to Domain-0 and jump to the entry of the registration function; the function, for creating domains and gates. The creation is implemented through a programming language.

[0158] Specifically, in the step D3, the information of the translation gate and the domain is stored in the trusted memory; when performing related operations, i.e., switching the permission domain through the gate, the information stored in the trusted memory is 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, i.e., Domain-Basic;

[0160] Step D5: Switch to the basic permission domain through the switching gate.

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

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

[0163] Step E2: Prepare the ISA-Context of the child process based on 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, reset the ISA-Context, i.e., cancel the existing permission domains and switching gates, and only keep a basic permission domain; if the switch function is executed, save the registers related to the ISA-Context of the previous process in the thread_struct, and restore the related registers from the thread_struct of the next process;

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

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

[0167] The Domain-U is used for managing the Domain in the ISA-Context; the Domain is a permission domain.

[0168] The application further provides a permission domain management system for a multi-privilege-level processor resource, which can be realized by executing the process steps of the permission domain management method for the multi-privilege-level processor resource, i.e., the permission domain management method for the multi-privilege-level processor resource can be understood as the preferred implementation of the permission domain management system for the multi-privilege-level processor resource by those skilled in the art.

[0169] The application provides a permission domain management system for a multi-privilege-level processor resource, which comprises an instruction verification module, a register read-write verification module, a register bit field write verification module and a start initialization module.

[0170] According to the ISA-Context, the start initialization module is triggered to work 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-write verification module is triggered to work; and according to the ID of the current permission domain, the register bit field write verification module is triggered to work.

[0171] In the subsequent work, the privilege level where the virtual machine monitor is located can be explored, and a large number of processor resources exist in the privilege level, which need to be isolated in a fine-grained manner. When different virtual machines are switched, the context also needs to be maintained, and the virtual machine monitor should expand to support this part of the function.

[0172] When the permission domain is switched, the consistency problem needs to be considered at the micro-architecture level. There are two consistency problems to be considered, one is caused by the permission domain switching due to the isa call, and the other is the change of the permission level, which further leads to the selection problem of different registers. The two problems are currently solved in Argus by forced serialization, but forced serialization of out-of-order CPUs will cause performance overhead to increase. In the future, optimization can be considered in combination with specific micro-architectures.

[0173] Those skilled in the art know that, in addition to implementing the system provided by the present application and each device, module and unit thereof in the form of pure computer readable program code, the system provided by the present application and each device, module and unit thereof can also be implemented in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers and embedded microcontrollers, etc. by logically programming the method steps to achieve the same functions. Therefore, the system provided by the present application and each device, module and unit thereof can be considered as a hardware component, and the devices, modules and units included therein for achieving various functions can also be considered as structures within the hardware component; the devices, modules and units for achieving various functions can also be considered as both software modules implementing methods and structures within hardware components.

[0174] The specific embodiments of the present application are described above. It needs to be understood that the present application is not limited to the specific embodiments described above, and various changes or modifications can be made by those skilled in the art within the scope of the claims, which does not affect the essential content of the present application. The embodiments of the present application and the features in the embodiments can be combined with each other in any manner without conflict.

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 the ISA-Context, execute the startup initialization step to obtain the ID of the current permission domain; Executing an 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; The ISA-Context is the 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: Reset the processor according to the ISA-Context and set the permission domain to Domain-0; Step D2: Create a permission domain and a conversion gate for the conversion gate, and switch the conversion gate to the Domain-0, and enter the entry of the registration function through the permission domain; the function is used to create the domain and the 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; The instruction checking step includes: Step A1: Read the ID of the current permission domain; the current permission domain is the basic permission 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: querying the corresponding permission bit according to the bitmap; determining whether the permission bit is set to 1; if so, marking the instruction to be tested as "instruction permission check passed"; if not, throwing a hardware exception; 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: Retrieve the corresponding bitmap in the HPT from the bitmap array according to the ID of the permission domain; Step B3: Search 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 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 determine whether V0 ⊕ V w ∧ ¬ M is 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. Among them, ¬ means no; ∧ means and; ⊕ means exclusive or.

2. The permission domain management method for multi-privilege level processor resources according to claim 1, characterized in that: The ISA-Context management steps 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 switch gate are canceled, 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 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 instructed 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.

3. A permission domain management system for multi-privilege level processor resources, characterized in that: include: Instruction test module, register read and write test module, register bit field write test module, startup initialization module; According to the ISA-Context, the initialization module is triggered to start working and obtain 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, trigger the register bit field write verification module to work; The ISA-Context is the 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: Reset the processor according to the ISA-Context and set the permission domain to Domain-0; Module D2: Creates a permission domain and a conversion gate for the conversion gate, switches the conversion gate to Domain-0, and enters the entry of the registration function through the permission domain; the function is used to create the domain and the gate; Module D3: Create a gate that can enter Domain-Basic based on 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 perform the target task; 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 yes, mark the instruction to be tested as "instruction permission check passed"; if no, throw a hardware exception; The register read and write verification module includes: 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: Search 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 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 determine whether V0 ⊕ V w ∧ ¬ M is 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. Among them, ¬ means no; ∧ means and; ⊕ means exclusive or.

4. The permission domain management system for multi-privilege level processor resources according to claim 3, characterized in that: Also includes: ISA-Context management modules include: Module E1: Enters the fork function and creates 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: Executes 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 canceled, leaving only a basic permission domain. 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 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 instructed 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