CN112784283A

CN112784283A - Capability management method and computer equipment

Info

Publication number: CN112784283A
Application number: CN201911088881.6A
Authority: CN
Inventors: 王楠; 张紫鹏
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2019-11-08
Filing date: 2019-11-08
Publication date: 2021-05-11
Also published as: KR20220085831A; AU2020379690A1; US20220261489A1; EP4044058A1; CA3157242A1; WO2021088744A1; EP4044058A4

Abstract

The application provides a capacity management method, a capacity management device, computer equipment and the like, and relates to the authority management of a kernel object in an operating system, such as the authority management of the kernel object in a microkernel architecture. Specifically, the method stores two types of information in the capability node of the capability owner: the method comprises the steps that information used for indicating that the capability is authorized out and information used for indicating the authorized capability are recorded, the incidence relation of the capability between an authorizer and an authorized person is established by recording the two types of information, the copying of the capability is avoided in the capability authorization process, the deletion of the capability is avoided in the process that the authorizer gives up the capability, and therefore the capability recovery and authorization are achieved while the deterministic delay is guaranteed. The method can be applied to a smart phone system or an unmanned system and the like.

Description

Capability management method and computer equipment

Technical Field

The present application relates to computer technologies, and in particular, to a method and an apparatus for managing capabilities, and a computer device.

Background

The operating system architecture (abbreviated as microkernel architecture) based on microkernels can be applied to various scenes such as cloud platforms, embedded devices, mobile devices, auxiliary driving, unmanned driving and the like. The microkernel architecture puts numerous components in a traditional operating system kernel (such as a macro kernel architecture Linux), such as a file system, a network protocol stack and the like, into a user-mode process to run, and reduces the real kernel function of the microkernel architecture to be very little. The microkernel architecture includes a user-mode process and a kernel. A user-mode process is a process that runs in user-mode. The kernel is responsible for managing critical resources and providing services for user mode processes, such as inter-process communication, page tables, interrupt control, and the like. The user-mode process requests services from the kernel through system calls. Since kernel resources and services are critical and access security needs to be guaranteed, the provisioning of kernel resources or services requires a security management mechanism to constrain.

The kernel uses kernel objects to abstract resources or services that it provides. The current microkernel architecture generally adopts a security mechanism (hereinafter, simply referred to as capability mechanism) based on capability (capability) to control the access of a user mode process to a kernel object. Specifically, the user mode process requests the kernel to access the kernel object through a system call, the request is firstly subjected to permission check of the capability mechanism, and the kernel starts to respond to the request after the permission check is passed.

The basic concept in the capability mechanism is capability. A capability is an unforgeable rights label that records the identity (e.g., number or memory address) of a kernel object, as well as the rights to access the kernel object. The permission check in the capability mechanism means: if a user mode process (hereinafter referred to as a process) wants to access a kernel object, the kernel needs to check whether the process obtains the capability of the kernel object, and if the process obtains the capability of the kernel object, the process can access the kernel object according to the authority recorded by the capability, otherwise, the process cannot access the kernel object. A process may obtain a number of different capabilities indicating that the process may access a number of different kernel objects. All capabilities acquired by a process are placed in a data structure called a capability node. Further, a process may share kernel objects to which it has access to other processes, i.e., capability authorization. Meanwhile, the process can also cancel the authority of accessing the kernel object by itself or other processes at any time, namely, the ability recovery.

To address the authorization and reclamation of capabilities, a capability copy and delete mechanism is commonly employed in the industry. Specifically, if a process a (also referred to as an authorizer) needs to share a kernel object O with a process B (also referred to as an authorized person), a capability C of the kernel object in its capability node is copied to a capability node of the process B. Thus, process B can access the kernel object O. Process B may also continue to perform sharing. In addition, in the process of copying the capability, the authority in the capability can be reduced. Copies of the aforementioned capabilities may also be referred to as derivatives.

Capacity recovery includes two cases: one is the ability of the authorizer to actively recover the authorization, and the other is the ability of the authorizer to give up. In order to accomplish capacity recovery, the foregoing derivatives are recorded, i.e., capacity C1 is derived from capacity C, and capacity C2 is derived from capacity C1. The data structure that records this derivation relationship is called a capability derivation tree. When an authorizer reclaims the authorization of a capability, all capabilities derived from that capability are deleted. When an authorized person actively relinquishes the authorization of a certain capability, the capability needs to be deleted in its capability node.

The prior art, although capable of authorizing and recovering capabilities, cannot guarantee deterministic latency. Specifically, since there is a copy of a capability, there may be multiple capabilities pointing to the same kernel object, so when an authorized person actively gives up authorization for a capability, there may be two cases: 1. when the capability is not the last capability pointing to the kernel object it contains, only the capability needs to be taken from the capability node; 2. when the capability is the last capability to point to the kernel object, the capability is deleted along with the kernel object. Otherwise, a memory leak may result because there is no other way to access the kernel object. Since the time consumption is different in the above different cases, it poses a great challenge to the analysis of the deterministic delay.

Disclosure of Invention

The present application provides a method for managing capabilities, and provides data structures, apparatuses, computer program products (e.g., operating systems), storage media, computer devices, and the like that implement the method. The management method provided by the application can ensure the deterministic time delay when the capacity is abandoned.

It should be noted that the capability management method provided in the present application may also be referred to as a rights management method, a kernel object management method, a capability-based kernel object management method, a capability recovery method, and the like.

First, concepts that may be present are introduced.

Operating the system: system software, which manages computer hardware and software resources, is also a cornerstone of computer systems. The operating system needs to handle basic transactions such as managing and configuring memory, prioritizing system resources, controlling input and output devices, operating the network, and managing the file system. The operating system may also provide an operator interface for a user to interact with the system.

Kernel: programs for managing data input and output requests from software, which are translated into data processing instructions for processing by a Central Processing Unit (CPU) and other electronic components in a computer, are the most fundamental parts of modern operating systems.

The kernel object is: is an abstraction of kernel-managed information, representing various information maintained by the kernel, such as thread control blocks, process page tables, process communication channels, etc. The kernel object is stored as a data structure in a memory block allocated by the kernel. The kernel objects are directly accessed by the kernel. The kernel provides an interface to allow user-mode processes to access kernel objects and uses a permission control mechanism to manage access to kernel objects by user-mode processes. It should be noted that the access of the user mode process to the kernel object is indirect, and the user mode process enters the kernel after calling the interface, and the kernel directly executes the access.

Capability: used to characterize the access rights of a certain kernel object. Two items of information are usually recorded in the competency: identification of kernel objects and access rights. A kernel object in a capability is a kernel object to which the capability points (or references). In other words, the capability represents the access rights of the kernel object. The identifier of the kernel object can be the memory address or number of the kernel object; the access rights may be read-only, read/write, etc. The kernel manages access to kernel objects by user-mode processes through capability-based security mechanisms. Specifically, only after obtaining a capability, a process may access the kernel object indicated by the capability, and needs to access according to the authority indicated by the capability. This capability is commonly named capability in existing microkernel systems.

Capability node: is a data structure for storing all the capabilities obtained by a process. The capability node itself is also a kernel object. In a microkernel architecture, such as the L4 family of microkernel architectures, the capability node is named cnode (capability node). All capability nodes are stored in a capability space (csspace).

Capability authorization (or capability sharing): the capabilities possessed by process a may be shared with process B so that process B may access the kernel object indicated by the capabilities. Capability authorization may also be referred to as kernel object authorization. Process a may be referred to as an authorizer and process B as an authorized person. The authorization of capabilities in the prior art is achieved through a copy (or derivative) of the capabilities. It should be understood that process a and process B are both generally user-mode processes herein. Rights can be modified during the copying of capabilities, e.g., process a may optionally grant only part of the rights to process B.

Capacity of recovery (or recovery authorization): process a revokes the capabilities granted to process B, i.e., the kernel object indicated by the capabilities is no longer shared.

Abandonment capability (or abandonment authorization): process B gives up the ability of process a to grant itself. The ability to reclaim and the ability to abandon may also be collectively referred to as ability reclamation, which is considered to be two different cases of ability reclamation.

The present application will now be described in terms of several aspects, it being understood that the following aspects may be practiced separately or in combination of any two or more of them. The following aspects may be realized and advantageous by reference to one another.

In a first aspect, the present application provides a data structure for managing capabilities, where the data structure includes capabilities and authorization information of the capabilities, the capabilities include an identifier of a kernel object and an access right, the authorization information of the capabilities includes first information indicating authorized capabilities and second information indicating capabilities authorized to go out, and neither the first information nor the second information is a capability.

In some implementations, the first information is used to find the authorized capability from a capability node of an owner of the authorized capability. The authorized capabilities are stored only in the owner's capability node.

In some implementation manners, the second information is used to find the authorized capability in the capability node where the second information is located. In some implementations, the second information further includes an authorization to go out, where the authorization is a part or all of the authorization to go out.

In some implementations, the second information is also used to indicate an authorized person of the ability to authorize egress.

In some implementations, the data structure can be stored as a kernel object in a corresponding storage space of the kernel. In particular, the data structure may be a capability node. The core may be a microcore.

In some implementations, the data structure may not include the first information, such as the data structure being present in or being a capability node of the authorizer. In some implementations, the data structure may not include the second information, such as the data structure being present in or being a capability node of an authorized person.

It should be understood that the authorizer and the authorizee are opposite roles, and the roles may be interchanged.

In some implementations, the first information and the second information can be an identification of the capability, or an identification of a container (e.g., a slot) that stores the capability (which can also be understood as a storage address of the capability), or the like. The first information and the second information are used to find the corresponding capabilities, but the first information and the second information are not the capabilities themselves.

Specifically, the first information and the second information may be M1 and M2 in fig. 2, respectively, or the first information and the second information may be M1 and M2 in fig. 3, respectively.

More specifically, the first information may be information 1 in CNode B or CNode C in fig. 4; the second information may be information 1 or information 2 in CNode a.

More specifically, the first information may be an identifier (or index) of uslot c stored in rslot c in fig. 5, and the uslot c may be found by using the identifier, and further, the content stored in uslot c may be accessed; the second information may be an identifier (or referred to as an index) of cap c stored in uslot c, and using the identifier may know that cap c is authorized to go out, and further, the second information may further include an identifier (or referred to as an index) of rslot, and using the identifier may know that cap c is authorized to the process where rslot c is located. It should be understood that in the implementation of fig. 5, deleting the first information or the second information may be implemented as deleting a container, i.e., a slot, storing the first information or the second information. There are many forms of implementation of the identification or index, and fig. 8 shows a specific implementation, but the present application is not limited thereto.

It can be seen that, unlike the prior art in which the capability node of the authorized person directly stores the authorized capability, the data structure provided in the present application indicates the authorized capability by storing the first information, i.e., the authorized capability can be found by the first information. When an authorized person gives up the capability, the kernel can directly delete the first information, so that the capability deletion is avoided, the uncertain condition of whether the kernel object needs to be deleted or not is avoided, and the deterministic time delay is ensured.

In addition, the data structure provided by the application also stores second information to indicate the authorized ability, so that an authorizer can directly delete the second information when recovering a certain authorized ability without a complex algorithm, and the recovery operation time is shortened.

Further, the same ability can be authorized to different authorized persons, and the second information is also used for recording which authorized person is, so that the authorized person can recover the ability of the authorized person by specifying the information of the authorized person, and the accuracy of recovery operation is improved.

In a second aspect, the present application provides a method for managing capabilities, the method executable by a kernel. The method may be initiated by an authorized person. This method can be considered as a method for achieving that the authorized person gives up the authorization of the capability. Specifically, the method comprises the following steps: receiving an abandoning request sent by an authorized person, wherein the abandoning request comprises a first identifier which is used for indicating the capability to be abandoned, and the capability to be abandoned is the capability authorized to the authorized person by the authorized person; and deleting first target information matched with the first identifier from the capacity node of the authorized person, wherein the capacity to be abandoned is only stored in the capacity node of the authorized person, and the first target information is used for finding the capacity to be abandoned from the capacity node of the authorized person.

Here, the capability node of the authorized person adopts the data structure mentioned in the foregoing aspect, and the first target information is used for indicating the capability to be relinquished, but not the capability to be relinquished itself.

In some implementations, deleting the first target information may be implemented by deleting a container storing the information, such as a delete slot in the embodiment of fig. 5.

Therefore, when an authorized person needs to give up a certain authorized capability, the kernel can directly delete the information corresponding to the capability in the capability node of the authorized person, and the capability is not deleted because the capability is not stored, so that the uncertain condition of whether the kernel object needs to be deleted or not does not occur, and the certainty of time delay is ensured.

In a third aspect, the present application provides a method for managing capabilities, the method executable by a kernel. The method may be initiated by an authorizer. This method can be considered as one method of achieving the authorizer's ability to reclaim. Specifically, the method comprises the following steps: receiving a recovery request sent by an authorizer, wherein the recovery request comprises a second identifier, the second identifier is used for indicating the capacity to be recovered, and the capacity to be recovered is the capacity authorized by the authorizer to an authorized person; and deleting second target information matched with the second identifier from the capability node of the authorizer, wherein the capability to be recovered is only stored in the capability node of the authorizer, and the second target information is used for searching the capability to be recovered from the capability of the authorizer. The second target information is used for indicating that the capacity to be recovered is authorized to be recovered.

Here, the capability node of the authorizer employs the data structure mentioned in the foregoing aspect, and the second target information is used for indicating the capability to be recycled, but not the capability itself.

In some implementations, the second target information may be independent of all capabilities of the authorizer. In other implementations, the second target information may be a tag or a suffix after the capability, and deleting the second target information may be deleting the tag or the suffix.

It can be seen that, when the authorizer recovers a capability, because the capability is only stored in the capability node of the authorizer, unlike the prior art in which the kernel has to execute a capability deletion operation in the capability node of the authorizer, the kernel only needs to delete the second target information corresponding to the capability from the capability node of the authorizer, thereby simplifying the recovery operation and shortening the capability recovery time. It should be noted that the kernel may also perform the deletion operation at the capability node of the authorized person according to the actual situation, but it is not required to be as complicated as the deletion capability in the prior art.

In some implementations, when the authorizer can authorize the same capability to different authorizers, the second target information stored in the authorizer's capability node indicates not only the capability authorized to go out, but also to which authorizer the capability is authorized. The second identifier is also used to indicate a particular authorized person (referred to as the target authorized person) if the authorizer is to recover the capabilities of the target authorized person. Therefore, the ability of accurately recovering the authorization to a certain authorized person can be realized, the ability of recovering all authorized persons is not needed in the prior art, and the authorized persons without the recovery ability are endowed again, so that the recovery time is shortened.

It should be noted that the first target information may be considered as information that matches the requirement of the requester in the plurality of first information, and the second target information may be considered as information that matches the requirement of the requester in the plurality of second information, so that the implementation of the first target information and the second target information may refer to the implementation of the first information and the second information in the first aspect, specifically refer to the implementation in fig. 3, fig. 4, fig. 5, and the like, and details thereof are not repeated here.

In a fourth aspect, the present application further provides a method for managing capabilities. The method may be performed by a kernel. The method may be initiated by an authorizer or an authorized person, and may be considered to implement authorization of the capability. Specifically, the method comprises the following steps: receiving an authorization request sent by an authorizer, wherein the authorization request is used for indicating that target capabilities in the authorizer's capability nodes are authorized out, and the target capabilities are only stored in the authorizer's capability nodes; recording authorization information in a capability node of the authorizer, wherein the authorization information is used for indicating that the target capability is authorized; recording authorized information in the ability node of the authorized person, wherein the authorized information is used for searching the target ability from the ability node of the authorized person.

The recording order of the authorized information and the authorization information is not limited. The authorized information and the authorization information in this aspect are similar to the first target information and the second target information in the foregoing aspect, respectively, and are not the capabilities themselves, and may be information for identifying or searching for the capabilities, such as an index of the capabilities or an index of a storage structure in which the capabilities are located.

With this authorization method, the capability is stored only in the capability space of the owner of the capability, i.e., the authorizer, and there is no need to copy the capability into the capability space of the authorized person, thereby shortening the execution time of the authorization.

In some implementation manners, the authorization information may also be used to indicate that the target capability is authorized to the authorized person, so that when the same capability is authorized to different authorized persons, different authorization information exists, and thus, when an authorized person recovers the capability, the authorization information including a certain authorized person may be deleted in a targeted manner, so as to achieve accurate recovery.

In some implementations, the method further includes: receiving an abandoning request sent by the authorized person, wherein the abandoning request comprises a first identifier, and the first identifier is used for identifying the target capability or identifying the authorized information; deleting the authorized information from the authorized person's capability node.

When the target capability is abandoned by the authorized person, the kernel does not need to delete the capability, only needs to delete the authorized information, and ensures the certainty of the time delay.

In some implementations, the method further includes: receiving a recycling request sent by the authorizer, wherein the recycling request comprises a second identifier, and the second identifier is used for identifying the target capability or the authorization information; deleting the authorization information from the authorizer's capability node.

When the authorizer recovers the capability, the kernel does not need to execute the operation of deleting the capability because the capability node of the authorized does not store the capability, and only the authorization information needs to be deleted, namely the relationship between the capability and the authorized is released, so that the recovery time is shortened.

The approach provided by the foregoing aspect is from a kernel perspective, and is described below from a user mode. Reference is made to the preceding aspects for the core implementation portions referred to in the following aspects.

In a fifth aspect, the present application provides a capacity management method, including: an authorizer sends an authorization request (for example, an interface Grant is called, that is, an authorization request is sent) to a kernel, the authorization request includes an authorization parameter (for example, cref), and the first parameter is used for indicating a capability to be authorized; the authorization request is used for instructing the kernel to authorize the to-be-authorized capability to an authorized person; and obtaining a recycling parameter (for example, uref) returned by the kernel, wherein the recycling parameter is used for the authorizer to manage (for example, recycle) the authorization.

In some implementations, the method further includes: the authorizer sends a recycle request (e.g., call interface Revoke, i.e., send a recycle request) to the kernel, the recycle request including the recycle parameter (e.g., uref) that is used by the kernel to perform capacity recycling.

In some implementations, the method further includes: the authorized person sends a prepare request to the kernel (for example, calling the interface preparGrant, that is, sending a prepare-to-receive authorization request); obtaining an abort parameter (e.g., rref) returned by the core, the abort parameter for the authorized person to manage (e.g., abort) the authorized capability.

In some implementations, the method further includes: the authorized person sends a yield request (e.g., call interface Reject, i.e., send yield request) to the kernel, including the yield parameter (e.g., rref) that is used by the kernel to perform a capability yield.

In addition to data structures and methods, the present application also implements apparatus, computer storage media and computer program products for methods, Application Program Interfaces (APIs), and the like.

In a sixth aspect, the present application provides a computer device comprising a hardware layer and an operating system running on the hardware layer, the operating system comprising a kernel for performing the method as provided in any one of the preceding aspects. The authorizer and authorizee may be processes within the operating system or processes of an application. The kernel may be a microkernel or a macrokernel. The computer device may be a terminal device, such as a smart phone, and the computer device may also be an intelligent device applied to unmanned driving, or a virtual reality/augmented reality/mixed reality device, an artificial intelligence device, and the like.

In a seventh aspect, the present application provides an apparatus for managing capabilities, the apparatus comprising one or more modules configured to implement the method provided in any one of the preceding aspects. In some implementations, the apparatus may be an operating system, or a kernel of an operating system. The kernel may be a microkernel or a macrokernel. In some implementations, the apparatus may be a user-mode application.

In an eighth aspect, the present application provides a computer device comprising one or more processors and a memory for storing computer-readable instructions, the one or more processors for reading the computer-readable instructions to implement the method provided by any one of the preceding aspects. The computer device may be a terminal device, such as a smart phone, and the computer device may also be an intelligent device applied to unmanned driving, or a virtual reality/augmented reality/mixed reality device, an artificial intelligence device, and the like.

In a ninth aspect, the present application provides a computer storage medium for storing a computer program which, when executed by one or more processors, implements the method provided by any one of the preceding aspects.

In a tenth aspect, the present application provides a computer program product for storing a computer program that, when executed by one or more processors, implements the method provided by any of the preceding aspects.

In some implementations, the computer program product is an operating system or a kernel of an operating system. In other implementations, the computer program product is an application.

In an eleventh aspect, the present application further provides one or more APIs. These APIs may be provided by the kernel to the user-mode in the form of system calls for user-mode processes to call to implement any one or more of the capability management methods provided herein.

The scheme provided by the application can be applied to a micro-kernel architecture and can also be applied to a macro-kernel architecture. The capacity management method provided by the application can be used for realizing authorization and recovery of the access authority of the kernel object and simultaneously ensuring deterministic time delay.

Drawings

The drawings that accompany the present application will be briefly described as follows. It is to be expressly understood that the drawings described below are only illustrative of some embodiments of the invention.

FIG. 1 is a schematic diagram of a prior art process for copying capabilities;

FIG. 2 is a schematic diagram of a capability node provided herein;

FIG. 3 is a schematic diagram of another capability node provided herein;

FIG. 4 is a diagram illustrating a plurality of capability nodes provided in the present application under a capability authorization scenario;

FIG. 5 is a schematic diagram of a more specific capability node provided herein;

FIG. 6 is a schematic diagram of a capability authorization process;

FIG. 7A is a schematic diagram of a process for recovering capabilities of an authorizer;

FIG. 7B is a diagram illustrating a process by which an authorized person relinquishes capabilities;

FIG. 8 is a schematic diagram of a more specific capability node provided herein;

FIG. 9 is a schematic diagram of a logical structure of a capacity management apparatus provided in the present application;

fig. 10 is a schematic diagram of a logical structure of a computer device provided in the present application.

Detailed Description

For the sake of easy understanding of the embodiments of the present application, the technical concept presented in the present application will be first described below. It should be understood that these technical concepts are applied to the embodiments to be described later in this application, but these embodiments are only a part of the embodiments of the solution provided by the present invention, so these technical concepts are not necessarily applied to all embodiments of the present application.

Macro kernel: an operating system kernel architecture is characterized in that the whole kernel program runs in a kernel space (kernel space). The macro core alone provides a unified high-level virtual interface to computer hardware relative to other types of operating system architectures, such as micro-core architectures or hybrid-core architectures. It provides a series of system calls to implement various operating system services such as process management, program concurrency, memory management, various drivers, etc.

Microkernel: another operating system kernel architecture is characterized by running as few functions as possible in a kernel space (kernel space) and providing the necessary mechanisms to implement an operating system. These mechanisms include address space management, thread management, interprocess communication, and the like. Compared with the macro kernel, the micro kernel puts numerous components such as a file system, a network protocol stack and the like in a user mode to run, and reduces the functions of the kernel to be very few.

And (4) process: and running entity of the program. A program is a description of instructions, data, and their organization, and a process is an execution entity of the program. Multiple threads can be concurrent in a process, each thread executing a different task in parallel. The thread may be an actual operation unit of the process, but the embodiment of the present application does not explicitly distinguish the thread from the process, and the process is used instead in the description process.

And (3) user mode process: a process running in user mode, not kernel space. The functions implemented by the user mode processes and the kernels are implemented by software codes, so that the method executed by the processors can also be regarded as a method executed after the processors read the software codes.

And (3) determining time delay: the delay refers to the execution time of the service, and the deterministic delay refers to the fact that the fluctuation of the execution time of the service needs to be guaranteed within a limited range. For example, for an unmanned or assisted driving system, an obstacle needs to be identified in front, the time for identifying the obstacle needs to be controlled within a fluctuation range, otherwise, a perception service cannot be planned, and a control service after perception cannot give a mechanical reaction, such as braking, within a certain time. The deterministic delay of the whole system is determined by all the components of the system together. The deterministic latency of the operating system is the root of the deterministic latency of the entire system, which requires the kernel to respond to user-mode processes within a certain time frame.

Derivation of the capabilities: if the process a needs to share the kernel object O with the process B, the capability C of the kernel object in the capability node of the process a is copied to the capability node of the process B as the capability C1. Thus, process B can access the kernel object O. Capability C1 is derived from capability C. Process B may also continue to perform sharing, i.e., process B may also copy capability C1 into process C's capability node as capability C2. Capability C2 is derived directly from capability C1 and indirectly from capability C. C. This relationship of C1 and C2 is a derivative of the capability.

Inter-process communication (Inter-process communication): is a communication mechanism provided by an operating system that allows processes to pass messages to and from each other.

The authorization of capabilities in the prior art is achieved through a copy (or derivative) of the capabilities. The copying of capabilities is accomplished through interprocess communication. The capabilities to be authorized are stored in the authorizer's send buffer. The sending cache may also store the number of capabilities, multiple capabilities may be granted at one time. The authorized person receives the capabilities by receiving the message and provides space to store the capabilities.

Specifically, fig. 1 is a process example of capacity copying. Suppose process a wants to delegate capability cap1 to process B. The cap1 records the access right to the kernel image O. cap1 is stored in a slot of the capability node CNode a of process a.

Step 1: process a sends a message to process B that includes the index (or identity) of packet cap 1. The authorization operation is initiated by process a, sends a message by invoking a system call, and specifies an index of capabilities in the message. The transmission of the message is completed by the kernel.

Step 2: process B applies for a new memory cell in its CNode B and gets the index of the memory cell. The operation is initiated by a process B, a system call is called to enter a kernel, and the kernel allocates a storage unit slot (slot) in a CNode B. The slot is a storage unit of storage capability commonly used in existing microkernel operating systems.

And 3, step 3: process B receives the message and designates the slot allocated in the previous step as the storage location of capabilities. The operation is initiated by process B, calls the system call to receive the information, and specifies the slot of the storage capability.

And 4, step 4: the kernel copies the contents of cap1 into the slot, becoming cap 11. Since cap 11 includes the kernel object O index, the kernel object O can be indexed according to the slot after step 4.

And 5, step 5: the kernel records the derivative relationship of cap1 and cap 11. There are various ways to record the derivation relationship, such as recording the correspondence between the index of cap1 and the index of cap 11, or recording the correspondence between the slot storing cap1 and the slot storing cap 11.

The above is merely an example, and the order of the steps may be changed in a specific implementation, for example, the order of the step 1 and the step 2 may be exchanged, or the authorized original requester may be an authorized person, and the like, and the description is not listed in this application.

The prior art cases involving capability deletion include at least two. The first case is the authorizer's ability to reclaim. Specifically, an authorizer initiates a request for recovering the capability to the kernel and specifies an index of the capability to be recovered; the kernel deletes all capabilities derived from the capability according to the derivation relationship of the capability, including directly derived and indirectly derived capabilities. The second case is where the authorized person gives up authorization. Specifically, an authorized person initiates a request for deleting the capability to the kernel, and specifies the capability to be deleted by specifying an index of a slot, where the slot is a slot for storing the capability to be deleted; the kernel removes capabilities from the CNode of the authorized person.

Although the capability mechanism provided by the prior art can realize the authorization and recovery of the capability, the deterministic delay cannot be guaranteed. Specifically, since there is copy in the capability authorization process, there may be a case where multiple capabilities point to the same kernel object, so when an authorized person actively gives up authorization of one capability, there may be two cases: 1. when the capability is not the last capability pointing to the kernel object it contains, only the capability needs to be taken from the capability node; 2. when the capability is the last capability to point to the kernel object, not only the capability is deleted, but the kernel object is also deleted, otherwise, a memory leak may result because the kernel object is not otherwise accessible. Since the time consumption is different in the above different cases, it poses a great challenge to the analysis of the deterministic delay. When analyzing the time delay of a program, for the behavior of deleting the capability, because it is uncertain whether the last capability refers to the kernel object, the behavior can be analyzed only according to the worst case, that is, the time delay is calculated according to the case that the kernel object is triggered to be recycled, which causes the case that the result of the time delay analysis is always the worst case, but the result is not always consistent with the actual operation result. Therefore, this latency analysis is inaccurate, in other words, the latency of actively relinquishing capacity is indeterminate, which results in the latency of the entire program being difficult to determine.

In view of the above problems, the present application provides a capability management method that proposes the concept of a capability owner (owner). The ability owner realizes centralized management of the ability by storing the authorization information in the own storage space, thereby realizing the deterministic time delay of the ability recovery. Here, the authorization information includes information of an authorized capability and information of an authorized capability.

Fig. 2 is a schematic diagram of a logical structure of a storage space of a capability owner according to this embodiment. The capability owner is a process, and the storage space of the process for storing the authorization information is a capability node. As shown in fig. 2, the capability node includes three kinds of information: "capability", "authorized-out capability information M2", and "authorized capability information M1". For example, if a capability is authorized to go out, the capability is recorded in "authorized capability information", and if a capability is authorized from other processes, the capability is recorded in "authorized capability information".

Neither the "authorized-out capability information M2" nor the "authorized capability information M1" recorded in the capability node is the capability itself, and is authorization information indicating the two authorization relationships. Using this information, the corresponding capabilities can be indexed. Specifically, "authorized-to-go capability" is information indicating that the capability is authorized to go out. For example, a capability may be identified as being authorized, or an additional data structure may store an identification of the authorized capability, as described in the embodiments below. Similarly, "authorized capability information M1" is information for indexing the authorized (in-coming) capability, with which the capability stored in the authorizer's capability node can be found.

It should be understood that in a particular operating system, not all processes 'capability nodes need to contain the above three pieces of information, and that some processes' capability nodes may not have the ability to authorize them and/or the ability to authorize them.

In this application, a process is the owner (owner) of the "capabilities" included in its capability node. According to the prior art, once authorized, a 'capability' is copied to a capability node of other processes, but the method provided by the application does not need to copy the capability, and only needs to record the authorization relationship through 'authorized capability information' and 'authorized capability information'. So a capability, with or without authorization, has only one copy, only one "owner".

There are a number of ways to determine the owner of a capability, such as by the kernel giving the capability to a process, i.e., creating the capability in the process' CNode; or when a process creates a kernel object, the corresponding capability of the kernel object is also created at the same time, and the process is the "owner" of the capability. The manner in which the owner of the capability is determined is not limited in this application. In addition, the owner of a capability allows changes, such as the owner of a capability can change from process A to process B, which does not affect the methods provided herein.

It should be noted that, in this embodiment, only one capability of one kernel object corresponds to the kernel object, and the kernel objects correspond to the capabilities one to one. Each capability has an owner and is stored in the owner's capability node. However, in other embodiments, the entire operating system does not exclude the case where there are multiple capabilities in a part of kernel objects, and the capabilities are stored in multiple capability nodes respectively, and this need not be the case, and the present application does not limit this according to actual requirements.

FIG. 3 is another embodiment of a memory space. As shown, a plurality of capabilities are stored in the capabilities, some of which may be identified as authorized by the addition of additional information (M2). In particular, the additional information may include to whom the capability is authorized, and the rights of the authorization. The ability to add no such additional information may be considered unauthorized, although it is also possible to add another additional information identifying the ability to be unauthorized.

Fig. 4 is an example of granting the capability to the authorized person by the authorizer, and fig. 4 shows that the process a grants the capability C stored by itself to the process B and the process C, respectively. As shown, CNode a stores two pieces of information, information 1 indicates that capability c is authorized for process B; information 2 indicates that capability C is authorized for process C. CNode B stores therein information 1 indicating that authorization to obtain capability c of process a is obtained. CNode C stores therein information 1 indicating that authorization to obtain capability C of process a is obtained. If process B or process C relinquishes authorization of capability C, the kernel may delete information 1 in CNode B or CNode C. If the process A recovers the capability c authorized for the process B, the kernel can delete the information 1 in the CNode A; if process a recovers the capability C granted to process C, the kernel may delete information 2 in CNode a.

Fig. 2 to fig. 4 illustrate data structures and possibly stored information of the capability nodes provided in the present application, and there are many specific implementations of the data structures or the information stored in the data structures, and the following embodiments illustrate specific implementations of the solutions provided in the present application by taking data structures commonly used in microkernel systems as examples. It is to be understood that the following specific implementations are merely examples, and those skilled in the art can easily make changes to the data structures or information forms based on these implementations and implement the solutions provided in the present application.

Fig. 5 is a schematic diagram of a more specific logic structure of a capability node according to an embodiment of the present application. CNode A is the capability node of process A, and CNode B is the capability node of process B. The two capability nodes respectively contain three data structures: capability tables (called "ctable" for short), authentication tables (called "utable" for short), and reference tables (called "rtable" for short).

It should be noted that "table" is only named as three data structures, but the data structures can be implemented in various forms in actual implementation and are not limited to tables.

The ctable is used to record the capabilities that a process has. Each capability is stored in a slot, referred to herein as cslot. Capabilities are only directly accessible by the kernel. Each capability has a unique reference, called cref. The user mode process may specify the capabilities to be accessed via cref. For example, when process A initiates authorization, cref is used to specify the capabilities to be authorized. It should be understood that only cslot is shown for convenience of illustration, and there may be more than one in actual implementation, and similarly, uslot and rslot may also be more than one.

It should be noted that in other embodiments, multiple capabilities may be stored in one slot as long as the capabilities can be distinguished.

The utable records capability authorization information, or information of authorized capability. Capability authorization information is stored in uslot. The capability authorization information records the capabilities that are authorized, the rights that are authorized, and to whom the capabilities are authorized. There are several ways to record the authorized capability: such as a reference cref for the direct recording capability or an index to cslot where the recording capability is located. Each uslot has a unique reference, called uref. The user mode process specifies the uslot it is to access by uref. For example, when an authorizer reclaims authorization, the uref may be used to specify the capabilities to be reclaimed.

The rtable records authorized information. Authorized information is stored in rslot. Authorized capability information is recorded in rslot. Each rslot has a unique reference called rref. The user mode process specifies by rref the rslot it is to access. For example, when relinquishing authorization, the user mode process may use rref to specify the capabilities to relinquish. The corresponding kernel object is accessed, also specified by rref. The rslot may also have an index that identifies the location of the rslot in rtable.

It should be noted that, in this embodiment, what is stored in uslot and rslot is not a capability, but a capability corresponding to the capability can be found according to the information stored in uslot and rslot. Only the rtable in CNodeB is shown in the figure, and it is understood that the CNode a can be similarly implemented if the rtable exists.

Because uslot and rslot record the information of the authorized capability and the authorized capability, respectively, in the example shown in fig. 3, uslot of CNode a and rslot of CNode B have a corresponding relationship, that is, corresponding rslot can be found according to uslot, and corresponding uslot can be found according to rslot.

Further, a capability may be authorized multiple times, and multiple uslots may correspond to it, using uref to specify which authorization to reclaim in particular. As shown in FIG. 3, two uslots, uslot B1 and uslot B2, are exemplarily depicted in CNode B. uslot B1 records a capability granted by process B to process C, uslot B2 records that the capability granted by process B to process D, and the granted rights may be the same or different. Thus, two authorizations of a capability are recorded with two uslots, respectively. When process B needs to reclaim the capabilities granted to process D, uslot B2 can be deleted by the reference uref of uslot B2.

When an authorizer reclaims capabilities, the prior art would use an index of capabilities, such as cref, to specify the capabilities that need to be reclaimed, which would reclaim all authorizations for one capability at a time. However, in the method provided by this embodiment, different grants with the same capability correspond to different uslots, so that the grant to be recovered can be specified by referring to the uslot, and thus fine-grained and more accurate grant recovery can be achieved.

It should be understood that if the system does not require such accurate reclamation, or if the system sets a capability to be authorized only once, the method provided by the present application may also specify the capability to be reclaimed by reference to the capability cref.

Fig. 6 is an example of a capability authorization process based on fig. 5. Suppose the capability to be authorized out is the capability cap c of the process a, the cap c is stored in a cslot c of the ctible, and the kernel object corresponding to the cap c is the kernel object o. As shown, the capability authorization process includes:

step 1: process B calls a system call to initiate a request grant operation. Specifically, after process B calls a system call, the kernel allocates an item rslot c in CNode B's rtable, and returns the reference rref of the rslot c to process B. Here, rslot c denotes rslot corresponding to cap c.

Step 2: process a invokes a system call to initiate an authorization operation. Specifically, after process a calls a system call, the kernel allocates an entry, uslot c, in the utable of CNode a. Here uslot c denotes uslot corresponding to cap c.

And 3, step 3: the kernel records the index of cap c in uslot c. The purpose of this step is to establish the relationship between uslot c and cap c, and record that the authorized capability is cap c.

And 4, step 4: the kernel records the index of uslot c in rslot c, and further records the index of rslot c in uslot c. The kernel returns the reference uref of uslot to process A. The purpose of this step is to establish a link between uslot c and rslot c, noting that cap c is authorized into rslot c, while rslot c's authorization is derived from uslot c.

It should be understood that in an operating system, a user mode process enters a kernel mode through a system call, then the kernel executes a program, and after the execution is completed, the user mode process is returned.

After the capability authorization process is executed, the process B may access rslot c according to rref, then access uslot c according to the information recorded in rslot c, and then access cap c according to the information recorded in uslot c.

After the authorization is completed, the process B accesses the kernel object o as follows: process B specifies with rref of rslot c that it is to access kernel object o. The kernel finds the corresponding rslot c from CNode B of process B according to rref, and then finds the corresponding uslot c (in CNode A of process A) according to rslot c. The access rights to kernel object o are recorded in uslot c (here the rights granted to process B are recorded). If the operation requested by process B is not allowed by the permissions in uslot c, then this access is denied, otherwise, access is allowed. It is also possible that the uslot c does not record the access right of the kernel object, and then the kernel can find the cap c according to the index of the cap c recorded in uslot c, and determine whether the access can be executed according to the right recorded in the cap c.

It should be noted that the information recorded in uslot c and rslot c only needs to ensure the ability of recording the authorized exit or the relationship between the authorized abilities, that is, it is ensured that the authorized person can find the corresponding ability, and the information is not limited to only recording the indexes of each other, and may further include other information or record other information (for example, directly recording the references of each other).

Further, fig. 7 is an example of a capacity recovery process based on fig. 5. Fig. 7(a) is a process of recovering the capability authorization by the process a. Fig. 7(B) is a process in which process B gives up the capability authorization.

As shown in fig. 7(a), the process a deletes uslot c, and can recycle the cap c authorized for the process B.

It should be noted that rslot c does not need to be deleted in this embodiment. Deleting uslot c has already released the authorization because process B has no access to the corresponding capabilities using uslot c's uref. In other embodiments, it is contemplated that rslot c may be deleted, but not as a mandatory requirement.

As shown in FIG. 7(B), process B deletes rslot c, and relinquishes cap c's authorization. Similarly, uslot c need not be deleted at the same time.

It should be noted that a slot is similar to a storage container, and deleting uslot c or deleting rslot c means deleting both the data stored therein and the structure (the structure itself is also data). In other embodiments, only the data stored in the container may be deleted, leaving the container.

It can be seen that, with the method provided in this embodiment, in the process of giving up authorization by an authorized person, the authorized person only needs to delete the corresponding rslot, does not need to delete the capability, and does not involve deletion of the memory object, so that the time delay can be determined. Moreover, only the rslot is deleted, and compared with the prior art, the time for deleting the capability and judging whether the capability is the last capability is also shorter.

In addition, because the capability is only held by the owner, the owner can delete the kernel object or the capability corresponding to the capability at any time, so that the management and control of the kernel object are more centralized and effective. When the owner of the capability deletes the capability, the kernel object must be deleted, and the time delay can also be determined.

Furthermore, the owner can record different authorization information of the same ability authorization to different processes, so that when the ability is recovered, a certain authorization can be accurately recovered. In the prior art, all the authorizations are required to be recovered firstly when the situation is treated, and then the authorizations which do not need to be recovered are granted again, so that compared with the prior art, the recovery method provided by the embodiment is more accurate, and the time consumption is less.

In the prior art, when an authorizer recovers the capability, since there may be a cascade authorization, for example, the process a copies its capability to the process B, and the process B copies the capability to the process C, when the process a recovers the authorization, it is necessary that the corresponding capability of the process C is also recovered. When the authorizer recovers the authorization, the number of rights to be recovered is uncertain. To achieve deterministic latency, the entire reclamation algorithm can be quite complex. By adopting the method provided by the application, an authorizer only needs to delete the authorization relation record when recovering the authorization, cascade recovery cannot be triggered, and deletion of the kernel object cannot be triggered, so that a responsible recovery algorithm is not needed, and the recovery speed is higher than that of the prior art.

The power management method provided herein is described below in a more specific embodiment implemented in a microkernel. As shown in FIG. 8, in a microkernel system, the capability mechanism is implemented based on three tables. In CNode, data structure maps (maps) are used to implement the ctable, utable and rtable, with one index corresponding to each element in the three tables. In other embodiments, the three tables may be implemented using other data structures, such as sets or arrays.

A ctable: realized by a map, the index is a positive integer and the value is capability. Each capability stores two pieces of information: a) a reference to a kernel object; b) rights to access kernel objects. The capability reference cref is represented by a 64-bit integer, with the first 32 bits being the index of its owner, CNode, and the last 32 bits being the capability index in its owner, CNode, disable. The index of CNode is the number of CNode in CSpace.

As shown in FIG. 8, CNode A has an index of 0x01, cap c has an index of 0x03 in the ctable of CNode A, and cap c has a cref of 0x 0000000100000003.

utable: implemented by a map, the index is a positive integer and the value is table _ node. Each table _ node stores four pieces of information: a) authorized capabilities are indexed in the ctable; b) an authorized right; c) an index of the CNode of the authorized person; d) index of rtable _ node in rtable in authorized person CNode. The reference uref of the utable _ node is represented by a 64-bit integer, the first 32 bits are the index of CNode, and the last 32 bits are the index of utable _ node in utable.

As shown in FIG. 8, the index of CNode A is 0x01, and the index of utable _ node c in utable is 0x04, so the uref corresponding to utable _ node c is 0x 0000000100000004.

rtable: realized by a map, the index is a positive integer and the value is rtable _ node. Each rtable _ node stores two parts of information: a) an index of the authorizer's CNode; b) the index of the utable _ node in the authorizer CNode in utable. The reference rref of the rtable _ node is represented by a 64-bit integer, the first 32 bits are the index of CNode, and the last 32 bits are the index of the rtable _ node in rtable.

As shown in FIG. 8, the index of CNode B is 0x02, and the index of rtable _ node c in rtable is 0x05, so the reference rref of rtable _ node c is 0x 0000000200000005.

In this embodiment, to implement the authorization of cap c, the specific implementation steps are as follows:

step 1: the kernel allocates one rtable _ node c in the rtable of CNode B. Thereafter, process B gets the reference rref for the rtable _ node c.

Step 2: the kernel allocates an utable _ node c among the utables of CNode a. Thereafter, process A gets the reference uref for this utable _ node c.

And 3, step 3: the kernel records the index of cap c in the ctable in the utable _ node c and the right to authorize out. Optionally, if the authority is not modified in the authorization process, the authorized authority may not be recorded.

And 4, step 4: the kernel records a) the index of table _ node c in CNode A; b) index of CNode a. Further, the kernel records a) the index of rtable _ node c in CNode B in utable _ node c; b) CNode B index.

It should be noted that the combination of the index of table _ node c in CNode a and the index of CNode a can be regarded as the reference uref of table _ node c; similarly, the combination of the index of table _ node c in CNode B and the index of CNode B can be considered as the reference rref of table _ node c. In the embodiment, the information composing the reference is stored separately, and the purpose can be achieved. In an actual implementation, uref and rref may also contain other information, such as identification information, for identifying which kind of reference it is.

After executing the above authorization flow of cap c, the information stored in table _ node c includes: a) index 0x03 of capability cap c; b) authorized rights, assumed to be read-only; c) index 0x02 of CNode B; d) index 0x05 in table _ node c. The information stored in rtable _ node c includes: a) index 0x01 of CNode A; b) the index of table _ node c in table 0x 04.

It will be readily appreciated that there are variations of the foregoing implementation, such as where the uref of utable _ node c can be recorded in rtable _ node c, thus including both the index of CNode a and the index of utable _ node c in CNode a.

It should be noted that table _ node in this implementation is a specific implementation of uslot in the foregoing embodiment; rtable _ node is a specific implementation of rslot in the previous embodiment.

If process A wants to recover authorization, it calls the system to delete utable _ node c corresponding to uref. If process B wants to give up authorization, it calls the system to delete the rtable _ node c corresponding to rref.

The embodiment may further provide a new Application Program Interface (API) (i.e. the foregoing system call), so that the user mode process can implement the foregoing capability authorization and capability recovery process:

interface preparGrant: for an authorized person to prepare to receive authorization. Specifically, the caller gets a rref and uses the rref to access the received capability after completion. For example, process B may invoke the interface in step 1 described above.

Interface Grant: the authorizer initiates authorization. Specifically, the caller specifies the authorized capability with cref and gets a uref. The caller then manages this authorization using uref, such as reclaim authorization. For example, process a may invoke the interface in step 2 above.

Interface Revoke: the authorizer recovers the authorization. Specifically, the caller uses the uref to specify the authorization to reclaim. For example, process A may invoke this interface upon the aforementioned reclaim authorization.

Interface Reject: the authorized person gives up the authorization. Specifically, the caller uses rref to specify the authorization to relinquish. For example, process B may invoke the interface when forgoing authorization

It should be noted that the names preparGrant, Grant, Revoke, and Reject of the interface are only examples, and the application is not limited thereto.

For the sake of simplifying the application document, the process of this embodiment is described in a simplified manner, and for more implementations, such as authorization initiation, etc., reference may be made to the foregoing embodiment.

It can be seen that, in the prior art scheme, an authorized person gives up authorization in a manner of deleting a capability, and since there is a copy of the capability, there may be multiple capabilities of a kernel object pointing to it, resulting in an uncertain time delay of deleting the capability. In this embodiment, authorization is accomplished by storing the authorization relationship for the capabilities, rather than by a copy of the capabilities. The method is realized by deleting the record of the authorization relationship when the authorized person gives up the authorization, and the deterministic time delay can be realized.

Furthermore, by using the method provided by the application, each kernel object only has one capability to point to the kernel object, and when one capability is deleted, the kernel object pointed to by the capability is deleted at the same time. In other words, the delete capability is only required when a kernel object needs to be deleted.

Furthermore, all the capabilities are held by the owner of the system, and the system can manage the single authorization of a certain time by modifying the authorization relation record, so that more accurate, faster and finer-grained capability management is realized.

In summary, the method provided by the application can effectively support active sharing and recovery of the kernel object while ensuring deterministic time delay, realize isolation of process resources, maintain flexibility of authority management, and improve efficiency of operations such as capability authorization and capability recovery.

Please refer to fig. 9, which is a schematic diagram of a logic structure of a capacity management apparatus according to the present application. As shown, the capacity management device 100 is located in the kernel of the whole computer system, and a user mode process A, a user mode process B and other processes can use the method provided by the capacity management device 100 through system call. The kernel stores a capability node A of a user mode process A and a capability node B of a user mode process B, and all the capability nodes are stored in a capability space. In this embodiment, a process a is taken as an authorizer, and a process B is taken as an authorized person.

The capability management apparatus 100 includes an authorization module 101, an abandonment module 102, and a recovery module 103, which are respectively used for implementing authorization of a capability, abandonment of a capability, and recovery of a capability.

The authorization module 101 is configured to receive an authorization request sent by a process a, where the authorization request is used to instruct that a target capability in a capability node a is authorized, and the target capability is only stored in the capability node a; recording authorization information in the capability node A, wherein the authorization information is used for indicating that the target capability is authorized; recording authorized information in a capability node B, wherein the authorized information is used for searching the target capability from the capability node A.

The abandoning module 102 is configured to receive an abandoning request sent by the process B, where the abandoning request includes a first identifier, the first identifier is used to indicate a capability to be abandoned, and the capability to be abandoned is a capability that the process a authorizes to the process B; and deleting first target information matched with the first identifier from the capability node B, wherein the capability to be abandoned is only stored in the capability node A, and the first target information is used for finding the capability to be abandoned from the capability node A.

The recovery module 103 is configured to receive a recovery request sent by a process a, where the recovery request includes a second identifier, where the second identifier is used to indicate a capability to be recovered, and the capability to be recovered is a capability authorized by the process a to a process B; and deleting second target information matched with the second identifier from the capability node A, wherein the capability to be recovered is only stored in the capability node A, and the second target information is used for finding the capability to be recovered from the capability node A, or the second target information is used for indicating that the capability to be recovered is authorized.

Optionally, when the process a authorizes the same capability to different processes, the second identifier is further used to indicate a target process, where the target process is one of the different processes, and the second target information is further used to indicate the target authorized person, for example, an identifier of the target process, or an identifier of a capability node of the target process, or an index of a slot in the foregoing embodiment. The second target information may be as long as it can indicate to whom the capability is authorized.

The effect of the capacity management apparatus 100 provided in this embodiment can refer to the foregoing method embodiments, and is not described herein again.

Fig. 10 is a schematic structural diagram of a computer system according to this embodiment. The computer system can be a smart phone, a smart home device (such as a large screen television, a smart voice device, and the like), an auxiliary automatic driving device, an unmanned device, or the like. As shown, the computer system includes a communication module 510, a sensor 520, a user input module 530, an output module 540, a processor 550, an audio-visual input module 560, a memory 570, and a power supply 580.

The communication module 510 may include at least one module that enables communication between the computer system and a communication system or other computer system. For example, the communication module 510 may include one or more of a wired network interface, a broadcast receiving module, a mobile communication module, a wireless internet module, a local area communication module, and a location (or position) information module, etc. The various modules are implemented in various ways in the prior art, and the embodiments are not described one by one.

The sensor 520 may sense a current state of the system, such as an open/close state, a position, whether there is contact with a user, a direction, and acceleration/deceleration, and the sensor 520 may generate a sensing signal for controlling the operation of the system.

A user input module 530 for receiving input digital information, character information, or contact touch operation/non-contact gesture, and receiving signal input related to user setting and function control of the system, etc. The user input module 530 includes a touch panel and/or other input devices.

The output module 540 includes a display panel for displaying information input by a user, information provided to the user or various menu interfaces of the system, and the like. Alternatively, the display panel may be configured in the form of a Liquid Crystal Display (LCD), an organic light-emitting diode (OLED), or the like. In other embodiments, the touch panel can be overlaid on the display panel to form a touch display screen. In addition, the output module 540 may further include an audio output module, an alarm, a haptic module, and the like.

And an audio/video input module 560 for inputting an audio signal or a video signal. The audio/video input module 560 may include a camera and a microphone.

The power supply 580 may receive external power and internal power under the control of the processor 550 and provide power required for the operation of the various components of the system.

Processor 550 may be indicative of one or more processors, for example, processor 550 may include one or more central processors, or include a central processor and a graphics processor, or include an application processor and a co-processor (e.g., a micro-control unit or a neural network processor). When processor 550 includes multiple processors, the multiple processors may be integrated on the same chip or may each be separate chips. A processor may include one or more physical cores, where a physical core is the smallest processing unit.

The memory 570 stores computer programs including an operating system program 572, application programs 571, and the like. Typical operating systems are, for example, seL4, L4, or Google IncA supplied Fuchsia and other microkernel operating system; also, systems for desktop or notebook computers such as Windows from microsoft corporation, MacOS from apple corporation, etc.; and as developed by google corporation

Android of

System, etc. is used for a system of a mobile terminal, etc.

The memory 570 may be one or more of the following types: flash (flash) memory, hard disk type memory, micro multimedia card type memory, card type memory (e.g., SD or XD memory), Random Access Memory (RAM), Static Random Access Memory (SRAM), Read Only Memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, or optical disk. In other embodiments, the memory 570 may be a network storage device on the internet, and the system may perform an update or read operation on the memory 570 on the internet.

The processor 550 is used to read the computer program in the memory 570 and then execute a method defined by the computer program, such as the processor 550 reading the operating system program 572 to run the operating system on the system and implement various functions of the operating system, or reading the one or more application programs 571 to run an application on the system. The solution provided by the present application, if implemented in software, may be stored in the memory 570 as a computer program, specifically, in whole or in part of the operating system program 572, and read and executed by the processor 550.

The memory 570 also stores other data 573 than computer programs, such as various capability nodes and the like referred to in this application.

The connection relationship of the modules in fig. 10 is only an example, and the method provided in any embodiment of the present application may also be applied to terminal devices in other connection manners, for example, all modules are connected through a bus. The division of the respective blocks in fig. 10 is only a logical division and does not represent that they are necessarily divided in hardware. The individual modules in fig. 10 are not necessarily required in other embodiments of the present application.

In addition, the application also provides a storage medium, a computer program product, a computer program and the like related to the scheme provided by the application. Reference may be made to the foregoing embodiments for specific implementations.

This application presents implementations as separate parts for a complete description of the aspects of the application, and provides different cases to illustrate the overall aspects of the application for a better understanding of the aspects of the application. It should be understood that there are some associations between various parts, and the implementation of the associations may be mutually referred to. There are some iterations between a case and the implementation of each part, which can also be referred to each other, but this does not mean that a certain case must be implemented according to a certain procedure.

It should be noted that capabilities, CNode, CSpace, slot, and the like are common concepts in the existing microkernel operating system, and for convenience of understanding by those skilled in the art, the embodiment of the present invention is taken as an example, but it is understood that the present application is also applicable if the names of the concepts are changed.

It is noted that, for convenience of application and understanding, the embodiments of the present application have been named after some systems, modules, devices, elements, data structures, instructions, etc., and these designations are intended to have the same meaning unless otherwise indicated. Also, these designations may be changed as desired and should not be construed as limiting the concepts provided herein.

It should be noted that the solution provided in this embodiment can be applied to a terminal device, a server, or the like. The terminal device herein includes, but is not limited to, a smart phone, a vehicle-mounted device (e.g., an automatic driving device), a personal computer, an artificial intelligence device, a tablet computer, a personal digital assistant, a smart wearable device (e.g., a smart watch or bracelet, smart glasses), a smart voice device (e.g., a smart speaker, etc.), a virtual reality/mixed reality/augmented reality display device, or a network access device (e.g., a gateway, etc.), etc. The server may include a storage server or a computing server, etc.

It should be noted that, the division of the modules or units in the foregoing embodiments is only provided as an exemplary illustration, the functions of the described modules are only exemplary, and the application is not limited thereto. Those skilled in the art may combine the functions of two or more modules, or split the functions of one module to obtain more modules with finer granularity, and other variations, as required.

The same or similar parts between the various embodiments described above may be referred to one another. In the present application, "a plurality" means two or more, or "at least two" unless otherwise specified. "A/B" in the present application includes three cases: "A", "B" and "A and B". An "identification (id)" of an object in this application refers to information that uniquely identifies the object, and the "identification" may directly identify the object, such as the name of the object, or indirectly indicate the object, such as the storage address of the object. In the present application, "first", "second", "third", and the like are used only for the purpose of distinction and do not mean a definite order; since the order is not limited, the first, second or third may be present.

The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment. In addition, in the drawings of the embodiments of the apparatus provided in the present application, the connection relationship between the modules indicates that there is a communication connection therebetween, and may be implemented as one or more communication buses or signal lines. One of ordinary skill in the art can understand and implement it without inventive effort.

The above description is only some specific embodiments of the present application, but the scope of the present application is not limited thereto.

Claims

1. A method for managing capabilities, comprising:

receiving an abandoning request sent by an authorized person, wherein the abandoning request comprises a first identifier which is used for indicating the capability to be abandoned, and the capability to be abandoned is the capability authorized to the authorized person by the authorized person;

and deleting first target information matched with the first identifier from the capacity node of the authorized person, wherein the capacity to be abandoned is only stored in the capacity node of the authorized person, and the first target information is used for finding the capacity to be abandoned from the capacity node of the authorized person.

2. The method of claim 1, further comprising:

receiving a recovery request sent by an authorizer, wherein the recovery request comprises a second identifier, the second identifier is used for indicating the capacity to be recovered, and the capacity to be recovered is the capacity authorized by the authorizer to an authorized person;

and deleting second target information matched with the second identifier from the capability node of the authorizer, wherein the capability to be recovered is only stored in the capability node of the authorizer, and the second target information is used for searching all the capabilities of the authorizer for the capability to be recovered.

3. The method of claim 2, wherein the second identifier is further used to indicate a target authorized person, and wherein the target authorized person is one of different authorized persons;

the deleting second target information matched with the second identifier from the capability node of the authorizer includes:

and deleting second target information matched with the second identifier from the capability node of the authorizer, wherein the second target information is also used for indicating the target authorized person.

4. The method of any one of claims 1-3, further comprising:

receiving an authorization request sent by an authorizer, wherein the authorization request is used for indicating that target capabilities in the authorizer's capability nodes are authorized out, and the target capabilities are only stored in the authorizer's capability nodes;

recording authorization information in a capability node of the authorizer, wherein the authorization information is used for indicating that the target capability is authorized;

recording authorized information in the ability node of the authorized person, wherein the authorized information is used for searching the target ability from the ability node of the authorized person.

5. A computer device, characterized in that the computer device comprises a memory for storing computer readable instructions and a processor for reading the computer readable instructions and implementing the power management method of any of claims 1-4.

6. A computer program product, characterized by computer-readable instructions that, when executed by one or more processors, implement the capacity management method of any one of claims 1-4.

7. The computer program product according to claim 6, wherein the computer program product is an operating system or a kernel of an operating system.

8. A method for capacity management, comprising:

an authorizer sends an authorization request to a kernel, wherein the authorization request comprises authorization parameters, and the authorization parameters are used for indicating the capacity to be authorized; the authorization request is used for instructing the kernel to authorize the to-be-authorized capability to an authorized person;

and the authorizer obtains a recovery parameter returned by the kernel, and the recovery parameter is used for the authorizer to manage the authorization.

9. The method of claim 8, further comprising:

and the authorizer sends a recovery request to the kernel, wherein the recovery request comprises the recovery parameter, and the recovery parameter is used by the kernel to execute capacity recovery.

10. The method of claim 8, further comprising:

the authorized person sends a preparation request to the kernel;

the authorized person obtains an abort parameter returned by the kernel, the abort parameter being used for the authorized person to manage the authorized capability.

11. The method of claim 10, further comprising:

the authorized person sends an abandonment request to the kernel, wherein the abandonment request comprises the abandonment parameter, and the abandonment parameter is used by the kernel for executing capacity abandonment.

12. A computer device, characterized in that the computer device comprises a memory for storing computer readable instructions and a processor for reading the computer readable instructions and implementing the power management method of any of claims 8-11.

13. A computer program product, characterized by computer-readable instructions that, when executed by one or more processors, implement the capacity management method of any one of claims 8-11.

14. The computer program product according to claim 13, wherein the computer program product is an application running in a user mode.