CN114969753A

CN114969753A - Loadable system module implementation method and system for dynamically determining running state

Info

Publication number: CN114969753A
Application number: CN202210523188.2A
Authority: CN
Inventors: 钱宇超; 古金宇; 臧斌宇; 陈海波
Original assignee: Shanghai Jiaotong University
Current assignee: Shanghai Jiaotong University
Priority date: 2022-05-13
Filing date: 2022-05-13
Publication date: 2022-08-30

Abstract

The invention provides a method and a system for realizing a loadable system module for dynamically determining an operation state, wherein the method comprises the following steps: the kernel provides a uniform API for system modules running in a kernel mode and a user mode through access control based on capability; through a symbol repositioning technology, when a system module is loaded, a called kernel API is dynamically determined to be realized in a kernel mode or a user mode; providing a cross-module calling mechanism based on a capability mechanism in a kernel, and transmitting parameters and return values by using shared memory pages; by providing a pre-defined interface, it is allowed to wait on multiple connections at once in the kernel API called across modules. The invention provides a new cross-module calling mechanism by utilizing a symbol relocation technology and a capability mechanism, and finally realizes a method for selectively loading a loadable system module into a kernel mode or a user mode and carrying out mutual communication during the operation period of an operating system.

Description

Loadable system module implementation method and system for dynamically determining running state

Technical Field

The invention relates to the technical field of kernel security, in particular to a loadable system module implementation method and system for dynamically determining a running state.

Background

In the field of research and engineering practice of operating system kernels, there are always trade-offs between kernel extensibility, functional module isolation and performance.

In order to make the functions of the operating system Kernel extensible, many common kernels often provide functions for dynamically loading optional Kernel modules as needed during runtime, such as Loadable Kernel Modules (LKM) of Linux and Kernel extensions (kerx extensions) of macOS. Taking the loadable kernel module of Linux as an example, this mechanism allows a user to install an official or third party provided kernel module into the kernel by configuration or manually by insmod commands, providing system functionality. After the kernel module is loaded into the memory, the kernel module operates in a kernel state, and in the kernel module, the code can randomly access symbols of the Linux kernel, including global variables, functions and the like. Therefore, when the kernel loads the module, the ELF loadable section of the kernel module needs to be loaded into the kernel address space first, and then the kernel symbols accessed by the module are subjected to Symbol relocation according to the Symbol Table (Symbol Table) of the ELF, so that the module knows the memory addresses of the kernel symbols in the operating period. In addition to accessing the kernel symbol, the kernel module may also access any location in the kernel address space through the pointer, and this access capability to any data of the kernel makes the security of the kernel module particularly important, and loading a kernel module with unknown security may cause malicious access or tampering to the kernel data. There have been many recent efforts in the research community to isolate kernel modules running in kernel mode from the kernel by using CPU hardware features such as Intel VT-x hardware virtualization technology to ensure that the kernel is not invaded.

The microkernel can be used for improving the isolation of all functional modules of the operating system from another approach, stripping most functions of the kernel of the operating system from the kernel mode and running as a user mode system service process, and similarly, a third-party kernel module which provides an extension function for the kernel in the microkernel can also provide services in the form of the user mode process in the microkernel. The Process-level address space isolation ensures that system services cannot access each other's data arbitrarily, but can only complete mutual Communication with the help of the kernel through an Inter-Process Communication (IPC) mechanism. Meanwhile, the System service runs in a user mode, so that the System service cannot randomly access the data of the kernel, cannot directly Call a CPU privilege instruction, and can only request the function provided by the kernel through a System Call (System Call) mechanism. It follows that in the microkernel, the performance of the IPC is a key indicator of the overall system performance, since all service processes after one system call in the microkernel are function calls, whereas in the microkernel the same service may require multiple IPC calls between multiple system services, whereas one IPC call involves four CPU privilege level switches, doubling with two system calls, and much higher overhead than function calls.

In recent years, with the rise of the system programming language of Rust, some research works such as RedLeaf have begun to explore the isolation of functional modules in the kernel by using the characteristics of the Rust language such as compile-time memory security check and visibility check of modules, functions and fields. The memory security feature of Rust is realized by an ownership (ownershirp) mechanism which determines an owner (owner) for each variable during compilation and tracks the transfer of ownership, so that a program cannot freely access memory spaces which do not belong to itself by default, i.e., without using unsafe statements; visibility setting of modules, functions and fields is realized through keywords such as pub, pub (create) and the like, and the characteristic enables a program not to call functions set to be invisible outside in other modules and access global variables or structure fields set to be invisible outside in other modules at will. At the same time, because these memory security and visibility checks occur at compile time, the compiled program has little additional overhead at run time. By utilizing the characteristics, some works divide the functions of the kernel of the operating system into logical modules, which are similar to Linux loadable kernel modules, run in a kernel state, but are similar to microkernels, the modules cannot directly access kernel data and functions, but data and service requests must be transmitted through a well-designed cross-module calling mechanism, so that the communication between the kernel modules has the performance close to function calling, and meanwhile, the isolation between the modules and the kernel are ensured.

In summary, the existing mechanism either loads the kernel module into the kernel mode for operation to expose the kernel address space, or separates the kernel function into the user mode for operation to improve isolation and reduce cross-module calling performance, or depends on the characteristics of the new programming language and cannot support modules written in other languages. These methods all have their own adaptive scenarios and limitations. The present invention is intended to provide a dynamically customizable solution that can comprehensively decide whether the operating system runs in a kernel mode or a user mode according to the properties of system modules and actual requirements during the running of the operating system.

Patent document CN104112098A (application number: CN201410340870.3) discloses a kernel module loading control method in an operating system, which includes the steps of: 1) in the process of executing the booting of the operating system, the kernel module processing capacity of all users is closed through the kernel sealing module in the kernel state, and the user verification function of the kernel sealing module is started, so that the kernel of the operating system enters a sealing state; 2) in the operating process of the operating system, the kernel sealing module intercepts the kernel module operation request, carries out user verification on the user or the application initiating the kernel module operation request, starts the kernel module processing capacity of the user or the application if the user or the application is verified to be passed, and loads or unloads the target kernel module requested by the user or the application through the kernel of the operating system. But the invention can not realize that the loadable system module is loaded to the kernel mode or the user mode optionally during the operation period of the operating system and is communicated with each other.

Disclosure of Invention

Aiming at the defects in the prior art, the invention aims to provide a loadable system module implementation method and system for dynamically determining a running state.

The loadable system module implementation method for dynamically determining the running state provided by the invention comprises the following steps:

step S1: the kernel provides a uniform API for system modules running in a kernel mode and a user mode through access control based on capability;

step S2: through a symbol repositioning technology, when a system module is loaded, a called kernel API is dynamically determined to be realized in a kernel mode or a user mode;

step S3: providing a cross-module calling mechanism based on a capability mechanism in a kernel, and transmitting parameters and return values by using shared memory pages;

step S4: by providing a pre-set interface, it is allowed to wait on multiple connections at a time in the kernel API that is called across modules.

Preferably, in the step S1:

when the system module is loaded to the memory for operation, a capability mechanism is adopted to provide access control to the kernel object, and the system module code does not directly access the memory data of the kernel object, but reads and writes through method calling;

in order to enable a function for realizing system call in a kernel to be directly called and a system call to be carried out through a syscall instruction to generate the same effect, a system module can observe the same behavior, a capability mechanism is introduced to provide uniform kernel object abstraction for the system module, the system module running in the kernel mode is the same as the system module running in a user mode, the kernel object is indirectly accessed through the capability, the capability mechanism enables access rights of different system modules to the kernel object to be mutually isolated, the system module cannot access the kernel object which is not accessed through forging the capability value, when the system module is written by using a memory security language, the system module is run in the kernel mode through the capability and a packaging library provided by the system kernel without worrying about that the module randomly accesses kernel data by guessing memory addresses and constructing pointers; when the system module is written by using a language without memory security, the system module is operated in a user mode to ensure the security of a kernel through the address space isolation of a process level.

Preferably, in the step S2:

by a symbol repositioning technology, different parameters of a special dynamic loader are used for controlling the undefined symbols of the system module in the ELF format to be redirected to a kernel mode implementation or a user mode implementation, the undefined symbols are APIs provided by the kernel of an operating system to the system module, the kernel mode implementation is shown as direct call to kernel functions, and the user mode implementation is shown as system call to the kernel;

the method comprises the steps that a specially-made dynamic loader determines whether a system module is loaded into a kernel mode or a user mode to be executed according to parameters specified by a user, the dynamic loader loads all loadable sections of an ELF into a memory, then relocates undefined symbols according to the relocating types of the undefined symbols, different operations are carried out on the actual memory address of the symbols in the operation period according to different relocating types, the relocating addresses are filled, the symbols required by the ELF are relocated to different implementations according to different parameters given by the user, and when the user loads the system module into the kernel mode to operate, the implementation of the relocating of the loader is to directly call a function for implementing system calling in the kernel, so that the kernel service is not required to be really requested to a user mode program through system calling when the system module operates; when a user loads a system module into a user mode to run, the syscall instruction traps to kernel processing, and CPU privilege level switching can occur in the process.

Preferably, in the step S3:

based on the capability mechanism, the kernel provides a cross-module calling mechanism for the system modules, so that the system modules can provide services and call external services through a unified mechanism, the operation of the mechanism needs the participation of a server and a client, the server firstly registers the services with the kernel, then the client is waited for connection on the capability of the service, the client obtains the capability through checking the service inwards, the connection is established to the server, after the connection is successful, the server waits for the calling request of the client on the capability of the connection, and provides the services for the future time and returns the service after receiving the request;

in the cross-module calling mechanism, an inner core provides an interface for a system module, two sides of the cross-module calling are divided into a client side and a server side, and the basic working mode is as follows:

at the server side:

a. registering a Server kernel object to a kernel through a cmc _ register _ Server interface, wherein the interface takes a character string as a key and the Server object as a value, maintaining a mapping table in the kernel so as to facilitate the query of a client, and returning the capability for accessing the kernel object;

b. calling a cmc _ accept interface on the Server object to enable the current thread to enter a waiting state, waiting for a client to initiate a Connection request, and returning the capability of the Connection kernel object after the Connection is successful;

c. the service end continuously calls a cmc _ wait interface on the Connection object to wait for cross-module calling of the client end, so that the current thread enters a waiting state, and when the interface returns, the service end indicates that a calling request of the client end is received and processes the calling request;

at a client:

i. inquiring a Server kernel object with a specific name from a kernel through a cmc _ find _ Server interface, and obtaining the capability which can be used for accessing the Server kernel object;

ii. Calling a cmc _ connect interface on the Server object to initiate Connection to a Server, checking whether the Server calls the cmc _ accept interface to wait for Connection or not by the interface, if so, creating a Connection kernel object in a kernel to represent the Connection established by the Server and the service, and returning the capability for accessing the Connection kernel object, and simultaneously returning the call of the cmc _ accept interface of the Server;

and iii, calling the cmc _ call interface on the Connection object by the client for a plurality of times to initiate a cross-module call.

Preferably, in the step S4:

an API of a cross-module calling mechanism allows one thread of a system module to wait for calling requests on a plurality of connections, so that a server can freely determine the number of threads serving for a client;

the kernel provides a cmc _ select interface for the system module, allows the cross-module call service end to wait on a plurality of Connection objects at the same time, any received cross-module call returns, and through the cmc _ select interface, the system module can determine how many threads are needed to process the cross-module call according to the actual situation;

when cross-module parameters need to transmit parameters and return values, a client and a server acquire a shared PMO corresponding to a Connection object through a cmc _ get _ shared _ PMO interface, the shared PMO is also in a capability form and is respectively mapped to an address space of the client and the server to access, the shared PMO is created when a cmc _ get _ shared _ PMO is called, a kernel ensures that the client and the server can obtain access authority to the same PMO, before the cmc _ call is called to initiate cross-module calling, the client fills specific services and required parameters to be requested in the shared PMO according to ABI appointed by the server at a specific position in the shared PMO, then the server acquires the parameters from the shared PMO after the cmc _ wait is returned and performs corresponding processing, fills return values in the specific position in the shared PMO according to the appointed ABI, and returns execution flow to the client when the next cmc _ wait is called;

and adding the capability of a Connection object to be returned currently in the cmc _ wait and cmc _ select interfaces, so that the execution flow is migrated to the initiating side of the just-processed call request immediately after the current service end thread is converted into a waiting state.

The invention provides a loadable system module implementation system for dynamically determining running states, which comprises the following components:

module M1: the kernel provides a uniform API for system modules running in a kernel mode and a user mode through access control based on capability;

module M2: through a symbol repositioning technology, when a system module is loaded, a called kernel API is dynamically determined to be realized in a kernel mode or a user mode;

module M3: providing a cross-module calling mechanism based on a capability mechanism in a kernel, and transmitting parameters and return values by using shared memory pages;

module M4: by providing a pre-set interface, it is allowed to wait on multiple connections at a time in the kernel API that is called across modules.

Preferably, in said module M1:

when the system module is loaded into a memory to run, a capability mechanism is adopted to provide access control for the kernel object, and the system module code does not directly access the memory data of the kernel object, but reads and writes through method calling;

in order to enable a system module to directly call a function for realizing system call in a kernel and to generate the same effect by carrying out system call through a syscall instruction, a system module can observe the same behavior, a capability mechanism is introduced to provide uniform kernel object abstraction for the system module, the system module running in a kernel mode is the same as the system module running in a user mode, the kernel object is indirectly accessed through the capability, the capability mechanism enables access rights of different system modules to the kernel object to be mutually isolated, the system module cannot access the kernel object which is not accessed by the system module through forging a capability value, and when the system module is written by using a memory security language, the system module is run in the kernel mode through the capability and a packaging library provided by the system kernel without worrying about that the module randomly accesses kernel data through a memory address guessing mode and a pointer constructing mode; when the system module is written by using a language without memory security, the system module is operated in a user mode to ensure the security of a kernel through the address space isolation of a process level.

Preferably, in said module M2:

Preferably, in said module M3:

based on a capability mechanism, a kernel provides a cross-module calling mechanism for system modules, so that the system modules can provide services and call external services through a unified mechanism, the operation of the mechanism needs participation of a server and a client, the server firstly registers services with the kernel, then waits for client connection on the capability of the service, the client obtains the capability through checking inquiry service inwards, establishes connection with the server, and after the connection is successful, the server waits for a calling request of the client on the connected capability, provides services for a period after receiving the request and returns;

in a cross-module calling mechanism, an inner core provides an interface for a system module, two sides of the cross-module calling are divided into a client side and a server side, and the basic working mode is as follows:

at the server side:

at a client:

Preferably, in said module M4:

an API of a cross-module calling mechanism allows one thread of a system module to wait for a calling request on a plurality of connections, so that a server can freely determine the number of threads serving for a client;

Compared with the prior art, the invention has the following beneficial effects:

1. the invention provides a new cross-module calling mechanism by utilizing the existing symbol relocation technology and capability mechanism, and finally realizes a method for selectively loading loadable system modules into a kernel mode or a user mode and carrying out mutual communication in the operating period of an operating system;

2. by symbol relocation, when the system module runs in a kernel mode, the expenditure for calling the kernel and other system modules is almost equivalent to function calling, and the system module is allowed to run in a user mode so as to realize process level isolation;

3. the invention will allow the operating system user to freely combine the system modules according to the actual needs and determine the privilege state in which they operate, so as to achieve the trade-off between performance and isolation.

Drawings

Other features, objects and advantages of the invention will become more apparent upon reading of the detailed description of non-limiting embodiments with reference to the following drawings:

FIG. 1 is a schematic diagram of symbol relocation behavior loaded into a kernel state and a user state;

FIG. 2 is a schematic diagram of kernel-mode and user-mode system module access kernel interfaces;

FIG. 3 is a basic workflow diagram for cross-module calling.

Detailed Description

The present invention will be described in detail with reference to specific examples. The following examples will assist those skilled in the art in further understanding the invention, but are not intended to limit the invention in any way. It should be noted that it would be obvious to those skilled in the art that various changes and modifications can be made without departing from the spirit of the invention. All falling within the scope of the present invention.

Example 1:

the invention has the main technical points that:

1. through the access control based on the capability, the kernel provides a unified API for the system modules running in the kernel mode and the user mode, compared with the traditional macro kernel that the kernel module can directly access the kernel object pointer, the unified API based on the capability makes it possible to replace different running modes during loading;

2. through a symbol relocation technology, the called kernel API is dynamically determined to be realized in a kernel mode or a user mode when the system module is loaded, so that the same system module binary program can be dynamically loaded to different running states to adapt to different requirements on performance and isolation;

3. providing a good abstract cross-module calling mechanism in a kernel, so that two system modules loaded to any running state can mutually request services in an optimal mode through a unified API (application programming interface), for example, the two modules running in the kernel state request services in a mode of calling a class function pointer, and the two modules running in a user state request services in a mode of IPC (micro-kernel IPC);

4. providing a function of waiting on a plurality of connections once in a kernel API called by a cross-module, so that the system service can determine the thread number for processing a client calling request according to the actual situation;

by providing a cmc _ select interface, the cross-module call server is allowed to wait on multiple Connection objects at the same time, and any received cross-module call returns

5. Parameters and return values of cross-module calling are transmitted through a memory page sharing technology, so that memory copy is reduced, and cross-module calling performance is improved;

6. the technical points 1-2 realize the dynamic loading of the system module to the kernel state or the user state for operation, and the technical points 3-5 realize the communication mechanism between the modules with high performance and low memory occupation;

the loadable system module implementation method for dynamically determining a running state provided by the present invention, as shown in fig. 1 to 3, includes:

specifically, in the step S1:

specifically, in the step S2:

the method comprises the steps that a specially-made dynamic loader determines whether a system module is loaded into a kernel mode or a user mode to be executed according to parameters specified by a user, the dynamic loader loads all loadable sections of an ELF into a memory, then relocates undefined symbols according to the relocating types of the undefined symbols, different operations are carried out on the actual memory address of the symbols in the operation period according to different relocating types, the relocating addresses are filled, the symbols required by the ELF are relocated to different implementations according to different parameters given by the user, and when the user loads the system module into the kernel mode to operate, the implementation of the relocating of the loader is to directly call a function for implementing system calling in the kernel, so that the kernel service is not required to be really requested to a user mode program through system calling when the system module operates; when a user loads a system module into a user mode operation, the CPU privilege level switching can occur in the process by trapping a syscall instruction into kernel processing.

specifically, in the step S3:

at the server side:

a. registering a Server kernel object to a kernel through a cmc _ register _ Server interface, wherein the interface takes a character string as a key and the Server object as a value, and maintaining a mapping table in the kernel so as to facilitate the query of a client and return capability for accessing the kernel object;

at a client:

and iii, calling the cmc _ call interface on the Connection object by the client for multiple times to initiate a cross-module call.

Specifically, in the step S4:

The loadable system module implementation system for dynamically determining the running state provided by the invention comprises:

specifically, in the module M1:

specifically, in the module M2:

specifically, in the module M3:

at the server side:

at a client:

Specifically, in the module M4:

Example 2:

example 2 is a preferred example of example 1, and the present invention will be described in more detail.

The method provided by the invention mainly solves the following problems:

1. how can a system module be loaded into kernel mode or user mode at will optionally run while the operating system is running?

2. How are system modules running in different privileged states made mutual procedure calls to request services?

The invention provides a method for realizing an operating system loadable system module for dynamically determining a running state, which comprises the following steps:

1. through a symbol repositioning technology, when a system module is loaded, a kernel mode implementation or a user mode implementation is determined for a kernel API depended on by the system module;

2. providing a mode of accessing the kernel object which is not sensitive to the privilege state of the system module by a capability mechanism;

3. providing a cross-module calling mechanism based on a capability mechanism, so that any two system modules in a kernel mode or a user mode can be called to request service;

4. the cross-module calling mechanism provides an API (application programming interface) to allow the system module to wait on a plurality of connections at a time, so that the system service can determine how many threads are used for processing the client calling request according to the actual situation;

5. when cross-module calling is performed, parameters and return values are transmitted in a memory page sharing mode, memory copy is reduced, and cross-module calling performance is improved;

6. the present invention is applicable to any architecture having a distinction between kernel-mode and user-mode.

The invention comprises the following technical points:

1. by a symbol relocation technology, different parameters of a special dynamic loader are used for controlling the undefined symbol of the system module in the ELF format to be redirected to a kernel mode implementation or a user mode implementation, wherein the undefined symbol is an API provided by an operating system kernel to the system module, the kernel mode implementation is represented as direct call to a kernel function, and the user mode implementation is represented as system call to the kernel;

2. when the system module is loaded to the memory for running, in order to enable the system module to access the kernel object in the same way no matter in the kernel mode or in the user mode, a capability mechanism is adopted to provide access control to the kernel object, and the system module code does not directly access the memory data of the kernel object, but reads and writes through method calling;

3. based on the capability mechanism, the kernel provides a cross-module calling mechanism for the system modules, so that the system modules can provide services and call external services through a unified mechanism, the operation of the mechanism needs the participation of a server and a client, the server firstly registers the services with the kernel, then the client is waited for connection on the capability of the service, the client obtains the capability through checking the service inwards, the connection is established to the server, after the connection is successful, the server waits for the calling request of the client on the capability of the connection, and provides the services for the future time and returns the service after receiving the request;

4. the API of the cross-module call mechanism allows a thread of the system module to wait for a call request on multiple connections, so that the server can freely decide the number of threads to serve the client, such as using one thread to serve all clients or creating one service thread for each client;

5. in order to improve the cross-module calling performance and reduce memory copy, parameters and return values are transmitted in a memory sharing page mode when the cross-module calling is performed.

The following is a detailed description of specific implementations of the invention:

the method comprises the steps that a specially-made dynamic loader can determine whether a system module is loaded into a kernel mode or executed in a user mode according to parameters specified by a user, the specific loading process is similar to the process of loading a loadable kernel module by a Linux kernel and the process of loading a dynamic link library by ld.so, the dynamic loader loads all loadable sections of an ELF into a memory at first, and then relocates undefined symbols (including global variables and functions) according to the relocation type of the symbols, specifically, the actual memory address of the symbols in the running period is subjected to different operations according to the different relocation types and is filled into a relocation address, such as a GOT or PLT table. So, different from Linux kernel or ld.so, according to different parameters given by users, the special dynamic loader relocates the symbols required by the ELF to different implementations, as shown in fig. 1, when a user loads a system module to kernel mode operation, the implementation of the relocation of the loader is to directly call a function for implementing system call in the kernel, so that the kernel service is not required to be really requested by the system call to a user mode program during the operation; when a user loads a system module into a user mode operation, the loader realizes relocation similar to a traditional user program, and the CPU privilege level switching can occur in the process of trapping in kernel processing through a syscall instruction.

In order to enable functions for realizing system call in a direct calling kernel and real system call through a syscall instruction to generate the same effect, namely, the same behavior can be observed for a system module, a capability mechanism is introduced to provide uniform kernel object abstraction for the system module, namely, in a traditional macro kernel, the kernel module can directly access fields of the kernel object, while in the invention, the system module running in a kernel state has to indirectly access the kernel object through the capability as the system module running in a user state, as shown in fig. 2. The Capability mechanism enables the access rights of different system modules to the kernel object to be isolated from each other, and the system module cannot access the kernel object which is not accessed by the system module through forging the Capability value. When the system module is written by using a memory security language such as Rust, the system module can be safely operated in a kernel mode through capability and an encapsulation library provided by a system kernel without worrying about that the module randomly accesses kernel data by guessing a memory address and constructing a pointer; when the system module is written in a non-memory-safe language such as C, the system module can be operated in a user mode to ensure the safety of a kernel through the address space isolation of a process level.

In the cross-module calling mechanism, the kernel provides interfaces such as cmc _ register _ server, cmc _ accept, cmc _ wait, cmc _ find _ server, cmc _ connect and cmc _ call for the system module. The two sides of the cross-module call are divided into a Client (Client) and a Server (Server), and the basic working mode is shown in fig. 3.

At the server side:

1. firstly, registering a Server kernel object to a kernel through a cmc _ register _ Server interface, wherein the interface takes a character string as a key and the Server object as a value, maintaining a mapping table in the kernel so as to facilitate the query of a client, and returning the capability which can be used for accessing the kernel object;

2. calling a cmc _ accept interface on the Server object to enable the current thread to enter a waiting state, waiting for a client to initiate a Connection request, and returning the capability of the Connection kernel object after the Connection is successful;

3. then the service end continuously calls a cmc _ wait interface on the Connection object to wait for cross-module calling of the client end, similar to the cmc _ accept interface, the current thread can enter a waiting state, and when the interface returns, the service end indicates that the call request of the client end is received and processes the call request;

at a client:

1. firstly, inquiring a Server kernel object with a specific name from a kernel through a cmc _ find _ Server interface, and obtaining the capability which can be used for accessing the Server kernel object;

2. then calling a cmc _ connect interface on the Server object to initiate Connection to the Server, wherein the interface can check whether the Server calls the cmc _ accept interface to wait for Connection, if so, creating a Connection kernel object in the kernel to represent the Connection established by the Server and return the capability for accessing the Connection kernel object, and simultaneously, calling the cmc _ accept interface of the Server end also returns;

3. the client may then invoke the cmc call interface on the Connection object multiple times to initiate a cross-module call.

In actual development, according to the difference between the type of the system module, the importance of providing service and the sensitivity of the function to delay, the service terminals of different system modules may need to process cross-module call requests of the client by using different numbers of threads, so the kernel of the invention also provides a cmc _ select interface for the system module, allows the cross-module call service terminals to wait on a plurality of Connection objects at the same time, and any received cross-module call can return. Through the interface, the system module can determine how many threads are needed to process cross-module calling according to actual conditions, one-to-one can be selected, namely, each client is connected with one thread, one-to-many can also be selected, namely, one thread is responsible for processing all client connections, and a dynamically-sized thread pool can be used for processing cross-module calling on a plurality of connections. This feature provides a high degree of freedom for memory footprint and performance tradeoffs of the system module.

When the cross-module parameters need to transfer parameters and return values, the client and the server can obtain the shared PMO corresponding to the Connection object through the cmc _ get _ shared _ PMO interface, and the shared PMO is also in a capability form and is respectively mapped to the address space of the client and the server to access. The shared PMO does not need to be created when the cmc _ connect, namely the connection is established, but is created inertly when the cmc _ get _ shared _ PMO is called, and the kernel ensures that the client and the server can obtain the access right to the same PMO. Before calling the cmc _ call to initiate the cross-module call, the client fills in specific service and required parameters to be requested in a specific position in the shared PMO according to ABI appointed by the server, then the server acquires the parameters from the shared PMO after the cmc _ wait is returned, performs corresponding processing, fills in a return value in the specific position in the shared PMO according to the appointed ABI, and returns an execution stream to the client when the cmc _ wait is called next time.

In the implementation of cross-module calling, a skill is used, so that the above workflow and thread migration model can coexist. Specifically, in the cmc _ wait and cmc _ select interfaces, the capability of a Connection object to be currently returned is added, so that the execution flow is migrated to the originating side of the just-processed call request immediately after the current service thread is turned into a waiting state. Conversely, if this trick is not used, the cmc _ wait and the cmc _ return interfaces need to be split, only waiting for a call request in the cmc _ wait, and only marking the client as the end of a cross-module call in the cmc _ return, which cannot directly perform thread migration.

Abbreviations and key term definitions:

-ELF: executable and Linable Format, a common file Format for Executable files and dynamic libraries

-symbol relocation: techniques for specifying run-time locations for undefined symbols in an executable file or dynamic library when loaded

-Capability: access control mechanism for user mode program commonly used in microkernel operating system to access kernel object

-a system module: the invention is a program loaded by operating system in operation for providing system extension function

-PMO: physical Memory Object, which represents a kernel Object of an available Physical Memory

Those skilled in the art will appreciate that, in addition to implementing the systems, apparatus, and various modules thereof provided by the present invention in purely computer readable program code, the same procedures can be implemented entirely by logically programming method steps such that the systems, apparatus, and various modules thereof are provided in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Therefore, the system, the device and the modules thereof provided by the present invention can be considered as a hardware component, and the modules included in the system, the device and the modules thereof for implementing various programs can also be considered as structures in the hardware component; modules for performing various functions may also be considered to be both software programs for performing the methods and structures within hardware components.

The foregoing description of specific embodiments of the present invention has been presented. It is to be understood that the present invention is not limited to the specific embodiments described above, and that various changes or modifications may be made by one skilled in the art within the scope of the appended claims without departing from the spirit of the invention. The embodiments and features of the embodiments of the present application may be combined with each other arbitrarily without conflict.

Claims

1. A loadable system module implementation method for dynamically determining a running state, comprising:

2. The method for implementing a loadable system module for dynamically determining a running state according to claim 1, wherein in the step S1:

in order to enable a function for realizing system call in a kernel to be directly called and a system call to be carried out through a syscall instruction to generate the same effect, a system module can observe the same behavior, a capability mechanism is introduced to provide uniform kernel object abstraction for the system module, the system module running in the kernel mode is the same as the system module running in a user mode, the kernel object is indirectly accessed through the capability, the capability mechanism enables access rights of different system modules to the kernel object to be mutually isolated, the system module cannot access the kernel object which is not accessed through forging the capability value, when the system module is written by using a memory security language, the system module is run in the kernel mode through the capability and a packaging library provided by the system kernel without worrying about that the module randomly accesses kernel data by guessing memory addresses and constructing pointers; when the system module is written by using a non-memory-safe language, the system module is operated in a user mode to ensure the safety of a kernel through the address space isolation of a process level.

3. The method for implementing a loadable system module for dynamically determining a running state according to claim 1, wherein in the step S2:

4. The method for implementing a loadable system module for dynamically determining a running state according to claim 1, wherein in the step S3:

at the server side:

step A1: registering a Server kernel object to a kernel through a cmc _ register _ Server interface, wherein the interface takes a character string as a key and the Server object as a value, maintaining a mapping table in the kernel so as to facilitate the query of a client, and returning the capability for accessing the kernel object;

step A2: calling a cmc _ accept interface on the Server object to enable the current thread to enter a waiting state, waiting for a client to initiate a Connection request, and returning the capability of the Connection kernel object after the Connection is successful;

step A3: the service end continuously calls a cmc _ wait interface on the Connection object to wait for cross-module calling of the client end, so that the current thread enters a waiting state, and when the interface returns, the service end indicates that a calling request of the client end is received and processes the calling request;

at a client:

step B1: inquiring a Server kernel object with a specific name from a kernel through a cmc _ find _ Server interface, and obtaining the capability which can be used for accessing the Server kernel object;

step B2: calling a cmc _ connect interface on the Server object to initiate Connection to a Server, checking whether the Server calls the cmc _ accept interface to wait for Connection or not by the interface, if so, creating a Connection kernel object in a kernel to represent the Connection established by the two, returning the capability for accessing the Connection kernel object, and simultaneously returning the call of the cmc _ accept interface of the Server;

step B3: the client calls the cmc call interface on the Connection object multiple times to initiate a cross-module call.

5. The method for implementing a loadable system module for dynamically determining a running state according to claim 1, wherein in the step S4:

6. A loadable system module implementing system for dynamically determining a running state, comprising:

module M3: providing a cross-module calling mechanism in a kernel based on a capability mechanism, and transmitting parameters and return values by adopting a shared memory page;

module M4: by providing a pre-defined interface, it is allowed to wait on multiple connections at once in the kernel API called across modules.

7. The system according to claim 6, wherein in the module M1:

8. The system according to claim 6, wherein in the module M2:

9. The system according to claim 6, wherein in the module M3:

at a server side:

at a client:

i. querying a Server kernel object with a specific name from a kernel through a cmc _ find _ Server interface, and obtaining the capability capable of being used for accessing the Server kernel object;

10. The system according to claim 6, wherein in the module M4: