A capability-based highly scalable microkernel security management method

Abstract

The present invention discloses a capability-based highly scalable microkernel security management method. A capability space is constructed in the kernel state, and at the same time, a parent pointer "parent", a child pointer "next", and a sibling pointer "slibing" are included in the capability structure, thereby forming a capability derivation tree. A microkernel security management system is constructed, including a capability space management subsystem CSpace deployed in the user state and a CPTR parsing module, a policy cache module, a capability lookup module, a policy security policy decision module, and an operation execution module deployed in the kernel state. In the initialization stage of the microkernel operating system, after the hardware initialization is completed, the capability space of the root service Rootserver is constructed immediately, and then user processes are created. Users send capability call information through the capability space management subsystem CSpace, which is subject to permission control and execution by the kernel state module, and then the capabilities are recycled. By designing the capability-based security management, the present invention makes all system calls depend on capabilities, making the call semantics more unified.

Description

Technical Field

[0001] The present invention belongs to the technical field of microkernels. More specifically, it relates to a highly scalable microkernel security management method based on capabilities. Background Art

[0002] The access mechanism based on capabilities (Capability) is the first protection mechanism to give a strict semantic definition. All kernel objects with restricted access are abstracted into a type, and a capability is an unforgeable triple, including an object, a type, and a permission. A visitor must hold the corresponding capability to access the object, and permission transfer is allowed to be restricted to create a secure operating environment. All capabilities are stored in the capability space. Formally, the capability space is a directed graph; conceptually, the capability space of a process is a part of the directed graph that the process can traverse. Based on this property, with proper design, the reachable objects of the capability set are a transitive, reflexive, and semi-symmetric closure, while an ACL (Access Control List) may violate this closure. Another great advantage of the capability mechanism is that it can build a formal semantics for it and then conduct formal verification on it, which is also an important part of future operating system security evaluation. Thanks to this, the SeL4 operating system is the first microkernel operating system to be formally verified, and many systems have also incorporated the capability mechanism. However, the disadvantage is that if the capacity of the nodes storing capabilities is set too large, too much memory will be consumed. And if it is set relatively small, the multi-layer capability space will affect the search speed and management difficulty.

[0003] The capability mechanism, as an autonomous access control mechanism, is an effective means to protect the resources of computer information systems from illegal access. However, it has an obvious drawback, that is, this control is autonomous, and the access rights of resources are completely determined by the subject. In this case, the premise of security is that the subject with management permissions must be trusted not to deliberately disclose the permissions. Therefore, it is best to combine mandatory access control and the principle of least privilege to create an isolated sandbox to avoid accidentally disclosing permissions. Although the autonomy of autonomous access control provides great flexibility for users, it lacks the high security required for high-security levels. At this time, the system needs to formulate more strict rules, which is mandatory access control (MAC). Under mandatory access control, each process, each file, and each IPC object (message queue, semaphore set, and shared storage area) in the system is assigned corresponding security attributes and is not allowed to be modified directly or indirectly by users or their programs like ACL. The system determines whether the subject can access the object in the expected manner by comparing the security attributes of the subject and the object. Users use autonomous access control to prevent other users from illegally invading their files, while mandatory access control, as a more powerful security protection method, prevents users from evading security control through accidents and conscious misoperations. Currently, a method and system for resource isolation of a microkernel operating system have been proposed, which abstractly manages the CPU resources and memory resources of each process by using resource containers; implements a device bandwidth isolation mechanism inside the relevant user-mode server; and implements a process sandbox mechanism based on the capability mechanism. However, this method does not consider the management cost of the capability space and the scalability of the capability architecture in general scenarios and needs to be further improved.

[0004] In addition, the existing implementation mechanism of the capability system based on the armv7-M microkernel is relatively simple. The capability pointer is allocated in the kernel state, increasing the scope of the security kernel. Moreover, the capability spaces of different processes are not isolated, resulting in incomplete security assurance. The resources of 64-bit general operating systems are more abundant, but simple management mechanisms may lead to system performance and usability problems. In addition, the capability mechanism is relatively fixed, with poor permission scalability, an imperfect management mechanism for the capability space, a lack of performance optimization for multi-level lookups in the existing capability mechanism, and the inability to make all system calls pass through capabilities. Summary of the Invention

[0005] The purpose of the present invention is to overcome the deficiencies of the prior art and provide a highly scalable microkernel security management method based on capabilities. By designing security management based on capabilities, all system calls depend on capabilities, making the call semantics more unified.

[0006] To achieve the above invention purpose, the highly scalable microkernel security management method based on capabilities of the present invention includes the following steps:

[0007] S1: Construct a capability space in the kernel mode, including the following capability objects:

[0008] Capability of information node CNode, used to store capability information, which is a node in the capability space and is used to organize and index capabilities;

[0009] Capability of thread control block TCB, used to represent the control authority for a thread, including starting, stopping, pausing, and resuming a thread;

[0010] Capability of startup information BOOTINFO, used to store the initial capability information of a process;

[0011] Capability of page table PAGETABLE, used to support the holder to operate on the page table, including establishing, modifying, and deleting the mapping from virtual address to physical address;

[0012] Capability of page frame FRAME, used to represent the physical page frame capability corresponding to the mapping operation of the page table;

[0013] Capability of physical memory DRAM, used to represent the free physical memory capability;

[0014] Capability of mutex SYNC, used to synchronize the access of multiple threads or processes to shared resources;

[0015] Capability of special state ZOMBIE, used for the state when a capability is revoked or a resource is released;

[0016] Capability of event notification NTFN, used to transfer events or signals between different entities;

[0017] Capability of remote procedure call CALLER, used to implement function calls across processes;

[0018] Capability of policy cache AVC, used to manage the switch of the policy cache vector and the replacement policy when updating the cache;

[0019] There are 5 operations corresponding to the capability of information node CNode, which are respectively:

[0020] Capability construction operation Build, an operation performed on the physical memory capability DRAM, used to construct a new capability object using a section of physical memory. The new capability object is a sub-capability of the physical memory capability DRAM;

[0021] Capability copy operation Copy, used to copy a capability from one CNode slot to another;

[0022] Capability deletion operation Delete, used to delete an entire capability and its derived sub-capabilities;

[0023] The revocation ability operation Revoke deletes the ownership abilities derived from an ability, but does not delete the ability itself;

[0024] The transfer ability operation Move moves an ability from one slot to another;

[0025] When the information node ability CNode performs an operation, the following rules need to be satisfied: The transfer ability operation Move can only be executed when the CNode ability is moved to its own slot No. 1. In other cases, the CNode ability cannot call the transfer ability operation Move; The ancestor DRAM of the CNode ability can only be transferred to a space outside its own CNode space; The ability markers derived from the copy ability operation Copy are marked as having no recycling permission;

[0026] Each ability's ability structure contains a parent pointer parent, a child pointer next, and a sibling pointer slibing, which are used to point to the parent ability, child ability, and sibling ability of the ability respectively;

[0027] S2: Build a microkernel security management system, including the ability space management subsystem CSpace deployed in the user state, and the CPTR parsing module, policy cache module, ability lookup module, policy security policy decision module, and operation execution module deployed in the kernel state. Among them:

[0028] The ability space management subsystem CSpace is used to manage the ability space based on the ability space of the process, that is, to save the information of the ability space of each process, allocate the ability address CPTR according to the user's ability call situation and send it to the CPTR parsing module, and recycle the ability after the call is completed;

[0029] The CPTR parsing module is used to parse the specific ability corresponding to the ability address CPTR, and distribute the ability address CPTR to the ability lookup module or the policy cache module according to the preset decision method of the ability;

[0030] The ability lookup module is used to find all the abilities of this ability call according to the information in the ability address CPTR, and then send the obtained ability information to the security policy decision module;

[0031] The policy cache module is used to cache the security decision policies of the abilities, match the corresponding ability information according to the information in the ability address CPTR and send it to the security policy decision module;

[0032] The security policy decision-making module is used to perform access control based on the received capability information, that is, to determine whether the current capability call has the corresponding permission according to the permission information in the capability information. If so, the corresponding capability operation is sent to the operation execution module; otherwise, a permission verification failure message is fed back to the capability space management subsystem CSpace.

[0033] The operation execution module is used to execute the capability operations received from the security policy decision-making module.

[0034] S3: In the initialization stage of the microkernel operating system, after the hardware initialization is completed, the capability space of the root service Rootserver is constructed immediately. The specific process is as follows:

[0035] 1) Static creation of the root capability node root_CNode;

[0036] 2) Initialize the physical memory DRAM capability, construct each continuous segment of physical memory as a DRAM capability and store it at the tail of the root capability node root_CNode;

[0037] 3) Construct each kernel object of the root service Rootserver based on the physical memory DRAM capability. After the construction is completed, these physical memory DRAMs are migrated to the lower slots, and the current available resources are recorded in the boot information capability BOOTINFO of the root service process;

[0038] S4: The root service Rootserver or its descendant processes, as the parent process, create user processes according to user requests. When creating a user process, first, the parent process applies for a memory space managed by the root service Rootserver, and then creates a capability information node CNode capability of the user process in the capability space of the root service Rootserver, and at the same time creates a fixed minimum capability set; use the conversion capability operation Move to copy the CNode capability of the user process to the first slot of the user process itself, thus completing the creation of the closed loop;

[0039] S5: When the user sends capability call information to the capability space management subsystem CSpace, the capability space management subsystem CSpace allocates the capability address CPTR in the following way:

[0040] When allocating the capability address CPTR in the root capability node root_Cnode, directly find an idle position through the root_CNode bitmap in the root capability node, and then return;

[0041] When allocating the capability address CPTR in the multi-level information node capability CNode, first allocate it in the root_CNode bitmap. If the allocation is successful, return. If the allocation fails, search for a bitmap allocation within the partial free CNode list partial_list. If the allocation is successful, return. If the allocation still fails, search the full free CNode list free_list. If the allocation is successful, return. If the allocation still fails, trigger the allocation mechanism of the secondary CNode to allocate the capability address CPTR, that is, create a CNode through the physical memory capability DRAM and add it to the partial free CNode linked list partial_list, and then allocate the capability address CPTR;

[0042] The capability space management subsystem CSpace sends the allocated capability address CPTR to the CPTR parsing module for subsequent processing;

[0043] S6: After the capability call is completed, recycle the capability according to the following steps:

[0044] 1) Determine whether the capability has sub-capabilities. If it does, go to step 2); otherwise, go to step 3);

[0045] 2) Use the Revoke capability operation to delete the sub-capabilities derived from this capability, and then go to step 3);

[0046] 3) Use the Delete capability operation to delete the current capability. The deletion process includes three cases:

[0047] Case 1: If the capability has no recycle permission, then this node will be deleted from the capability inheritance system, and the content of this slot will be processed in a certain way. If the object directly called this time is deleted, then directly clear this slot. If the slot deleted based on the inheritance system, it needs to be set to the ZOMBIE type. When the user mode accesses the capability address CPTR again, then truly clear this slot;

[0048] Case 2: If the capability has recycle permission, has sibling capabilities and its end address does not coincide with the DRAM of the physical memory capability of the parent capability, then convert this capability into a physical memory capability DRAM of the corresponding kernel object size, wait for reallocation or recycle together with the parent capability.

[0049] Case 3: If the capability has recycle permission, has sibling capabilities and its end coincides with the start of the physical memory DRAM of the parent capability, or has no sibling capabilities, then merge this capability with the physical memory DRAM of the parent capability. At this time, the physical memory DRAM of the parent capability increases by the corresponding size.

[0050] The present invention relates to a highly scalable microkernel security management method based on capabilities. A capabilities space is constructed in the kernel state, including the information node capability CNode, the thread control block capability TCB, the startup information capability BOOTINFO, etc. At the same time, the capabilities structure contains a parent pointer parent, a child pointer next, and a sibling pointer slibing, thus forming a capabilities derivation tree. A microkernel security management system is constructed, including a capabilities space management subsystem CSpace deployed in the user state and a CPTR parsing module, a policy cache module, a capabilities lookup module, a policy security policy decision module, and an operation execution module deployed in the kernel state. During the initialization stage of the microkernel operating system, after the hardware initialization is completed, the capabilities space of the root service Rootserver is constructed, and then user processes are created. Users send capabilities invocation information through the capabilities space management subsystem CSpace, which is controlled and executed by the kernel state module, and then the capabilities are recycled.

[0051] The present invention has the following beneficial effects:

[0052] 1) The present invention designs a set of capabilities system frameworks, redesigns the capabilities structure and supporting operations, so that the storage structure and inheritance structure of the capabilities space are sufficient to support the flexibility of policies, thus supporting multiple security policies. And all system calls rely on capabilities, making the call semantics more unified;

[0053] 2) The present invention introduces a policy cache in the microkernel, improving the efficiency of access control;

[0054] 3) The present invention can completely isolate the capabilities spaces between different processes, so that each process can only access the capabilities resources within its own process. All external capabilities must be obtained through explicit requests and placed in its own capabilities space before they can be accessed, thus enhancing security. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 is a flowchart of a specific implementation manner of the highly scalable microkernel security management method based on capabilities of the present invention;

[0056] Figure 2 is an example diagram of the capabilities derivation tree in this embodiment;

[0057] Figure 3 is a structure diagram of the microkernel security management system in the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0058] The following describes the specific implementation manner of the present invention with reference to the drawings, so that those skilled in the art can better understand the present invention. It should be particularly noted that in the following description, when the detailed description of known functions and designs may dilute the main content of the present invention, these descriptions will be ignored here.

[0059] Embodiment

[0060] Figure 1 is a flowchart of a specific implementation manner of the power-based highly scalable microkernel security management method of the present invention. As Figure 1 shown, the specific steps of a power-based highly scalable microkernel security management method of the present invention include:

[0061] S101: Construct a capability space:

[0062] A capability, as an unforgeable token, points to a specific kernel object and contains access permissions and other organizational information. To better implement microkernel security management, the present invention first needs to construct a capability space in the kernel state, including the following capability objects:

[0063] Capability node of information CNode, which is used to store capability information, is a node of the capability space (Capability space Node), and is used to organize and index capabilities. CNode itself can be regarded as a container or directory, and the number of slots is fixed (a power of 2), and this number is determined when creating this Cnode.

[0064] Thread control block capability TCB (Thread Control Block), which is used to represent the control permissions for a process, including starting, stopping, pausing, and resuming a process. An entity with the TCB capability can manage the life cycle and state of a process.

[0065] Boot information capability BOOTINFO, which is used to store the initial capability information of a process. BOOTINFO should be able to store information and does not correspond to the operations of system services.

[0066] Page table capability PAGETABLE, which is used to support the holder to operate on the page table, including establishing, modifying, and deleting the mapping from virtual address to physical address.

[0067] Page frame capability FRAME, which is used to represent the physical page frame capability corresponding to the mapping operation of the page table. FRAME does not correspond to the operations of system services.

[0068] Physical memory capability DRAM, which is used to represent the free physical memory capability.

[0069] Mutex capability SYNC, which is used to synchronize the access of multiple processes or a process to shared resources.

[0070] Special status capability ZOMBIE, which is used for the status when a capability is revoked or a resource is released. This kind of capability no longer points to a valid resource and does not correspond to the operations of system services;

[0071] The event notification capability NTFN is used to transfer events or signals between different entities.

[0072] The remote procedure call capability CALLER is used to implement function calls across processes, mainly for user processes to call system services. CALLER can be regarded as a kind of inter - process communication (IPC) mechanism.

[0073] The policy cache capability AVC is used to manage the switch of the policy cache vector and the replacement policy when updating the cache. The AVC capability can control the state of the current process capability cache, corresponding to a kernel object, including the switch of the policy cache, the size of the current cache pool, and the replacement policy. The AVC capability can be regarded as a resource library of a specific object manager, providing support for policy cooperation between the object manager and the security server, including the policy decision request initiated by the object manager and the policy change request initiated by the server.

[0074] In the present invention, an independent capability space is set for each process, similar to the process address space, thereby improving security and enabling processes within the same process to share capabilities, facilitating the sharing of capabilities between processes. The capability space (CSpace: CapabilitySpace) is a container for storing capabilities. There are two organizational structures for CSpace. One is a storage structure centered on the CNode capability, and the other is an inheritance structure centered on the capability inheritance relationship, facilitating access to capabilities in different situations and requirements. For the entire operating system, the space occupied by the CNode capabilities of all processes constitutes all the capability spaces, and these capabilities form one or several capability inheritance trees due to the inheritance relationship. The inheritance tree is the organizational form of all capabilities. For each process, the capability subsystem performs permission checks for a single task, and its capability space is the capability space composed of all CNodes that it can find. The CNode capability can manage the capability space. Five operations are defined in the present invention, including:

[0075] Build capability operation Build: An operation performed on the physical memory capability DRAM, used to build a new capability object using a section of physical memory. The new capability object is a sub - capability of the physical memory capability DRAM.

[0076] Copy capability operation Copy: Copy a capability, copying a capability from one CNode slot to another. The copied capability also belongs to the derived sub - capability, and can be used in conjunction with the CALLER capability for inter - process capability transfer.

[0077] Delete capability operation Delete: Delete a capability, deleting an entire capability and its derived sub - capabilities.

[0078] Revoke power operation: The revoke power operation deletes all the ownership powers derived from a power, but does not delete the power itself.

[0079] Move power operation: Move a power from one slot to another.

[0080] According to the above description, the revoke operation will delete all the objects derived from a power. Different from deleting the power, it will not affect the directly called power. Since deletion and revocation call each other, it is necessary to prevent the system from falling into an infinite loop due to the inability to delete the power in the case of circular application. To solve this problem and achieve a complete power space operation, the following rules are set in the present invention:

[0081] The Move power operation can only be executed when the CNode power is moved to its own slot No. 1. In other cases, the CNode power cannot call the Move power operation. That is to say, only when the CNode power is the root of a process power space can the Move operation be performed. That is to say, this operation is only allowed when creating a process (fork operation), thus avoiding circular deletion.

[0082] Since all kernel objects after system initialization ultimately depend on the DRAM power in the power derivation tree, the ancestor DRAM of the CNode power can only be transferred to a space outside its own CNode space and cannot be moved into its own CNode space.

[0083] In addition, the powers derived from the Copy power operation are marked as having no recycling permission.

[0084] In the capability space, there are corresponding operations for each capability. For example, when creating a CNode, the user must specify the number of slots it owns, which determines the amount of memory it will use. Each slot requires 6 * WORD_BITS bytes of physical memory, which can just accommodate one capability. On a 64-bit architecture, it is 48 bytes. The creation of a CNode requires calling the DRAM capability object. Therefore, the caller must have a DRAM capability with sufficient space, and there must be free slots in its own CSpace to store this CNode. Since a CNode is a kernel object and a spin lock is required when multiple cores access this object concurrently, in order to improve the utilization rate of space and reduce the granularity of the lock, the 48B space in the 0th position of the CNode can be designed as a CNode_header structure to store the spin lock and the address of the process root_CNode. In order to enable any capability object to quickly obtain the address of the root_CNode, the CNode can be aligned with 0x4000, so that when unmapping, the pagetable capability can be quickly found through the Frame capability for reverse mapping operations.

[0085] It can be seen that the operations (build / copy) of capabilities contain a layer of inheritance semantics, so the inheritance relationships between all capabilities must be recorded. The parent-child relationship means that the child is derived from the parent, and the parent can determine the existence of the child. That is to say, the parent capability implies the ability to recycle the child capabilities. On the other hand, one capability may derive more than one capability, and these child capabilities are in a sibling relationship, and they all come from the same parent. In this embodiment, in order to clearly organize the inheritance relationships of capabilities, in addition to the basic attributes in the capability structure of each capability, it also includes a parent pointer parent, a child pointer next, and a sibling pointer slibing, which are used to point to the parent capability, child capability, and sibling capability of this capability respectively, thus forming a circular linked list to construct a capability derivation tree between capabilities. The capability structure in this embodiment can be represented as follows:

[0086]

[0087] Among them, the two words w and ww are fields for storing the capability type and the corresponding kernel object information, right_info is the permission field, and parent, next, and sibling are the parent pointer and sibling pointer required to construct the inheritance relationship respectively.

[0088] The parent pointer parent, the child pointer next, and the sibling pointer slibing can establish a capability derivation tree in the capability object, so that the target capability object can be quickly found, accelerating the management of the capability space. Figure 2 This is an example diagram of the capability derivation tree in this embodiment. AsFigure 2 As shown, this capability derivation tree demonstrates a standard derivation scenario: the DRAM capability of a process is a large block of available memory. The process can use it to build (create) any type of sub-capability. After creation, the remaining space will decrease. If the created one is a DRAM capability, then the DRAM capability can continue to build, such as creating a TCB capability, a CNode stub, etc. Other capabilities can also derive sub-capabilities when the permissions are sufficient. For example, a TCB capability can authorize a subset of the capability permissions to other processes through copy.

[0089] There are also some special scenarios. When the parent process exits before the child process, if the parent process creates the child process using its own DRAM capability, then the child process will also be forced to exit. To prevent this situation, when the parent process creates a child process, it can first apply to the root service Rootserver for a section of DRAM. In this way, when the parent process exits, it will not affect the memory resources of the child process, and the TCB of the child process can be placed in the capability space of the parent process, so that the parent process can also control the life cycle of the child process. In addition, since a process needs some fixed capabilities to run normally, and there may be only one copy of these capabilities in the whole system. Then, if the capabilities of the child process come from a copy of the parent process's capability space, according to the semantics defined above, when the parent process exits first, the capabilities of the child process still need to be deleted. Therefore, this requires the transfer flag in the capability to be processed. When the T flag bit in right_info is 0, the copy is not made as a child but as a sibling capability.

[0090] S102: Deploy the microkernel security management system:

[0091] To implement the microkernel security management based on capabilities, a microkernel security management system is deployed in the microkernel operating system in the present invention. Figure 3 This is the structural diagram of the microkernel security management system in the present invention. As Figure 3 shown, the microkernel security management system in the present invention includes a capability space management subsystem CSpace deployed in the user state, and a CPTR parsing module, a policy cache module, a capability lookup module, a policy security policy decision module, and an operation execution module deployed in the kernel state. Next, each module will be described in detail.

[0092] The capability space management subsystem CSpace is used to manage the capability space based on the process's capability space, that is, to send the capability address CPTR to the CPTR parsing module according to the user's invocation of capabilities, and recycle the capabilities after the invocation is completed. In the present invention, some fixed capabilities are created during system initialization, and each process also knows its own capability space state after creation. Therefore, the user space can fully manage its own capability space based on this, and the kernel is only responsible for checking and executing specific capability invocations, rather than being responsible for the cumbersome allocation and recycling algorithms.

[0093] The CPTR parsing module is used to parse the specific capability corresponding to the capability address CPTR, and distribute the capability address CPTR to the capability lookup module or the policy cache module according to the preset decision method of the capability. Since the starting address of the root node root_CNode of the capability space of each process is in the process control block TCB of the process, and the capability structure corresponding to root_CNode is default in this space, the number of slots of this node and the protection bit of this CNode can be obtained by parsing the capability address CPTR, and the information node capability CNode can be found according to the index in the capability address CPTR, thus completing the lookup. In this embodiment, the capability address CPTR is distributed according to the included capability level. When the capability level is less than the preset level, it is sent to the policy cache module, otherwise it is sent to the capability lookup module.

[0094] The capability lookup module is used to find all the capabilities of this capability invocation according to the information in the capability address CPTR, and then send the obtained capability information to the security policy decision module.

[0095] The policy cache module is used to cache the security decision policies of capabilities, match the corresponding capability information according to the information in the capability address CPTR, and send it to the security policy decision module. The policy cache module is set to alleviate the adverse effects caused by multi-level capability lookup during normal capability lookup, and provide a cache mechanism for security decisions in the kernel state. What is stored in the policy cache module is a set of triples (capability object, Cptr, status information) that identify access events.

[0096] The security policy decision module is used to perform access control according to the received capability information, that is, to judge whether this capability invocation has the corresponding permission according to the permission information in the capability information. If it has, the corresponding capability operation is sent to the operation execution module, otherwise, an information of failed permission verification is fed back to the capability space management subsystem CSpace.

[0097] In this embodiment, the information of the capability object and the corresponding kernel object permissions is stored in right_info, including three types of permission information: the capability access permission cap_right, which represents the permission for the current capability object, such as authorization grant, transfer, write, etc.; the type access permission object_right, which represents the permission for the kernel object pointed to by the capability, such as the recycling permission, etc.; the mandatory access permission mac_level, which represents the mandatory access control permission for the object resources, and can represent an object access level, which can correspond to the access level within the process TCB, so as to control the level of the process to access resources. Among them, a part of the bits are reserved for definition according to specific capabilities, which can support rich and fine-grained permission management. And the current security policy is dynamically switched through an abstract function pointer interface layer.

[0098] The operation execution module is used to execute the capability operations received from the security policy decision module.

[0099] According to the above description, when a certain subject accesses a restricted resource through the capability address CPTR, first perform CPTR parsing, then query the corresponding capability through the capability lookup module or the policy cache module, and then the security policy decision module determines whether there is a corresponding permission, and sends the operation information passing the permission judgment to the operation execution module for execution. Due to the existence of the policy cache, local requests will be greatly accelerated without having to traverse the policy every time, but correspondingly, the capacity problem of the cache and the scheduling policy problem are introduced. In addition, when the policy changes, the access vector of the cache may become invalid, and at this time, the corresponding vector invalidation operation needs to be performed.

[0100] S103: System initialization:

[0101] In the initialization stage of the microkernel operating system, after the hardware initialization is completed, the capability space of the root service Rootserver is constructed immediately. The specific process is as follows:

[0102] 1) Static creation of the root capability node root_CNode. The root capability node root_CNode refers to the first CNode in the capability space of a certain process, and its address is usually stored in the process control block TCB of the process. The root capability node root_CNode of the root service Rootserver is relatively special and is statically created during system initialization.

[0103] 2) Initialize the physical memory DRAM capabilities, construct each continuous physical memory segment as a DRAM capability and store it at the tail of the root capability node root_CNode. All capabilities of the entire system inherit from this DRAM capability.

[0104] 3) Construct each kernel object of the root service Rootserver based on the capabilities of physical memory DRAM. After construction, migrate this physical memory DRAM to the lower slots, and record the current available resources in the boot information capability BOOTINFO of the root service process. That is to say, all the resources available to the entire system after kernel initialization are stored in the boot information capability BOOTINFO of Rootserver.

[0105] S104: User process initialization:

[0106] In the present invention, a capability space is constructed for each user, thus completely isolating the capability spaces between different processes, such that each process can only access the capability resources within its own process. All acquisitions of external capabilities must be through explicit requests and placed in its own capability space before access can be made. The specific method is as follows:

[0107] The root service Rootserver or its descendant processes, as the parent process, create a user process according to the user request. When creating a user process, first, the parent process applies for a memory space managed by the root service Rootserver, and then creates a capability information node CNode capability of the user process in the capability space of the root service Rootserver, and simultaneously creates a fixed minimum capability set. That is to say, the root node root_CNode of the created user process must first be placed within the parent process, and then continue to use this space to create the initial capabilities of the child process with this newly created CNode as the container. Therefore, different from the creation of the Rootserver capability space during system initialization, next, it is also necessary to use the capability conversion operation Move to copy the CNode capability of the user process to the first slot of the user process itself, thus completing the creation of the closed loop. At this time, the capability spaces of the parent process and the child process (the created user process) are completely separated in the storage structure, and the parent process cannot parse out the capabilities of the child process through capabilities at least.

[0108] S105: Invoke capabilities:

[0109] In the present invention, due to the streamlined functions of the kernel, only necessary access control and operations are performed. Therefore, the allocation of the capability address CPTR is performed in the user state, thereby reducing the trusted computing base of the kernel. A user-state process only needs to know the initial capability distribution and can then fully manage its own capability space through system calls. However, the capacity of the root capability node root_CNode is limited, so multi-level capability space allocation is required. The usage of the slots in a capability information node CNode is represented by a bitmap. Each CNode corresponds to a bitmap structure in the user state, and the capability space management subsystem CSpace stores all the information about the current process's capability space. The allocation of the capability address CPTR is divided into two methods:

[0110] Case 1: When allocating the capability address CPTR in the root capability node root_Cnode, directly find an idle position through the root_CNode bitmap in the root capability node and then return.

[0111] Case 2: When allocating the capability address CPTR in the multi-level information node capability CNode, the root capability node root_CNode bitmap structure also stores three secondary bitmap lists, namely the full CNode list full_list, the partially free CNode list partial_list, and the all free CNode list free_list. First, the root_CNode bitmap is allocated. If the allocation is successful, it returns. If the allocation fails, a bitmap allocation is searched in the partial free CNode list partial_list. If the allocation is successful, it returns. If the allocation still fails, the all free CNode list free_list is searched. If the allocation is successful, it returns. If the allocation still fails, the allocation mechanism of the secondary CNode is triggered. In actual applications, in order to ensure that there are urgent slots for implicit expansion of capability space, each CNode bitmap will record a water level. When the water level is less than a value, the system can scan all CNode bitmaps of the current process and recycle ZOMBIE type capabilities. When the water level is lower than the emergency space position, the normal slots are used up and the secondary CNode allocation mechanism is triggered. At this time, a CNode is created through the physical memory capability DRAM and added to the partial free CNode linked list partial_list, and then the capability address CPTR is allocated.

[0112] The capability space management subsystem CSpace sends the allocated capability address CPTR to the CPTR parsing module for subsequent processing.

[0113] S106: Reclaiming Power:

[0114] Since the management operations of process resources in the present invention all rely on CNode capabilities, the recovery of capabilities is a key issue, because in a huge inheritance structure, how to quickly find all the sub-capabilities of a capability and delete them, while also taking into account the invalidation of the policy cache. Because the deletion and revocation operations may involve the deletion of more than one capability, and the user state is not clear about which capabilities have been recovered. The present invention introduces the ZOMBIE capability to identify a capability that has not been recovered, indicating that it is not actively recovered and requires additional operations later, so that it can be recovered in conjunction with the user state capability address CPTR management, ensuring the consistency of kernel Cspace and Cptr allocation management. The specific steps for recovering capabilities in the present invention include:

[0115] 1) Determine whether there are sub - capabilities for the current capability. If so, go to step 2); otherwise, go to step 3).

[0116] 2) Use the Revoke operation of the revocation capability to delete the sub - capabilities derived from this capability, and then go to step 3).

[0117] 3) Use the Delete operation of the deletion capability to delete the current capability. The deletion process includes three cases.

[0118] Case 1: If the capability has no recycling permission, then this node will be deleted from the capability inheritance system, and the content of this slot will be processed in a certain way.

[0119] If the object directly called this time is deleted, then directly clear this slot. If the slot deleted based on the inheritance system is being processed, it cannot be marked as empty at this time, because the user - mode capability address CPTR does not know that it is already empty. Therefore, it needs to be set to the ZOMBIE type. When the user - mode accesses the capability address CPTR again, this slot will be truly cleared, so as to synchronize the management of the user - mode capability address CPTR.

[0120] Case 2: If the capability has recycling permission, has sibling capabilities and the end address of the sibling capabilities does not coincide with the DRAM of the physical memory capability of the parent capability, then this capability cannot be recycled into the DRAM capability of the parent capability. Convert this capability into a physical memory capability DRAM of the corresponding kernel object size, and wait for re - allocation or recycling together with the parent capability.

[0121] Case 3: If the capability has recycling permission, has sibling capabilities and the start of the end of the sibling capabilities coincides with the DRAM of the physical memory capability of the parent capability, or there are no sibling capabilities, then merge this capability with the physical memory DRAM of the parent capability. At this time, the physical memory DRAM of the parent capability increases by the corresponding size.

[0122] Although the above - described illustrative specific embodiments of the present invention have been described to facilitate those skilled in the art to understand the present invention, it should be clear that the present invention is not limited to the scope of the specific embodiments. For those of ordinary skill in the art, as long as various changes are within the spirit and scope of the present invention defined and determined by the appended claims, these changes are obvious. All inventions created using the concept of the present invention are within the scope of protection.

Claims

1. A highly scalable microkernel security management method based on capabilities, characterized in that: The following steps are involved: S1: Construct a capability space in kernel state, including the following capability objects: Information node capability CNode is used to store capability information. It is a node in the capability space and is used to organize and index capabilities. Thread Control Block Capabilities TCB, used to indicate the control rights for threads, including starting, stopping, pausing, and resuming threads; Boot information capability BOOTINFO is used to store the initial capability information of the process; Page table capability PAGETABLE is used to support the holder to operate the page table, including creating, modifying and deleting the mapping from virtual address to physical address; Page frame capability FRAME is used to indicate the corresponding physical page frame capability after the mapping operation on the page table; Physical memory capability DRAM, used to indicate free physical memory capability; The mutex capability SYNC is used to synchronize access to shared resources by multiple threads or processes; Special state capability ZOMBIE, used when the capability is revoked or the resource is released; Event notification capability NTFN, used to transmit events or signals between different entities; Remote procedure call capability CALLER, used to implement cross-process function calls; Policy cache capability AVC, used to manage the switch of policy cache vector and the replacement strategy when updating cache; There are five operations corresponding to the information node capability CNode, namely: The capability operation Build is an operation performed on the physical memory capability DRAM, and is used to construct a new capability object using a segment of physical memory. The new capability object is a child capability of the physical memory capability DRAM. The Copy capability operation copies a capability from one CNode slot to another; The capability deletion operation Delete deletes a capability and all its derived sub-capabilities; Revoke capability operation, which deletes all capabilities derived from a capability, but does not delete the capability itself; The Move operation moves a capability from one slot to another. When executing operations, the information node capability CNode needs to meet the following rules: the transfer capability operation Move can only be executed when the CNode capability is moved to its own slot 1. In other cases, the CNode capability cannot call the transfer capability operation Move; the ancestor DRAM of the CNode capability can only be transferred to a space outside its own CNode space; the capability derived from the copy capability operation Copy is marked as having no recovery authority; The capability structure of each capability contains a parent pointer parent, a child pointer next and a sibling pointer slibing, which are used to point to the parent capability, child capability and sibling capability of the capability respectively; S2: Construct a microkernel security management system, including the capability space management subsystem CSpace deployed in user state, and the CPTR parsing module, policy cache module, capability search module, policy security policy decision module and operation execution module deployed in kernel state, where: The capability space management subsystem CSpace is used to manage the capability space based on the process capability space, that is, to save the capability space information of each process, allocate the capability address CPTR according to the user's call to the capability and send it to the CPTR parsing module, and recycle the capability after the call is completed; The CPTR parsing module is used to parse the corresponding specific capability from the capability address CPTR, and distribute the capability address CPTR to the capability search module or the policy cache module according to the preset decision method of the capability; The capability search module is used to search for all capabilities of the capability call according to the information in the capability address CPTR, and then send the obtained capability information to the security policy decision module; The cache module is used to cache the security decision policy of the capability, and obtains the corresponding capability information according to the information in the capability address CPTR and sends it to the security policy decision module; The security policy decision module is used to perform access control based on the received capability information, that is, to determine whether the capability call has the corresponding permission based on the permission information in the capability information. If so, the corresponding capability operation is sent to the operation execution module, otherwise, the permission verification failure information is fed back to the capability space management subsystem CSpace; The operation execution module is used to execute the capability operation received from the security policy decision module; S3: During the initialization phase of the microkernel operating system, after the hardware initialization is completed, the capability space of the root service Rootserver is constructed. The specific process is as follows: 1) Statically create the root capability node root_CNode; 2) Initialize the physical memory DRAM capability, construct each continuous physical memory segment as a DRAM capability and store it at the end of the root capability node root_CNode; 3) Construct various kernel objects of the root service Rootserver based on the physical memory DRAM capability. After the construction is completed, these physical memory DRAMs are migrated to the low-level slots, and the current available resources are recorded in the boot information capability BOOTINFO of the root service process; S4: The root service Rootserver or its descendant process acts as the parent process to create a user process according to the user request. When creating a user process, the parent process first applies for a memory space managed by the root service Rootserver, then creates a capability information node CNode capability of the user process in the capability space of the root service Rootserver, and creates a fixed minimum capability set at the same time; the capability conversion operation Move is used to copy the CNode capability of the user process to the first slot of the user process itself, thereby completing the creation of a closed loop; S5: When the user sends capability call information to the capability space management subsystem CSpace, the capability space management subsystem CSpace allocates the capability address CPTR in the following manner: When allocating the capability address CPTR in the root capability node root_Cnode, directly find an idle position through the root_CNode bitmap in the root capability node and then return; When allocating the capability address CPTR in the multi-level information node capability CNode, first allocate it in the root_CNode bitmap. If the allocation is successful, return. If the allocation fails, find a bitmap allocation in the partial free CNode list partial_list. If the allocation is successful, return. If the allocation still fails, search all free CNode lists free_list. If the allocation is successful, return. If the allocation still fails, trigger the allocation mechanism of the secondary CNode to allocate the capability address CPTR, that is, create a CNode through the physical memory capability DRAM and add it to the partial free CNode linked list partial_list, and then allocate the capability address CPTR; The capability space management subsystem CSpace sends the assigned capability address CPTR to the CPTR parsing module for subsequent processing; S6: After the capability call is completed, the capability is reclaimed according to the following steps: 1) Determine whether the capability has sub-capabilities. If so, proceed to step 2), otherwise proceed to step 3); 2) Use the Revoke capability operation to delete the sub-capabilities derived from the capability, and then go to step 3); 3) Use the delete capability operation Delete to delete the current capability. The deletion process includes three situations: Case 1: If the capability has no recovery permission, the node will be deleted from the capability inheritance system, and the content of the slot will be processed; if the object deleted this time is a directly called object, the slot will be directly cleared; if the slot deleted this time is based on the inheritance system, it needs to be set to ZOMBIE type, and when the user state accesses the capability address CPTR again, the slot will be truly cleared; Case 2: If the capability has the right to recycle, and has a sibling capability and its end address does not overlap with the DRAM of the physical memory capability of the parent capability, then the capability is converted into a physical memory capability DRAM of the corresponding kernel object size, waiting to be allocated again or recycled together with the parent capability; Case 3: If the capability has the right to recycle, has a sibling capability and its end overlaps with the beginning of the physical memory capability DRAM of the parent capability, or has no sibling capability, then the capability and the physical memory DRAM of the parent capability are merged, and the physical memory DRAM of the parent capability is increased by the corresponding size.

2. The highly scalable microkernel security management method according to claim 1, characterized in that: The permissions in step S2 include: capability access permission cap_right, which indicates the permission to the current capability object; type access permission object_right, which indicates the permission to the kernel object pointed to by the capability; and mandatory access permission mac_level, which indicates the mandatory access control permission to the object resource.

Images