WO2015078294A1 - Kernel module loading method and apparatus - Google Patents
Kernel module loading method and apparatus Download PDFInfo
- Publication number
- WO2015078294A1 WO2015078294A1 PCT/CN2014/090842 CN2014090842W WO2015078294A1 WO 2015078294 A1 WO2015078294 A1 WO 2015078294A1 CN 2014090842 W CN2014090842 W CN 2014090842W WO 2015078294 A1 WO2015078294 A1 WO 2015078294A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- lkm
- kernel
- lkms
- loading
- accordance
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/445—Program loading or initiating
- G06F9/44521—Dynamic linking or loading; Link editing at or after load time, e.g. Java class loading
- G06F9/44526—Plug-ins; Add-ons
Definitions
- the present disclosure relates to the field of computers, and in particular, to a kernel module loading method and apparatus.
- An operating system is a program used for managing hardware and software resources of a computer, and is responsible for basic transactions such as managing and configuring a memory, deciding priorities of supplies and demands of system resources, controlling input and output devices, operating a network, and managing a file system.
- a kernel is a core of an operating system, and refers to system software used for providing functions such as controlling and multitasking of a hardware abstraction layer, a magnetic disk, and a file system, where because it is relatively complicated to perform direct operations for hardware of the computer, the kernel generally provides a hardware abstraction method to implement the operations.
- the hardware abstraction hides the complexity, and provides a set of compact and unified interfaces for application software and hardware, so that program design becomes easier.
- a loadable kernel module is an interface that is opened by the kernel of the operating system for a user to compile the kernel.
- Various functions may be implemented by using the LKM. For example, dynamic modification may be implemented on the operating system when the operating system is running, a failure or vulnerability of the kernel of the operating system may be repaired, or the like.
- Existing popular operating systems such as Linux, Microsoft Windows, and Mac OS X all support the LKM function, however, definitions of LKM structure supported by various operating systems or even supported by kernels of different versions of the same operating system vary, and therefore, how to enable a compiled LKM to be compatible to various operating systems or kernels of different versions of the same operating system becomes a problem.
- a method of loading kernel modules is performed at a device (e.g., device 400 of FIG. 4) with one or more processors and memory.
- the method includes: obtaining a first loadable kernel module (LKM) and a second LKM, wherein the first LKM satisfies a first loading condition for being loaded into a first kernel, and the second LKM satisfies a second loading condition for being loaded into a second kernel different from the first kernel; identifying respective differences in one or more characteristic properties between the first and second LKMs; in accordance with the identified respective differences, modifying a respective one of the first and second LKMs; and loading the modified respective one of the first and second LKMs into the first kernel, wherein the modified respective one of the first and second LKM provides one or more functions in accordance with the second LKM.
- LKM loadable kernel module
- a computing device (e.g., device 400 of FIG. 4 or a component thereof (e.g., LKM manager 426) ) includes one or more processors and memory storing one or more programs for execution by the one or more processors, the one or more programs include instructions for performing, or controlling performance of, the operations of any of the methods described herein.
- a non-transitory computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which, when executed by a computing device (e.g., device 400 of FIG. 4 or a component thereof (e.g., LKM manager 426) ) with one or more processors, cause the computing device to perform, or control performance of, the operations of any of the methods described herein.
- a computing device (e.g., device 400 of FIG. 4 or a component thereof (e.g., software manager 426) ) includes means for performing, or controlling performance of, the operations of any of the methods described herein.
- FIGS. 1A-1B are flowcharts of a kernel module loading method in accordance with some embodiments.
- FIGS. 2A-2B is a flowchart of a kernel module loading method in accordance with some embodiments.
- FIG. 3 is a schematic view of a kernel module loading apparatus in accordance with some embodiments.
- FIG. 4 is a block diagram of a device in accordance with some embodiments.
- a kernel module loading method As shown in FIG. 1A, the method includes:
- S102 Obtain a first LKM, where the first LKM satisfies a first loading condition for being loaded to a first kernel;
- S104 Obtain a second LKM, where the second LKM satisfies a second loading condition for being loaded to a second kernel, but does not satisfy the first loading condition;
- one of problems to be solved by the technical solutions provided herein is to provide a method so that an LKM that is compiled based on one operating system and a kernel of one version of the operating system can be successfully loaded to another operating system or a kernel of another version of the same operating system, so as to simplify cross-platform design of the LKMs.
- complicated update work for the LKM of an old version that is required when the operating system and/or a kernel version thereof is updated may thus be avoided.
- a kernel of an operating system to which an LKM currently needs to be loaded successfully is referred to as a “first” kernel
- a kernel that originally matches the LKM is referred to as a “second” kernel
- the LKM is referred to as a “second” LKM.
- step S104 may be performed to obtain the second LKM
- step S102 is performed to obtain another LKM that has been compiled and satisfies a loading condition for being loaded to the first kernel, where, for ease of description, this other LKM is referred to as the first LKM, and the loading condition is referred to as a first loading condition.
- step S106 is performed, the second LKM is updated by using the first LKM or the first loading condition as a reference, so as to obtain an updated second LKM satisfying the first loading condition.
- Step S108 is performed to load the updated second LKM into the first kernel, and thereby achieving the effect of successfully loading the second LKM to the first kernel, where the second LKM is originally compiled based on the second kernel and satisfies the second loading condition for being loaded to the second kernel.
- the first loading condition corresponding to the first kernel may include various conditions.
- a loading function of an LKM opened by a developer of the kernel to a user is generally provided with one or more verification steps, where if the LKM self-defined by the user passes the verification steps, the self-defined LKM may be loaded to the kernel normally, and if the verification steps are not passed, loading of the self-defined LKM is stopped.
- loading a self-defined LKM to a Linux kernel needs to pass the following three verification steps:
- Vermagic Check to see whether a version identifier of the LKM is consistent with a version identifier of the Linux kernel, and if so, the Vermagic verification step is passed; otherwise, the Vermagic verification step is not passed, where the version identifier of the LKM is used to identify a compiling environment and a running environment of the LKM.
- Module Struct check Check to see whether a size and a definition of a structure of the LKM are consistent with a definition of a structure of an LKM defined by the Linux kernel, and if so, the Module Struct check is passed; otherwise, the Module Struct check is not passed.
- the concept of the structure of the LKM is similar to a concept of a structure known by persons skilled in the art, which may include multiple data fields used for describing the LKM, and may further include an initialization function pointer used when the LKM is loaded and a clearing function pointer used when the LKM is unloaded.
- the number of members included in the structure of the LKM may vary according to change of a kernel version or kernel configuration.
- Symbol CRC check Check to see whether identifiers in the LKM is consistent with identifiers defined by the Linux kernel, and if so, the Symbol CRC check is passed; otherwise, the Symbol CRC check is not passed.
- the identifiers in the LKM represent symbols used to identify functions, structures and the like in the LKM. Specifically, during the check, specific comparison objects are generally not the identifiers, a CRC checksum of the identifiers in the LKM and a CRC checksum of the identifiers defined by the kernel are calculated respectively, the calculated CRC checksums are compared, and a check result of the CRC checksums is used as a result of the Symbol CRC check.
- the Linux operating system may load the self-defined LKM to the Linux kernel only after the three verification steps are all passed, and for another mainstream operating system, similar verification measures also exist.
- the to-be-loaded LKM it may be ensured that the LKM successfully loaded to a kernel can be identified by the normally running kernel or operating system, thereby improving the reliability of the kernel and running stability of the kernel.
- the verification measures may form the first loading condition which needs to be satisfied when successfully loading the second LKM module to the first kernel, and include a requirement on a structure of the LKM, a requirement on an identifier of the LKM and a requirement on a version identity of the LKM; however, they are not limited in this embodiment.
- a condition that is used for loading a self-defined LKM and set by a certain operating system and a kernel thereof may be different from the three conditions as described above, or may be variations of the three conditions, so that the first loading condition corresponding to the first kernel of this type may also include other factors.
- the obtained first LKM is a self-defined LKM that can be successfully loaded by the first kernel, so that the first LKM necessarily satisfies the first loading condition, and therefore, specific content of the first loading condition, such as a definition of a structure of the LKM, a definition of an identifier of the LKM, and a definition of a version identity of the LKM, may be reflected by using the first LKM as a template or by analyzing the first LKM, so that update of the second LKM may be implemented according to the specific content of the first loading condition obtained by using the first LKM as a template or by analyzing the first LKM, and the updated second LKM satisfies the first loading condition, thereby achieving the effect of loading the updated second LKM to the first kernel.
- the processing manner is obviously superior to the conventional processing manner of manually modifying an LKM for each operating system and a kernel of each version, thereby achieving the effect of obviously reducing maintenance cost of the LKM.
- the first loading condition may include a structure corresponding to the first kernel, where step S106 may include:
- S202 Update a structure of the second LKM according to a structure of the first LKM, so as to form an updated second LKM.
- the verification measures of the Linux operating system for the self-defined LKM include the Module Struct verification step, where the so-called structure of the LKM may include multiple data fields used for describing the LKM, such as one or more function types corresponding to one or more system call functions for being called by the Linux operating system; however, this is not limited in the present method, and in some embodiments, the structure of the first LKM may also include data field (s) for one or more function types, and other data fields used for describing the LKM, such as one or more function pointers.
- the so-called structure of the LKM may include multiple data fields used for describing the LKM, such as one or more function types corresponding to one or more system call functions for being called by the Linux operating system; however, this is not limited in the present method, and in some embodiments, the structure of the first LKM may also include data field (s) for one or more function types, and other data fields used for describing the LKM, such as one or more function pointers.
- step S202 may include:
- S302 Obtain structure description information corresponding to the structure of the first LKM, record the obtained structure description information in a first configuration file, and mark the recorded structure description information as being corresponding to the first kernel;
- S304 Search the first configuration file for the structure description information corresponding to the first kernel, and update the structure of the second LKM according to the found structure description information, so as to form the updated second LKM.
- the obtained structure of the first LKM generally may be represented as a piece of Executable and Linkable Format (ELF) code, and the piece of ELF code is used to describe information such as sizes and types of various data or functions included in the first LKM, and because the first LKM satisfies the first loading condition corresponding to the first kernel, the structure description information is consistent with the definition of the structure made by the operating system where the first kernel is located.
- ELF Executable and Linkable Format
- the obtained structure description information may be recorded in the first configuration file, and the structure description information is marked as being corresponding to the first kernel, so that in the update operation for the second LKM that is performed subsequently, the structure description information corresponding to the first kernel may be found in the first configuration file, without the need of temporarily capturing a first LKM satisfying the first loading condition. For a situation in which multiple second LKMs need to be loaded to the first kernel in turn, repeated capturing of the first LKM may be avoided through the above manner, thereby improving the processing efficiency.
- structure description information respectively corresponding to different kernels is recorded in the first configuration file intensively, so as to perform unified management and maintenance on the structure description information conveniently, thereby further reducing the maintenance cost.
- the structure description information is not limited to be recorded by a certain format.
- step S304 and step S302 may be performed separately, for example, in one scenario, step S102 may be performed before one time period to obtain the first LKM, step S302 is then performed to perform corresponding obtaining, recording and marking operations on the structure description information thereof, step S104 is performed after this time period to obtain the second LKM, step S304 is then performed to update the second LKM, and finally step S108 is performed to load the updated second LKM to the first kernel.
- the second LKM may also be updated according to the first LKM obtained in real time, where the first LKM may include multiple first system call functions, the second LKM may also include multiple second system call functions, and the structure of the first LKM includes multiple function types to which the multiple first system call functions belong, where, in some embodiments, step S202 may include:
- step S402 may be performed to replace multiple first system call functions in the first LKM correspondingly with multiple second system call functions in the second LKM, in other words, insert the multiple second system call functions in the first LKM, where the structure of the first LKM including the multiple first system call functions satisfies the first loading condition, and therefore, as long as the multiple second system call functions are correspondingly inserted in the first LKM, and it is ensured that the function types of the inserted second system call functions are consistent with the function types of the replaced first system call functions, the formed structure of the updated second LKM also satisfies the first loading condition, and therefore, the updated second LKM satisfies the first loading condition, and step S108 may be performed to successfully load the updated second LKM to the first kernel.
- the first loading condition may also include an operating system identity and/or a version identity corresponding to the first kernel, where, step S106 may further include:
- S502 Update the operating system identity and/or the version identity in the first LKM to the second LKM.
- the verification measures of the Linux operating system for the self-defined LKM further include the Vermagic verification step, and in this scenario, the first loading condition may include a version identity corresponding to the first kernel. Further, in some embodiments, the first loading condition may further include an operating system identity corresponding to the first kernel, so that the operating system can perform initial identification for the self-defined LKM.
- step S502 may be performed to update the operating system identity and/or the version identity in the first LKM to the second LKM, where, the first LKM satisfies the first loading condition; therefore the operating system identity and/or the version identity in the first LKM is corresponding to the first kernel, and the operating system identity and/or the version identity in the updated second LKM obtained in the above manner is also corresponding to the first kernel, so that the second LKM satisfies the first loading condition.
- update operations respectively performed through step S202 and step S502 need not be in any particular sequence, which is also not limited in the present method.
- the first loading condition may also include multiple LKM identifiers corresponding to the first kernel, and the LKM identifiers are used to identify a structure corresponding to the first kernel and/or belong to system call functions of the function types corresponding to the first kernel, where as shown in FIG. 1B, when step S106 is performed, the kernel module loading method may further include:
- S604 Update the found multiple LKM identifiers to the structure of the second LKM and/or a second system call function of a function type identified by any one of the multiple LKM identifiers in the second LKM.
- the verification measures of the Linux operating system for the self-defined LKM further include the Symbol CRC verification step, that is, in some embodiments, the first loading condition may further include multiple LKM identifiers corresponding to the first kernel, where the LKM identifiers may be used to identify a structure of the LKM that is corresponding to the first kernel and meets a definition made by the first kernel and an operating system thereof, for example, the LKM identifiers may be used to identify an overall identity of the structure and each attribute identifier included in the structure, and may also be used to identify system call functions of various function types corresponding to the first kernel, so that the operating system can call the system call functions subsequently.
- the first loading condition may further include multiple LKM identifiers corresponding to the first kernel, where the LKM identifiers may be used to identify a structure of the LKM that is corresponding to the first kernel and meets a definition made by the first kernel and an operating system thereof, for example, the LKM identifiers may be used to identify an overall identity of the structure and
- the LKM identifiers corresponding to the first kernel may be recorded in the second configuration file intensively, for example, for a Linux kernel, the corresponding LKM identifiers are generally stored in a /proc/kallsyms path, and therefore, in this embodiment, the second configuration file may be a file accessed through the path.
- the above description is only an example, and is not limited in the present method.
- the kernel module loading method may further include:
- S702 Record multiple function pointers corresponding to the multiple second system call functions in the updated second LKM, so that the operating system calls the corresponding second system call functions according to one or more of the multiple function pointers.
- the operating system may implement calling for one or more of the second system call functions by using the function pointer corresponding to each of the multiple second system call functions included in the second LKM recorded in the step S702.
- the recording operation on the multiple function pointers corresponding to the multiple second system call functions as described in step S702 may include many types, for example, the recorded function pointer may be the function pointer corresponding to the original system call function in the first kernel, and in this scenario, when the operating system calls the corresponding system call function according to the function pointer, the called function is no longer the original system call function of the first kernel, but the second system call function pointed by the function pointer in the loaded second LKM, so that the operation of loading the second LKM to the first kernel in this scenario may be considered as replacement to the original system call function in the first kernel.
- the recorded function pointer may be the function pointer corresponding to the original system call function in the first kernel, and in this scenario, when the operating system calls the corresponding system call function according to the function pointer, the called function is no longer the original system call function of the first kernel, but the second system call function pointed by the function pointer in the loaded second LKM, so that the operation of loading the second LKM to the first kernel in this scenario may be considered as replacement
- a recorded function pointer may also be a newly added pointer that is different from the function pointers corresponding to the original call functions in the first kernel, and in this scenario, the second system call function in the loaded second LKM may be used for adding a new function for the first kernel and may also be used for repairing original failure or vulnerability of the first kernel.
- specific functions of the second LKM loaded to the first kernel are not limited in the present method; however, this type of embodiments based on the present method should all fall within the scope of the present disclosure.
- the technical solution of the present disclosure substantially or contributive parts to the prior art may be embodied by a software product, and the computer software product is stored in a storage medium (such as a ROM/RAM, a magnetic disk and an optical disc) , and includes several instructions used to enable a terminal device (which may be a mobile phone, a computer, a server, a network device, or the like) to perform the method described herein.
- a storage medium such as a ROM/RAM, a magnetic disk and an optical disc
- FIGS. 2A-2B is a flowchart of a method of loading kernel modules in accordance with some embodiments. The method may be performed by a device (e.g., device 400 of FIG. 4) running an operating system having a first kernel (e.g., a Linux kernel of a first version, or a particular version of another OS platform) .
- a first kernel e.g., a Linux kernel of a first version, or a particular version of another OS platform
- the device obtains (202) a first loadable kernel module (LKM) and a second LKM, wherein the first LKM satisfies a first loading condition for being loaded into a first kernel, and the second LKM satisfies a second loading condition for being loaded into a second kernel different from the first kernel.
- the first LKM is an LKM of the first kernel
- the second LKM is the LKM that is for a newer version of the first kernel, or a different platform than the first kernel.
- the second LKM needs to be made into a form that can be loaded into the first kernel, or alternatively, the functions provided in the second LKM needs to be made available to the first kernel.
- the device identifies (204) respective differences in one or more characteristic properties (e.g., the characteristics that prevents the second LKM from being loaded into the first kernel successfully) between the first and second LKMs.
- the device modifies (206) a respective one of the first and second LKMs, and loads (208) the modified respective one of the first and second LKMs into the first kernel, wherein the modified respective one of the first and second LKM provides one or more functions in accordance with the second LKM.
- the first LKM may be modified internally to call the functions specified in the second LKM, and thus, when the first LKM is loaded into the first kernel, the functions referred to in the second LKM can be called and utilized by the first kernel.
- the second LKM may be modified according to the characteristics of the first LKM, such that the second LKM would be able to satisfy the condition for being loaded into the first kernel successfully and providing its functions to the first kernel.
- obtaining the first LKM and the second LKM further includes (210) : receiving an instruction for loading the second LKM into the first kernel; determining whether the second LKM satisfies the first loading condition for being loaded into the first kernel; and in accordance with a determination that the second LKM does not satisfy the first loading condition for being loaded into the first kernel, obtaining the first LKM that satisfies the first loading condition for being loaded into the first kernel.
- identifying respective differences in one or more characteristic properties between the first and second LKMs further includes (212) at least one of: identifying a first difference between respective operating system identities or version identities corresponding to the first and second LKMs; identifying a second difference between respective structures corresponding to the first and second LKMs; and identifying a third difference between respective system function calls corresponding to the first and second LKMs. This step is described as the verification steps determining whether the LKM may be loaded into the first kernel successfully, and identifying the reasons for failing the load the LKM into the first kernel.
- modifying a respective one of the first and second LKMs further includes (214) : in accordance with the identified respective differences, modifying one or more first function pointers corresponding to one or more operating system calls in the first LKM to one or more second function pointers in the second LKM. This can be done such that when the first LKM is loaded into the first kernel, the function pointers in the first LKM will point to functions as specified in the second LKM, such that even though the second LKM is not loaded into the first kernel, the functions provided by the second LKM (e.g. , additional functions or patches) can be provided to the first kernel.
- loading the modified respective one of the first and second LKMs into the first kernel further includes (216) loading the modified first LKM into the first kernel.
- modifying a respective one of the first and second LKMs further includes (218) : in accordance with the identified respective differences, modifying at least one of a respective operating system identity, version identity, and structure of the second LKM in accordance with corresponding at least one of a respective operating system identity, version identity, and structure of the first LKM.
- loading the modified respective one of the first and second LKMs into the first kernel further includes (210) loading the modified second LKM into the first kernel.
- the second LKM After being modified according to the characteristic properties of the first LKM, the second LKM will be able to pass the condition for being loaded into the first kernel successfully, and thus can provide its functions to the first kernel.
- other modifications such as modifying the functions and function pointers in the second LKM according to corresponding functions and functions pointers in the first LKM may also be performed before the second LKM is loaded into the first kernel.
- FIGS. 1A-1B Other aspects of the method for loading kernel modules are provided with respect to FIGS. 1A-1B and are not repeated here in the interest of brevity.
- a kernel module loading apparatus used for implementing the kernel module loading method is further provided. As shown in FIG. 3, the apparatus includes:
- a first obtaining unit 302 used to obtain a first loadable kernel module (LKM) , where the first LKM satisfies a first loading condition for being loaded to a first kernel;
- LKM loadable kernel module
- a second obtaining unit 304 used to obtain a second LKM, where the second LKM satisfies a second loading condition for being loaded to a second kernel but does not satisfy the first loading condition;
- a loading unit 308 used to load the updated second LKM to the first kernel.
- one of problems to be solved in the technical solution provided herein is providing an apparatus, so that an LKM compiled based on an operating system and a kernel of a version of the operating system can be successfully loaded to another operating system or a kernel of another version of the same operating system, so as to simplify cross-platform design of the LKM through the implementation of the function, and avoid complicated update work for the LKM of an old version that is required when the operating system and/or a kernel version thereof is updated.
- a kernel of an operating system to which an LKM currently needs to be loaded successfully is referred to as a first kernel
- a kernel that originally matches the LKM is referred to as a second kernel
- the LKM is referred to as a second LKM.
- the kernel module loading apparatus can obtain the second LKM by using the second obtaining unit 304, obtain, by using the first obtaining unit 302, another LKM that has been compiled and satisfies a loading condition for being loaded to the first kernel, where, for ease of description, the another LKM is referred to as a first LKM, and the loading condition is referred to as a first loading condition.
- the second LKM is updated by using the first LKM or the first loading condition as a reference, so as to obtain an updated second LKM satisfying the first loading condition, and the loading unit 308 is further used to load the updated second LKM to the first kernel, thereby achieving the effect of successfully loading the second LKM to the first kernel, where the second LKM is originally compiled based on the second kernel and satisfies the second loading condition for being loaded to the second kernel.
- the first loading condition corresponding to the first kernel may include various conditions.
- a loading function of an LKM opened by a developer of the kernel to a user is generally provided with one or more verification steps, where if the LKM self-defined by the user passes the verifications, the self-defined LKM may be loaded to the kernel normally, and if the verifications are not passed, loading of the self-defined LKM is stopped.
- loading a self-defined LKM to a Linux kernel needs to pass the following three verification steps:
- Vermagic Check to see whether a version identity of the LKM is consistent with a version identity of the Linux kernel, and if yes, the Vermagic check is passed; otherwise, the Vermagic check is not passed, where the version identity of the LKM is used to identify a compiling environment and a running environment of the LKM;
- Module Struct check Check to see whether a size and a definition of a structure of the LKM are consistent with a definition of a structure of an LKM defined by the Linux kernel, and if yes, the Module Struct check is passed; otherwise, the Module Struct check is not passed, where the concept of the structure of the LKM is similar to a concept of a structure known by persons skilled in the art, which may include multiple data fields used for describing the LKM, and may further include an initialization function pointer when the LKM is loaded and a clearing function pointer when the LKM is unloaded, where the number of members included in the structure of the LKM may vary according to change of a kernel version or kernel configuration; and
- Symbol CRC check Check to see whether an identifier in the LKM is consistent with an identifier defined by the Linux kernel, and if yes, the Symbol CRC check is passed; otherwise, the Symbol CRC check is not passed, where the identifier in the LKM represents a symbol used to identify a function, a structure and the like in the LKM. Specifically, during the check, specific comparison objects are generally not the identifiers, a CRC checksum of the identifier in the LKM and a CRC checksum of the identifier defined by the kernel are calculated respectively, the calculated CRC checksums are compared, and a check result of the CRC checksums is used as a result of the Symbol CRC check.
- the Linux operating system may load the self-defined LKM to the Linux kernel only after the three verification steps are all passed, and for another mainstream operating system, similar verification measures also exist.
- the to-be-loaded LKM it may be ensured that the LKM successfully loaded to a kernel can be identified by the normally running kernel or operating system, thereby improving the reliability of the kernel and running stability of the kernel.
- the verification measures may form the first loading condition which needs to be satisfied when successfully loading the second LKM module to the first kernel, and include a requirement on a structure of the LKM, a requirement on an identifier of the LKM and a requirement on a version identity of the LKM; however, they are not limited in this embodiment, and in some embodiments, a condition that is used for loading a self-defined LKM and set by a certain operating system and a kernel thereof may be different from the three conditions as described above, or may be variations of the three conditions, so that the first loading condition corresponding to the first kernel of this type may also include another factor.
- the obtained first LKM is a self-defined LKM that can be successfully loaded by the first kernel, so that the first LKM necessarily satisfies the first loading condition, and therefore, specific content of the first loading condition, such as a definition of a structure of the LKM, a definition of an identifier of the LKM, and a definition of a version identity of the LKM, may be reflected by using the first LKM as a template or by analyzing the first LKM, so that update of the second LKM may be implemented according to the specific content of the first loading condition obtained by using the first LKM as a template or by analyzing the first LKM, and the updated second LKM satisfies the first loading condition, thereby achieving the effect of loading the updated second LKM to the first kernel.
- the processing manner is obviously superior to the conventional processing manner of manually modifying an LKM for each operating system and a kernel of each version, thereby achieving the effect of obviously reducing maintenance cost of the LKM.
- the first loading condition may include a structure corresponding to the first kernel, where the first updating unit 306 may include:
- a first updating module 310 used to update a structure of the second LKM according to a structure of the first LKM, so as to form an updated second LKM.
- the verification measures of the Linux operating system for the self-defined LKM include the Module Struct verification step, where the so-called structure of the LKM may include multiple data fields used for describing the LKM, such as a function type of a system call function for being called by the Linux operating system; however, this is not limited in the present apparatus, and in some embodiments, the structure of the first LKM may also include a function type, and may also include another data field used for describing the LKM, such as a function pointer.
- the first updating module 310 may include:
- a recording sub-module used to obtain structure description information corresponding to the structure of the first LKM, record the obtained structure description information in a first configuration file, and mark the recorded structure description information as being corresponding to the first kernel;
- an updating sub-module used to search the first configuration file for the structure description information corresponding to the first kernel, and update the structure of the second LKM according to the found structure description information, so as to form the updated second LKM.
- the obtained structure of the first LKM generally may be represented as a piece of Executable and Linkable Format (ELF) code, and the piece of ELF code is used to describe information such as sizes and types of various data or functions included in the first LKM, and because the first LKM satisfies the first loading condition corresponding to the first kernel, the structure description information is consistent with the definition of the structure made by the operating system where the first kernel is located.
- ELF Executable and Linkable Format
- the obtained structure description information may be recorded in the first configuration file, and the structure description information is marked as being corresponding to the first kernel, so that in the update operation for the second LKM that is performed subsequently, the structure description information corresponding to the first kernel may be found in the first configuration file, without the need of temporarily capturing a first LKM satisfying the first loading condition. For a situation in which multiple second LKMs need to be loaded to the first kernel in turn, repeated capturing of the first LKM may be avoided through the above manner, thereby improving the processing efficiency.
- structure description information respectively corresponding to different kernels is recorded in the first configuration file intensively, so as to perform unified management and maintenance on the structure description information conveniently, thereby further reducing the maintenance cost.
- the structure description information is not limited to be recorded by a certain format.
- the recording operation performed by the recording sub-module and the updating operation performed by the updating sub-module may be performed separately, for example, in one scenario, the first obtaining unit 302 is used before one time period to obtain the first LKM, the recording sub-module is used to perform corresponding obtaining, recording and marking operations on the structure description information thereof, the second obtaining unit 304 is used after this time period to obtain the second LKM, the updating sub-module is then used to update the second LKM, and finally the loading unit 308 is used to load the updated second LKM to the first kernel.
- the second LKM may also be updated according to the first LKM obtained in real time, where the first LKM may include multiple first system call functions, the second LKM may also include multiple second system call functions, and the structure of the first LKM includes multiple function types to which the multiple first system call functions belong, where in some embodiments, the first updating module 310 may include:
- the replacing sub-module may be used to replace multiple first system call functions in the first LKM correspondingly with multiple second system call function in the second LKM, in other words, insert the multiple second system call functions in the first LKM, where the structure of the first LKM including the multiple first system call functions satisfies the first loading condition, and therefore, as long as the multiple second system call functions are correspondingly inserted in the first LKM, and it is ensured that the function types of the inserted second system call functions are consistent with the function types of the replaced first system call functions, the formed structure of the updated second LKM also satisfies the first loading condition, and therefore, the updated second LKM satisfies the first loading condition, and the loading unit 108 may be used to successfully load the updated second LKM to the first kernel.
- the first loading condition may also include an operating system identity and/or a version identity corresponding to the first kernel, where the first updating unit 306 may further include:
- a second updating module used to update the operating system identity and/or the version identity in the first LKM to the second LKM.
- the verification measures of the Linux operating system for the self-defined LKM further include the Vermagic verification step, and in this scenario, the first loading condition may include a version identity corresponding to the first kernel. Further, in some embodiments, the first loading condition may further include an operating system identity corresponding to the first kernel, so that the operating system can perform initial identification for the self-defined LKM.
- the second updating module may be used to update the operating system identity and/or the version identity in the first LKM to the second LKM, where, the first LKM satisfies the first loading condition; therefore the operating system identity and/or the version identity in the first LKM is corresponding to the first kernel, and the operating system identity and/or the version identity in the updated second LKM obtained in the above manner is also corresponding to the first kernel, so that the second LKM satisfies the first loading condition.
- update operations respectively performed by the first updating module 310 and the second updating module have no necessary sequence, which is also not limited in the present technology.
- the first loading condition may also include multiple LKM identifiers corresponding to the first kernel, and the LKM identifiers are used to identify a structure corresponding to the first kernel and/or belong to system call functions of the function type corresponding to the first kernel, where the kernel module loading apparatus may further include:
- a searching unit used to search the second configuration file for the multiple LKM identifiers
- a second updating unit used to update the found multiple LKM identifiers to the structure of the second LKM and/or a second system call function of a function type identified by any one of the multiple LKM identifiers in the second LKM.
- the verification measures of the Linux operating system for the self-defined LKM further include the Symbol CRC verification step, that is, in some embodiments, the first loading condition may further include multiple LKM identifiers corresponding to the first kernel, where the LKM identifiers may be used to identify a structure of the LKM that is corresponding to the first kernel and meets a definition made by the first kernel and an operating system thereof, for example, the LKM identifiers may be used to identify an overall identity of the structure and each attribute identifier included in the structure, and may also be used to identify a system call function of a function type corresponding to the first kernel, so that the operating system can call the system call function subsequently.
- the LKM identifiers may be used to identify a structure of the LKM that is corresponding to the first kernel and meets a definition made by the first kernel and an operating system thereof, for example, the LKM identifiers may be used to identify an overall identity of the structure and each attribute identifier included in the structure, and may also be used to identify a
- the LKM identifiers corresponding to the first kernel may be recorded in the second configuration file intensively, for example, for a Linux kernel, the corresponding LKM identifiers are generally stored in a /proc/kallsyms path, and therefore, in this embodiment, the second configuration file may be a file accessed through the path.
- the above description is only an example, and is not limited in the present apparatus.
- the kernel module loading apparatus may further include:
- a recording unit used to record multiple function pointers corresponding to the multiple second system call functions in the updated second LKM, so that the operating system calls the corresponding second system call function according to one or more of the multiple function pointers.
- the operating system may implement calling for one or more of the second system call functions by using the function pointer corresponding to each of the multiple second system call functions included in the second LKM recorded in the recording unit.
- the recording operation on the multiple function pointers corresponding to the multiple second system call functions performed by the recording unit may include many types, for example, the recorded function pointer may be the function pointer corresponding to the original system call function in the first kernel, and in this scenario, when the operating system calls the corresponding system call function according to the function pointer, the called function is no longer the original system call function of the first kernel, but the second system call function pointed by the function pointer in the loaded second LKM, so that the operation of loading the second LKM to the first kernel in this scenario may be considered as replacement to the original system call function in the first kernel.
- the recorded function pointer may also be a newly added pointer that is different from the function pointers corresponding to the original call function in the first kernel, and in this scenario, the second system call function in the loaded second LKM may be used for adding a new function for the first kernel and may also be used for repairing original failure or vulnerability of the first kernel.
- specific functions of the second LKM loaded to the first kernel are not limited in the present apparatus; however, this type of embodiments based on the present apparatus should all fall within the scope of the present disclosure.
- the disclosed apparatus, unit and module may be implemented through other manners.
- the described apparatus embodiment is only an example, for example, a division of units is only a division of logic functions, and in fact, another division manner may exist during implementation, for example, multiple units or components may be combined or integrated to another system, or some features may be omitted or not performed.
- the shown or discussed mutual coupling or direct coupling or communication connection may be performed through indirect coupling or communication connection of some interfaces, units or modules electrically or in other forms.
- the units described as separated parts may be or may not be physically separated, and parts shown as units may or may not be physical units, that is, they may located on the same place, or may also be distributed to multiple network units. A part of or all units may be selected according to actual requirements to implement the object of the solution of this embodiment.
- various functional units in each embodiment may be integrated in one processing unit, the units may exist separately and physically, and two or more units may be integrated in one unit.
- the integrated unit may be implemented in hardware form, and may also be implemented in form of a software function unit.
- the integrated unit is implemented in form of a software function unit and is sold or used as a separated product
- the unit may be stored in a computer readable storage medium.
- the technical solution of the present disclosure substantially or contributive parts to the prior art or all or a part of the technical solution may be embodied by a software product
- the computer software product is stored in a storage medium and includes several instructions used to enable a computer device (which may be a personal computer, a server, a network device, or the like) to perform all or a part of steps of the method described in the embodiments of the present technology.
- the storage medium includes various medium capable of storing program codes, such as a USB flash disk, a read-only memory (ROM) , a random access memory (RAM) , a movable hard disk, a magnetic disk, or an optical disc.
- FIG. 4 is a block diagram illustrating a representative device 400 in accordance with some embodiments.
- Device 400 typically, includes one or more processing units (CPUs) 402, one or more network interfaces 404, memory 406, and one or more communication buses 408 for interconnecting these components (sometimes called a chipset) .
- Device 400 also optionally includes a user interface 410.
- User interface 410 includes one or more output devices 412 that enable presentation of media content, including one or more speakers and/or one or more visual displays.
- User interface 410 also includes one or more input devices 414, including user interface components that facilitate user input such as a keyboard, a mouse, a voice-command input unit or microphone, a touch screen display, a touch-sensitive input pad, a gesture capturing camera, or other input buttons or controls. Furthermore, some devices 400 use a microphone and voice recognition or a camera and gesture recognition to supplement or replace the keyboard.
- Memory 406 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid state memory devices; and, optionally, includes non-volatile memory, such as one or more magnetic disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid state storage devices. Memory 406, optionally, includes one or more storage devices remotely located from one or more processing units 402. Memory 406, or alternatively the non-volatile memory within memory 406, includes a non-transitory computer readable storage medium.
- memory 406, or the non-transitory computer readable storage medium of memory 406, stores the following programs, modules, and data structures, or a subset or superset thereof:
- operating system 416 including procedures for handling various basic system services and for performing hardware dependent tasks, this is also referred to as the kernel or includes the kernel;
- network communication module 418 for connecting device 400 to other computing devices (e.g., a server or other devices) connected to one or more networks via one or more network interfaces 404 (wired or wireless) ;
- presentation module 420 for enabling presentation of information (e.g., a user interface for application (s) 426, widgets, websites and webpages thereof, and/or games, audio and/or video content, text, etc. ) at device 400 via one or more output devices 412 (e.g., displays, speakers, etc. ) associated with user interface 410;
- information e.g., a user interface for application (s) 426, widgets, websites and webpages thereof, and/or games, audio and/or video content, text, etc.
- output devices 412 e.g., displays, speakers, etc.
- input processing module 422 for detecting one or more user inputs or interactions from one of the one or more input devices 414 and interpreting the detected input or interaction;
- one or more applications 426 for execution by user device 100 e.g., games, application marketplaces, payment platforms, and/or other web or non-web based applications
- user device 100 e.g., games, application marketplaces, payment platforms, and/or other web or non-web based applications
- LKM manager 426 which provides data processing and functionalities for loading loadable kernel modules, distinguishing the LKMs that are compatible or incompatible with the current kernel, and making the modifications to the LKMs to make them compatible with the current kernel, and other functions described herein.
- the LKM manager 426 includes one or more of, but not limited to the following sub-modules:
- ⁇ obtaining module 428 to obtain loadable kernel modules from the user, from the memory, and from disc storage;
- ⁇ characteristic collection module 430 to gather pertinent characteristic properties associated with each obtained LKMs and determining the pertinent characteristics that need to be modified in order to bring an incompatible LKM into compliance with the loading condition of the current kernel;
- ⁇ LKM modification module 432 to modify LKMs to conform to the loading conditions of the current kernel
- Each of the above identified elements may be stored in one or more of the previously mentioned memory devices, and corresponds to a set of instructions for performing a function described above.
- the above identified modules or programs i.e., sets of instructions
- memory 406 optionally, stores a subset of the modules and data structures identified above.
- memory 406, optionally, stores additional modules and data structures not described above.
- stages that are not order dependent may be reordered and other stages may be combined or broken out. While some reordering or other groupings are specifically mentioned, others will be obvious to those of ordinary skill in the art and so do not present an exhaustive list of alternatives. Moreover, it should be recognized that the stages could be implemented in hardware, firmware, software or any combination thereof.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Stored Programmes (AREA)
Abstract
Method and Apparatus for loading kernel modules are disclosed. The method includes: obtaining a first loadable kernel module (LKM) and a second LKM, wherein the first LKM satisfies a first loading condition for being loaded into a first kernel, and the second LKM satisfies a second loading condition for being loaded into a second kernel different from the first kernel; identifying respective differences in one or more characteristic properties between the first and second LKMs; in accordance with the identified respective differences, modifying a respective one of the first and second LKMs; and loading the modified respective one of the first and second LKMs into the first kernel, wherein the modified respective one of the first and second LKM provides one or more functions in accordance with the second LKM.
Description
PRIORITY CLAIM AND RELATED APPLICATION
This application claims priority to Chinese Patent Application No.201310617869.6, entitled “Kernel Module Loading Method and Apparatus, ” filed on November 27,2013, which is incorporated by reference in its entirety.
FIELD OF THE TECHNOLOGY
The present disclosure relates to the field of computers, and in particular, to a kernel module loading method and apparatus.
An operating system is a program used for managing hardware and software resources of a computer, and is responsible for basic transactions such as managing and configuring a memory, deciding priorities of supplies and demands of system resources, controlling input and output devices, operating a network, and managing a file system. A kernel is a core of an operating system, and refers to system software used for providing functions such as controlling and multitasking of a hardware abstraction layer, a magnetic disk, and a file system, where because it is relatively complicated to perform direct operations for hardware of the computer, the kernel generally provides a hardware abstraction method to implement the operations. The hardware abstraction hides the complexity, and provides a set of compact and unified interfaces for application software and hardware, so that program design becomes easier.
A loadable kernel module (LKM) is an interface that is opened by the kernel of the operating system for a user to compile the kernel. Various functions may be implemented by using the LKM. For example, dynamic modification may be implemented on the operating system when the operating system is running, a failure or vulnerability of the kernel of the operating system may be repaired, or the like. Existing popular operating systems such as Linux, Microsoft Windows, and Mac OS X all support the LKM function, however, definitions of LKM structure supported by various operating systems or even supported by kernels of different versions of the same operating system vary, and therefore,
how to enable a compiled LKM to be compatible to various operating systems or kernels of different versions of the same operating system becomes a problem.
SUMMARY
To address the issues identified above, in some embodiments, a method of loading kernel modules is performed at a device (e.g., device 400 of FIG. 4) with one or more processors and memory. The method includes: obtaining a first loadable kernel module (LKM) and a second LKM, wherein the first LKM satisfies a first loading condition for being loaded into a first kernel, and the second LKM satisfies a second loading condition for being loaded into a second kernel different from the first kernel; identifying respective differences in one or more characteristic properties between the first and second LKMs; in accordance with the identified respective differences, modifying a respective one of the first and second LKMs; and loading the modified respective one of the first and second LKMs into the first kernel, wherein the modified respective one of the first and second LKM provides one or more functions in accordance with the second LKM.
In some embodiments, a computing device (e.g., device 400 of FIG. 4 or a component thereof (e.g., LKM manager 426) ) includes one or more processors and memory storing one or more programs for execution by the one or more processors, the one or more programs include instructions for performing, or controlling performance of, the operations of any of the methods described herein. In some embodiments, a non-transitory computer readable storage medium storing one or more programs, the one or more programs comprising instructions, which, when executed by a computing device (e.g., device 400 of FIG. 4 or a component thereof (e.g., LKM manager 426) ) with one or more processors, cause the computing device to perform, or control performance of, the operations of any of the methods described herein. In some embodiments, a computing device (e.g., device 400 of FIG. 4 or a component thereof (e.g., software manager 426) ) includes means for performing, or controlling performance of, the operations of any of the methods described herein.
Various advantages of the present application are apparent in light of the descriptions below.
The aforementioned features and advantages of the disclosed technology as well as additional features and advantages thereof will be more clearly understood hereinafter
as a result of a detailed description of preferred embodiments when taken in conjunction with the drawings.
FIGS. 1A-1B are flowcharts of a kernel module loading method in accordance with some embodiments.
FIGS. 2A-2B is a flowchart of a kernel module loading method in accordance with some embodiments.
FIG. 3 is a schematic view of a kernel module loading apparatus in accordance with some embodiments.
FIG. 4 is a block diagram of a device in accordance with some embodiments.
Like reference numerals refer to corresponding parts throughout the several views of the drawings.
DETAILED DESCRIPTIONS
Reference will now be made in detail to embodiments, examples of which are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the subject matter presented herein. But it will be apparent to one skilled in the art that the subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.
It should be noted that, terms such as "first" and "second" in the specification, the claims and the accompanying drawings of the present disclosure are used to distinguish like objects, and are not used to describe a specific order or priorities. It should be understood that, the data used like this may be exchanged in a suitable situation, so that the embodiments of the present technology described here may be implemented in an order other than those shown in the drawings or described.
In some embodiments, a kernel module loading method is provided. As shown in FIG. 1A, the method includes:
S102: Obtain a first LKM, where the first LKM satisfies a first loading condition for being loaded to a first kernel;
S104: Obtain a second LKM, where the second LKM satisfies a second loading condition for being loaded to a second kernel, but does not satisfy the first loading condition;
S106: Update the second LKM according to the first LKM, where the updated second LKM satisfies the first loading condition; and
S108: Load the updated second LKM to the first kernel.
It should be noted that, one of problems to be solved by the technical solutions provided herein is to provide a method so that an LKM that is compiled based on one operating system and a kernel of one version of the operating system can be successfully loaded to another operating system or a kernel of another version of the same operating system, so as to simplify cross-platform design of the LKMs. Through the implementation of the disclosed functions, complicated update work for the LKM of an old version that is required when the operating system and/or a kernel version thereof is updated may thus be avoided. For ease of description, a kernel of an operating system to which an LKM currently needs to be loaded successfully is referred to as a “first” kernel, and a kernel that originally matches the LKM is referred to as a “second” kernel, and the LKM is referred to as a “second” LKM.
In order to address the above problem, according to the kernel module loading method in some embodiments, step S104 may be performed to obtain the second LKM, and step S102 is performed to obtain another LKM that has been compiled and satisfies a loading condition for being loaded to the first kernel, where, for ease of description, this other LKM is referred to as the first LKM, and the loading condition is referred to as a first loading condition. Further, step S106 is performed, the second LKM is updated by using the first LKM or the first loading condition as a reference, so as to obtain an updated second LKM satisfying the first loading condition. Step S108 is performed to load the updated second LKM into the first kernel, and thereby achieving the effect of successfully loading the second LKM to the first kernel, where the second LKM is originally compiled based on the second kernel and satisfies the second loading condition for being loaded to the second kernel.
In some embodiments, the first loading condition corresponding to the first kernel may include various conditions. Specifically, a loading function of an LKM opened by a developer of the kernel to a user is generally provided with one or more verification steps, where if the LKM self-defined by the user passes the verification steps, the self-defined LKM may be loaded to the kernel normally, and if the verification steps are not passed,
loading of the self-defined LKM is stopped. For example, loading a self-defined LKM to a Linux kernel needs to pass the following three verification steps:
1) Vermagic: Check to see whether a version identifier of the LKM is consistent with a version identifier of the Linux kernel, and if so, the Vermagic verification step is passed; otherwise, the Vermagic verification step is not passed, where the version identifier of the LKM is used to identify a compiling environment and a running environment of the LKM.
2) Module Struct check: Check to see whether a size and a definition of a structure of the LKM are consistent with a definition of a structure of an LKM defined by the Linux kernel, and if so, the Module Struct check is passed; otherwise, the Module Struct check is not passed. The concept of the structure of the LKM is similar to a concept of a structure known by persons skilled in the art, which may include multiple data fields used for describing the LKM, and may further include an initialization function pointer used when the LKM is loaded and a clearing function pointer used when the LKM is unloaded. The number of members included in the structure of the LKM may vary according to change of a kernel version or kernel configuration.
3) Symbol CRC check: Check to see whether identifiers in the LKM is consistent with identifiers defined by the Linux kernel, and if so, the Symbol CRC check is passed; otherwise, the Symbol CRC check is not passed. The identifiers in the LKM represent symbols used to identify functions, structures and the like in the LKM. Specifically, during the check, specific comparison objects are generally not the identifiers, a CRC checksum of the identifiers in the LKM and a CRC checksum of the identifiers defined by the kernel are calculated respectively, the calculated CRC checksums are compared, and a check result of the CRC checksums is used as a result of the Symbol CRC check.
In the above scenario, the Linux operating system may load the self-defined LKM to the Linux kernel only after the three verification steps are all passed, and for another mainstream operating system, similar verification measures also exist. By checking the to-be-loaded LKM, it may be ensured that the LKM successfully loaded to a kernel can be identified by the normally running kernel or operating system, thereby improving the reliability of the kernel and running stability of the kernel.
In some embodiments, the verification measures may form the first loading condition which needs to be satisfied when successfully loading the second LKM module to the first kernel, and include a requirement on a structure of the LKM, a requirement on an
identifier of the LKM and a requirement on a version identity of the LKM; however, they are not limited in this embodiment. In some embodiments, a condition that is used for loading a self-defined LKM and set by a certain operating system and a kernel thereof may be different from the three conditions as described above, or may be variations of the three conditions, so that the first loading condition corresponding to the first kernel of this type may also include other factors.
In some embodiments, the obtained first LKM is a self-defined LKM that can be successfully loaded by the first kernel, so that the first LKM necessarily satisfies the first loading condition, and therefore, specific content of the first loading condition, such as a definition of a structure of the LKM, a definition of an identifier of the LKM, and a definition of a version identity of the LKM, may be reflected by using the first LKM as a template or by analyzing the first LKM, so that update of the second LKM may be implemented according to the specific content of the first loading condition obtained by using the first LKM as a template or by analyzing the first LKM, and the updated second LKM satisfies the first loading condition, thereby achieving the effect of loading the updated second LKM to the first kernel. The processing manner is obviously superior to the conventional processing manner of manually modifying an LKM for each operating system and a kernel of each version, thereby achieving the effect of obviously reducing maintenance cost of the LKM.
On the basis of the above description, more specifically, in some embodiments, the first loading condition may include a structure corresponding to the first kernel, where step S106 may include:
S202: Update a structure of the second LKM according to a structure of the first LKM, so as to form an updated second LKM.
As described in the foregoing, the verification measures of the Linux operating system for the self-defined LKM include the Module Struct verification step, where the so-called structure of the LKM may include multiple data fields used for describing the LKM, such as one or more function types corresponding to one or more system call functions for being called by the Linux operating system; however, this is not limited in the present method, and in some embodiments, the structure of the first LKM may also include data field (s) for one or more function types, and other data fields used for describing the LKM, such as one or more function pointers.
In some embodiments, many types of specific manners of updating the structure of the second LKM according to the structure of the first LKM exist, and as one feasible type, in some embodiments, step S202 may include:
S302: Obtain structure description information corresponding to the structure of the first LKM, record the obtained structure description information in a first configuration file, and mark the recorded structure description information as being corresponding to the first kernel; and
S304: Search the first configuration file for the structure description information corresponding to the first kernel, and update the structure of the second LKM according to the found structure description information, so as to form the updated second LKM.
In the above scenario, the obtained structure of the first LKM generally may be represented as a piece of Executable and Linkable Format (ELF) code, and the piece of ELF code is used to describe information such as sizes and types of various data or functions included in the first LKM, and because the first LKM satisfies the first loading condition corresponding to the first kernel, the structure description information is consistent with the definition of the structure made by the operating system where the first kernel is located. Further, in step S302, the obtained structure description information may be recorded in the first configuration file, and the structure description information is marked as being corresponding to the first kernel, so that in the update operation for the second LKM that is performed subsequently, the structure description information corresponding to the first kernel may be found in the first configuration file, without the need of temporarily capturing a first LKM satisfying the first loading condition. For a situation in which multiple second LKMs need to be loaded to the first kernel in turn, repeated capturing of the first LKM may be avoided through the above manner, thereby improving the processing efficiency. On the other hand, structure description information respectively corresponding to different kernels is recorded in the first configuration file intensively, so as to perform unified management and maintenance on the structure description information conveniently, thereby further reducing the maintenance cost. Definitely, the above description is only an example, and in some embodiments, the structure description information is not limited to be recorded by a certain format.
It should be noted that, in some embodiments, step S304 and step S302 may be performed separately, for example, in one scenario, step S102 may be performed before
one time period to obtain the first LKM, step S302 is then performed to perform corresponding obtaining, recording and marking operations on the structure description information thereof, step S104 is performed after this time period to obtain the second LKM, step S304 is then performed to update the second LKM, and finally step S108 is performed to load the updated second LKM to the first kernel.
The above description is only one feasible embodiment, and is not intended to limit the present method. For example, in some embodiments, the second LKM may also be updated according to the first LKM obtained in real time, where the first LKM may include multiple first system call functions, the second LKM may also include multiple second system call functions, and the structure of the first LKM includes multiple function types to which the multiple first system call functions belong, where, in some embodiments, step S202 may include:
S402: Replace each first system call function in the first LKM with one or more second system call functions in multiple second system call functions and of a function type the same as that of each first system call function, to serve as the updated second LKM.
In some embodiments, step S402 may be performed to replace multiple first system call functions in the first LKM correspondingly with multiple second system call functions in the second LKM, in other words, insert the multiple second system call functions in the first LKM, where the structure of the first LKM including the multiple first system call functions satisfies the first loading condition, and therefore, as long as the multiple second system call functions are correspondingly inserted in the first LKM, and it is ensured that the function types of the inserted second system call functions are consistent with the function types of the replaced first system call functions, the formed structure of the updated second LKM also satisfies the first loading condition, and therefore, the updated second LKM satisfies the first loading condition, and step S108 may be performed to successfully load the updated second LKM to the first kernel.
Further, in some embodiments, the first loading condition may also include an operating system identity and/or a version identity corresponding to the first kernel, where, step S106 may further include:
S502: Update the operating system identity and/or the version identity in the first LKM to the second LKM.
As described in the foregoing, the verification measures of the Linux operating system for the self-defined LKM further include the Vermagic verification step, and in this scenario, the first loading condition may include a version identity corresponding to the first kernel. Further, in some embodiments, the first loading condition may further include an operating system identity corresponding to the first kernel, so that the operating system can perform initial identification for the self-defined LKM. In consideration with the factors, in some embodiments, step S502 may be performed to update the operating system identity and/or the version identity in the first LKM to the second LKM, where, the first LKM satisfies the first loading condition; therefore the operating system identity and/or the version identity in the first LKM is corresponding to the first kernel, and the operating system identity and/or the version identity in the updated second LKM obtained in the above manner is also corresponding to the first kernel, so that the second LKM satisfies the first loading condition. It should be noted that, in various embodiments, update operations respectively performed through step S202 and step S502 need not be in any particular sequence, which is also not limited in the present method.
In some embodiments, the first loading condition may also include multiple LKM identifiers corresponding to the first kernel, and the LKM identifiers are used to identify a structure corresponding to the first kernel and/or belong to system call functions of the function types corresponding to the first kernel, where as shown in FIG. 1B, when step S106 is performed, the kernel module loading method may further include:
S602: Search a second configuration file for the multiple LKM identifiers; and
S604: Update the found multiple LKM identifiers to the structure of the second LKM and/or a second system call function of a function type identified by any one of the multiple LKM identifiers in the second LKM.
As described in the foregoing, the verification measures of the Linux operating system for the self-defined LKM further include the Symbol CRC verification step, that is, in some embodiments, the first loading condition may further include multiple LKM identifiers corresponding to the first kernel, where the LKM identifiers may be used to identify a structure of the LKM that is corresponding to the first kernel and meets a definition made by the first kernel and an operating system thereof, for example, the LKM identifiers may be used to identify an overall identity of the structure and each attribute identifier included in the structure, and may also be used to identify system call functions of various function types
corresponding to the first kernel, so that the operating system can call the system call functions subsequently.
In some embodiments, the LKM identifiers corresponding to the first kernel may be recorded in the second configuration file intensively, for example, for a Linux kernel, the corresponding LKM identifiers are generally stored in a /proc/kallsyms path, and therefore, in this embodiment, the second configuration file may be a file accessed through the path. Definitely, the above description is only an example, and is not limited in the present method.
Based on the above description, in some embodiments, after step S108 is performed to successfully load the updated second LKM to the first kernel, the kernel module loading method may further include:
S702: Record multiple function pointers corresponding to the multiple second system call functions in the updated second LKM, so that the operating system calls the corresponding second system call functions according to one or more of the multiple function pointers.
Similar to the calling manner of the existing operating system for the functions in the kernel having the self-defined LKM loaded, and in some embodiments, after step S108 is performed to successfully load the updated second LKM to the first kernel, the operating system may implement calling for one or more of the second system call functions by using the function pointer corresponding to each of the multiple second system call functions included in the second LKM recorded in the step S702.
It should be noted that, in some embodiments, the recording operation on the multiple function pointers corresponding to the multiple second system call functions as described in step S702 may include many types, for example, the recorded function pointer may be the function pointer corresponding to the original system call function in the first kernel, and in this scenario, when the operating system calls the corresponding system call function according to the function pointer, the called function is no longer the original system call function of the first kernel, but the second system call function pointed by the function pointer in the loaded second LKM, so that the operation of loading the second LKM to the first kernel in this scenario may be considered as replacement to the original system call function in the first kernel. Definitely, in some embodiments, a recorded function pointer may also be a newly added pointer that is different from the function pointers corresponding to the original call functions in the first kernel, and in this scenario, the second system call
function in the loaded second LKM may be used for adding a new function for the first kernel and may also be used for repairing original failure or vulnerability of the first kernel. In view of the above, specific functions of the second LKM loaded to the first kernel are not limited in the present method; however, this type of embodiments based on the present method should all fall within the scope of the present disclosure.
It should be noted that, for the method embodiments as described in the foregoing, for ease of description, the embodiments are expressed as combinations of a series of actions; however, persons skilled in the art should know that the present method is not limited by the order of the described order, and because some steps may be performed in other orders or simultaneously according to the present method. Persons skilled in the art may also know that the embodiments described in the specification are all preferred embodiments, and involved actions and modules are not necessary for the present method.
Through the descriptions of the embodiment, persons skilled in the art may clearly know that the method according to the above embodiment may be implemented by software and necessary universal hardware platform, and may also be implemented by hardware; however, the former is a better implementation in many situations. Based on such understanding, the technical solution of the present disclosure substantially or contributive parts to the prior art may be embodied by a software product, and the computer software product is stored in a storage medium (such as a ROM/RAM, a magnetic disk and an optical disc) , and includes several instructions used to enable a terminal device (which may be a mobile phone, a computer, a server, a network device, or the like) to perform the method described herein.
FIGS. 2A-2B is a flowchart of a method of loading kernel modules in accordance with some embodiments. The method may be performed by a device (e.g., device 400 of FIG. 4) running an operating system having a first kernel (e.g., a Linux kernel of a first version, or a particular version of another OS platform) .
In some embodiments, the device obtains (202) a first loadable kernel module (LKM) and a second LKM, wherein the first LKM satisfies a first loading condition for being loaded into a first kernel, and the second LKM satisfies a second loading condition for being loaded into a second kernel different from the first kernel. For example, the first LKM is an LKM of the first kernel, and the second LKM is the LKM that is for a newer version of the first kernel, or a different platform than the first kernel. The second LKM needs to be made into a form that can be loaded into the first kernel, or alternatively, the functions provided in
the second LKM needs to be made available to the first kernel. The device identifies (204) respective differences in one or more characteristic properties (e.g., the characteristics that prevents the second LKM from being loaded into the first kernel successfully) between the first and second LKMs. In accordance with the identified respective differences, the device modifies (206) a respective one of the first and second LKMs, and loads (208) the modified respective one of the first and second LKMs into the first kernel, wherein the modified respective one of the first and second LKM provides one or more functions in accordance with the second LKM. For example, the first LKM may be modified internally to call the functions specified in the second LKM, and thus, when the first LKM is loaded into the first kernel, the functions referred to in the second LKM can be called and utilized by the first kernel. In some embodiments, the second LKM may be modified according to the characteristics of the first LKM, such that the second LKM would be able to satisfy the condition for being loaded into the first kernel successfully and providing its functions to the first kernel.
In some embodiments, obtaining the first LKM and the second LKM further includes (210) : receiving an instruction for loading the second LKM into the first kernel; determining whether the second LKM satisfies the first loading condition for being loaded into the first kernel; and in accordance with a determination that the second LKM does not satisfy the first loading condition for being loaded into the first kernel, obtaining the first LKM that satisfies the first loading condition for being loaded into the first kernel.
In some embodiments, identifying respective differences in one or more characteristic properties between the first and second LKMs further includes (212) at least one of: identifying a first difference between respective operating system identities or version identities corresponding to the first and second LKMs; identifying a second difference between respective structures corresponding to the first and second LKMs; and identifying a third difference between respective system function calls corresponding to the first and second LKMs. This step is described as the verification steps determining whether the LKM may be loaded into the first kernel successfully, and identifying the reasons for failing the load the LKM into the first kernel.
In some embodiments, in accordance with the identified respective differences, modifying a respective one of the first and second LKMs further includes (214) : in accordance with the identified respective differences, modifying one or more first function pointers corresponding to one or more operating system calls in the first LKM to one or more
second function pointers in the second LKM. This can be done such that when the first LKM is loaded into the first kernel, the function pointers in the first LKM will point to functions as specified in the second LKM, such that even though the second LKM is not loaded into the first kernel, the functions provided by the second LKM (e.g. , additional functions or patches) can be provided to the first kernel. In such embodiments, loading the modified respective one of the first and second LKMs into the first kernel further includes (216) loading the modified first LKM into the first kernel.
In some embodiments, in accordance with the identified respective differences, modifying a respective one of the first and second LKMs further includes (218) : in accordance with the identified respective differences, modifying at least one of a respective operating system identity, version identity, and structure of the second LKM in accordance with corresponding at least one of a respective operating system identity, version identity, and structure of the first LKM. In such embodiments, loading the modified respective one of the first and second LKMs into the first kernel further includes (210) loading the modified second LKM into the first kernel. After being modified according to the characteristic properties of the first LKM, the second LKM will be able to pass the condition for being loaded into the first kernel successfully, and thus can provide its functions to the first kernel. In some embodiments, other modifications, such as modifying the functions and function pointers in the second LKM according to corresponding functions and functions pointers in the first LKM may also be performed before the second LKM is loaded into the first kernel.
Other aspects of the method for loading kernel modules are provided with respect to FIGS. 1A-1B and are not repeated here in the interest of brevity.
In some embodiments, a kernel module loading apparatus used for implementing the kernel module loading method is further provided. As shown in FIG. 3, the apparatus includes:
1) a first obtaining unit 302, used to obtain a first loadable kernel module (LKM) , where the first LKM satisfies a first loading condition for being loaded to a first kernel;
2) a second obtaining unit 304, used to obtain a second LKM, where the second LKM satisfies a second loading condition for being loaded to a second kernel but does not satisfy the first loading condition;
3) a first updating unit 306, used to update the second LKM according to the first LKM, where the updated second LKM satisfies the first loading condition; and
4) a loading unit 308, used to load the updated second LKM to the first kernel.
It should be understood that, one of problems to be solved in the technical solution provided herein is providing an apparatus, so that an LKM compiled based on an operating system and a kernel of a version of the operating system can be successfully loaded to another operating system or a kernel of another version of the same operating system, so as to simplify cross-platform design of the LKM through the implementation of the function, and avoid complicated update work for the LKM of an old version that is required when the operating system and/or a kernel version thereof is updated. For ease of description, a kernel of an operating system to which an LKM currently needs to be loaded successfully is referred to as a first kernel, and a kernel that originally matches the LKM is referred to as a second kernel, and the LKM is referred to as a second LKM.
To solve the above problem, the kernel module loading apparatus provided according to some embodiments can obtain the second LKM by using the second obtaining unit 304, obtain, by using the first obtaining unit 302, another LKM that has been compiled and satisfies a loading condition for being loaded to the first kernel, where, for ease of description, the another LKM is referred to as a first LKM, and the loading condition is referred to as a first loading condition. Further, by using the first updating unit 306, the second LKM is updated by using the first LKM or the first loading condition as a reference, so as to obtain an updated second LKM satisfying the first loading condition, and the loading unit 308 is further used to load the updated second LKM to the first kernel, thereby achieving the effect of successfully loading the second LKM to the first kernel, where the second LKM is originally compiled based on the second kernel and satisfies the second loading condition for being loaded to the second kernel.
In some embodiments, the first loading condition corresponding to the first kernel may include various conditions. Specifically, a loading function of an LKM opened by a developer of the kernel to a user is generally provided with one or more verification steps, where if the LKM self-defined by the user passes the verifications, the self-defined LKM may be loaded to the kernel normally, and if the verifications are not passed, loading of the self-defined LKM is stopped. For example, loading a self-defined LKM to a Linux kernel needs to pass the following three verification steps:
1) Vermagic: Check to see whether a version identity of the LKM is consistent with a version identity of the Linux kernel, and if yes, the Vermagic check is passed; otherwise, the Vermagic check is not passed, where the version identity of the LKM is used to identify a compiling environment and a running environment of the LKM;
2) Module Struct check: Check to see whether a size and a definition of a structure of the LKM are consistent with a definition of a structure of an LKM defined by the Linux kernel, and if yes, the Module Struct check is passed; otherwise, the Module Struct check is not passed, where the concept of the structure of the LKM is similar to a concept of a structure known by persons skilled in the art, which may include multiple data fields used for describing the LKM, and may further include an initialization function pointer when the LKM is loaded and a clearing function pointer when the LKM is unloaded, where the number of members included in the structure of the LKM may vary according to change of a kernel version or kernel configuration; and
3) Symbol CRC check: Check to see whether an identifier in the LKM is consistent with an identifier defined by the Linux kernel, and if yes, the Symbol CRC check is passed; otherwise, the Symbol CRC check is not passed, where the identifier in the LKM represents a symbol used to identify a function, a structure and the like in the LKM. Specifically, during the check, specific comparison objects are generally not the identifiers, a CRC checksum of the identifier in the LKM and a CRC checksum of the identifier defined by the kernel are calculated respectively, the calculated CRC checksums are compared, and a check result of the CRC checksums is used as a result of the Symbol CRC check.
In the above scenario, the Linux operating system may load the self-defined LKM to the Linux kernel only after the three verification steps are all passed, and for another mainstream operating system, similar verification measures also exist. By checking the to-be-loaded LKM, it may be ensured that the LKM successfully loaded to a kernel can be identified by the normally running kernel or operating system, thereby improving the reliability of the kernel and running stability of the kernel.
In some embodiments, the verification measures may form the first loading condition which needs to be satisfied when successfully loading the second LKM module to the first kernel, and include a requirement on a structure of the LKM, a requirement on an identifier of the LKM and a requirement on a version identity of the LKM; however, they are not limited in this embodiment, and in some embodiments, a condition that is used for loading a self-defined LKM and set by a certain operating system and a kernel thereof may be
different from the three conditions as described above, or may be variations of the three conditions, so that the first loading condition corresponding to the first kernel of this type may also include another factor.
In some embodiments, the obtained first LKM is a self-defined LKM that can be successfully loaded by the first kernel, so that the first LKM necessarily satisfies the first loading condition, and therefore, specific content of the first loading condition, such as a definition of a structure of the LKM, a definition of an identifier of the LKM, and a definition of a version identity of the LKM, may be reflected by using the first LKM as a template or by analyzing the first LKM, so that update of the second LKM may be implemented according to the specific content of the first loading condition obtained by using the first LKM as a template or by analyzing the first LKM, and the updated second LKM satisfies the first loading condition, thereby achieving the effect of loading the updated second LKM to the first kernel. The processing manner is obviously superior to the conventional processing manner of manually modifying an LKM for each operating system and a kernel of each version, thereby achieving the effect of obviously reducing maintenance cost of the LKM.
On the basis of the above description, more specifically, in some embodiments, the first loading condition may include a structure corresponding to the first kernel, where the first updating unit 306 may include:
1) a first updating module 310, used to update a structure of the second LKM according to a structure of the first LKM, so as to form an updated second LKM.
As described in the foregoing, the verification measures of the Linux operating system for the self-defined LKM include the Module Struct verification step, where the so-called structure of the LKM may include multiple data fields used for describing the LKM, such as a function type of a system call function for being called by the Linux operating system; however, this is not limited in the present apparatus, and in some embodiments, the structure of the first LKM may also include a function type, and may also include another data field used for describing the LKM, such as a function pointer.
In some embodiments, many types of specific manners of updating the structure of the second LKM according to the structure of the first LKM exist, and as one feasible type, in some embodiments, the first updating module 310 may include:
1) a recording sub-module, used to obtain structure description information corresponding to the structure of the first LKM, record the obtained structure description
information in a first configuration file, and mark the recorded structure description information as being corresponding to the first kernel; and
2) an updating sub-module, used to search the first configuration file for the structure description information corresponding to the first kernel, and update the structure of the second LKM according to the found structure description information, so as to form the updated second LKM.
In the above scenario, the obtained structure of the first LKM generally may be represented as a piece of Executable and Linkable Format (ELF) code, and the piece of ELF code is used to describe information such as sizes and types of various data or functions included in the first LKM, and because the first LKM satisfies the first loading condition corresponding to the first kernel, the structure description information is consistent with the definition of the structure made by the operating system where the first kernel is located. Further, in some embodiments, the obtained structure description information may be recorded in the first configuration file, and the structure description information is marked as being corresponding to the first kernel, so that in the update operation for the second LKM that is performed subsequently, the structure description information corresponding to the first kernel may be found in the first configuration file, without the need of temporarily capturing a first LKM satisfying the first loading condition. For a situation in which multiple second LKMs need to be loaded to the first kernel in turn, repeated capturing of the first LKM may be avoided through the above manner, thereby improving the processing efficiency. On the other hand, structure description information respectively corresponding to different kernels is recorded in the first configuration file intensively, so as to perform unified management and maintenance on the structure description information conveniently, thereby further reducing the maintenance cost. Definitely, the above description is only an example, and in some embodiments, the structure description information is not limited to be recorded by a certain format.
It should be noted that, in this embodiment, the recording operation performed by the recording sub-module and the updating operation performed by the updating sub-module may be performed separately, for example, in one scenario, the first obtaining unit 302 is used before one time period to obtain the first LKM, the recording sub-module is used to perform corresponding obtaining, recording and marking operations on the structure description information thereof, the second obtaining unit 304 is used after this time period to
obtain the second LKM, the updating sub-module is then used to update the second LKM, and finally the loading unit 308 is used to load the updated second LKM to the first kernel.
Definitely, the above description is only one feasible embodiment, and is not intended to limit the present apparatus. For example, in some embodiments, the second LKM may also be updated according to the first LKM obtained in real time, where the first LKM may include multiple first system call functions, the second LKM may also include multiple second system call functions, and the structure of the first LKM includes multiple function types to which the multiple first system call functions belong, where in some embodiments, the first updating module 310 may include:
1) a replacing sub-module, used to Replace each first system call function in the first LKM with one or more second system call functions in multiple second system call functions and of a function type the same as that of each first system call function, to serve as the updated second LKM.
In some embodiments, the replacing sub-module may be used to replace multiple first system call functions in the first LKM correspondingly with multiple second system call function in the second LKM, in other words, insert the multiple second system call functions in the first LKM, where the structure of the first LKM including the multiple first system call functions satisfies the first loading condition, and therefore, as long as the multiple second system call functions are correspondingly inserted in the first LKM, and it is ensured that the function types of the inserted second system call functions are consistent with the function types of the replaced first system call functions, the formed structure of the updated second LKM also satisfies the first loading condition, and therefore, the updated second LKM satisfies the first loading condition, and the loading unit 108 may be used to successfully load the updated second LKM to the first kernel.
Further, in some embodiments, the first loading condition may also include an operating system identity and/or a version identity corresponding to the first kernel, where the first updating unit 306 may further include:
1) a second updating module, used to update the operating system identity and/or the version identity in the first LKM to the second LKM.
As described in the foregoing, the verification measures of the Linux operating system for the self-defined LKM further include the Vermagic verification step, and in this scenario, the first loading condition may include a version identity corresponding to the first
kernel. Further, in some embodiments, the first loading condition may further include an operating system identity corresponding to the first kernel, so that the operating system can perform initial identification for the self-defined LKM. In consideration with the factors, in some embodiments, the second updating module may be used to update the operating system identity and/or the version identity in the first LKM to the second LKM, where, the first LKM satisfies the first loading condition; therefore the operating system identity and/or the version identity in the first LKM is corresponding to the first kernel, and the operating system identity and/or the version identity in the updated second LKM obtained in the above manner is also corresponding to the first kernel, so that the second LKM satisfies the first loading condition. It should be noted that, in some embodiments, update operations respectively performed by the first updating module 310 and the second updating module have no necessary sequence, which is also not limited in the present technology.
On the other hand, in some embodiments, the first loading condition may also include multiple LKM identifiers corresponding to the first kernel, and the LKM identifiers are used to identify a structure corresponding to the first kernel and/or belong to system call functions of the function type corresponding to the first kernel, where the kernel module loading apparatus may further include:
1) a searching unit, used to search the second configuration file for the multiple LKM identifiers; and
2) a second updating unit, used to update the found multiple LKM identifiers to the structure of the second LKM and/or a second system call function of a function type identified by any one of the multiple LKM identifiers in the second LKM.
As described in the foregoing, the verification measures of the Linux operating system for the self-defined LKM further include the Symbol CRC verification step, that is, in some embodiments, the first loading condition may further include multiple LKM identifiers corresponding to the first kernel, where the LKM identifiers may be used to identify a structure of the LKM that is corresponding to the first kernel and meets a definition made by the first kernel and an operating system thereof, for example, the LKM identifiers may be used to identify an overall identity of the structure and each attribute identifier included in the structure, and may also be used to identify a system call function of a function type corresponding to the first kernel, so that the operating system can call the system call function subsequently.
In some embodiments, the LKM identifiers corresponding to the first kernel may be recorded in the second configuration file intensively, for example, for a Linux kernel, the corresponding LKM identifiers are generally stored in a /proc/kallsyms path, and therefore, in this embodiment, the second configuration file may be a file accessed through the path. Definitely, the above description is only an example, and is not limited in the present apparatus.
Based on the above description, in some embodiments, after the loading unit 108 is used to successfully load the updated second LKM to the first kernel, the kernel module loading apparatus may further include:
1) a recording unit, used to record multiple function pointers corresponding to the multiple second system call functions in the updated second LKM, so that the operating system calls the corresponding second system call function according to one or more of the multiple function pointers.
Similar to the calling manner of the existing operating system for the function in the kernel having the self-defined LKM loaded, and in some embodiments, after the loading unit 308 is used to successfully load the updated second LKM to the first kernel, the operating system may implement calling for one or more of the second system call functions by using the function pointer corresponding to each of the multiple second system call functions included in the second LKM recorded in the recording unit.
It should be noted that, in some embodiments, the recording operation on the multiple function pointers corresponding to the multiple second system call functions performed by the recording unit may include many types, for example, the recorded function pointer may be the function pointer corresponding to the original system call function in the first kernel, and in this scenario, when the operating system calls the corresponding system call function according to the function pointer, the called function is no longer the original system call function of the first kernel, but the second system call function pointed by the function pointer in the loaded second LKM, so that the operation of loading the second LKM to the first kernel in this scenario may be considered as replacement to the original system call function in the first kernel. Definitely, in some embodiments, the recorded function pointer may also be a newly added pointer that is different from the function pointers corresponding to the original call function in the first kernel, and in this scenario, the second system call function in the loaded second LKM may be used for adding a new function for the first kernel and may also be used for repairing original failure or vulnerability of the first
kernel. In view of the above, specific functions of the second LKM loaded to the first kernel are not limited in the present apparatus; however, this type of embodiments based on the present apparatus should all fall within the scope of the present disclosure.
In the embodiments provided in this application, it should be understood that, the disclosed apparatus, unit and module may be implemented through other manners. The described apparatus embodiment is only an example, for example, a division of units is only a division of logic functions, and in fact, another division manner may exist during implementation, for example, multiple units or components may be combined or integrated to another system, or some features may be omitted or not performed. On the other hand, the shown or discussed mutual coupling or direct coupling or communication connection may be performed through indirect coupling or communication connection of some interfaces, units or modules electrically or in other forms.
The units described as separated parts may be or may not be physically separated, and parts shown as units may or may not be physical units, that is, they may located on the same place, or may also be distributed to multiple network units. A part of or all units may be selected according to actual requirements to implement the object of the solution of this embodiment.
In addition, various functional units in each embodiment may be integrated in one processing unit, the units may exist separately and physically, and two or more units may be integrated in one unit. The integrated unit may be implemented in hardware form, and may also be implemented in form of a software function unit.
If the integrated unit is implemented in form of a software function unit and is sold or used as a separated product, the unit may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present disclosure substantially or contributive parts to the prior art or all or a part of the technical solution may be embodied by a software product, and the computer software product is stored in a storage medium and includes several instructions used to enable a computer device (which may be a personal computer, a server, a network device, or the like) to perform all or a part of steps of the method described in the embodiments of the present technology. The storage medium includes various medium capable of storing program codes, such as a USB flash disk, a read-only memory (ROM) , a random access memory (RAM) , a movable hard disk, a magnetic disk, or an optical disc.
Figure 4 is a block diagram illustrating a representative device 400 in accordance with some embodiments. Device 400, typically, includes one or more processing units (CPUs) 402, one or more network interfaces 404, memory 406, and one or more communication buses 408 for interconnecting these components (sometimes called a chipset) . Device 400 also optionally includes a user interface 410. User interface 410 includes one or more output devices 412 that enable presentation of media content, including one or more speakers and/or one or more visual displays. User interface 410 also includes one or more input devices 414, including user interface components that facilitate user input such as a keyboard, a mouse, a voice-command input unit or microphone, a touch screen display, a touch-sensitive input pad, a gesture capturing camera, or other input buttons or controls. Furthermore, some devices 400 use a microphone and voice recognition or a camera and gesture recognition to supplement or replace the keyboard. Memory 406 includes high-speed random access memory, such as DRAM, SRAM, DDR RAM, or other random access solid state memory devices; and, optionally, includes non-volatile memory, such as one or more magnetic disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid state storage devices. Memory 406, optionally, includes one or more storage devices remotely located from one or more processing units 402. Memory 406, or alternatively the non-volatile memory within memory 406, includes a non-transitory computer readable storage medium.
In some implementations, memory 406, or the non-transitory computer readable storage medium of memory 406, stores the following programs, modules, and data structures, or a subset or superset thereof:
one or more applications 426 for execution by user device 100 (e.g., games, application marketplaces, payment platforms, and/or other web or non-web based applications) ;
· obtaining module 428 to obtain loadable kernel modules from the user, from the memory, and from disc storage;
· characteristic collection module 430 to gather pertinent characteristic properties associated with each obtained LKMs and determining the pertinent characteristics that need to be modified in order to bring an incompatible LKM into compliance with the loading condition of the current kernel;
· LKM modification module 432 to modify LKMs to conform to the loading conditions of the current kernel;
· Loading module 434 for loading modified LKMs that meet the loading conditions of the current kernel; and
· Other modules 436 for implementing other functions involved in loading LKMs described herein.
Each of the above identified elements may be stored in one or more of the previously mentioned memory devices, and corresponds to a set of instructions for performing a function described above. The above identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures, modules or data structures, and thus various subsets of these modules may be combined or otherwise re-arranged in various implementations. In some implementations, memory 406, optionally, stores a subset of the modules and data structures identified above. Furthermore, memory 406, optionally, stores additional modules and data structures not described above.
While particular embodiments are described above, it will be understood it is not intended to limit the disclosure to these particular embodiments. On the contrary, the disclosed technology includes alternatives, modifications and equivalents that are within the spirit and scope of the appended claims. Numerous specific details are set forth in order to provide a thorough understanding of the subject matter presented herein. But it will be apparent to one of ordinary skill in the art that the subject matter may be practiced without these specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.
Although some of the various drawings illustrate a number of logical stages in a particular order, stages that are not order dependent may be reordered and other stages may be combined or broken out. While some reordering or other groupings are specifically mentioned, others will be obvious to those of ordinary skill in the art and so do not present an exhaustive list of alternatives. Moreover, it should be recognized that the stages could be implemented in hardware, firmware, software or any combination thereof.
The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the disclosed technology to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles of the disclosed technology and its practical applications, to thereby enable others skilled in the art to best utilize the disclosed technology and various embodiments with various modifications as are suited to the particular use contemplated.
Claims (20)
- A method of loading kernel modules, comprising:at a device having one or more processors and memory:obtaining a first loadable kernel module (LKM) and a second LKM, wherein the first LKM satisfies a first loading condition for being loaded into a first kernel, and the second LKM satisfies a second loading condition for being loaded into a second kernel different from the first kernel;identifying respective differences in one or more characteristic properties between the first and second LKMs;in accordance with the identified respective differences, modifying a respective one of the first and second LKMs; andloading the modified respective one of the first and second LKMs into the first kernel, wherein the modified respective one of the first and second LKM provides one or more functions in accordance with the second LKM.
- The method of claim 1, wherein obtaining the first LKM and the second LKM further comprises:receiving an instruction for loading the second LKM into the first kernel;determining whether the second LKM satisfies the first loading condition for being loaded into the first kernel; andin accordance with a determination that the second LKM does not satisfy the first loading condition for being loaded into the first kernel, obtaining the first LKM that satisfies the first loading condition for being loaded into the first kernel.
- The method of claim 1, wherein identifying respective differences in one or more characteristic properties between the first and second LKMs further comprises at least one of:identifying a first difference between respective operating system identities or version identities corresponding to the first and second LKMs;identifying a second difference between respective structures corresponding to the first and second LKMs; andidentifying a third difference between respective system function calls corresponding to the first and second LKMs.
- The method of claim 1, wherein in accordance with the identified respective differences, modifying a respective one of the first and second LKMs further comprises:in accordance with the identified respective differences, modifying one or more first function pointers corresponding to one or more operating system calls in the first LKM to one or more second function pointers in the second LKM.
- The method of claim 4, wherein loading the modified respective one of the first and second LKMs into the first kernel further comprises loading the modified first LKM into the first kernel.
- The method of claim 1, wherein in accordance with the identified respective differences, modifying a respective one of the first and second LKMs further comprises:in accordance with the identified respective differences, modifying at least one of a respective operating system identity, version identity, and structure of the second LKM in accordance with corresponding at least one of a respective operating system identity, version identity, and structure of the first LKM.
- The method of claim 6, wherein loading the modified respective one of the first and second LKMs into the first kernel further comprises loading the modified second LKM into the first kernel.
- A device for loading kernel modules, comprising:one or more processors; andmemory having instructions stored thereon, the instructions, when executed by the one or more processors, cause the processors to perform operations comprising:obtaining a first loadable kernel module (LKM) and a second LKM, wherein the first LKM satisfies a first loading condition for being loaded into a first kernel, and the second LKM satisfies a second loading condition for being loaded into a second kernel different from the first kernel;identifying respective differences in one or more characteristic properties between the first and second LKMs;in accordance with the identified respective differences, modifying a respective one of the first and second LKMs; andloading the modified respective one of the first and second LKMs into the first kernel, wherein the modified respective one of the first and second LKM provides one or more functions in accordance with the second LKM.
- The device of claim 8, wherein obtaining the first LKM and the second LKM further comprises:receiving an instruction for loading the second LKM into the first kernel;determining whether the second LKM satisfies the first loading condition for being loaded into the first kernel; andin accordance with a determination that the second LKM does not satisfy the first loading condition for being loaded into the first kernel, obtaining the first LKM that satisfies the first loading condition for being loaded into the first kernel.
- The device of claim 8, wherein identifying respective differences in one or more characteristic properties between the first and second LKMs further comprises at least one of:identifying a first difference between respective operating system identities or version identities corresponding to the first and second LKMs;identifying a second difference between respective structures corresponding to the first and second LKMs; andidentifying a third difference between respective system function calls corresponding to the first and second LKMs.
- The device of claim 8, wherein in accordance with the identified respective differences, modifying a respective one of the first and second LKMs further comprises:in accordance with the identified respective differences, modifying one or more first function pointers corresponding to one or more operating system calls in the first LKM to one or more second function pointers in the second LKM.
- The device of claim 11, wherein loading the modified respective one of the first and second LKMs into the first kernel further comprises loading the modified first LKM into the first kernel.
- The device of claim 8, wherein in accordance with the identified respective differences, modifying a respective one of the first and second LKMs further comprises:in accordance with the identified respective differences, modifying at least one of a respective operating system identity, version identity, and structure of the second LKM in accordance with corresponding at least one of a respective operating system identity, version identity, and structure of the first LKM.
- The device of claim 13, wherein loading the modified respective one of the first and second LKMs into the first kernel further comprises loading the modified second LKM into the first kernel.
- A non-transitory computer-readable medium having instructions stored thereon, the instructions, when executed by one or more processors, cause the processors to perform operations comprising:obtaining a first loadable kernel module (LKM) and a second LKM, wherein the first LKM satisfies a first loading condition for being loaded into a first kernel, and the second LKM satisfies a second loading condition for being loaded into a second kernel different from the first kernel;identifying respective differences in one or more characteristic properties between the first and second LKMs;in accordance with the identified respective differences, modifying a respective one of the first and second LKMs; andloading the modified respective one of the first and second LKMs into the first kernel, wherein the modified respective one of the first and second LKM provides one or more functions in accordance with the second LKM.
- The computer-readable medium of claim 15, wherein obtaining the first LKM and the second LKM further comprises:receiving an instruction for loading the second LKM into the first kernel;determining whether the second LKM satisfies the first loading condition for being loaded into the first kernel; andin accordance with a determination that the second LKM does not satisfy the first loading condition for being loaded into the first kernel, obtaining the first LKM that satisfies the first loading condition for being loaded into the first kernel.
- The computer-readable medium of claim 15, wherein identifying respective differences in one or more characteristic properties between the first and second LKMs further comprises at least one of:identifying a first difference between respective operating system identities or version identities corresponding to the first and second LKMs;identifying a second difference between respective structures corresponding to the first and second LKMs; andidentifying a third difference between respective system function calls corresponding to the first and second LKMs.
- The computer-readable medium of claim 15, wherein in accordance with the identified respective differences, modifying a respective one of the first and second LKMs further comprises:in accordance with the identified respective differences, modifying one or more first function pointers corresponding to one or more operating system calls in the first LKM to one or more second function pointers in the second LKM.
- The computer-readable medium of claim 18, wherein loading the modified respective one of the first and second LKMs into the first kernel further comprises loading the modified first LKM into the first kernel.
- The computer-readable medium of claim 15, wherein in accordance with the identified respective differences, modifying a respective one of the first and second LKMs further comprises:in accordance with the identified respective differences, modifying at least one of a respective operating system identity, version identity, and structure of the second LKM in accordance with corresponding at least one of a respective operating system identity, version identity, and structure of the first LKM; andwherein loading the modified respective one of the first and second LKMs into the first kernel further comprises loading the modified second LKM into the first kernel.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310617869.6A CN104679532B (en) | 2013-11-27 | 2013-11-27 | kernel module loading method and device |
CN201310617869.6 | 2013-11-27 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2015078294A1 true WO2015078294A1 (en) | 2015-06-04 |
Family
ID=53198345
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/CN2014/090842 WO2015078294A1 (en) | 2013-11-27 | 2014-11-11 | Kernel module loading method and apparatus |
Country Status (2)
Country | Link |
---|---|
CN (1) | CN104679532B (en) |
WO (1) | WO2015078294A1 (en) |
Cited By (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170090897A1 (en) * | 2015-09-26 | 2017-03-30 | Cisco Technology, Inc. | In-service upgrade of kernel loadable modules |
WO2018153052A1 (en) * | 2017-02-22 | 2018-08-30 | 百度在线网络技术(北京)有限公司 | Method and device for loading kernel module |
US10635511B2 (en) | 2016-12-27 | 2020-04-28 | Huawei Technologies Co., Ltd. | Kernel update method and apparatus, and computer device |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105183530A (en) * | 2015-11-03 | 2015-12-23 | 浪潮(北京)电子信息产业有限公司 | Module loading method and system based on K-UNIX core |
CN105893085A (en) * | 2016-03-30 | 2016-08-24 | 百度在线网络技术(北京)有限公司 | Method and device for loading kernel module |
CN105868639A (en) * | 2016-03-30 | 2016-08-17 | 百度在线网络技术(北京)有限公司 | Kernel vulnerability repair method and device |
CN105893850B (en) * | 2016-03-30 | 2017-12-15 | 百度在线网络技术(北京)有限公司 | Leak restorative procedure and device |
CN109543400B (en) * | 2017-09-21 | 2022-08-09 | 华为技术有限公司 | Method and equipment for dynamically managing kernel nodes |
CN110401687B (en) * | 2018-04-25 | 2021-10-22 | 华为技术有限公司 | Configuration file transmission method, related equipment and storage medium |
CN111752620B (en) * | 2019-03-26 | 2024-08-20 | 斑马智行网络(香港)有限公司 | Processing method and loading method of kernel module |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5961642A (en) * | 1997-07-31 | 1999-10-05 | Ncr Corporation | Generic kernel modification for the dynamic configuration of operating systems in a multi-processor system |
US20040221275A1 (en) * | 2002-04-17 | 2004-11-04 | Thomas Handal | Apparatus and method for modifying a kernel module to run on multiple kernel versions |
CN101281488A (en) * | 2007-04-06 | 2008-10-08 | 上海宇梦通信科技有限公司 | Inner core debug method of Linux operating system |
US20100205587A1 (en) * | 2009-02-10 | 2010-08-12 | Huafei Dai | Method, device and system for realizing kernel online patching |
CN101986266A (en) * | 2010-10-22 | 2011-03-16 | 浙江大学 | Method for transplanting Android mobile phone operating system to Atom development board |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050071856A1 (en) * | 2003-09-26 | 2005-03-31 | Kumar C.P. Vijay | Dynamically loadable stub modules |
CN100464304C (en) * | 2006-08-29 | 2009-02-25 | 飞塔信息科技(北京)有限公司 | Device and method for realizing zero copy based on Linux operating system |
CN101589386B (en) * | 2006-12-04 | 2013-03-27 | 桑迪士克Il有限公司 | Incremental transparent file updating |
CN103020518B (en) * | 2012-11-06 | 2015-07-08 | 中国科学院计算技术研究所 | Method and system for protecting data structure in Linux kernel initialization based on TPM (Trusted Platform Module) |
-
2013
- 2013-11-27 CN CN201310617869.6A patent/CN104679532B/en active Active
-
2014
- 2014-11-11 WO PCT/CN2014/090842 patent/WO2015078294A1/en active Application Filing
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5961642A (en) * | 1997-07-31 | 1999-10-05 | Ncr Corporation | Generic kernel modification for the dynamic configuration of operating systems in a multi-processor system |
US20040221275A1 (en) * | 2002-04-17 | 2004-11-04 | Thomas Handal | Apparatus and method for modifying a kernel module to run on multiple kernel versions |
CN101281488A (en) * | 2007-04-06 | 2008-10-08 | 上海宇梦通信科技有限公司 | Inner core debug method of Linux operating system |
US20100205587A1 (en) * | 2009-02-10 | 2010-08-12 | Huafei Dai | Method, device and system for realizing kernel online patching |
CN101986266A (en) * | 2010-10-22 | 2011-03-16 | 浙江大学 | Method for transplanting Android mobile phone operating system to Atom development board |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20170090897A1 (en) * | 2015-09-26 | 2017-03-30 | Cisco Technology, Inc. | In-service upgrade of kernel loadable modules |
CN108027724A (en) * | 2015-09-26 | 2018-05-11 | 思科技术公司 | Upgrade in the service of kernel loadable module |
US10289398B2 (en) * | 2015-09-26 | 2019-05-14 | Cisco Technology, Inc. | In-service upgrade of kernel loadable modules |
US10635511B2 (en) | 2016-12-27 | 2020-04-28 | Huawei Technologies Co., Ltd. | Kernel update method and apparatus, and computer device |
WO2018153052A1 (en) * | 2017-02-22 | 2018-08-30 | 百度在线网络技术(北京)有限公司 | Method and device for loading kernel module |
US11237844B2 (en) | 2017-02-22 | 2022-02-01 | Baidu Online Network Technology (Beijing) Co., Ltd. | Method and apparatus for loading kernel module |
Also Published As
Publication number | Publication date |
---|---|
CN104679532B (en) | 2018-12-11 |
CN104679532A (en) | 2015-06-03 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2015078294A1 (en) | Kernel module loading method and apparatus | |
US9772838B2 (en) | Firmware update discovery and distribution | |
US9235404B2 (en) | Firmware update system | |
CN102779050B (en) | The system and method for the guide performance of acceleration is provided | |
US9110761B2 (en) | Resource data structures for firmware updates | |
US10733017B2 (en) | Task scheduling based on performance control conditions for multiple processing units | |
US9558016B2 (en) | Platform system, method for changing support hardware configuration of universal extensible firmware interface basic input output system and computer program product | |
CN112861057A (en) | Page rendering method, device and equipment based on small program and storage medium | |
US10241718B2 (en) | Electronic device and method of analyzing fragmentation of electronic device | |
US20150261567A1 (en) | Task migration method and apparatus | |
US20170351507A1 (en) | Silent upgrade of software with dependencies | |
US10176072B2 (en) | Device configuration with cached pre-assembled driver state | |
WO2015074526A1 (en) | Method and apparatus for injecting java by tecode into target process | |
CN109684573B (en) | Target picture display method and device, storage medium and electronic equipment | |
US8086778B2 (en) | Filter driver to enumerate smartcard nodes for plug and play | |
CN111158987A (en) | Health check method and device of micro-service architecture | |
CN109144586A (en) | A kind of driving adaptation method, device, computer equipment and storage medium | |
CN105446760B (en) | Method and apparatus for application installation | |
US11169829B2 (en) | Determining candidate patches for a computer software | |
US9141803B2 (en) | Self-healing of operating system components | |
CN110109706B (en) | System and method for component inventory and compliance in a platform | |
US20140297953A1 (en) | Removable Storage Device Identity and Configuration Information | |
US11340882B2 (en) | Systems and methods for enforcing update policies while applying updates from bootable image file | |
WO2017067459A1 (en) | Desktop data loading method and device | |
US10176062B2 (en) | Cloud servers and methods for handling dysfunctional cloud services |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 14865075 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
32PN | Ep: public notification in the ep bulletin as address of the adressee cannot be established |
Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 19.10.2016) |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 14865075 Country of ref document: EP Kind code of ref document: A1 |