Kernel code processing method and electronic equipment

Abstract

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

Description

[0001] This application is a divisional application of the application with the application number of 202310011073.X, the application date of January 5, 2023, and the title of "Kernel Code Processing Method and Electronic Device". TECHNICAL FIELD

[0002] The present application relates to the technical field of computers, and in particular to a kernel code processing method and an electronic device. BACKGROUND

[0003] 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 driving.

[0004] In actual application, there are cases of cooperation between multiple hardware manufacturers, and at this time, it is necessary to merge the patch code of each manufacturer.

[0005] However, there may be a case where 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

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

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

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

[0009] 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;

[0010] 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.

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

[0012] 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.

[0013] Or, in the case that the first patch code only contains the extended code, the obtaining the first source file according to the first patch code comprises:

[0014] The first patch code is taken as the first source file.

[0015] The above method preferably further comprises:

[0016] Receiving the kernel software package sent by the second device;

[0017] Installing 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;

[0018] 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.

[0019] The above method preferably further comprises:

[0020] 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;

[0021] Sending 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.

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

[0023] 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;

[0024] Generating 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.

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

[0026] The first object file, the first header file and the second source file, generating a kernel software package, comprising:

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

[0028] adding the first target file and the first header file to a path corresponding to the second target file according to a storage path corresponding to the second target file, the path being where a target file associated with the first target file in terms of code function is located;

[0029] 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;

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

[0031] 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;

[0032] The generating of the kernel software package according to the first target file, the first header file and the second source file comprises:

[0033] adding the first target file and the first header file to a path corresponding to a storage path corresponding to 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;

[0034] compiling the third source file to obtain a second compiled file, the second compiled file comprising 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;

[0035] 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;

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

[0037] 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.

[0038] The method, preferably, further comprises:

[0039] 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 at least a configuration file corresponding to the first patch code;

[0040] obtaining 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 being used to generate the kernel software package according to the first target file, the first header file and a second source file;

[0041] 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 the second patch code.

[0042] An electronic device, which comprises, as a first device:

[0043] a memory configured to store a computer program and data generated by running the computer program;

[0044] a processor configured to execute 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 comprising 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.

[0045] An electronic device, which comprises, as a second device:

[0046] a memory configured to store a computer program and data generated by running the computer program;

[0047] a processor configured to execute 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 the first device by compiling a first source file, 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.

[0048] 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

[0049] 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0064] 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.

[0065] Referring to FIG. 1, it shows an implementation flowchart of a kernel code processing method according to an embodiment of the present application, which can be applied to an electronic device capable of code compilation, such as a first device shown in FIG. 2, 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:

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

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

[0068] ​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.

[0069] 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. 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.

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

[0071] 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.

[0072] 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 in 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.

[0073] 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.

[0074] 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.

[0075] 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.

[0076] 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.

[0077] 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 safety of the non-open-source code can be ensured while the kernel software package is built.

[0078] 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 preset kernel version corresponding kernel base code in step 101 to obtain the first source file. The kernel version corresponding kernel base code 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 version corresponding kernel base code 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 code in the kernel base code according to the kernel directory. In addition, in the embodiment, the code compilation parameters corresponding to the extension code are 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 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. When the first source file is compiled in step 102, the compilation can be performed according to the target obj rule. Therefore, 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.

[0079] 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.

[0080] 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.

[0081] 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

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

[0083] 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.

[0084] 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.

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

[0086] 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 (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).

[0087] 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.

[0088] In addition, when the first device obtains the first kernel module file, 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.

[0089] It can be seen that in the embodiment, the kernel environment constructed by 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.

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

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

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

[0093] ​In an implementation, in the case that the first patch code contains the extension code and / or the modification code, the kernel base code corresponding to the preset kernel version is patched by using the first patch code in the embodiment to obtain the first source file. Based on this, the kernel configuration file corresponding to the kernel base code is modified by using the configuration file corresponding to the first patch code in step 107, for example, the configuration item corresponding to the extension code is added in the kernel configuration file corresponding to the kernel base code, and / or the configuration item corresponding to the modification code is 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 the configuration items of the corresponding functional modules in the kernel base code and the first patch code, etc. Based on this, when the first source file is compiled in step 102, the code corresponding to the corresponding functional modules can be compiled into the object file according to the configuration items in the first kernel configuration file.

[0094] In another implementation, in the case that the first patch code contains only the extension code, the first patch code is taken as the first source file in the embodiment. Based on this, the configuration file corresponding to the first patch code is taken as the first kernel configuration file in step 107. The first kernel configuration file contains the configuration items of the corresponding functional modules in the first patch code, etc. Based on this, when the first source file is compiled in step 102, the code corresponding to the corresponding functional modules in the first patch code can be compiled into the object file according to the configuration items in the configuration file corresponding to the first patch code.

[0095] Step 108: The first kernel configuration file is sent 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.

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

[0097] Further, in the embodiment, in addition to sending the first compiled file and the first kernel configuration file to the second device, the Kconfig file and the Makefile file corresponding to the first source file are also sent to the second device, so that the second device generates the kernel software package according to at least the first compiled file, the first kernel configuration file, the Kconfig file and the Makefile file, etc.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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.

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

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

[0105] 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.

[0106] 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.

[0107] 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.

[0108] 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.

[0109] 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.

[0110] 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.

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

[0112] 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.

[0113] 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.

[0114] 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

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

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

[0117] 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.

[0118] ​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.

[0119] 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.

[0120] The storage path corresponding to the second target file is the storage path where each target file located in the kernel directory corresponding to the kernel basic code, based on which, in the embodiment, the first target file is first searched for the second target file associated with the code function thereof according to the kernel directory, 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.

[0121] 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.

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

[0123] 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 taken as the target image file.

[0124] 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.

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

[0126] 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.

[0127] 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.

[0128] 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.

[0129] 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.

[0130] 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.

[0131] 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

[0132] 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.

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

[0134] 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.

[0135] Specifically, in this embodiment, the kernel compilation rule can be used to identify each compiled file in the third source file, and the 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.

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

[0137] 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.

[0138] 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.

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

[0140] 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, so as 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.

[0141] 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.

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

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

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

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

[0146] 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.

[0147] 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.

[0148] 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 based on this, 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 in step 502, 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] 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 based on this, 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 in step 502, 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.

[0150] 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.

[0151] 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 is 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.

[0152] 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.

[0153] 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

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

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

[0156] 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.

[0157] 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.

[0158] ​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.

[0159] 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.

[0160] 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.

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

[0162] 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.

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

[0164] 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.

[0165] ​​It should be noted that the specific implementation of each unit in this embodiment can be referred to the corresponding content above, and will not be described in detail here.

[0166] refer to Figure 12 This is a schematic diagram of a kernel code processing device provided in Embodiment 4 of this application. The device is configured on an electronic device capable of building kernel software packages, such as... Figure 2 The second device shown. The technical solution in this embodiment is mainly used to improve the security of non-open-source code.

[0167] Specifically, the device in this embodiment may include the following units:

[0168] The file receiving unit 1201 is used to receive 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 the first device compiling a first source file, and the first source file is a source file obtained by the first device according to the first patch code;

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

[0170] As can be seen from the above scheme, in the kernel code processing device provided in Embodiment 4 of this application, when building a kernel software package on the second device, at least the compiled object file and header file sent by the first device are used. Unlike the source file before compilation, which is easy to know, the source file of the first device cannot be easily known by the second device. Therefore, this application can ensure the security of the non-open source code while building the kernel software package.

[0171] In one implementation, the first target file is a target file obtained by compiling the extended code in the first patch code; the software package building unit 1202 is specifically used for: compiling the second source file to obtain a second compiled file, the second compiled file containing the second target file and a second header file corresponding to the second target file; adding the first target file and the first header file to the path of the target file in the second target file that is associated with the code function of the first target file according to the storage path corresponding to the second target file; performing at least linking processing on the first target file and the second target file to obtain a target image file, the target image file containing a kernel image file and / or a compressed kernel image file, the compressed kernel image file being obtained by compressing the kernel image file; and generating a kernel software package based at least on the target image file, the first header file, and the second header file.

[0172] In one implementation, 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 has a corresponding storage path in the kernel directory corresponding to the kernel base code; the software package building unit 1202 is specifically used to: 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, so as to obtain a third source file; compile the third source file to obtain a second compiled file, the second compiled file containing 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; link the first target file and the second target file at least to obtain a target image file, the target image file containing 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 based at least on the target image file, the first header file, and the second header file.

[0173] In one implementation, 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 contains only the kernel base code.

[0174] In one implementation, the apparatus in this embodiment may further include the following units, such as... Figure 13 As shown:

[0175] The configuration file processing unit 1203 is configured to receive a first kernel configuration file sent by the first device, wherein the first kernel configuration file is a kernel configuration file obtained by the first device at least based on the configuration file corresponding to the first patch code; and to obtain a target kernel configuration file at least based on the first kernel configuration file and the second kernel configuration file; wherein the target kernel configuration file is used to generate the kernel software package based on the first target file, the first header file and the second source file; wherein 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 based on the configuration file corresponding to the second patch code.

[0176] It should be noted that the specific implementation of each unit in this embodiment can be referred to the corresponding content above, and will not be described in detail here.

[0177] refer to Figure 14 This is a schematic diagram of the structure of an electronic device provided in Embodiment 5 of this application, as shown below.Figure 2 The first device shown may be a vendor server that provides non-open-source code. This electronic device, as the first device, may include the following structure:

[0178] Memory 1401 is used to store computer programs and data generated by the execution of said computer programs;

[0179] The processor 1402 is configured to execute the computer program to: obtain a first source file based on a first patch code; compile the first source file to obtain a first compiled file, the first compiled file containing a first object file and a first header file corresponding to the first object file; and send the first compiled file to a second device at least so that the second device generates a kernel package based on the first compiled file.

[0180] As can be seen from the above scheme, in the electronic device provided in Embodiment 5 of this application, after obtaining the first source file based on the first patch code on the first device, the first source file can be compiled to obtain a first compiled file containing a first object file and a first header file. Then, the first compiled file is sent to the second device, thereby generating a kernel software package on the second device based at least on the first compiled file. It is evident that in this embodiment, the binary file compiled by the first device received on the second device does not provide the second device with the non-open-source patch code of the first device. Therefore, this application can ensure the security of the non-open-source code while building the kernel software package.

[0181] It should be noted that the specific implementation of the processor in this embodiment can be referred to the corresponding content above, and will not be described in detail here.

[0182] refer to Figure 15 This is a schematic diagram of the structure of an electronic device provided in Embodiment Six of this application, as shown below. Figure 2 The second device shown could be a vendor server used to build kernel software packages. This electronic device, as a second device, could include the following structure:

[0183] Memory 1501 is used to store computer programs and data generated by the execution of said computer programs;

[0184] The processor 1502 is configured to execute the computer program 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 the first device compiling a first source file, and the first source file is a source file obtained by the first device based on a first patch code; generate a kernel package based on the first target file, the first header file, and the second source file; the second source file is a source file obtained at least according to the kernel base code corresponding to a preset kernel version.

[0185] As can be seen from the above scheme, in the electronic device provided in Embodiment Six of this application, when building the kernel software package on the second device, at least the compiled object file and header file sent by the first device are used. Unlike the source file before compilation, which is easy to know, the source file of the first device cannot be easily known by the second device. Therefore, this application can ensure the security of the non-open source code while building the kernel software package.

[0186] Taking the construction of a kernel software package (hereinafter referred to as the kernel source package or kernel package) for a certain hardware as an example, the driver part of the hardware manufacturer cannot do without kernel source code patches. The production of the kernel source package will merge the non-open source part of the code and the open source part of the kernel code to produce the kernel package. When the kernel code of two or more manufacturers needs to be merged, there are non-open source parts. In this case, the only way is to merge the plaintext source code of multiple parties. However, this is easy for competing manufacturers to obtain and crack, which poses the problem of source code leakage and security cannot be guaranteed.

[0187] In view of this, and in response to the situation where plaintext leakage occurs during the merging of kernel source code from multiple parties, this embodiment proposes a kernel package creation method to address the risk of leakage of kernel code from multiple parties, in accordance with the technical solution of this application described above. This method improves the security of kernel source code merging and enables cooperation among multiple hardware manufacturers. Plaintext is not obtained during the merging process, eliminating the risk of obtaining confidential information from multiple source codes and ensuring that "important source code is not visible, and plaintext code is not leaked."

[0188] In specific implementation, this embodiment is applicable to the construction of kernel packages compiled from various Linux operating systems. The following will take the Debian operating system running in the AArch64 processor architecture environment as an example for explanation, using a vendor server that provides non-open source code (hereinafter referred to as the non-open source vendor) and a vendor server that implements code merging (hereinafter referred to as the merged vendor) as examples.

[0189] 1. For example Figure 16 As shown in the flowchart, the first step of this embodiment includes:

[0190] (1) Non-open source vendors prepare .oh files for kernel patches and kernel drivers:

[0191] First, vendors that do not open-source their products and those that merge their products agree in advance to use the same kernel version.

[0192] Then, the non-open-source vendors obtained the kernel base code corresponding to their kernel version from the official website. If the non-open-source vendors have some modified source code to provide, a patch can be created here, which is the first patch code mentioned earlier, and can be provided to the patch file of the merging vendor. If not, this step can be ignored.

[0193] Afterwards, non-open-source vendors added their own source code (i.e., the first patch code, which may be driver code or code added to kernel functions; these are all code that needs to be compiled into the kernel image file and loaded into the kernel in non-ko form) to the official kernel base code by patching (the patch -p0 patch_file command or git apply patch_file can be used to achieve this).

[0194] If there is extended code in the kernel patch from a non-open-source vendor (i.e., modifications not made to the kernel .c source file), the new target obj rule is added to each layer of the Makefile in the kernel patch's source code. Then, make is executed, and it will compile according to the Makefile file in the source code path. At the same time, the user configures Kconfig to enable the feature options of the patch's target files in the kernel from the config graphical configuration. Then, a .o file is created in the same folder as the .c files of the kernel code (i.e., all kernel source code, including the patch code). This compilation produces a single .o file of the kernel source code, while preserving the location of the .o file of the extended code in the kernel directory.

[0195] For example, in the kernel tree {kernel tree / drivers / net / ao}, the format drivers / net / ao needs to be preserved. The non-open-source .h files modified by the patch should also be placed in a folder {drivers / net / ah} along with the .o files, following the location of the .h files in the current kernel directory. The compiled kernel patch, kernel driver .o and .h files, along with the Makefile and Kconfig files for each layer of compilation rules, should be provided to the merging vendor in a compressed package. The kernel directory structure provided by the non-open-source vendor is as follows: Figure 17 As shown in the image.

[0196] (2) Merging vendors' .o and .h files into non-open-source vendors:

[0197] First, the merging vendor obtains the official code for the same kernel version from the kernel website, which is not open source. The `debian` directory and `debian.master` directory represent a kernel package compilation method used by Ubuntu's open source system; these need to be downloaded and used. Then, the merging vendor places its own non-open source patch files into the kernel source code, as follows:

[0198] After merging the non-open-source code with the open-source kernel source code, the source code patch needs to be placed in the debian / patches / directory, such as... Figure 18 As shown in the image; afterwards, the order of the patches is recorded in the `debian / patches / series` file. Taking the arm64 architecture processor as an example, the kernel source code path is modified to the `debian / patches / series-arm64` file. After enabling the patching, `Seriers-arm64` is configured as follows. Figure 19 As shown in the image.

[0199] The merging vendor applies the patch files (.o and .h files, and makefiles and Kconfig for each layer of compilation rules) provided by the non-open-source vendor to the kernel source code via patching (either using the command `patch -p0 patch_file` or `git apply patch_file`). Then, in `debian / build / build-generic`, execute `makemenuconfig` (a graphical kernel configuration tool). This extracts the .o and .h files from the non-open-source vendor into the kernel (since the directory structure is the same, extracting the .oh compressed file allows you to directly place the .o / .h files in the corresponding locations in the kernel code). Based on the kernel configuration provided by the non-open-source vendor, the merging vendor's patch code, and other kernel module features that the merging vendor needs to enable, the kernel module configuration file (`config`) is modified again (merging the configurations for the three requirements into one configuration, meaning all features that need to be compiled into the kernel are enabled). After the merging vendor completes the configuration, it is placed in the path `debian.master / config / arm64 / config_zytc_5.4.100_arm64`.

[0200] It should be noted that the rules for reading the kernel configuration file (config) when compiling packages are as follows:

[0201] First, in this embodiment, the kernel compilation package config file is obtained in the following way:

[0202] This embodiment only requires one kernel configuration file, which can be: based on the open-source kernel base code, empty or clear the config.common.ubuntu file, and the config.flavour.ge file.

[0203] neric provides the complete config settings for merging vendors.

[0204] In addition, this embodiment optimizes the kernel configuration file reading rules on the merge vendor side, retaining only one kernel cortex file, with the following operations:

[0205] Via cp -a $(archconfdir) / config_zytc_5.4.100.$(arch) $(builddir) / build-$* / .c

[0206] The config command will copy the file debian.master / config / arm64 / config_zytc_5.4.100_arm64 from the specified path to the kernel compilation directory to complete the config configuration reading.

[0207] (3) Merging vendors to create kernel packages:

[0208] After (2) is completed, compile the kernel dpkg-bubuilpackage to automatically build the kernel package. At this time, the merge vendor can produce a kernel package that includes parts from non-open source vendors and non-open source code from the merge vendor.

[0209] It's important to note that during the process of generating the .o cache path for the kernel source package, the `debian / ` directory is first located. The configuration file is modified without deleting the cache directory. `debian / rule.d / 2-binary-arch.mk` is the rule file for compiling and creating the kernel package. At this point, the merge vendor modifies the kernel compilation configuration file to generate the kernel source code (which includes parts of the code that the merge vendor does not open-source). The `debian / build / build-generic` is the path for generating the .o file cache. It does not contain kernel .c source files, only .o files. Some .h files are placed in the same folder as the .o files, but due to kernel compilation rules, some kernel header files are generated in a separate directory. This means that vendors compiling the kernel may miss some .h files. In `debian / build / too`...

[0210] Use `ls -perarch` to locate the patched .h files from the merge vendors, and then organize the remaining header files according to the kernel directory structure. Refer to the non-open-source vendor directory structure organization method in (1) to organize the remaining .h files according to the kernel directory structure. The kernel tree is as follows: Figure 20 As shown in the image.

[0211] Additionally, 2-binary-arch.mk, such as Figure 21 As shown in the image. The .o file cache path is as follows: Figure 22 As shown in the image.

[0212] (4) Non-open source vendors merge the .o / .h rules of the custom module (i.e., the first kernel module file) and create a ko file (non-open source vendors can ignore this step if they do not have a ko module):

[0213] For example, a non-open-source vendor might obtain a merged kernel package from a merge vendor, install it into the operating system or root file system, execute Make to generate a .ko file compiled for the current kernel version, and then provide it to the merge vendor.

[0214] (5) Merge the vendor's driver ko file (this step can be ignored if the vendor does not have a ko module):

[0215] For example, in this embodiment, the driver .ko file is dynamically loaded using insmod or modprobe. The difference between modprobe and insmod is that modprobe can resolve the dependencies of the loaded module by looking up the dependencies through the files / lib / modules / `uname -r` / modules.dep and modules.deo.bb; while insmod cannot resolve the dependencies.

[0216] Here, we'll use the dpemod command, taking modprobe mode as an example, to decompress linux-modules-extra-5.4.100-2-generic_5.4.100-2.0+tc1_amd64.deb.

[0217] Copy the contents of the linux-modules-5.4.100-2-generic_5.4.100-2.0+tc1_amd64.deb file to the same path to obtain the lib / modules directory. Then copy the ko file provided by a non-open source vendor to the same path as / lib / modules. After executing the dpemod -b command to load the ko module dependencies, compress the two deb packages back into their original state. This will give you a package that can automatically load ko files provided by non-open source vendors.

[0218] (6) At this point, the merging vendor completes the production of the kernel software package, and the non-open source code of both the merging vendor and the non-open source vendor is merged. The merging vendor or the non-open source vendor can release the kernel software package and driver ko module package or build the operating system.

[0219] (7) When the non-open source code of a vendor or a merged vendor changes, the kernel package needs to be recompiled. At this time, the process will return to steps (1)(2)(3)(4)(5)(6).

[0220] As can be seen, unlike existing kernel package compilation technologies, in this embodiment, the system kernel does not have direct contact with the code of multiple parties when it is compiled into a package. During the package compilation, the cache directory is preprocessed, and the target code files are manipulated through compilation. The kernel package generates .o files during the compilation process. The purpose of compilation is to convert the source code into assembly language, so that the non-open-source source code will not be parsed during the merging process. This ensures the security of important source code, prevents malicious behavior from obtaining plaintext, eliminates the risk of leakage of important source code due to the absence of open-source kernel, and improves the security of operations on important code.

[0221] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to the method section.

[0222] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0223] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0224] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method of processing kernel code, characterized by, The method applied to a 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 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; wherein the method further comprises: obtaining a first kernel configuration file according to at least a configuration file corresponding to the first patch code; the first kernel configuration file being 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 at least the first kernel configuration file, the first target file and the first header file.

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 using the first patch code to obtain the first source file; the extension code being used to add corresponding functions to the kernel; the modification code being 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 of claim 1, 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.

4. A method of processing kernel code, characterized by, The method applied to a second device comprises: 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; 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 kernel base code corresponding to a preset kernel version; 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 at least a configuration file corresponding to the first patch code; obtaining 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 being used to generate the kernel software package according to the first target file, the first header file and the second source file.

5. The method of claim 4, wherein, the first target file being a target file obtained by compiling an extension code in the first patch code; The first target file and the first header file are added to a path corresponding to a storage path of the first target file in the second source file according to the storage path of the second target file, to obtain a third source file. The first target file and the second target file are at least subjected to linking processing 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. The first target file and the second target file are at least subjected to linking processing 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. The first target file and the second target file are at least subjected to linking processing 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. The first target file and the second target file are at least subjected to linking processing 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. The first target file and the second target file are at least subjected to linking processing 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. The first target file and the second target file are at least subjected to linking processing 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. The first target file and the second target file are at least subjected to linking processing 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. 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. 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. The electronic device as the first device comprises:

6. The method according to claim 4 or 5, characterized in that, a memory configured to store a computer program and data generated by running the computer program; 7. The method according to claim 4 or 5, characterized in that, ​ ​ 8. An electronic device, comprising: ​ ​ The processor is configured to execute the computer program to implement: 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 including a first object file and a first header file corresponding to the first object file; sending 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; obtaining a first kernel configuration file according to a configuration file corresponding to the first patch code; the first kernel configuration file being used for compiling the first source file to obtain the first compiled file; and sending the first kernel configuration file to the second device to enable the second device to generate the kernel software package according to at least the first kernel configuration file, the first object file and the first header file.

9. 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 implement: 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 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; generating a kernel software package according to the first object 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 basic code corresponding to a preset kernel version; 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 at least a configuration file corresponding to the first patch code; and obtaining 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 being used for generating the kernel software package according to the first object file, the first header file and the second source file.

Images