Kernel code processing method and electronic device

Abstract

The application discloses a kernel code processing method and an electronic device. The method applied to a first device comprises the following steps: obtaining a first source file according to a first patch code; compiling the first source file to obtain a first compiled file, wherein the first compiled file comprises a first target file and a first header file corresponding to the first target file; and sending at least the first compiled file to a second device, so that the second device generates a kernel software package according to at least the first compiled file.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a kernel code processing method and electronic equipment. BACKGROUND

[0002] In the scenario of building a driver software package for hardware, a kernel software package is obtained by merging non-open source patch code and open source kernel code, which is used for hardware driver.

[0003] In actual application, there is a situation of cooperation of multiple hardware manufacturers, at this time, it is necessary to merge the patch code of each manufacturer.

[0004] However, there may be a situation that one or more parties have non-open source code, if the scheme of merging the plaintext source code of multiple parties is still used, the non-open source code is easy to be cracked, resulting in source code leakage, and the code security is low. SUMMARY

[0005] Therefore, the present application provides a kernel code processing method and electronic equipment to solve the technical problem of low code security in building a kernel software package in the prior art. As follows:

[0006] A kernel code processing method applied to a first device, the method comprising:

[0007] obtaining a first source file according to a first patch code;

[0008] compiling the first source file to obtain a first compiled file, the first compiled file comprising a first object file and a first header file corresponding to the first object file;

[0009] sending at least the first compiled file to a second device, so that the second device generates a kernel software package according to at least the first compiled file.

[0010] The above method is preferably, in the case that the first patch code comprises extension code and / or modification code, the obtaining a first source file according to a first patch code comprises:

[0011] patching kernel base code corresponding to a preset kernel version using the first patch code to obtain a first source file; the extension code is used to add corresponding functions to the kernel; and the modification code is used to modify corresponding functions in the kernel.

[0012] Alternatively, in the case that the first patch code only comprises the extension code, the obtaining a first source file according to a first patch code comprises:

[0013] taking the first patch code as a first source file.

[0014] The method, preferably, further comprises:

[0015] receiving the kernel package sent by the second device;

[0016] installing the kernel package in the first device, so that the first device can obtain a first kernel module file in a kernel environment corresponding to the kernel package;

[0017] sending the first kernel module file to the second device, so that the second device adds the first kernel module file to the kernel package.

[0018] The method, preferably, further comprises:

[0019] obtaining a first kernel configuration file according to at least a configuration file corresponding to the first patch code; the first kernel configuration file is used for compiling the first source file to obtain the first compiled file;

[0020] sending the first kernel configuration file to the second device, so that the second device generates the kernel package according to at least the first kernel configuration file, the first object file and the first header file.

[0021] A kernel code processing method applied to a second device, the method comprising:

[0022] receiving a first object file and a first header file corresponding to the first object file sent by a first device; the first object file and the first header file are files obtained by compiling a first source file by the first device, and the first source file is a source file obtained by the first device according to a first patch code;

[0023] generating a kernel package according to the first object file, the first header file and a second source file; the second source file is a source file obtained according to at least a kernel base code corresponding to a preset kernel version.

[0024] The method, preferably, the first object file is an object file obtained by compiling an extension code in the first patch code;

[0025] The method, preferably, the first object file is an object file obtained by compiling an extension code in the first patch code;

[0026] compiling the second source file to obtain a second compiled file, the second compiled file comprising a second object file and a second header file corresponding to the second object file;

[0027] adding the first target file and the first header file to a path corresponding to a storage path of the first target file in the second target file according to the storage path corresponding to the second target file;

[0028] at least linking the first target file and the second target file to obtain a target image file, the target image file comprising a kernel image file and / or a kernel image compressed file, the kernel image compressed file being obtained by compressing the kernel image file;

[0029] generating a kernel software package according to at least the target image file, the first header file and the second header file;

[0030] Alternatively, the first source file is a source file obtained by patching the kernel base code using the first patch code, and the first target file corresponds to a storage path in a kernel directory corresponding to the kernel base code.

[0031] The method further comprises:

[0032] adding the first target file and the first header file to a path corresponding to a storage path of the first target file in the second target file according to the storage path corresponding to the second target file;

[0033] compiling the third source file to obtain a second compiled file, the second compiled file comprising the second target file corresponding to the second source file, the second header file corresponding to the second target file, the first target file and the first header file;

[0034] at least linking the first target file and the second target file to obtain a target image file, the target image file comprising a kernel image file and / or a kernel image compressed file, the kernel image compressed file being obtained by compressing the kernel image file;

[0035] generating a kernel software package according to at least the target image file, the first header file and the second header file.

[0036] Preferably, the second source file is a source file obtained by patching the kernel base code using a second patch code; or the second source file only comprises the kernel base code.

[0037] The method further comprises:

[0038] receive a first kernel configuration file sent by the first device, the first kernel configuration file being a kernel configuration file obtained by the first device according to at least a configuration file corresponding to the first patch code;

[0039] obtain a target kernel configuration file according to at least the first kernel configuration file and a second kernel configuration file; the target kernel configuration file is used to generate the kernel software package according to the first target file, the first header file and a second source file;

[0040] The second kernel configuration file is a kernel configuration file corresponding to the kernel base code, or the second kernel configuration file is a kernel configuration file obtained by modifying a kernel configuration file corresponding to the kernel base code according to a configuration file corresponding to a second patch code.

[0041] An electronic device, which comprises a first device and comprises:

[0042] a memory for storing a computer program and data generated by running the computer program;

[0043] a processor for executing the computer program to achieve: obtaining a first source file according to a first patch code; compiling the first source file to obtain a first compiled file, the first compiled file containing a first target file and a first header file corresponding to the first target file; and sending at least the first compiled file to a second device to enable the second device to generate a kernel software package according to at least the first compiled file.

[0044] An electronic device, which comprises a second device and comprises:

[0045] a memory for storing a computer program and data generated by running the computer program;

[0046] a processor for executing the computer program to achieve: receiving a first target file and a first header file corresponding to the first target file sent by a first device; the first target file and the first header file being files obtained by compiling a first source file by the first device, the first source file being a source file obtained by the first device according to a first patch code; and generating a kernel software package according to the first target file, the first header file and a second source file; the second source file being a source file obtained according to at least a kernel base code corresponding to a preset kernel version.

[0047] It can be seen from the technical solution that, in the kernel code processing method and the electronic device, after the first source file is obtained according to the first patch code on the first device, the first source file can be compiled first to obtain the first compiled file containing the first target file and the first header file, and then the first compiled file is sent to the second device, so that the kernel software package is generated on the second device according to at least the first compiled file. It can be seen that the binary file of the first device received on the second device in the present application is compiled, and the non-open source patch code of the first device cannot be obtained by the second device, so that the present application can ensure the security of the non-open source code while realizing the construction of the kernel software package. BRIEF DESCRIPTION OF DRAWINGS

[0048] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0049] Figure 1 A flowchart of a kernel code processing method provided by the first embodiment of the present application;

[0050] Figure 2 An example diagram between the first device and the second device in the embodiment of the present application;

[0051] Figure 3 Another flowchart of a kernel code processing method provided by the first embodiment of the present application;

[0052] Figure 4 A partial flowchart of a kernel code processing method provided by the first embodiment of the present application;

[0053] Figure 5 A flowchart of a kernel code processing method provided by the second embodiment of the present application;

[0054] Figure 6 , Figure 7 and Figure 8 are partial flowcharts of a kernel code processing method provided by the second embodiment of the present application, respectively;

[0055] Figure 9 A structural schematic diagram of a kernel code processing device provided by the third embodiment of the present application;

[0056] Figure 10 and Figure 11 are another structural schematic diagram of a kernel code processing device provided by the third embodiment of the present application, respectively;

[0057] Figure 12 FIG. 1 shows a structural schematic diagram of a kernel code processing device according to an embodiment of the present application;

[0058] Figure 13 FIG. 2 shows another structural schematic diagram of a kernel code processing device according to an embodiment of the present application;

[0059] Figure 14 FIG. 3 shows a structural schematic diagram of an electronic device according to an embodiment of the present application;

[0060] Figure 15 FIG. 4 shows a structural schematic diagram of an electronic device according to an embodiment of the present application;

[0061] Figure 16 FIG. 5 shows a flowchart of a software package construction process according to an embodiment of the present application;

[0062] Figure 17 、 Figure 18 、 Figure 19 、 Figure 20 、 Figure 21 and Figure 22 are respectively storage example diagrams in a software package construction process according to an embodiment of the present application. DETAILED DESCRIPTION

[0063] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0064] Referring to FIG. 5, it is a flowchart of an implementation of a kernel code processing method according to an embodiment of the present application. The method can be applied to an electronic device capable of code compilation, such as a first device shown in FIG. 6, for example, a manufacturer server providing non-open source code. The first device and a second device have a connection capable of data transmission, the second device is a device capable of code merging to construct a kernel software package, such as a manufacturer server constructing a kernel software package, and the first device and the second device have the same processor architecture. The technical solution in the embodiment is mainly used to improve the security of non-open source code. Figure 1 Figure 2 Specifically, the method in the embodiment can include the following steps:

[0065] Specifically, the method in the embodiment can include the following steps:

[0066] Step 101: obtaining a first source file according to a first patch code.

[0067] ​The first source file is a.c file, which can be understood as a file formed by source code. The first patch code refers to code that needs to be patched to the kernel base code.

[0068] Specifically, the first patch code can include extension code and / or modification code. The extension code is used to add corresponding functions to the kernel, and the modification code is used to modify the existing corresponding functions in the kernel, such as deleting a segment of code or adjusting a segment of code.

[0069] Step 102: Compiling the first source file to obtain a first compiled file.

[0070] The first compiled file includes at least one first target file and a first header file corresponding to the first target file. The first target file refers to an object file obtained by compiling the first source file, i.e., a binary code file with a.o file suffix. The first header file is a file included in the first source file that matches the first target file, with a.h file suffix.

[0071] Specifically, in this embodiment, the first source file can be compiled according to a preset kernel compilation rule to obtain the first compiled file. The kernel compilation rule here can be specified by the device user of the first device according to requirements. In addition, the device user of the first device can also write a corresponding Makefile file for the first source file according to requirements. The Makefile file can also be referred to as a Kbuilt-makefile. The first source file has a top-level Makefile file and a Makefile file under the path of each layer of source files. The Makefile file under each path is used to compile the source files under the corresponding path into target files, library files, and module files. The top-level Makefile file is used to specify the paths of these target files, so as to link these target files to form a vmlinux file. The Kbuilt-makefile specifies the function modules compiled into the kernel, the function modules compiled into module files, and the source file content through a specific syntax, so as to implement the compilation of the kernel or the module. In addition, the device user of the first device can also set the configuration items in the configuration file corresponding to the first source file through the configuration graphical interface built by Kconfig according to requirements.

[0072] It should be noted that the first compiled file can include one first target file or multiple first target files. These target files are various independent files. In addition, the first target file and its corresponding first header file are stored in the same path.

[0073] Step 103: At least sending the first compiled file to the second device, so that the second device generates a kernel software package according to at least the first compiled file.

[0074] The second device is a device for building the kernel software package, such as a vendor server for building the kernel software package. In this embodiment, the first compiled file can be sent to the second device through a data connection between the first device and the second device, such as a dedicated network or the Internet. The second device receiving the first compiled file can generate the kernel software package based on the first compiled file. Since the file sent by the first device to the second device is a compiled target file, the non-open-source patch code of the first device cannot be read on the second device.

[0075] In addition, the first device can also send the configuration file, Kconfig, Makefile and other files participating in the compilation of the first source file to the second device, so that the second device can generate the kernel software package according to these files.

[0076] As can be seen from the above solution, in the kernel code processing method provided by the first embodiment of the present application, after the first source file is obtained from the first patch code on the first device, the first source file can be compiled first to obtain the first compiled file containing the first target file and the first header file, and then the first compiled file is sent to the second device, so that the kernel software package is generated on the second device based on at least the first compiled file. It can be seen that the binary file compiled by the first device received on the second device in this embodiment cannot obtain the non-open-source patch code of the first device for the second device, so that the present application can ensure the security of the non-open-source code while implementing the kernel software package construction.

[0077] In an implementation, in the case that the first patch code contains any one or any multiple of the extension code and the modification code, the first patch code can be used to patch the kernel base code corresponding to the preset kernel version in step 101 to obtain the first source file. The kernel base code corresponding to the kernel version corresponds to a kernel directory, and the kernel directory can represent the storage path of the code. That is, the first source file contains not only the kernel base code corresponding to the kernel version but also the first patch code. For example, in the embodiment, the extension code in the first patch code is added to the code path of the related function in the kernel base code according to the kernel directory; and / or, the modification code in the first patch code is added to the same code path of the corresponding function in the kernel base code according to the kernel directory. In addition, in the embodiment, the code compilation parameter corresponding to the extension code is added to the code path where the extension code is located, for example, the newly added target obj rule, i.e., the code compilation parameter, is added to each layer of Makefile in the extension code in the kernel base code, and in addition, the corresponding Kconfig is added to facilitate the construction of the graphical interface so that the user can set the configuration items corresponding to each function module in the configuration file corresponding to the extension code. In step 102, when the first source file is compiled, the compilation can be performed according to the target obj rule, so that the patched kernel base code is compiled into one or more independent target files, and based on this, the path where the extension code in the first patch code is located is retained in the kernel directory.

[0078] In another implementation, in the case that the first patch code contains only the extension code, the first patch code can be used as the first source file in step 101, that is, the first source file contains only the first patch code.

[0079] It should be noted that the kernel version is a kernel version agreed in advance between the first device and a second device for building the kernel software package, such as a manufacturer server for building the kernel software package. Therefore, the first device and the second device can obtain the same kernel base code according to the kernel version. For example, the manufacturer server providing non-open source code and the manufacturer server for building the kernel software package agree in advance to build the kernel software package for a certain specific version of the kernel base code, and the specific version is the preset kernel version in the embodiment. Based on this, in the case that the first patch code contains the extension code, the first patch code can be compiled in the embodiment, and the kernel base code does not need to be compiled, thereby reducing the data transmission amount between the first device and the second device to speed up the construction efficiency of the kernel software package.

[0080] In an implementation, the method in the embodiment can further include the following steps on the first device, as shown in step 101: Figure 3

[0081] ​Step 104: receiving the kernel software package sent by the second device.

[0082] The second device can transmit the kernel software package to the first device through the data connection between the first device and the second device, so that the first device can obtain the kernel software package for implementing the corresponding kernel function.

[0083] Step 105: installing the kernel software package in the first device, so that the first device can obtain the first kernel module file in the kernel environment corresponding to the kernel software package.

[0084] The first kernel module file is an independent kernel module file with a file suffix of.ko.

[0085] It should be noted that the kernel software package at least contains a kernel image file and / or a kernel image compression file. Based on this, the kernel image file in the kernel software package is executed in the first device, or the kernel image file obtained by decompressing the kernel image compression file is executed in the first device, so that the first device obtains the kernel module file (i.e., the ko file) of the first device in the kernel environment corresponding to the kernel image file and the header file (such as the first header file).

[0086] Step 106: sending the first kernel module file to the second device, so that the second device adds the first kernel module file to the kernel software package.

[0087] In addition, when the first kernel module file is obtained, the first device can record the storage directory of the first kernel module file, and then when the first kernel module file is sent to the second device, the storage directory of the first kernel module file can be sent to the second device together, so that the second device stores the first kernel module file according to the storage directory of the first kernel module file.

[0088] It can be seen that in the embodiment, the kernel environment constructed by using the kernel software package generated by the second device is used to generate the kernel module file, and then the second device adds the kernel module file of the first device to the kernel software package, so that the addition of the kernel module file is realized on the premise that the source code of the kernel module file is not leaked.

[0089] In an implementation manner, the embodiment can further include the following steps before step 102, as shown in Figure 4

[0090] Step 107: obtaining the first kernel configuration file according to at least the configuration file corresponding to the first patch code.

[0091] The first kernel configuration file is used for compiling the first source file to obtain the first compiled file.

[0092] ​In one implementation, where the first patch code includes extension code and / or modification code, this embodiment uses the first patch code to patch the kernel base code corresponding to a preset kernel version to obtain a first source file. Based on this, in step 107, the configuration file corresponding to the first patch code is used to modify the kernel configuration file corresponding to the kernel base code. For example, configuration items corresponding to the extension code are added to the kernel configuration file corresponding to the kernel base code, and / or configuration items corresponding to the modification code are adjusted in the kernel configuration file corresponding to the kernel base code, etc., thereby obtaining the first kernel configuration file. The first kernel configuration file contains configuration items for the corresponding functional modules in the kernel base code and the first patch code. Based on this, when compiling the first source file in step 102, the code corresponding to the corresponding functional modules can be compiled into object files according to the configuration items in the first kernel configuration file.

[0093] In another implementation, where the first patch code only contains extended code, this embodiment uses the first patch code as the first source file. Based on this, in step 107, the configuration file corresponding to the first patch code is used as the first kernel configuration file. The first kernel configuration file contains configuration items for the corresponding functional modules in the first patch code. Based on this, when compiling the first source file in step 102, the code corresponding to the corresponding functional modules in the first patch code can be compiled into the target file according to the configuration items in the configuration file corresponding to the first patch code.

[0094] Step 108: Send the first kernel configuration file to the second device so that the second device can generate a kernel package based on at least the first kernel configuration file, the first object file, and the first header file.

[0095] Specifically, in order to reduce the amount of data transmission, in this embodiment, the first compiled file and the first kernel configuration file can be compressed first, and then transmitted to the second device.

[0096] Furthermore, in this embodiment, in addition to sending the first compiled file and the first kernel configuration file to the second device, the Kconfig file and Makefile file corresponding to the first source file are also sent to the second device, so that the second device can generate a kernel package based on at least the first compiled file, the first kernel configuration file, the Kconfig file and the Makefile file.

[0097] It should be noted that the configuration item in the configuration file can at least represent whether the corresponding function module is started, whether it is compiled into the kernel, and whether it is compiled into the kernel module file. Therefore, the configuration items corresponding to the function modules in the kernel configuration file are different, and the compiled files are different. The configuration items extended by the first device are determined by the Kconfig file added by the device user of the first device.

[0098] Based on the above implementation, when the first source file is compiled in step 102, the first target file and the first header file in the first compiled file, as well as the first kernel configuration file, the Kconfig file and the Makefile file, are stored according to the kernel directory, and the first target file and the first header file are stored in the path where the corresponding code file (i.e..c file) is located according to the kernel directory. The first target file and the first header file are stored in the same path.

[0099] In addition, in the case where the first source file is obtained by patching the kernel base code corresponding to the kernel version using the first patch code, the first source file contains non-open source code (first patch code) and open source code (kernel base code). When the first source file is compiled in step 102, all the codes in the first source file can be compiled, so that the first compiled file obtained thereby contains at least the first target file and the corresponding first header file, but does not contain the source code file, i.e..c file; or, only the non-open source code in the first source file and the open source code having a dependency relationship with the non-open source code are compiled in step 102, so that the first compiled file obtained thereby contains the first target file and the corresponding first header file, and may also contain the source code file, i.e..c file.

[0100] It should be noted that when the kernel base code needs to be patched on the first device, steps 101-103 can be re-executed, that is, the target file and the header file recompiled are sent to the second device, and the kernel software package is reconstructed by the second device.

[0101] Reference Figure 5 An implementation flowchart of a kernel code processing method provided by Embodiment Two of the present application can be applied to an electronic device capable of constructing a kernel software package, such as a second device as shown in Figure 2 The first device and the second device have the same processor architecture. The technical solution in the embodiment is mainly used to improve the security of non-open source code.

[0102] Specifically, the method in the embodiment can include the following steps:

[0103] Step 501: receiving the first target file and the first header file corresponding to the first target file sent by the first device.

[0104] The first target file and the first header file are files obtained by compiling the first source file by the first device, and the first source file is a source file obtained by the first device according to the first patch code.

[0105] In addition, the second device also receives the first kernel configuration file, the Kconfig file and the Makefile file corresponding to the first source file sent by the first device.

[0106] Step 502: generating a kernel software package according to the first target file, the first header file and the second source file, the second source file being a source file obtained at least according to kernel basic code corresponding to a preset kernel version.

[0107] Specifically, the first target file and the first header file received by the second device may be compressed by the first device, at this time, the second device first decompresses the first target file and the first header file, and then uses the decompressed first target file, the first header file and the second source file to construct the kernel software package.

[0108] The second device can obtain the second source file at least according to the kernel basic code before step 502, and it should be noted that the second device can obtain the second source file before or after step 501 or synchronously with step 501, and the technical solutions formed by different execution sequences are all within the protection scope of the present application.

[0109] Specifically, when the second device obtains the second source file, if there is a second patch code preset on the second device, i.e. the kernel basic code needs to be patched, the second device can use the second patch code to patch the kernel basic code to obtain the second source file, at this time, the second source file contains the kernel basic code patched by the second patch code; and if there is no second patch code on the second device, i.e. the second device does not need to patch the kernel basic code, the second device can use the kernel basic code as the second source file, at this time, the second source file only contains the kernel basic code.

[0110] The second patch code can contain an expansion code and / or a modification code.

[0111] It should be noted that the kernel basic code in the second source file is kernel basic code corresponding to a preset kernel version, and the kernel version is a version agreed by the first device and the second device in advance.

[0112] From the above scheme, it can be known that the kernel code processing method provided in Embodiment Two of the present application uses the compiled object files and header files sent by the first device when constructing the kernel software package on the second device, which is different from the source files before being compiled and is easy to be known. The source files of the first device cannot be easily known by the second device, and thus the present application can ensure the security of the non-open source code while implementing the kernel software package construction.

[0113] In an implementation manner, in the case that the first patch code only contains the extension code, the corresponding first object file can be an object file obtained by compiling the extension code in the first patch code by the first device. Based on this, in step 502, when generating the kernel software package according to the first object file, the first header file and the second source file, the following manner can be used for implementation, as shown in the following formula (1): Figure 6

[0114] Step 601: Compiling the second source file to obtain a second compiled file.

[0115] The second compiled file contains a second object file and a second header file corresponding to the second object file.

[0116] Specifically, in the present embodiment, the second source file can be compiled according to a preset kernel compilation rule, so that the code in the second source file is compiled into independent object files and corresponding header files. The preset kernel compilation rule can be specified by the device user of the second device according to requirements. In addition, the device user of the second device can also write a corresponding Makefile file, also known as Kbuilt-makefile, for the second source file according to requirements. The second source file has a top Makefile file and a Makefile file in the path of each layer of source files. The Makefile file in each layer of paths is used to compile the source files in the corresponding path into object files, library files and module files, and the top Makefile file is used to specify the paths of the object files, so as to link the object files to form a vmlinux file. The Kbuilt-makefile specifies the function modules compiled into the kernel, the function modules compiled into the module files and the source file contents through a specific syntax, so as to implement the compilation of the kernel or the module. In addition, the device user of the second device can also set the configuration items in the configuration file corresponding to the second source file through the configuration graphical interface constructed by Kconfig according to requirements.

[0117] ​It should be noted that the second target file and the second header file and the Kconfig file and the Makefile file corresponding to the second source file are stored in the path where the corresponding code is located in the kernel directory of the kernel basic code, and the second target file and the second header file are stored in the same path.

[0118] Step 602: According to the storage path corresponding to the second target file, the first target file and the first header file are added to the path where the target file associated with the code function of the first target file is located in the second target file.

[0119] Wherein, the storage path corresponding to the second target file is the storage path where each target file is located presented by the kernel directory corresponding to the kernel basic code, based on this, in the embodiment, first, the kernel directory is used to find the second target file associated with the code function of the first target file, then the first target file is added to the path where the found second target file is located, and the first header file is added to the path where the first target file is located, thereby realizing the merging of the first target file and the second target file.

[0120] In addition, the Kconfig file and the Makefile file corresponding to the first target file and the first header file are also added to the corresponding path, and the path where the second target file and the second header file are located also has the corresponding Kconfig file and Makefile file.

[0121] Step 603: At least link processing is performed on the first target file and the second target file to obtain a target image file.

[0122] In an implementation manner, in the embodiment, the first target file and the second target file can be linked into a kernel image file vmlinux, for example, by Arm-linux-ld -o vmlinux -T arch / arm / kernel / vmlinux.lds arch / arm / kernel / head.o * / built-in.o, using the top-level Makefile file in the kernel directory to link the.o file (target file) into vmlinux (kernel image file), at this time, the kernel image file is used as the target image file.

[0123] In another implementation, the first target file and the second target file can be linked into a kernel image file vmlinux in the embodiment. Then, in order to reduce the space occupation, the kernel image file is compressed, and the kernel image compression file obtained by compression can be named vmlinuz.zimage. Based on this, the target image file is generated according to the kernel image file and the kernel image compression file, and the target image file contains the kernel image file and / or the kernel image compression file.

[0124] Step 604: generating the kernel software package according to at least the target image file, the first header file and the second header file.

[0125] In an implementation, in the case that the target image file contains only the kernel image file, the kernel software package containing the kernel image file, the first header file and the second header file can be generated according to the kernel image file, the first header file and the second header file in the embodiment.

[0126] In another implementation, in the case that the target image file contains only the kernel image compression file, the kernel software package containing the kernel image compression file, the first header file and the second header file can be generated according to the kernel image compression file, the first header file and the second header file in the embodiment.

[0127] In another implementation, in the case that the target image file contains the kernel image file and the kernel image compression file, the kernel software package containing the kernel image file, the kernel image compression file, the first header file and the second header file can be generated according to the kernel image file, the kernel image compression file, the first header file and the second header file in the embodiment, or the kernel software package containing the kernel image file, the first header file and the second header file can be generated according to the kernel image file, the first header file and the second header file in the embodiment.

[0128] In order to reduce the space occupation of the software package, the kernel software package containing the kernel image compression file, the first header file and the second header file can be generated according to the kernel image compression file, the first header file and the second header file in the embodiment.

[0129] In another implementation, the second device can also first add the first target file and the first header file, the Makefile file and the Kconfig file to the path corresponding to the storage path of the second target file according to the kernel compilation rule, and then compile the second source file added with the first target file. The kernel compilation rule on the second device can identify each compiled file in the second source file and compile the different types of compiled files according to the respective corresponding compilation parameters to obtain independent target files and corresponding header files. For example, according to the kernel compilation rule, in the case of identifying the target file, no processing is performed, and in the case of identifying the source file, the compilation processing is performed, thereby obtaining the compiled files composed of the second target file, the second header file, the first target file and the first header file, and then at least the target file is processed, such as linking, to obtain the corresponding target image file, thereby constructing the kernel software package.

[0130] In another implementation, in the case where the first patch code contains the expansion code and / or the modification code, the corresponding first target file can be a target file obtained by compiling the kernel base code patched by the first patch code for the first device, based on which, in step 502, when generating the kernel software package according to the first target file, the first header file and the second source file, the following implementation can be used, as shown in the following: Figure 7

[0131] Step 701: Add the first target file and the first header file to the path corresponding to the storage path of the first target file in the second source file according to the kernel directory corresponding to the kernel base code, to obtain a third source file.

[0132] Step 702: Compile the third source file to obtain a second compiled file.

[0133] The second compiled file contains the second target file corresponding to the second source file, the second header file corresponding to the second target file, the first target file and the first header file.

[0134] Specifically, in this embodiment, each compiled file in the third source file can be identified according to the kernel compilation rule, and different types of compiled files can be compiled according to the respective corresponding compilation parameters to obtain independent target files and corresponding header files. For example, according to the kernel compilation rule, in the case of identifying the target file, no processing is performed, and in the case of identifying the source file, the compilation processing is performed, thereby obtaining the second compiled file composed of the second target file, the second header file, the first target file and the first header file.

[0135] ​Step 703: performing at least linking processing on the first target file and the second target file to obtain a target image file.

[0136] In an implementation manner, the first target file and the second target file can be linked into a kernel image file vmlinux in the embodiment, and at this time, the kernel image file is taken as the target image file.

[0137] In another implementation manner, the first target file and the second target file can be linked into a kernel image file vmlinux in the embodiment, and then, in order to reduce space occupation, compression processing is performed on the kernel image file, the obtained kernel image compression file can be named vmlinuz.zimage based on the compression processing on the kernel image file, and based on the kernel image file and the kernel image compression file, the target image file is generated, and the target image file contains the kernel image file and / or the kernel image compression file.

[0138] Step 704: generating a kernel software package according to the target image file, the first header file and the second header file.

[0139] Specifically, the kernel software package is made according to the kernel image file and / or the kernel image compression file in the target image file, the first header file and the second header file according to a software package generation rule to obtain the kernel software package containing these files. The kernel software package at least contains the kernel image compression file, the first header file and the second header file.

[0140] In another implementation manner, the second device can also perform compiling processing on the second source file according to a kernel compiling rule to obtain the second target file and the second header file, then add the first target file and the first header file to the second target file in a path where files associated with the first target file in terms of code function are located, thereby obtaining the compiling file composed of the second target file, the second header file, the first target file and the first header file, and then performing at least linking processing on the target files to obtain the corresponding target image file, thereby constructing the kernel software package.

[0141] In an implementation manner, the embodiment can further include the following steps before step 502, as shown in Figure 8

[0142] Step 503: receiving the first kernel configuration file sent by the first device.

[0143] The first kernel configuration file is obtained by the first device at least according to the configuration file corresponding to the first patch code.

[0144] ​Step 504: obtaining a target kernel configuration file according to the first kernel configuration file and the second kernel configuration file.

[0145] The target kernel configuration file is used to generate the kernel software package according to the first target file, the first header file, the Makefile file, the Kconfig file and the second source file. That is, the configuration items in the target kernel configuration file are used to process the first target file, the first header file, the Makefile file, the Kconfig file and the second source file in step 502 to build the kernel software package.

[0146] It should be noted that the second kernel configuration file is a kernel configuration file corresponding to the kernel basic code, or the second kernel configuration file is obtained by modifying the kernel configuration file corresponding to the kernel basic code according to the configuration file corresponding to the second patch code.

[0147] In an implementation manner, in a case where the second source file is a source file obtained by patching the kernel basic code corresponding to a preset kernel version using the second patch code, the kernel configuration file corresponding to the kernel basic code is modified using the configuration file corresponding to the second patch code in the embodiment, for example, a configuration item corresponding to the extended code in the second patch code is added in the kernel configuration file corresponding to the kernel basic code, and / or a configuration item corresponding to the modified code in the second patch code is adjusted in the kernel configuration file corresponding to the kernel basic code, and the like, thereby obtaining the second kernel configuration file. The second kernel configuration file contains configuration items of corresponding functional modules in the kernel basic code and the second patch code and the like, based on which, in step 502, the code corresponding to the corresponding functional modules in the second source file can be compiled into a target file according to the configuration items in the second kernel configuration file, and then the kernel software package is built according to the obtained second target file and the first target file and the respective corresponding header files.

[0148] In another implementation manner, in a case where the second source file is the kernel basic code, the kernel configuration file corresponding to the kernel basic code is used as the second kernel configuration file in the embodiment, and the second kernel configuration file contains configuration items of corresponding functional modules in the kernel basic code and the like, based on which, in step 502, the code corresponding to the corresponding functional modules in the kernel basic code can be compiled into a target file according to the configuration items in the second configuration file, and then the kernel software package is built according to the obtained second target file and the first target file and the respective corresponding header files.

[0149] Further, the kernel package can be sent to the first device on the second device, so that the first device can build a corresponding kernel environment by executing the kernel image file (the kernel image compressed file is decompressed) in the kernel package and obtain the first kernel module file, i.e., the ko file, in the kernel environment. Then, the first device sends the first kernel module file to the second device. Based on this, the first kernel module file can be added to the kernel package on the second device. At this time, the kernel package at least contains the kernel image compressed file, the first header file, the second header file, and the first kernel module file. Further, the first device also sends the storage directory of the first kernel module file to the second device, so that the second device stores the first kernel module file according to the storage directory of the first kernel module file.

[0150] In addition, the kernel environment can also be built on the second device by executing the kernel image file in the kernel package, and the second kernel module file on the second device can be obtained and added to the kernel package. At this time, the kernel package at least contains the kernel image compressed file, the first header file, the second header file, the first kernel module file, and the second kernel module file.

[0151] It should be noted that when the kernel base code needs to be patched on the second device, since the code provided on the first device does not change, only step 502 needs to be re-executed to obtain the updated kernel package.

[0152] Reference Figure 9 A structure diagram of a kernel code processing device according to Embodiment Three of the present application is provided. The device can be configured on an electronic device capable of code compilation, such as a first device as shown in FIG. 8. The technical solution in the embodiment mainly serves to improve the security of non-open source code. Figure 2

[0153] Specifically, the device in the embodiment can include the following units:

[0154] The source file obtaining unit 901 is configured to obtain a first source file according to the first patch code.

[0155] The source file compiling unit 902 is configured to compile the first source file to obtain a first compiled file, wherein the first compiled file contains a first target file and a first header file corresponding to the first target file.

[0156] The file sending unit 903 is configured to send at least the first compiled file to a second device, so that the second device generates a kernel package according to at least the first compiled file.

[0157] ​As can be seen from the above scheme, the kernel code processing apparatus provided in Embodiment Three can first compile the first source file to obtain the first compilation file containing the first object file and the first header file after obtaining the first source file according to the first patch code on the first device, and then send the first compilation file to the second device, so as to generate the kernel software package on the second device according to at least the first compilation file. It can be seen that the binary file of the first device after compilation received on the second device in this embodiment cannot obtain the non-open source patch code of the first device for the second device, so that the safety of the non-open source code can be ensured while the kernel software package is constructed.

[0158] In an implementation manner, in a case where the first patch code contains the extension code and / or the modification code, the source file obtaining unit 901 is specifically configured to: patch kernel base code corresponding to a preset kernel version by using the first patch code to obtain the first source file; the extension code is used to add corresponding functions to the kernel; and the modification code is used to modify corresponding functions in the kernel.

[0159] Alternatively, in a case where the first patch code contains only the extension code, the source file obtaining unit 901 is specifically configured to: take the first patch code as the first source file.

[0160] In an implementation manner, the apparatus in this embodiment can further contain units as shown in the following table: Figure 10

[0161] The module adding unit 904 is configured to: receive the kernel software package sent by the second device; install the kernel software package in the first device, so that the first device can obtain a first kernel module file in a kernel environment corresponding to the kernel software package; and send the first kernel module file to the second device, so that the second device adds the first kernel module file to the kernel software package.

[0162] In an implementation manner, the apparatus in this embodiment can further contain units as shown in the following table: Figure 11

[0163] The configuration file processing unit 905 is configured to: obtain a first kernel configuration file according to at least a configuration file corresponding to the first patch code; the first kernel configuration file is used to compile the first source file to obtain the first compilation file; and send the first kernel configuration file to the second device, so that the second device generates the kernel software package according to at least the first kernel configuration file, the first object file and the first header file.

[0164] ​​It should be noted that the specific implementation of each unit in this embodiment can refer to the corresponding content in the foregoing, which will not be described in detail here.

[0165] Reference Figure 12 A structural schematic diagram of a kernel code processing apparatus provided in Embodiment Four of the present application is provided, which is configured on an electronic device capable of constructing a kernel software package, such as a second device as shown in the figure. The technical solution in this embodiment is mainly used to improve the security of non-open source code. Figure 2

[0166] Specifically, the apparatus in this embodiment can include the following units:

[0167] The file receiving unit 1201 is configured to receive a first target file and a first header file corresponding to the first target file sent by a first device; the first target file and the first header file are files obtained by compiling a first source file by the first device, and the first source file is a source file obtained by the first device according to a first patch code;

[0168] The software package construction unit 1202 is configured to generate a kernel software package according to the first target file, the first header file, and a second source file; the second source file is a source file obtained at least according to a kernel base code corresponding to a preset kernel version.

[0169] From the above solution, it can be known that in the kernel code processing apparatus provided in Embodiment Four of the present application, when constructing a kernel software package on a second device, at least the compiled target file and the header file sent by a first device are used, which is different from the case that the source file before being compiled is easily known. The second device cannot easily know the source file of the first device, and thus the present application can ensure the security of non-open source code while realizing the construction of the kernel software package.

[0170] In an implementation manner, the first target file is a target file obtained by compiling an expansion code in the first patch code; and the software package construction unit 1202 is specifically configured to: compile a second source file to obtain a second compiled file, the second compiled file including a second target file and a second header file corresponding to the second target file; add the first target file and the first header file to a path where a target file associated with the first target file in terms of code function is located according to a storage path corresponding to the second target file; at least perform linking processing on the first target file and the second target file to obtain a target image file, the target image file including a kernel image file and / or a kernel image compressed file, the kernel image compressed file being obtained by compressing the kernel image file; and generate a kernel software package according to at least the target image file, the first header file, and the second header file.​

[0171] In an implementation manner, the first source file is a source file obtained by patching the kernel base code using the first patch code, and the first target file corresponds to a storage path in a kernel directory corresponding to the kernel base code; the software package construction unit 1202 is specifically configured to: add the first target file and the first header file to a path corresponding to the first target file in the second source file to obtain a third source file according to the kernel directory corresponding to the kernel base code; compile the third source file to obtain a second compilation file, the second compilation file including a second target file corresponding to the second source file, a second header file corresponding to the second target file, the first target file and the first header file; and at least link the first target file and the second target file to obtain a target image file, the target image file including a kernel image file and / or a kernel image compressed file, the kernel image compressed file being obtained by compressing the kernel image file; and generate a kernel software package according to at least the target image file, the first header file and the second header file.

[0172] In an implementation manner, the second source file is a source file obtained by patching the kernel base code using a second patch code; or the second source file only includes the kernel base code.

[0173] In an implementation manner, the apparatus in the embodiment can further include the following units, as shown in Figure 13

[0174] The configuration file processing unit 1203 is configured to receive a first kernel configuration file sent by the first device, the first kernel configuration file being a kernel configuration file obtained by the first device according to at least a configuration file corresponding to the first patch code; obtain a target kernel configuration file according to at least the first kernel configuration file and a second kernel configuration file; the target kernel configuration file is used to generate the kernel software package according to the first target file, the first header file and the second source file; and the second kernel configuration file is a kernel configuration file corresponding to the kernel base code, or the second kernel configuration file is a kernel configuration file obtained by modifying a kernel configuration file corresponding to the kernel base code according to a configuration file corresponding to a second patch code.

[0175] It should be noted that the specific implementation of each unit in the embodiment can refer to the corresponding content in the foregoing, which will not be described in detail here.

[0176] Reference Figure 14 A structural schematic diagram of an electronic device provided in Embodiment Five of the present application is shown in​Figure 2 The first device shown, such as a vendor server that provides non-open source code. The electronic device as the first device can include the following structure:

[0177] The memory 1401 is configured to store a computer program and data generated by running of the computer program.

[0178] The processor 1402 is configured to execute the computer program to implement the following: obtaining a first source file according to a first patch code; compiling the first source file to obtain a first compiled file containing a first target file and a first header file corresponding to the first target file; and sending at least the first compiled file to a second device to enable the second device to generate a kernel software package according to at least the first compiled file.

[0179] According to the above scheme, the electronic device provided by the embodiment five can first compile the first source file to obtain the first compiled file containing the first target file and the first header file after obtaining the first source file according to the first patch code on the first device, and then send the first compiled file to the second device, so that the second device generates the kernel software package according to at least the first compiled file. It can be seen that the binary file of the first device compiled and received by the second device in the embodiment cannot obtain the non-open source patch code of the first device for the second device, so that the application can ensure the security of the non-open source code while implementing the construction of the kernel software package.

[0180] It should be noted that the specific implementation of the processor in the embodiment can refer to the corresponding content in the foregoing, which will not be described in detail here.

[0181] Reference Figure 15 The structure diagram of the electronic device provided by the embodiment six of the application is shown in FIG. 6. Figure 2 The second device shown, such as a vendor server that constructs a kernel software package. The electronic device as the second device can include the following structure:

[0182] The memory 1501 is configured to store a computer program and data generated by running of the computer program.

[0183] The processor 1502 is configured to execute the computer program to implement the following steps: receiving a first target file and a first header file corresponding to the first target file sent by a first device; the first target file and the first header file are files obtained by compiling a first source file by the first device, and the first source file is a source file obtained by the first device according to a first patch code; generating a kernel software package according to the first target file, the first header file and a second source file; the second source file is a source file obtained according to a kernel base code corresponding to a preset kernel version.

[0184] According to the above scheme, the electronic device provided by the embodiment six of the present application uses at least the compiled target file and the header file sent by the first device when constructing the kernel software package on the second device, which is different from the source file before being compiled and is easy to be obtained. The second device cannot easily obtain the source file of the first device, and thus the present application can ensure the security of the non-open source code while implementing the construction of the kernel software package.

[0185] Taking the construction of a kernel software package (hereinafter referred to as a kernel source code package or a kernel package) of a certain hardware as an example, the drive part of a hardware manufacturer cannot be separated from the kernel source code patch. The kernel source code package combines the non-open source code and the open source kernel code to generate the kernel package. In the process of combining the kernel codes of two or more manufacturers, the non-open source code exists in the process of combining the kernel codes of two or more manufacturers. Only the plaintext source code of multiple parties can be combined, but this is easy to be obtained and cracked by a competitor manufacturer, and there is a problem of source code leakage, and the security cannot be guaranteed.

[0186] Therefore, in view of the situation that the kernel source code of multiple parties is exposed in plaintext, according to the technical scheme of the present application in the foregoing, the embodiment proposes a kernel package production method for the risk of kernel code leakage of multiple parties, improves the security of kernel source code combination, and realizes the possibility of cooperation of multiple hardware manufacturers. The plaintext code is not leaked, and the risk of obtaining the source code of multiple parties and leaking the secret is eliminated.

[0187] In a specific implementation, the embodiment is applicable to the construction of a kernel package compiled by multiple Linux operating systems. Taking a processor architecture environment in which a Debian operating system runs in an AArch64 state as an example, a server of a manufacturer providing non-open source code (referred to as a non-open source manufacturer) and a server of a manufacturer implementing code combination (referred to as a combination manufacturer) are taken as examples.

[0188] 1. As shown in the flowchart in the Figure 16 The first step of the embodiment includes the following steps:

[0189] (1) Non-open source manufacturers prepare kernel patch and kernel driver.o.h file:

[0190] First, non-open source manufacturers and mergers manufacturers agree on the same kernel version.

[0191] Then, the non-open source manufacturer obtains the kernel basic code corresponding to the kernel version from the official website. If the non-open source manufacturer has some modified source code, the first patch code mentioned above can be made, that is, the patch file can be provided to the merger manufacturer, if not, this step can be ignored.

[0192] After that, the non-open source manufacturer adds its own source code (i.e. the first patch code, which may be a driver code or a newly added kernel function code, all of which are compiled into a kernel image file, not in the form of ko loaded into the kernel) to the official kernel basic code by patching (patch -p0 patch_file command or git apply patch_file can achieve it);

[0193] If there is an extension code in the kernel patch of the non-open source manufacturer (i.e. not modified in the kernel.c source file), add the new target obj rule to the current Makefile of the source code of the kernel patch, execute make, and then it will compile according to the Makefile file of the source code path, and the user configures Kconfig to configure the function options of the target file of the patch to be turned on to the kernel from the config graphical configuration, and then create an.o file in the same folder as the.c file of the kernel code (i.e. all kernel source code, including patch code), so that the compilation produces a single.o file of the kernel source code, and the location of the.o file of the extension code is kept in the kernel directory;

[0194] For example, in {kernel tree / drivers / net / a.o}, drivers / net / a.o is required to be kept in this form, and the.h file modified by the patch of the non-open source part is also placed in a folder according to the current directory of the.h file and the.o file {drivers / net / a.h}, and the compressed package of the.o and.h of the kernel patch and kernel driver and the makefile and Kconfig file of each layer of compilation rule is provided to the merger manufacturer. The kernel directory structure provided by the non-open source manufacturer is shown in Figure 17 .

[0195] (2) Mergers manufacturers integrate.o and.h files of non-open source manufacturers:

[0196] First, the merger obtains the official code of the non-open source manufacturer and the kernel version from the kernel official website, and the debian directory and the debian.master directory are compiled in the manner of an open source kernel package of ubantu, which needs to be downloaded for use of this compilation rule, and then the merger places the non-open source patch file into the kernel source code, as shown in the following:

[0197] After the merger combines the non-open source part of the code with the open source kernel source code, the source patch needs to be placed in the debian / patches / directory, as shown in the following: Figure 18 After that, the order of the patch is recorded in the debian / patches / series file, and the arm64 architecture processor is taken as an example, as shown in the following: Figure 19

[0198] The merger places the patch file (.o file and.h file and each layer of compilation rule makefile and Kconfig) provided by the non-open source manufacturer into the kernel source code by patching (patch -p0 patch_file command or git apply patch_file can be realized), executes make menuconfig (kernel configuration config graphical tool) in debian / build / build-generic, decompresses the.o and.h files provided by the non-open source manufacturer into the kernel (because the directory structure is the same, decompression of the.o and.h compressed files can be directly placed in the corresponding position of the kernel code), and according to the kernel config provided by the non-open source manufacturer, the patch code of the merger, and other kernel module functions that need to be compiled into the kernel by the merger, modifies the kernel module configuration file config again (combines the configurations of the three requirements into one configuration, that is, all the functions that need to be compiled into the kernel are enabled), and places the config completed by the merger in the debian.master / config / arm64 / config_zytc_5.4.100_arm64 path.

[0199] It needs to be specially pointed out that the reading rule of the config kernel configuration file when compiling the kernel software package is as follows:

[0200] First, the kernel compilation software package config acquisition file in the embodiment is as follows:

[0201] ​Only one kernel configuration file is needed in this embodiment, which can be config.common.ubuntu. The config.common.ubuntu file is empty or cleared based on the open source kernel basic code, and config.flavour.ge

[0202] neric puts the complete config configuration completed by the merging vendor together.

[0203] In addition, the reading rule of the kernel configuration file is optimized on the merging vendor side in this embodiment, and only one kernel cortex file is retained, which has the following operations.

[0204] The config file is copied to the specified path by cp -a $(archconfdir) / config_zytc_5.4.100.$(arch) $(builddir) / build-$* / .c

[0205] onfig to the kernel compilation directory to complete the config configuration reading.

[0206] (3) The merging vendor makes a kernel package:

[0207] After (2) is completed, the kernel is compiled dpkg-bubuilpackage, and the kernel software package is automatically built. At this time, the merging vendor can make a kernel software package containing the non-open source vendor part and the non-open source code of the merging vendor.

[0208] It should be noted that in the process of generating the.o cache path of the kernel source package, first find the debian / directory, modify the configuration file without deleting the cache directory, and the debian / rule.d / 2-binary-arch.mk is the rule file for kernel compilation and package making. At this time, the merging vendor modifies the kernel compilation configuration file to generate the kernel source code (the source code contains the non-open source part of the merging vendor).o cache directory, debian / build / build-generic is the.o file cache path, which does not contain kernel.c source files, only.o files, and a part of.h files and.o files are placed in a folder. However, due to the kernel compilation rule, a part of the kernel header files will be produced in a separate directory, which may cause the non-open source vendor to lack a part of the.h file when compiling the kernel. In debian / build / too

[0209] ls-perarch, find the.h file patched by the merger, and arrange another part of the header file in the form of the kernel directory. Refer to the arrangement method of the non-open source vendor directory structure in (1), and arrange another part of the.h file in the form of the kernel directory. The kernel tree is shown in Figure 20

[0210] In addition, 2-binary-arch.mk is shown in Figure 21 The.o file cache path is shown in Figure 22

[0211] (4) The.o / .h rule of the non-open source vendor's integrated custom module (i.e. the first kernel module file), and make a ko file (the non-open source vendor can ignore this step if there is no ko module):

[0212] For example, the non-open source vendor installs the kernel software package merged by the merger into the operating system or the root file system, executes Make, generates the ko compiled in the current kernel environment kernel version, and then provides it to the merger.

[0213] (5) The merger integrates the driver ko file (the non-open source vendor can ignore this step if there is no Ko module):

[0214] For example, in this embodiment, the driver ko file is dynamically loaded by insmod or modprobe, modprobe and insmod. The difference lies in that modprobe can solve the dependency relationship of load module, which is through / lib / modules / `uname -r` / modules.dep and modules.deo.bb files to find the dependency relationship; while insmod cannot solve the dependency relationship.

[0215] Here, the merger uses the dpemod command in the modprobe mode as an example. Decompress linux-modules-extra-5.4.100-2-generic_5.4.100-2.0+tc1_amd64.deb.

[0216] The contents of the linux-modules-5.4.100-2-generic_5.4.100-2.0+tc1_amd64.deb file are copied to the same path to obtain the lib / modules directory, and then the ko file provided by the non-open source vendor is copied to the same path in / lib / modules. After executing the dpemod -b command to load the ko module dependency relationship, the two deb packages are reversely compressed, and the software package that can automatically load the ko provided by the non-open source vendor is obtained.​​

[0217] (6) At this time, the kernel package is completed by the merging company, and the merging of the non-open source code of the merging company and the non-open source company is completed, and the kernel package and the driver ko module package can be released or the operating system can be built by the merging company or the non-open source company.

[0218] (7) When the non-open source code of the non-open source company or the merging company is changed, the kernel package needs to be recompiled, and at this time, the process reenters steps (1), (2), (3), (4), (5), and (6).

[0219] It can be seen that, unlike the existing kernel package compilation technology, in the embodiment, the system kernel will not directly contact the multi-party code when compiling into a software package. The target code file is operated by compiling during the preprocessing of the cache directory. The kernel package will generate an.o file during the compilation process. The role of the compilation is to convert the source code into assembly language, so that the non-open source code will not be parsed during the merging process. It can be ensured that the important part of the source code is safe and will not be taken in plaintext by malicious behavior. There is no risk of important source code leakage caused by the open source of the kernel, and the security of the operation of the important code is improved.

[0220] The embodiments in the specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and the related parts can be referred to the method part.

[0221] The skilled person can further realize that the units and algorithm steps of the examples described in combination with the embodiments disclosed in the present text can be realized in electronic hardware, computer software or a combination of the two. In order to clearly show the interchangeability of hardware and software, the composition and steps of each example have been described in the above description. Whether the functions are executed in hardware or software depends on the specific application and design constraints of the technical solution. The skilled person can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the present application.

[0222] The steps of the method or algorithm described in combination with the embodiments disclosed in the present text can be directly implemented in hardware, software modules executed by a processor, or a combination of the two. The software modules can be placed in random access memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs, or any other form of storage medium known in the art.

[0223] The foregoing description of the disclosed embodiments enables a person skilled in the art to make or use the application. Modifications of these embodiments will occur to persons of skill in the art, and, while certain embodiments according to the principles set forth herein are shown and described, it is to be understood that the same are not limiting of the scope of the application as it is set forth in the appended claims, and that various modifications are made within the scope of the appended claims. Therefore, it is contemplated to cover the application in its broadest scope, including all features that can be made or used in the embodiments described herein.

Claims

1. A method of processing kernel code, characterized by, The method applied to the first device comprises: obtaining a first source file according to a first patch code; compiling the first source file to obtain a first compiled file, the first compiled file comprising a first target file and a first header file corresponding to the first target file; sending the first compiled file to the second device at least to enable the second device to generate a kernel software package according to the first compiled file at least; wherein the method further comprises: receiving the kernel software package sent by the second device; installing the kernel software package in the first device to enable the first device to obtain a first kernel module file in a kernel environment corresponding to the kernel software package; sending the first kernel module file to the second device to enable the second device to add the first kernel module file to the kernel software package.

2. The method of claim 1, wherein, In the case that the first patch code comprises an extension code and / or a modification code, the obtaining of the first source file according to the first patch code comprises: patching kernel base code corresponding to a preset kernel version by using the first patch code to obtain the first source file; the extension code is used to add corresponding functions to the kernel; and the modification code is used to modify corresponding functions in the kernel. Or, in the case that the first patch code only comprises the extension code, the obtaining of the first source file according to the first patch code comprises: taking the first patch code as the first source file.

3. The method according to claim 1 or 2, characterized in that, The method further comprises: obtaining a first kernel configuration file according to a configuration file corresponding to the first patch code at least; the first kernel configuration file is used to compile the first source file to obtain the first compiled file; sending the first kernel configuration file to the second device to enable the second device to generate the kernel software package according to the first kernel configuration file, the first target file and the first header file at least.

4. A method of processing kernel code, characterized by, The method applied to the second device comprises: receiving a first target file and a first header file corresponding to the first target file sent by the first device; the first target file and the first header file are files obtained by compiling a first source file by the first device, and the first source file is a source file obtained by the first device according to a first patch code; generating a kernel software package according to the first target file, the first header file and a second source file; the second source file is a source file obtained according to kernel base code corresponding to a preset kernel version at least; wherein the method further comprises: receiving a first kernel configuration file sent by the first device, the first kernel configuration file being a kernel configuration file obtained by the first device according to a configuration file corresponding to the first patch code at least; obtaining a target kernel configuration file according to the first kernel configuration file and a second kernel configuration file at least; the target kernel configuration file is used to generate the kernel software package according to the first target file, the first header file and the second source file; The second kernel configuration file is a kernel configuration file corresponding to the kernel base code, or the second kernel configuration file is a kernel configuration file obtained by modifying the kernel configuration file corresponding to the kernel base code according to a configuration file corresponding to the second patch code.

5. The method of claim 4, wherein, The first target file is a target file obtained by compiling the extension code in the first patch code. The first target file, the first header file and the second source file are used to generate a kernel software package, including: The second source file is compiled to obtain a second compiled file, and the second compiled file includes a second target file and a second header file corresponding to the second target file; The first target file and the first header file are added to a path corresponding to the second target file according to a storage path of the second target file; The first target file and the second target file are at least linked to obtain a target image file, and the target image file includes a kernel image file and / or a kernel image compressed file, and the kernel image compressed file is obtained by compressing the kernel image file; The target image file, the first header file and the second header file are used to generate a kernel software package. The first source file is a source file obtained by patching the kernel base code using the first patch code by the first device, and the first target file corresponds to a storage path in a kernel directory corresponding to the kernel base code. The first target file, the first header file and the second source file are used to generate a kernel software package, including: The first target file and the first header file are added to a path corresponding to the storage path of the first target file in the second source file according to a kernel directory corresponding to the kernel base code to obtain a third source file; The third source file is compiled to obtain a second compiled file, and the second compiled file includes a second target file corresponding to the second source file, a second header file corresponding to the second target file, the first target file and the first header file; The first target file and the second target file are at least linked to obtain a target image file, and the target image file includes a kernel image file and / or a kernel image compressed file, and the kernel image compressed file is obtained by compressing the kernel image file; The target image file, the first header file and the second header file are used to generate a kernel software package.

6. The method according to claim 4 or 5, characterized in that, The second source file is a source file obtained by patching the kernel base code using the second patch code; or the second source file only includes the kernel base code.

7. An electronic device, comprising: The electronic device as the first device includes: A memory is configured to store a computer program and data generated by running the computer program. A processor is configured to execute the computer program to perform the following steps. The processor is configured to execute the computer program to: obtain a first source file according to a first patch code; compile the first source file to obtain a first compiled file, the first compiled file including a first object file and a first header file corresponding to the first object file; send the first compiled file to a second device to enable the second device to generate a kernel software package according to at least the first compiled file; receive the kernel software package sent by the second device; install the kernel software package in the first device to enable the first device to obtain a first kernel module file in a kernel environment corresponding to the kernel software package; and send the first kernel module file to the second device to enable the second device to add the first kernel module file to the kernel software package.

8. An electronic device, comprising: The electronic device as the second device includes: a memory configured to store a computer program and data generated by running the computer program; The processor is configured to execute the computer program to: receive a first object file and a first header file corresponding to the first object file sent by a first device; the first object file and the first header file are files obtained by compiling a first source file by the first device, and the first source file is a source file obtained by the first device according to a first patch code; generate a kernel software package according to the first object file, the first header file, and a second source file; the second source file is a source file obtained according to at least a kernel basic code corresponding to a preset kernel version; receive a first kernel configuration file sent by the first device, the first kernel configuration file being a kernel configuration file obtained by the first device according to at least a configuration file corresponding to the first patch code; obtain a target kernel configuration file according to at least the first kernel configuration file and a second kernel configuration file; the target kernel configuration file is used to generate the kernel software package according to the first object file, the first header file, and the second source file; and the second kernel configuration file is a kernel configuration file corresponding to the kernel basic code, or the second kernel configuration file is a kernel configuration file obtained by modifying a kernel configuration file corresponding to the kernel basic code according to a configuration file corresponding to a second patch code.

Images