A method and device for repairing program defects in kernel state of embedded system

Abstract

The present invention relates to the field of embedded software, and in particular to a method and device for repairing program defects in the kernel state of an embedded system. The method mainly comprises: passing a shared library containing a patch segment required by a process to a kernel module, and the kernel module loading the shared library into the process space of the corresponding process; the kernel module obtaining the addresses of the original memory segment and the patch segment corresponding to the patch segment in the memory control block, and replacing the address of the original memory segment in the memory control block with the address of the patch segment. The present invention can conveniently perform replacement and repair when any process needs to be repaired, modified, or a new program function is added, without requiring the process to be initialized in advance or restarting the process after the operation. This method can achieve online repair, modification, or new function addition, thereby enhancing the robustness of the program.

Description

Technical field

[0001] The present invention relates to the field of embedded software, and in particular to a method and device for repairing program defects in a kernel state of an embedded system. [Background Technology]

[0002] In the field of embedded software technology, processes are divided into kernel mode and user mode. When a user process runs in kernel mode, the CPU can access all data in memory, including peripheral devices such as the hard drive and network interface card, and can also switch from one program to another. When a user process runs in user mode, the process has limited access to memory and is prohibited from accessing peripheral devices. This deprives the process of CPU usage, allowing other programs to acquire CPU resources.

[0003] In current system process scheduling methods, when a running kernel-mode process encounters a defect or requires modification or functionality, the process must be shut down, modified, and then restarted. However, in some scenarios, critical processes must remain running and cannot be shut down or interrupted, making program defect repair difficult.

[0004] In view of this, how to overcome the defects of the existing technology and solve the problem of difficulty in repairing program defects in kernel mode is a problem to be solved in this technical field. [Summary of the invention]

[0005] In response to the above defects or improvement needs of the prior art, the present invention solves the problem of repairing program defects without closing the process in kernel mode.

[0006] The embodiment of the present invention adopts the following technical solutions:

[0007] In the first aspect, the present invention provides a method for repairing program defects in the kernel state of an embedded system, specifically: passing the shared library containing the patch segment that the process needs to use to the kernel module, and the kernel module loads the shared library into the process space of the corresponding process; the kernel module obtains the original memory segment and the address of the patch segment corresponding to the patch segment in the memory control block, and replaces the address of the original memory segment in the memory control block with the address of the patch segment.

[0008] Preferably, the kernel module loads the shared library into the process space of the corresponding process, specifically including: obtaining the segment information of the patch segment to be used in the shared library, and reading the patch segment into the virtual address space corresponding to the process; the kernel module obtains the corresponding memory control block according to the process control information of the process, and writes the virtual address of the patch segment into the corresponding memory control block; and relocates the function to be repaired according to the virtual address of the patch segment.

[0009] Preferably, writing the virtual address of the patch segment into the corresponding memory control block specifically includes: adding segment information of the patch segment in the memory control block of the process, and writing the virtual address of the patch segment into the corresponding segment information in the memory control block.

[0010] Preferably, the method further includes: pausing execution of the process before obtaining segment information of the patch segment to be used in the shared library; and continuing execution of the process after relocating the function to be repaired.

[0011] Preferably, the kernel module obtains the addresses of the original memory segment and the patch segment corresponding to the patch segment in the memory control block, specifically including: obtaining the virtual addresses of the original memory segment and the patch segment, and converting the virtual addresses of the original memory segment and the patch segment into kernel linear addresses.

[0012] Preferably, obtaining the virtual addresses of the original memory segment and the patch segment specifically includes: parsing the files where the original memory segment and the patch segment are located, and obtaining the offset addresses of the original memory segment and the patch segment in the files respectively; parsing the maps file of the process, and obtaining the running base addresses of the modules where the original memory segment and the patch segment are located respectively; taking the running base address of the module where the original memory segment is located as the starting point, offsetting according to the offset address of the original memory segment to obtain the virtual address of the original memory segment when it is running, and taking the running base address of the module where the patch segment is located as the starting point, offsetting according to the offset address of the patch segment to obtain the virtual address of the patch segment when it is running.

[0013] Preferably, the virtual addresses of the original memory segment and the patch segment are converted into kernel linear addresses, specifically including: obtaining the kernel virtual page table corresponding to the process through the process control information of the process and the address of the patch segment in the memory control block; obtaining the physical address of the patch segment according to the address of the patch segment in the memory control block and the information of the kernel virtual page table; and converting the physical address of the patch segment into a kernel linear address.

[0014] Preferably, the method further includes: reading the assembly instruction backup of the original memory segment according to the kernel linear address of the original memory segment; and replacing the assembly instruction of the original memory segment with the assembly instruction of the patch segment.

[0015] Preferably, the method further includes: the kernel module obtaining the process ID of the process, and obtaining the process control block and memory management unit of the process according to the process ID.

[0016] On the other hand, the present invention provides a device for repairing program defects in the kernel state of an embedded system, specifically: including at least one processor and a memory, the at least one processor and the memory are connected via a data bus, the memory stores instructions that can be executed by at least one processor, and after the instructions are executed by the processor, they are used to complete the method for repairing program defects in the kernel state of the embedded system in the first aspect.

[0017] Compared with existing technologies, the beneficial effects of the embodiments of the present invention are: loading the user-repaired patch segment into the process space, and redirecting the kernel's call address from the original memory segment address to the patch segment memory address through address translation and address replacement, thereby achieving the effect of program repair. Utilizing the technical solution of the present invention, any process that needs repair, modification, or new program functionality can be conveniently replaced and repaired without requiring the process to complete related operations such as initialization in advance or restarting the process after the operation. This allows for online repair, modification, or new functionality, enhancing program robustness.

Brief Description of the Drawings

[0018] To more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. Those skilled in the art can also derive other drawings based on these drawings without inventive effort.

[0019] Figure 1 A flowchart of a method for repairing program defects in kernel mode of an embedded system provided by an embodiment of the present invention;

[0020] Figure 2 A flowchart of another method for repairing program defects in kernel mode of an embedded system provided by an embodiment of the present invention;

[0021] Figure 3 A flowchart of a method for repairing program defects in kernel mode of an embedded system provided by an embodiment of the present invention;

[0022] Figure 4 A flowchart of a method for repairing program defects in kernel mode of an embedded system provided by an embodiment of the present invention;

[0023] Figure 5 A flowchart of a method for repairing program defects in kernel mode of an embedded system provided by an embodiment of the present invention;

[0024] Figure 6 A schematic diagram of the structure of a device for repairing program defects in kernel state of an embedded system provided by an embodiment of the present invention. [Specific implementation method]

[0025] In order to make the purpose, technical solutions and advantages of the present invention more clearly understood, the present invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0026] The present invention is an architecture of a specific functional system. Therefore, the specific embodiments mainly illustrate the functional logical relationship between the various structural modules, and do not limit the specific software and hardware implementation methods.

[0027] In addition, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other. The present invention will be described in detail below with reference to the accompanying drawings and embodiments.

[0028] Example 1:

[0029] When repairing a program defect, patch code or patch data needs to be loaded into memory and used to replace the code or data in the original process. In existing technical solutions, when running in user mode, due to the limitations of user mode permissions, it is not convenient to directly access external data, and the process needs to be closed for repair and then restarted. When running in kernel mode, the kernel module cannot directly operate the virtual address of the user mode process, so direct replacement is also impossible. In this embodiment, the virtual address is also referred to as the virtual address. The present invention provides a program defect repair method applicable to both user mode and kernel mode processes. Code or data can be replaced without closing the process, completing the program repair.

[0030] like Figure 1 As shown, the specific steps of the method for repairing program defects in the kernel state of an embedded system provided by the embodiment of the present invention are as follows:

[0031] Step 101: The shared library containing the patch segment to be used by the process is passed to the kernel module, and the kernel module loads the shared library into the process space of the corresponding process.

[0032] During the running of a process, external code or data can be obtained through a shared library. In the solution provided in this embodiment, process repair or modification, newly added program functions or data are also provided using shared libraries. If a shared library is to be used in a process, it needs to be loaded into the process space of the process. In an embedded system, a shared library is specifically a dynamic link library so. When the first program that requires a module in a shared library is started, a single copy of the shared library will be loaded into the memory during runtime. When other programs that use the same shared library are subsequently started, the copy of the library that has been loaded into the memory will be used. Based on this feature of the shared library, the program can be repaired through the shared library. First, the code or data for repair is obtained through the shared library, and then the call address is relocated in step 102, so that the code or data in the shared library can be used when the process is running, instead of the code or data of the original process, to achieve the repair effect.

[0033] Taking code repair as an example, when the code calls the patch function that needs to be used after the repair in the so code segment for the first time, when the operating system executes to the function, it will obtain the function instructions in the physical address corresponding to the function virtual address based on the function call information in the process control block and execute them. At this time, the physical address will mark whether the disk data corresponding to the physical address has been loaded into the physical memory. If not, the corresponding data on the disk will be loaded into the physical memory, and then the corresponding function instructions in the physical memory will be read for execution. When the function is called again, since the function instructions have been loaded into the physical memory in the above process, the corresponding data will be directly obtained and executed. When data repair is performed, the same process is also used. According to the data virtual address in the process control block, the corresponding data is read into the physical memory from the shared library for use.

[0034] Through the above process, the specified so can be loaded into the specified user process in the kernel state, and the result after execution is the same as the result of the user state process calling dlopen to load so. In a specific implementation scenario, if a so is dlopened in the user state, only some items are added in the memory management to establish a mapping relationship. The user state process calling dlopen to load so by itself only maps the virtual kernel and physical memory. When the function in the so is actually called, the operating system will actually load the things in the so into the physical memory. In step 101, it is equivalent to completing the so loading work performed by the above-mentioned user state in the kernel state.

[0035] Step 102: The kernel module obtains the addresses of the original memory segment and the patch segment corresponding to the patch segment in the Process Control Block (PCB), and replaces the address of the original memory segment in the PCB with the address of the patch segment.

[0036] During compilation, a shared library must use independent address segments to store code or data. Therefore, direct code or data replacement cannot be used. During process execution, the call relationship must be processed and symbol relocation performed, replacing the function call or data call address in the original process with the code segment or data segment address in the shared library already loaded into memory. After the shared library containing the new code is loaded into the designated process, the address of the function to be modified or repaired in the process must be obtained. The address of the original code segment or data segment in the memory control block is then modified to the address of the patch code segment or patch data segment in the shared library loaded into memory in step 101. The using process can then call the patch code segment or patch data segment loaded into memory when calling. Furthermore, since the kernel module cannot directly manipulate the virtual address of a user-mode process, the virtual address of the designated process must be converted into a physical address, and then the physical address must be converted into a kernel linear address that the kernel can operate on. Since the virtual address to physical address conversion methods differ between user-mode and kernel-mode, using the kernel linear address conversion step ensures that the converted physical addresses are identical.

[0037] After steps 101 and 102 of this embodiment, the shared library "so" is loaded into the address space of the specified user-mode process in kernel mode. By modifying the call mapping relationship in the process control block, the code segment or data segment to be replaced is located, and the code or data to be modified is obtained. Because the shared library loading and call address relocation are both performed in the kernel module, they do not affect the operation of the process. Therefore, the program defect can be repaired without shutting down the process.

[0038] Furthermore, since each process has a unique process ID (PID), the memory control block of each process is placed in the kernel in the form of a memory management structure. The kernel module obtains the process ID of the process and obtains the process control block and memory management unit of the process based on the process ID. The memory management unit contains the memory management information of each process, including the calling address information of each code segment or data segment.

[0039] In step 101, Figure 2 As shown, the kernel module loads the shared library into the process space of the corresponding process, which specifically includes the following steps.

[0040] Step 201: Obtain the segment information of the patch segment to be used in the shared library, and read the patch segment into the virtual address space corresponding to the process.

[0041] In order to load the required patch segment into memory and pass it to the kernel module, it is necessary to parse the shared library and obtain the segment information of the shared library. Then, the code segment or data segment to be loaded into the memory is read into the virtual address space of the process. In actual use, the segment information that needs to be loaded into the memory mainly includes segments with the attribute LOAD, which include code segments, data segments, BSS segments, etc. In this process, the address data used is the virtual address space managed by the process, rather than the actual physical memory address. When accessing data, the process manages and operates on the virtual memory that it can manage. The read and write addresses of the virtual memory are virtual addresses. When reading and writing these virtual memories, the operating system obtains the actual physical memory based on the corresponding information in the process's memory management unit, and then reads and writes the physical memory.

[0042] Step 202: The kernel module obtains the corresponding memory control block according to the process control information of the user-mode process, and writes the virtual address of the patch segment into the corresponding memory control block.

[0043] When calling code or data, the kernel module makes the call based on the memory management information in the memory control block of the corresponding process, that is, the address stored in mm_struct. In order for the kernel module to call the code or data of the patch segment to replace the original code or data while the process is running, it is necessary to manually map the user-mode memory space and write the virtual address of the patch segment to the corresponding location in the memory control block. The memory control block only stores content related to the memory address, such as recording the code segment information by writing the start and end addresses of the code segment. When calling, it can directly search in the memory based on the address information.

[0044] Step 203: Relocate the function to be repaired according to the virtual address of the patch segment.

[0045] After the shared library is loaded into the address space of the process and the address of the patch segment is written to the corresponding position of the memory control block, the kernel module relocates the patch code or patch data in the shared library through the address and calls the repaired patch code or patch data during execution.

[0046] After steps 201 to 203 provided in this embodiment, the relocation of the patch segment is completed, so that the kernel module can call the patch segment or patch data.

[0047] In step 202, when writing the virtual address of the patch segment into the corresponding memory control block, it is necessary to add the segment information of the patch segment to the memory control block of the process, and write the virtual address of the patch segment into the corresponding segment information in the memory control block. Specifically, data recording the address information of the patch segment or patch data, such as the starting address and ending address of the code segment, and the mapping relationship between the address and the physical memory address, is added to the memory management unit. The address information written is virtual address information.

[0048] Furthermore, in step 102, since the virtual addresses used by the kernel module and the user-mode process are converted to physical addresses in different ways, the kernel module cannot directly use the virtual address of the user-mode process when performing address replacement, and needs to convert the virtual address into a kernel linear address before performing the replacement. Specifically, the virtual addresses of the original memory segment and the patch segment can be obtained, and the virtual addresses of the original memory segment and the patch segment can be converted into kernel linear addresses. In actual use scenarios, the virtual addresses of the corresponding segments can be obtained through the maps file of the user-mode process, and the files containing the original memory segment and the patch segment are parsed to obtain the offset addresses of the original memory segment and the patch segment in the files respectively. The maps file of the user-mode process is parsed to obtain the running base addresses of the modules containing the original memory segment and the patch segment respectively. Starting from the running base address of the module containing the original memory segment, the offset address of the original memory segment is used to offset and obtain the virtual address of the original memory segment when it is running. Starting from the running base address of the module containing the patch segment, the offset address of the patch segment is used to offset and obtain the virtual address of the patch segment when it is running. After obtaining the virtual address, the kernel virtual page table corresponding to the process is obtained using the process control information and the address of the patch segment in the memory control block. The physical address of the patch segment is obtained based on the address of the patch segment in the memory control block and the information in the kernel virtual page table. The physical address of the patch segment is converted into a kernel linear address. Through the above steps, the virtual address of the user process, which the kernel module cannot directly operate on, is converted into a consistent kernel linear address that the kernel module can use, allowing the kernel module to accurately redefine the patch segment using the replaced address.

[0049] Furthermore, to avoid execution errors caused by replacing code or data during patching, the process needs to be paused and placed in a sleep state during the replacement. Before obtaining the segment information for the patch segment to be used in the shared library, the state of the process's control information is modified, and the process execution is suspended. After relocating the function to be repaired, the state of the process's control information is modified, and the process execution continues. Because the method provided in this embodiment only relocates part of the code or data in the process and does not modify the original code or data, there is no need to shut down the process.

[0050] Furthermore, in addition to directly using the shared library's relocation to repair the program, the solution provided by this embodiment can also directly modify the original code or data of the process based on the patch code or patch data in the shared library to complete the re-release of the program. Specifically, the assembly instruction backup of the original memory segment can be read based on the kernel linear address of the original memory segment, and the assembly instructions of the original memory segment can be replaced with the assembly instructions of the patch segment. After the instruction replacement, the original code or data of the process is repaired and can be executed according to the normal process without having to use the shared library again to relocate and call the code or data in the shared library.

[0051] In a specific implementation scenario, the program repair method provided by this embodiment can be directly compiled into the kernel code and executed by a kernel module, or it can be loaded into the kernel as a kernel module when needed. When it is necessary to modify, repair, or add new program functions, the process ID of the user-mode process to be modified or repaired and the shared library information where the new code is located are passed to the kernel module. After receiving this information, the kernel module then uses the technology disclosed in this invention to process the program.

[0052] The method for repairing program defects in the kernel state of the embedded system provided by this embodiment can.

[0053] Example 2:

[0054] In this embodiment, based on the method for repairing program defects in the kernel state of an embedded system provided in Example 1, a usage process in a specific scenario is provided by taking replacing a patch function for a process by hot patching as an example.

[0055] According to step 101, the user-mode process PID that needs to be patched and the hot patch SO information where the new code is located are passed to the kernel module. The specific implementation method can be as follows:

[0056] Method 1: User mode provides an interface to pass the process pid and the path where the hot patch so is located to the kernel module.

[0057] Method 2: Use the proc file system to pass the process pid and the path to the hotpatch.so file to the kernel module. For example, to load the patch libpatch.so for process ID 1234, use the proc file system to pass the parameters as follows: echo 1234 / dev / shm / libpatch.so > / proc / hotpatch.

[0058] Specifically, such as Figure 3 As shown, to load the patch so into the process that needs to be patched, you can use the following steps.

[0059] Step 301: Obtain the control information of the process according to the process PID.

[0060] The control information of the process is the process control block PCB information, which is also the information managed by the task_struct structure. This information contains all the information required by the process.

[0061] Step 302: Modify the state of the process's control information to suspend the execution of the process.

[0062] The PCB contains a status bit used to mark the process status. Simply changing the status to TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE will suspend the execution of the process.

[0063] Step 303: Obtain the memory management unit of the process according to the process control information.

[0064] The PCB stores the memory management unit information for a process, which is managed by the mm_struct structure. This structure records the entire virtual address space of the process. This information can be directly obtained from the process control information structure task_struct.

[0065] Step 304: Parse the hot patch so, obtain the segment information of the so, and read the segment that needs to be loaded into the memory into the virtual address space of the process.

[0066] The segments that need to be loaded into the virtual address space of the process, that is, the segments of type LOAD displayed by running the readelf -l libpatch.so command, can be obtained by parsing the patch.so file.

[0067] Step 305: Add corresponding segment data information to the memory management unit of the process, and update the segment virtual address loaded in step 304 into the segment data information.

[0068] Step 306: Relocate the function of the hot patch so.

[0069] After loading the patch so into the process address space, the symbols in the patch so need to be relocated before the process can correctly use the functions therein.

[0070] Step 307: Modify the state of the process's control information to allow the process to continue executing.

[0071] Corresponding to step 302, the status position in the process control information is set to TASK_RUNNING.

[0072] According to step 102, Figure 4 As shown, the specific implementation steps for obtaining the original memory segment address and the patch segment address are as follows.

[0073] Step 401: Obtain the offset address of the original memory segment.

[0074] Parse the module file containing the original memory segment. If the original memory segment is in the executable file corresponding to the process, the module file refers to that executable file. If the original memory segment is in a shared library, the module file refers to that shared library. Directly read and parse the module file to obtain the offset address of the original memory segment within the file.

[0075] Step 402: Obtain the base address of the original memory segment during runtime.

[0076] The runtime base address of the original memory segment is the runtime base address of the module where the function is located. The runtime base address of the module where the function is located can be obtained by parsing the maps file of the patched process.

[0077] Step 403: Obtain the runtime address of the original memory segment.

[0078] The runtime address of the original memory segment can be obtained by adding the offset address obtained in step 401 to the base address obtained in step 402.

[0079] Step 404: Obtain the runtime address of the patch segment.

[0080] Similar to obtaining the address of the original memory segment, the runtime address of the patch segment can be obtained using steps similar to steps 401 to 403.

[0081] Furthermore, you can Figure 5 As shown, modify the original memory segment content and repair the function defect. The specific implementation steps are as follows.

[0082] Step 501: Convert the original memory segment address into a kernel linear address that can be directly read and written by the kernel.

[0083] Step 502: Convert the patch segment address into a kernel linear address that can be directly read and written by the kernel.

[0084] Step 503: Read the original memory segment assembly instruction backup.

[0085] Step 503: Modify the original memory segment content to the patch segment content.

[0086] Through the steps provided in this embodiment, the program repair process can be completed. It can be seen that the program repair method provided in Example 1 can simply and effectively complete the program repair without closing the process, achieving the effect of program repair in kernel state.

[0087] Example 3:

[0088] Based on the method for repairing program defects in the kernel state of an embedded system provided in the above-mentioned embodiments 1 and 2, the present invention also provides a device for repairing program defects in the kernel state of an embedded system that can be used to implement the above-mentioned method, such as Figure 6 , which is a schematic diagram of the device architecture of an embodiment of the present invention. The device for repairing program defects in the kernel state of an embedded system of this embodiment includes one or more processors 11 and a memory 12. Figure 6 A processor 11 is taken as an example.

[0089] The processor 11 and the memory 12 may be connected via a bus or other means. Figure 6 The bus connection is taken as an example.

[0090] Memory 12, as a non-volatile computer-readable storage medium for the method for repairing program defects in kernel mode of an embedded system, can be used to store non-volatile software programs, non-volatile computer executable programs, and modules, such as the method for repairing program defects in kernel mode of an embedded system in Examples 1 and 2. Processor 11 executes the various functional applications and data processing of the apparatus for repairing program defects in kernel mode of an embedded system by running the non-volatile software programs, instructions, and modules stored in memory 12, thereby implementing the method for repairing program defects in kernel mode of an embedded system in Examples 1 and 2.

[0091] The memory 12 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state memory device. In some embodiments, the memory 12 may optionally include a memory remotely located relative to the processor 11, and such remote memory may be connected to the processor 11 via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0092] The program instructions / modules are stored in the memory 12. When executed by one or more processors 11, the method for repairing program defects in the embedded system kernel state in the above-mentioned embodiments 1 to 2 is executed. For example, the above-described method Figure 1-Figure 5 The steps shown.

[0093] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a disk or an optical disk, etc.

[0094] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention should be included in the scope of protection of the present invention.

Claims

1. A method for repairing program defects in kernel mode of an embedded system, characterized by: Pass the shared library containing the patch segment that the process needs to use to the kernel module, and the kernel module loads the shared library into the process space of the corresponding process; The kernel module obtains the addresses of the original memory segment and the patch segment corresponding to the patch segment in the memory control block, and replaces the address of the original memory segment in the memory control block with the address of the patch segment; The kernel module obtains the addresses of the original memory segment and the patch segment corresponding to the patch segment in the memory control block, specifically including: parsing the files where the original memory segment and the patch segment are located, and respectively obtaining the offset addresses of the original memory segment and the patch segment in the files; parsing the maps file of the process, and respectively obtaining the running base addresses of the modules where the original memory segment and the patch segment are located; using the running base address of the module where the original memory segment is located as the starting point, performing an offset according to the offset address of the original memory segment to obtain the virtual address of the original memory segment when it is running, and using the running base address of the module where the patch segment is located as the starting point, performing an offset according to the offset address of the patch segment to obtain the virtual address of the patch segment when it is running, and converting the virtual addresses of the original memory segment and the patch segment into kernel linear addresses.

2. The method for repairing program defects in kernel mode of an embedded system according to claim 1, characterized in that: The kernel module loads the shared library into the process space of the corresponding process, specifically including: Get the segment information of the patch segment to be used in the shared library, and read the patch segment into the virtual address space corresponding to the process; The kernel module obtains the corresponding memory control block according to the process control information of the process and writes the virtual address of the patch segment into the corresponding memory control block; Relocate the function to be repaired according to the virtual address of the patch segment.

3. The method for repairing program defects in kernel mode of an embedded system according to claim 2, characterized in that: Writing the virtual address of the patch segment into the corresponding memory control block specifically includes: The segment information of the patch segment is added to the memory control block of the process, and the virtual address of the patch segment is written into the corresponding segment information in the memory control block.

4. The method for repairing program defects in kernel mode of an embedded system according to claim 2, characterized in that: Also includes: Before obtaining the segment information of the patch segment to be used in the shared library, the process is suspended; After the function to be repaired is relocated, the process continues to execute.

5. The method for repairing program defects in kernel mode of an embedded system according to claim 1, characterized in that: The conversion of the virtual addresses of the original memory segment and the patch segment into kernel linear addresses specifically includes: Obtain the kernel virtual page table corresponding to the process through the process control information of the process and the address of the patch segment in the memory control block; Obtain the physical address of the patch segment based on the address of the patch segment in the memory control block and the information of the kernel virtual page table; Convert the physical address of the patch segment to a kernel linear address.

6. The method for repairing program defects in kernel mode of an embedded system according to claim 1, characterized in that: Also includes: Read the assembly instruction backup of the original memory segment according to the kernel linear address of the original memory segment; Replace the assembly instructions of the original memory segment with the assembly instructions of the patch segment.

7. The method for repairing program defects in kernel mode of an embedded system according to claim 1, characterized in that: Also includes: The kernel module obtains the process ID of the process and obtains the process control block and memory management unit of the process according to the process ID.

8. A device for repairing program defects in kernel mode of an embedded system, characterized by: The method comprises at least one processor and a memory, wherein the at least one processor and the memory are connected via a data bus, and the memory stores instructions that can be executed by the at least one processor, and after being executed by the processor, the instructions are used to complete the method for repairing program defects in the kernel state of the embedded system according to any one of claims 1 to 7.

Images