Patch repairing method, patch manufacturing method, related equipment and system

Abstract

The embodiment of the invention provides a patch repairing method, which comprises the following steps that: after downloading a patch file (generated through a static link), terminal equipment moves a binary code of a patch function to a patch area on an MCU (Microprogrammed Control Unit), and synthesizes a jump instruction based on an original function recorded in the patch file and a running address mapping relationship of the patch function; and inserting the jump instruction at an original function in a system mirror image (formed by static link) stored on the MCU, so that the jump instruction points to a patch function in a patch area, thereby repairing the kernel problem of the MCU. Wherein the patch area is a section of running address allocated in advance and does not conflict with the running address occupied by the existing system mirror image (formed by static link) on the MCU. Therefore, the problem of compatibility between the patch and the static link project is solved, a function level patch repair scheme of the full static link project is realized, and function level updating can be realized on the premise of supporting an MCU platform of a macro-kernel architecture without re-burning the whole system mirror image.

Description

Technical Field

[0001] The present application relates to the field of electronic technology, and in particular to a patch repair method, a patch production method, and related equipment and systems. Background Art

[0002] Static linking is when linking, linking each target module (code segment generated by compilation) and the library functions they depend on into a complete program, completing the relocation operation from the symbol to the running address, so that there is no need to load the dependent library and perform the relocation operation when running the program. Therefore, the program formed by static linking has the advantages of fast startup speed and fast running speed. However, once a module in the software project needs to be updated, even if only one function is updated, the entire project must be recompiled, which is not convenient for updating. Summary of the invention

[0003] The embodiments of the present application provide a patch repair method, a patch production method, related equipment and systems, which solve the compatibility problem between patches and static link projects, implement a function-level patch repair solution for full static link projects, and support function-level updates for MCU platforms with macro-kernel architectures without reburning the entire system image.

[0004] In a first aspect, an embodiment of the present application provides a patch repair method, which is applied to a terminal device, where a first image is running on the terminal device, and the first image is obtained by compiling and statically linking source code of a first software project;

[0005] The method may include: a terminal device downloads a patch file of a first software project from a server, the patch file including a protocol header, a function description table and binary data of the patch function; the function description table including: a running address of the patch function, a running address of an original function to be repaired by the patch function, and N bytes of machine code; the binary data of the patch function including variables referenced by the patch function, and instructions for instructing a program counter PC pointer to jump to the running address of a function that the patch function depends on; the terminal device moves the binary data of the patch function to a patch area, the patch area is a section of running address space, and does not conflict with the running address space storing the first image; the terminal device synthesizes a jump instruction based on the running address of the patch function, the jump instruction is used to instruct the PC pointer to jump to the running address of the patch function; the terminal device inserts the jump instruction into the running address of the original function; wherein N is a positive integer, and N is equal to the byte length of the jump instruction.

[0006] In the first aspect, the first image is the basic image mentioned in the subsequent embodiments, and the first software project is a software project built to obtain the basic image and subsequent new images, and is composed of a series of source code files.

[0007] Implementing the method of the first aspect can solve the compatibility problem between patches and static link projects, realize a function-level patch repair solution for full static link projects, and support function-level updates for MCU platforms with macro-kernel architecture without re-burning the entire system image.

[0008] In combination with the first aspect, in some embodiments, before the terminal device synthesizes the jump instruction based on the running address of the patch function, it can also verify and determine that the N bytes of machine code included in the function description table are the same as the N bytes of machine code read from the running address of the original function. Here, this verification is the "consistency check" mentioned in the subsequent embodiments. The specific details can be referred to in the subsequent embodiments, which will not be expanded here.

[0009] In combination with the first aspect, in some embodiments, the jump instruction includes a reserved bit, a jump bit and an address bit stored consecutively, wherein the address bit is after the jump bit, the address bit is used to store the running address of the patch function, the jump bit is used to store the second instruction under the first instruction set, and the second instruction is used to read the data stored in the address bit into the program counter PC register.

[0010] The byte length of the address bit and the jump bit can be the same as the minimum moving byte length of the PC pointer, for example, 4 bytes. The first instruction set can be a thumb instruction set. The second instruction can be a load register LDR instruction under the thumb instruction set: LDR PC, [PC, #0X0].

[0011] In combination with the first aspect, in some embodiments, the patch area may include: a first area and a second area; the first area is used to store initialization data of the patch function, and the second area is used to store running data of the patch function, the running data is the initial data that is decrypted, decompressed and then moved to the second area; the initialization data is the binary data of the patch function included in the patch file.

[0012] The first area and the second area may be the area A ( Figure 2 The ".patch_init" area shown in Figure ), area B ( Figure 2 The first area can also be used to store code instructions of the function PatchRegionInit, which is used to perform decryption, decompression, and movement to the second area. The running address of the function PatchRegionInit is recorded in the protocol header.

[0013] In combination with the first aspect, in some embodiments, when withdrawing a patch file, the terminal device may write N bytes of machine code in the function description table back to the original function running address, and move out the patch area to store the binary data of the original function.

[0014] In the second aspect, an embodiment of the present application provides a patch production method, which is applied to a server, and the method may include: the server incrementally compiles the source code of a first software project that has been modified based on a baseline version, and identifies difference functions; the difference functions include functions whose source code has been changed and functions that depend on functions whose source code has been changed; the server compiles the difference file to obtain a redirectable target file; the difference file refers to a source code file including the difference function, the difference file includes a first source code file, the original function in the first source code file is modified to a patch function, and the first source code file is written with code that redirects the patch function to a specified running address on a terminal device; the server statically links the redirectable target file to obtain a second image; the server records the running addresses configured for the original function and the patch function during static linking; the running address configured for the patch function is the specified running address; the server extracts the binary code of the patch function from the second image, and generates a patch file.

[0015] Among them, the patch file may include a protocol header, a function description table and binary data of the patch function; the function description table may include: the running address of the patch function, the running address of the original function to be repaired by the patch function, and N bytes of machine code; the binary data of the patch function includes variables referenced by the patch function, and instructions that instruct the program counter PC pointer to jump to the running address of the function that the patch function depends on; the N bytes of machine code are a backup of the N bytes stored at the running address of the original function.

[0016] In combination with the second aspect, in some embodiments, the designated running address is a running address in a patch area, which is pre-allocated by the server and does not conflict with the running address occupied by the first image running on the terminal device.

[0017] In combination with the second aspect, in some embodiments, the first image running on the terminal device is saved by the server as an archived image; before generating the patch file, the method may also include: the server uses the archived image to verify and confirm that the running address configured for each function in the second image is consistent with the running address configured for each function in the archived image.

[0018] In a third aspect, the present application provides a terminal device, which includes one or more microcontroller units MCU and one or more memories; wherein, the one or more memories are coupled to the MCU, and the one or more memories are used to store computer program codes, and the computer program codes include computer instructions. When the MCU executes the computer instructions, the terminal device executes the method described in the first aspect and any possible implementation method of the first aspect.

[0019] In a fourth aspect, the present application provides a server comprising one or more processors and one or more memories; wherein the one or more memories are coupled to the processor, and the one or more memories are used to store computer program code, and the computer program code comprises computer instructions, and when the processor executes the computer instructions, the server executes the method described in the second aspect and any possible implementation manner of the second aspect.

[0020] In the fifth aspect, an embodiment of the present application provides a chip system, which is applied to a terminal device, and the chip system includes one or more processors, which are used to call computer instructions so that the terminal device executes the method described in the first aspect and any possible implementation method of the first aspect.

[0021] In the sixth aspect, an embodiment of the present application provides a chip system, which is applied to a server, and the chip system includes one or more processors, which are used to call computer instructions to enable the server to execute the method described in the second aspect and any possible implementation method of the second aspect.

[0022] In a seventh aspect, the present application provides a computer-readable storage medium comprising instructions, which, when executed on a terminal device, enables the terminal device to execute the method described in the first aspect and any possible implementation manner of the first aspect.

[0023] In an eighth aspect, the present application provides a computer program product comprising instructions, which, when executed on a server, enables the server to execute the method described in the second aspect and any possible implementation of the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the background technology, the drawings required for use in the embodiments of the present application or the background technology will be described below.

[0025] Figure 1 Briefly shows how kpatch works;

[0026] Figure 2 The fully statically linked function-level patch repair solution provided by the embodiment of the present application is shown;

[0027] Figure 3 The patch file protocol provided by the embodiment of the present application is shown;

[0028] Figure 4 The state machine of the patch engine provided by the embodiment of the present application is shown;

[0029] Figure 5 The jump instruction format provided by the embodiment of the present application is shown;

[0030] Figure 6 The patch system provided by the embodiment of the present application is shown;

[0031] Figure 7 The terminal device provided by the embodiment of the present application is shown;

[0032] Figure 8 It shows the changes of data stored in MCU memory during the process of enabling the patch engine;

[0033] Fig. 9 The patch making server provided in the embodiment of the present application is shown;

[0034] Fig.10 The overall process of the patch repair method provided by the embodiment of the present application is shown;

[0035] Fig.11 The patch engine patching process and the function operation mechanism before and after patching are exemplified;

[0036] Fig.12 It is exemplified that the patch function module under static linking is an independent and complete loading module;

[0037] Fig.13 The patch making method provided by the embodiment of the present application is shown. DETAILED DESCRIPTION

[0038] The terms used in the following embodiments of the present application are only for the purpose of describing specific embodiments and are not intended to limit the present application.

[0039] Static linking is widely used by microcontroller unit (MCU) platforms that support macro kernel architecture because it completes the loading and relocation of dependent libraries before the program runs, and does not require high computer resources to run the program. Here, MCU platform refers to equipment or devices that use MCU, integrated circuit systems (such as multi-processor chips or motherboards), etc.

[0040] Different from the chips with powerful processing and storage capabilities in smart devices such as mobile phones, such as system on chip (SOC) that integrate multi-core processors (such as application processor (AP), neural network processing unit (NPU), graphic processing unit (GPU)) and large-capacity high read and write bandwidth memory, MCU is limited in resources and performance. MCU usually only contains a reduced specification central processing unit (CPU), necessary memory and peripherals (such as general purpose input output (GPIO) interface, serial port, timer, etc.), and these limited hardware resources are integrated on a chip. Due to the limitation of resources and performance, MCU operation has the following characteristics:

[0041] 1. It is difficult to support complex dynamic loading and memory mapping when running lightweight operating systems such as real-time operating systems (RTOS) without introducing additional framework mechanisms (such as dynamic linkers, virtual memory mechanisms, and ftrace frameworks);

[0042] 2. The system image is directly burned into the read-only memory (ROM). The CPU fetches instructions from the ROM for execution. A large amount of data modification will result in a long ROM writing time.

[0043] 3. The system images of MCU platforms are mostly statically compiled macro kernels and do not support dynamic linking.

[0044] Taking the above characteristics into consideration, updating the functions of the MCU platform, even if it is only a minor update, requires recompiling the entire system source code to generate a new version to replace the system image on the MCU platform, which is not suitable for frequent updates. In addition, erasing and rewriting the entire system image will cause large-scale write loss to the ROM on the MCU, and the writing time is also very long.

[0045] Therefore, it is urgent to introduce a function-level patch repair solution that can be applied to the MCU platform of the macro kernel architecture without recompiling the entire system source code.

[0046] Kpatch developed by Red Hat works at the function level: old functions are replaced by new ones. Kpatch implements real-time patching in the running kernel. Its working principle is as follows: Kpatch first converts the source diff patch into a patch module through kpatch-build. Specifically, Figure 1 As shown in (a), kpatch-build compiles the kernel with or without source patches (compiling relocatable target files), compares the binaries of the relocatable target files, such as identifying differences based on the executable and linkable format (ELF), and generates a patch module containing a new binary version of the function to be replaced. Then, kpatch hooks the mcount call instruction of the old function through the kernel ftrace subsystem to redirect calls to the old function to the new function. Figure 1 As shown in (b), when the old function is called, kpatch can redirect it to the new function through ftrace, jump table and kernel symbol table, so as to fix the kernel problem while the kernel is running.

[0047] Although it works at the function level, kpatch relies on the dynamic loading mechanism of the Linux driver and does not support the problem repair of statically linked projects. In addition, kpatch needs to rely on the kernel symbol table to solve the problem of redirecting new and old functions, and it is necessary to ensure that the kernel symbol table is correct; and kpatch relies on ftrace, which will cause the image to expand and make it difficult to port to a resource-constrained MCU platform.

[0048] The embodiment of the present application provides a patch repair method, which solves the compatibility problem between the patch and the static link project, realizes the function-level patch repair solution of the full static link project, and can support the MCU platform of the macro-kernel architecture to realize function-level update without re-burning the entire system image.

[0049] The patch repair solution provided in the embodiment of the present application is designed with emphasis on the following aspects.

[0050] (1) Function-level patch repair for full static linking

[0051] like Figure 2As shown, in the patch repair method, the patch file contains the running address mapping relationship between the repair object (original function, or old function) and the patch function (or new function). In the figure, "old funcAddr" and "newfuncAddr" represent the running address of the original function and the running address of the patch function respectively. After downloading the patch, the MCU platform can move the binary code of the patch function to the patch area, perform consistency verification, synthesize jump instructions, and then insert the jump instruction into the binary code of the original function to point to the patch function in the patch area, so as to repair the MCU kernel problem. The patch area is a section of MCU running addresses allocated in advance, such as a section of free ROM space on the MCU. The patch area does not conflict with the storage space occupied by the system image on the MCU, and therefore will not affect the system image on the MCU.

[0052] In this article, the running address refers to the address on the memory that supports the CPU to directly fetch instructions and run. The memory supports byte addressing of instructions, and the code instructions stored on it can be directly read and run by the CPU, which may include but is not limited to: read only memory (ROM), random access memory (RAM), pseudo static read access memory (PSRAM), etc.

[0053] like Figure 2 As shown, the patch file may also include the machine code "old cmd", which may be a backup of a section of machine code that would be occupied (covered) by the jump instruction at the original function entry, and its length depends on the length of the jump instruction, which is generally several bytes. In an embodiment of the present application, "old cmd" can be used for consistency verification, to verify whether the patch file is a patch for repairing the system image running on the MCU, if so, the consistency verification is successful; otherwise, the consistency verification fails. "Old cmd" can also be used for the recovery mechanism of patch revocation, that is, to write the machine code "old cmd" back to the original function entry to complete the image recovery when the patch is revoked, and to restore to the system image before the patch is loaded.

[0054] Figure 2 In the example, the basic image on the MCU platform may include a .data field, a .bss field, a .text field, and other fields, wherein the .text field is a code segment for storing machine instructions after the function code is assembled, such as machine instructions of function 1 and function 2.

[0055] The patch area may include two parts: area A (shown as ".patch_init" in the figure) and area B (shown as ".patch_run" in the figure). Area A is used to store the initialization data of the patch function, which comes directly from the binary data of the patch function in the patch file. It cannot be run yet and needs further decryption and decompression; area A can also be used to store the code instructions of the function PatchRegionInit. The function PatchRegionInit can be used to decrypt and decompress the initialization data of the patch function stored in area A to obtain the running data of the patch function (that is, the code instructions of the patch function that can be directly fetched and run by the CPU and the variables referenced by the patch function), and then move the running data of the patch function to area B; area B can be used to store the code instructions of the patch function and the variables referenced by the patch function moved by the function PatchRegionInit, and is also the place where the patch function is actually run.

[0056] Suitable, such as Figure 2 As shown, moving the binary code of the patch function to the patch area may include the following steps:

[0057] The first step is to move the original patch function binary data included in the patch file to area A;

[0058] The second step is to read the code instructions of the function PatchRegionInit, decrypt and decompress the original patch function binary code, and obtain initialization data that can be directly fetched and run by the CPU. Here, the initialization data may include: the code instructions of the patch function and the variables referenced by the patch function.

[0059] The third step is to move the initialization data to region B. The running address of the function PatchRegionInit is recorded in the "initaddr" field in the patch file protocol header.

[0060] (2) Patch File Protocol

[0061] The patch repair method provided in the embodiment of the present application is adapted to the characteristics of static linking, and an adaptive patch file is designed as the core middleware of the patch tool and the patch engine. The patch tool is a functional component running on the patch server for making patch files, and the patch engine is a functional component running on the terminal device for parsing patch files, performing consistency checks, synthesizing jump instructions, and function jumps.

[0062] like Figure 3 As shown, the patch file may include three parts: protocol header, function description table and binary code segment.

[0063] The protocol header part may include multiple fields: "initaddr" field, "ident" field, "OXEF" field, "magic" field, "version" field, "class" field, "endian" field, "machine" field, "chksum" field, "entsize" field, "num" field, "hot flag" field, "bsize" field, and "reserve" field.

[0064] Among them, the "initaddr" field can record the running address of the patchRegionInit function in the patch area; the "ident" field can be used for patch package identity identification, for example, to identify what chip architecture the patch file supports running on, the file type of the patch file, etc.; the "OXEF" field can be used to identify the legitimacy of the patch file. For example, if the value of this field is "OXEF", the terminal device considers that the patch file is a legal patch, otherwise the patch is abandoned. Of course, OXEF is only an example, and the value can be adjusted in actual applications. The "magic" field can be used to indicate the file type of the patch file. For example, when the value of this field is "quick fix", it can indicate that the file type is a patch file. The "version" field can be used to indicate the platform type to which the patch file is adapted, such as the ARM architecture platform or the X86 architecture platform; the "class" field can be used to indicate the machine type to which the patch file is applicable, such as a 32-bit or 64-bit machine type; the "endian" field can be used to indicate the word order that should be adopted by the machine to which the patch file is applicable, such as big-endian or little-endian; the "machine" field can be used to indicate the device type to which the patch file is applicable, and the "chksum" field can be a checksum to prevent the patch file from being tampered with; the "entsize" field can be used to indicate the size of each member in the function description table; the "num" field can be used to indicate the number of functions to be repaired; the "bsize" field can be used to indicate the size of the function binary code in the patch file; the "reserve" field is a reserved field, which is used depending on the actual application and is not restricted.

[0065] Among them, the "hot flag" field can be used to control the hot and cold mode of patch activation on the server side. For example, when hotflag is set to 1, the server sets the patch activation mode to hot patch mode. Hot patch refers to a patch that takes effect during system operation without restarting the system. When hot flag is set to 0, the server sets the patch activation mode to cold patch mode. For functions that are resident in system memory, cold patch mode can be used for repair. Cold patch refers to a patch that takes effect only after restarting the system. When the cold patch mode is used to repair the kernel, the loading of the patch file only depends on the file system, and its repair and adaptation range is wider. However, the loading of hot patches also requires the CPU to scan the function stack frame, and the CPU needs to be locked before inserting the jump instruction to prevent the original function from being in operation, but some interrupts will not be responded to during the locking period. Here, the function that is resident in system memory can refer to a function that will be in the task stack for a long time, such as a function that includes a loop. kpatch does not support repairing functions in the task stack, otherwise the system may crash due to inconsistencies before and after the function call.

[0066] The function description table can store the running address mapping relationship of one or more old functions and their corresponding new functions, such as Figure 3 The mapping relationship formed by multiple groups of oldAddr (indicating the running address of the old function) and newAddr (indicating the running address of the new function) shown in the figure can be used to synthesize jump instructions, and the instructions jump from the old function to the new function. The machine code "old cmd" can also be stored in the function description table for consistency verification and the recovery mechanism of the patch undo action. "Old cmd" can be a backup of a section of machine code that will be occupied (overwritten) by the jump instruction at the entrance of the original function. Its length is the same as the length of the jump instruction, which is generally several bytes. Since the patch package requires atomic access, it is safer to store "old cmd" in the patch file. In addition to backing up the several bytes occupied by the jump instruction at the entrance of the original function, "old cmd" can also be used to record the synthesis rules of the jump instruction. The instruction sets used by platforms with different architectures may be different, and therefore the instruction synthesis rules that need to be followed are different. For example, the instruction set used by the cortex-M architecture platform is the ARM and thumb instruction sets, the instruction set used by the X86 architecture platform is the X86 instruction set, and the instruction set architecture (ISA) architecture platform uses the fifth-generation reduced instruction set computer (RISC-V) instruction set, so that the terminal device can generate jump instructions according to the synthesis rules indicated by "oldcmd".

[0067] In addition, the function description table may also include reserved fields, the length of which depends on the byte alignment requirements. Of course, a few bits can also be extracted from it to mark patch update results (such as occupying 1 bit) and program execution results (such as occupying 2 bits).

[0068] The binary code segment can store the code segments of each patch function and the target modules they depend on, as well as the binary code of the referenced string variables. This part of the binary code will be moved to the pre-allocated patch area on the MCU platform. For example, Figure 3 As shown in , the binary codes of a patch function and its dependent target module ("ITCM_CODE_SECTION") and the strings they reference ("ITCM_STRING_SECTION") may be stored at 0x100A7000 to 0x100A8000 in the patch area.

[0069] (3) Patch Engine

[0070] The patch file enabling process requires the patch engine to perform loading actions, and its parsing process corresponds to the patch file protocol. The patch engine runs on the MCU platform and is the core function of the patch repair method provided by the embodiment of the present application. It loads the patch file after parsing the patch file according to the patch file protocol, which may specifically include: consistency check of the patch file, moving the binary code of the patch function to the patch area, inserting jump instructions, and executing function jumps (patch function runs successfully).

[0071] The patch engine presents the following states during the patch enabling process:

[0072] Idle state: No patch. At this time, the MCU platform has not downloaded the patch file and no update will occur.

[0073] Ready state: The consistency check of the patch file passes, and the binary code of the patch function is moved to the patch area.

[0074] Activated state: synthesize jump instructions and insert jump instructions into the binary code of the original function.

[0075] Running state: The patch function runs successfully.

[0076] Figure 4 Figure 2 shows the state machine of the patch engine, illustrating the switching between the above states. Figure 4 As shown:

[0077] When it is detected that the MCU platform has not downloaded the patch file, the patch engine is in an idle state.

[0078] In the idle state, once a patch download is detected, the patch engine can load the patch into the patch area and perform a consistency check on the patch. If the consistency check of the patch passes and it is successfully moved to the patch area, the patch engine enters the ready state.

[0079] In the ready state, the patch engine can synthesize a jump instruction based on the running address mapping relationship between the original function and the patch function, and insert the jump instruction at the binary code of the original function to instruct the program to jump to the patch function for execution. The jump can be implemented by assigning the program counter (PC) register with the running address of the binary code of the patch function. If the jump instruction is synthesized and inserted successfully, the patch engine enters the activated state. The PC register is used to save the address of the next instruction to be fetched, and its value is generally automatically increased by 4, that is, 4-byte alignment. The activated state is only a transient state, and once the jump instruction is inserted, it enters the running state.

[0080] In the running state, once the program runs to the original function, if the original function is called, the CPU in the MCU will read and execute the jump instruction inserted into the original function, thereby assigning the PC pointer to the target address pointed to by the jump instruction (that is, the running address of the patch function), so that the CPU will execute the instruction at the target address (that is, the binary instruction of the patch function) in the next step to run the patch function.

[0081] In the running state, the patch engine can move the binary code of the patch function out of the patch area to roll back to the idle state and withdraw to the base image. In addition, in the activated state, the patch engine can delete the jump instruction inserted in the original function and restore the several bytes covered by the jump instruction at the entry of the original function based on the "old cmd" to roll back to the ready state; and in the ready state, the patch engine can move the binary code of the patch function out of the patch area to roll back to the idle state. These state rollbacks can occur when the patch is revoked.

[0082] As mentioned above, through the complete state machine design, the patch engine can run more stably.

[0083] In order to further enhance the fault tolerance of the patch engine, the patch engine can be deployed in a dual-core image to jointly maintain the normal operation of the patch engine state machine. The dual-core image can be, for example, a normal operating system image (system.img) and an image loaded in recovery mode (such as recovery.img). When the system.img runs abnormally, the patch engine in system.img enters emergency mode. At this time, the MCU platform restarts and enters recovery mode, loads recovery.img, and the patch engine deployed in recovery.img runs, and then takes on the task of loading patch files to repair the kernel until system.img returns to normal.

[0084] For example, Figure 4 As shown in the figure, system operation abnormalities can occur in the idle state, ready state, and running state. Restart the MCU platform and use the patch engine deployed in recovery.img to ensure Figure 4 The state machine runs normally to achieve uninterrupted patch repair and patch cancellation.

[0085] (4) Function-level jump design under the thumb instruction set

[0086] The jump instruction can be inserted into the binary code of the original function by the patch engine, for example, after the .init segment. The jump instruction implements the function jump by assigning the running address of the patch function to the PC register. For example, the implementation of the jump instruction can be based on a load register (LDR) instruction under the thumb instruction set, such as "LDR PC, [R1]", where the data stored at the storage address R1 is the running address of the patch function (which can be marked as "newAddr"). The LDR instruction can be used to read the data at the storage address R1 into the PC register to point to the next instruction of the CPU, that is, the code instruction at "newAddr", that is, the code instruction of the patch function.

[0087] In this way, the jump instruction design provided in the embodiment of the present application only changes the PC register, does not change the stack frame of the original function, and does not change the values ​​of other registers, thereby realizing function-level unconditional jumps. Unlike kpatch, it does not rely on the ftrace framework and kernel symbol table to realize the jump between new and old functions.

[0088] Furthermore, in order to achieve the purpose of compact instruction and small space occupation, the jump instruction format can be as follows Figure 5As shown, it includes the following parts: alignment bit, jump bit and address bit. Among them, the jump bit stores the LDR instruction, the address bit stores the running address of the patch function ("newAddr"), and the alignment bit exists depending on the instruction alignment requirements. In addition, the address bit follows the jump bit, and their lengths can be the minimum number of bytes moved by the PC pointer, that is, it depends on the byte alignment of the instruction address, such as the address bit and the jump bit are both 4 bytes under 4-byte alignment. For this reason, the LDR instruction stored in the jump bit can be specifically: LDR PC, [PC, #0X0], and the LDR instruction indicates that the data at the address offset of the PC pointer 0X0 is read into the PC register. Since when the CPU runs the LDR instruction in the jump bit, the PC pointer has moved to the next 4 bytes and points to the first address of the address bit, therefore, the LDR instruction essentially indicates that the running address of the patch function stored in the address bit is read into the PC register, so as to point the code instruction of the patch function stored at the running address to the next instruction of the CPU, thereby realizing the function jump. In this way, through the ingenious design of the jump instruction format, not only the jump instruction itself is compact and occupies little space, but also the CPU execution action is streamlined. After the jump instruction is inserted into the original function, the CPU does not need to perform additional actions for the function jump, and the stack and other registers do not need to be specially modified for this purpose.

[0089] Next, the product for patch repair provided in the embodiment of the present application is introduced.

[0090] Patch System 100

[0091] Figure 6 FIG. 1 shows a patch system 100 provided in an embodiment of the present application. Figure 6 As shown, the patch system 100 may include: a terminal device 200, a patch making server 300, and a patch distribution server 400. The patch making server 300 may be used to make a patch file in accordance with the patch file protocol, and then deploy it to the patch distribution server 400; the patch distribution server 400 may be used to distribute the patch to the terminal device 200; the terminal device 200 may be used to download the patch file and enable the patch engine to perform function-level patch repair on the MCU kernel program.

[0092] The terminal device 200 can use an MCU as a co-processor to reduce the burden of the main core processor, reduce power consumption, and improve the endurance of the device. The patch production server 300 and the patch distribution server 400 can be integrated into one, and the two can be collectively referred to as patch servers.

[0093] Regarding the specific operations performed by the terminal device 200, the patch production server 300, and the patch distribution server 400, please refer to the descriptions in the previous and following texts, which will not be expanded here.

[0094] Terminal device 200

[0095] Figure 7 The terminal device 200 provided in the embodiment of the present application is shown. The terminal device 200 may be a wearable product including an MCU (such as a smart watch, a sports watch, a heart rate belt, etc.), an Internet of Things (IoT) product, a robotic arm, a smart car, etc. Figure 7 As shown, the terminal device 200 may include: a main processor 110, an MCU 120, a memory 130, a display screen 140, a wireless communication module 150, a sensor 160, etc. These components may be coupled via a bus.

[0096] The main processor 110 can be a processor with powerful processing capabilities and rich storage and peripheral resources, such as an application processor (AP), a neural network processing unit (NPU), a graphics processing unit (GPU), a modem processor, etc., or it can be a system on chip (SOC) that integrates multiple processors.

[0097] The main processor 110 may include one or more interfaces, such as an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general purpose input and output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0098] The main processor 110 may be provided with a cache memory, which can be used to store instructions or data just used or cyclically used by the main processor 110. If the main processor 110 needs to use the instruction or data again, it can be directly called from the cache memory, which can reduce the waiting time of the main processor 110 and improve the program running efficiency.

[0099] The main processor 110 can also be connected to the memory 130 externally. The memory 130 may include a program storage area and a user data storage area, wherein the program storage area may store an operating system and one or more application programs (such as a camera application, a phone application), and the data storage area may store data (such as photos, contacts) created by the user in the process of using the terminal device 200. The memory 130 may be a high-speed random access memory or a non-volatile memory, such as a disk, a flash memory, a universal flash storage (UFS), etc. The memory 130 may also be an external memory card, such as a Micro SD card.

[0100] MCU120 may include a CPU with reduced specifications, necessary memory and peripherals, such as read only memory (ROM), random access memory (RAM), pseudo static read access memory (PSRAM), general purpose input and output (GPIO) interface, serial port, timer, etc. MCU120 may also be externally connected to memory 130 to store patch files downloaded by terminal device 200 from patch distribution server 400. MCU120 may be used as a coprocessor of main processor 110 to assist main processor 110 in completing processing tasks that it cannot perform or performs inefficiently, such as signal transmission between devices, management of access devices, Bluetooth communication management, graphics processing, audio processing, etc., so as to reduce the burden of main processor, reduce power consumption, and improve the endurance of equipment. For example, when the terminal device 200 is in low power mode, the main processor 110 enters sleep mode to save power consumption; at this time, the MCU 120 can monitor whether there is a touch signal from the touch-sensitive sensor set on the display screen 140, which can be generated by the user's touch operation. If there is a touch signal, the main processor 110 is awakened to light up the display screen 140 to display the lock screen interface. For another example, in low power mode, when the main processor 110 is asleep, the MCU 120 interacts with the Bluetooth module to monitor the Bluetooth communication status. When the Bluetooth is disconnected or a nearby device is found, the main processor 110 is awakened to light up the display screen 140 to display some reminder messages or user interaction interfaces so that the user can know or adjust the Bluetooth status.

[0101] The main processor 110 and the MCU 120 can run different tasks relatively independently, and the two can be isolated from each other and run different operating systems or bare metal programs. For example, the main processor 110 runs the Linux operating system, and the MCU 120 runs a lightweight operating system such as a real-time operating system (RTOS). The two can communicate through a bus, shared memory, etc. Although the main processor 110 and the MCU 120 run different systems, the main processor 110 can be used as the main core to control the normal operation of the entire device. For example, the Linux operating system running on the main processor 110 can be loaded with an MCU driver to control the operation of the MCU.

[0102] The terminal device 200 can realize complex display through the main processor 110 (such as AP, GPU) and the display screen 140, such as real-time refresh of the game application interface, preview screen display of the camera application, and update interface following user touch operation. The terminal device 200 can also realize simple display through the MCU120 and the display screen 140, such as only displaying the current time in low power mode. The display screen 140 can be used to display images, videos, etc. The display screen 140 can be a liquid crystal display (LCD), an organic light-emitting diode (OLED) display screen, an active matrix organic light-emitting diode or an active matrix organic light-emitting diode (AMOLED) display screen, a flexible light-emitting diode (FLED) display screen, a quantum dot light-emitting diode (QLED) display screen, etc.

[0103] The wireless communication module 150 may include wireless communication modules such as 2G / 3G / 4G / 5G, wireless fidelity (Wi-Fi) communication module, bluetooth (BT) communication module, global navigation satellite system (GNSS) communication module, frequency modulation (FM) communication module, near field communication (NFC) communication module, infrared (IR) communication module, etc. The wireless communication module 150 may also be a communication device integrating multiple communication processing modules. The wireless communication module 150 receives electromagnetic waves via an antenna, modulates and filters the electromagnetic wave signals, and sends the processed signals to the main processor 110 or MCU120. The wireless communication module 150 may also receive signals to be sent from the main processor 110 or MCU120, modulate the frequency of the signals, amplify the signals, and convert them into electromagnetic waves for radiation via the antenna.

[0104] Among them, the received signals of the 2G / 3G / 4G / 5G wireless communication module and the Wi-Fi communication module are also demodulated into low-frequency baseband signals by the modem processor and then transmitted to the baseband processor for processing. The low-frequency baseband signals are processed by the baseband processor and then transmitted to the main processor 110. The main processor 110 outputs sound through an audio device (not limited to a speaker, a receiver, etc.) or displays an image or video through a display screen. The signals to be sent by the 2G / 3G / 4G / 5G wireless communication module and the Wi-Fi communication module are also modulated into medium and high frequency signals by the modem processor and then transmitted through the antenna.

[0105] The sensor 160 may include a gyro sensor, an acceleration sensor, a pressure sensor, a proximity light sensor, an ambient light sensor, a temperature sensor, a distance sensor, and a touch-sensitive sensor disposed on the display screen 140 , and the like.

[0106] Figure 7The schematic structure does not constitute a limitation on the terminal device 200. The terminal device 200 may include more or fewer components than shown in the figure, or combine certain components, or split certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware. For example, the terminal device 200 may also not have a main processor 110, but only have an MCU 120 as a computing core; correspondingly, the wireless communication module 150 may only be a Bluetooth communication module, and does not include a high data rate, remote communication module such as a wifi module, a 2G / 3G / 4G / 5G module, and the sensor 160 may only be a sensor with a low sampling rate and low algorithm requirements such as a light sensor and a temperature sensor, so as to adapt to the simple processing capabilities that can be provided by only using the MCU as a computing core.

[0107] The ROM of MCU120 may store a statically linked program image, which may include an RTOS and one or more bare metal applications or functional programs running thereon. The program code of the patch repair method provided in the embodiment of the present application may also be statically linked to the program image to support the MCU120 to execute the patch engine function. The CPU in MCU120 directly reads the statically linked code instructions stored in ROM, RAM, etc. and runs the code instructions.

[0108] In addition, a portion of the free ROM space on MCU120 can be reserved as a patch area. After the terminal device 200 downloads the patch file, the binary code of the patch function can be moved to the patch area for storage. The patch area is not occupied by the statically linked original program image (also known as the base image), so the patch repair method provided in the embodiment of the present application will not affect the base image, ensuring the normal operation of MCU120.

[0109] The ROM that stores the program image and reserves the patch area can support byte addressing of instructions. The function code stored on it can be directly executed by the CPU without being loaded into RAM for execution. This article calls this instruction fetching and execution mode "on-chip instruction fetching (or on-chip execution)".

[0110] Figure 8 FIG. 2 shows the changes of data stored in the memory of MCU 120 during the process of enabling the patch engine. Figure 8 As shown, this change can be presented in the following three stages:

[0111] 1. Before downloading the patch file.

[0112] At this time, the base image is stored on the ROM, and the .text segment of the base image includes code segments of multiple functions such as function 1 and function 2. Among them, function 1 and function 2 are the objects to be repaired. Specifically, the storage address of function 1 to be repaired is marked as "oldAddr1", and the storage address of function 2 to be repaired is marked as "oldAddr2". "oldAddr1" and "oldAddr2" are also the running addresses of function 1 and function 2 before the patch repair, that is, the CPU directly fetches instructions from this address to run function 1 and function 2.

[0113] 2. Download the patch file and move the patch function to the patch area.

[0114] After downloading the patch file, the binary part of the patch function in the patch file is moved to the patch area by the patch engine. The patch functions include the patch function of function 1 and the patch function of function 2. In the patch area, the binary code of the patch function of function 1 is stored at the address "newAddr1", and the binary code of the patch function of function 2 is stored at the address "newAddr2". "newAddr1" and "newAddr2" will become the running addresses of function 1 and function 2 after the patch repair, that is, the CPU directly fetches instructions from this address to run the patch function of function 1 and the patch function of function 2.

[0115] Compared with before downloading the patch file, the change in the data stored in the MCU's memory is that the patch area on the ROM has changed from being free to storing data, and data must be written to the two locations "newAddr1" and "newAddr2" in the patch area. "newAddr1" and "newAddr2" are the running addresses of the patch function recorded in the function description table of the patch file. In addition to this data storage change, the data stored in the RAM will also increase, and there will be more variables referenced by the patch function.

[0116] 3. Insert a jump instruction at the function to be repaired.

[0117] After the patch function is moved to the patch area and passes the consistency check, the patch engine can insert a jump instruction into the binary code of the function 1 and function 2 to be repaired. Specifically, the jump instruction inserted into the function 1 to be repaired can be: LDR PC, [PC, #0x0], and the running address "newAddr1" of the patch function of function 1 is stored immediately after the jump instruction, and its value is also recorded in the function description table of the patch file. The jump instruction inserted into the function 2 to be repaired can also be: LDR PC, [PC, #0x0], and the running address "newAddr2" of the patch function of function 2 is stored immediately after the jump instruction, and its value is also recorded in the function description table of the patch file.

[0118] Compared with the previous stage, the data stored in the MCU's memory has changed. The data stored at "oldAddr1" and "oldAddr2" are no longer the binary codes of function 1 and function 2 to be repaired, but have become the jump instruction "LDR PC, [PC, #0x0]" and the following "newAddr1" and "newAddr2". The data stored after the jump instruction is consistent with the running address of the patch function recorded in the function description table of the patch file, and the data characteristics are very distinct.

[0119] Patch Production Server 300

[0120] Fig. 9 FIG. 3 shows a patch making server 300 provided in an embodiment of the present application. Fig. 9 As shown, the patch making server 300 may include: a central processing unit (CPU) 210, a memory 220, an input and output device 230, a communication module 240, etc. These components may be coupled via a bus.

[0121] The central processing unit (CPU) 210 is the computing core of the patch making server 300 and has powerful computing capabilities. It is coupled to the memory 220 and can be used to read and execute computer-readable instructions in the memory 220, and run the operating system and various programs. Specifically, the CPU 210 can be used to call the program stored in the memory 220, such as the implementation program of the patch making method provided in the embodiment of the present application, and execute the instructions contained in the program. The patch making method will be expanded in the subsequent embodiments, and will not be described here in detail.

[0122] The memory 220 may include a high-speed random access memory, a non-volatile memory, such as a disk, a flash memory or other non-volatile solid-state storage device. The memory 220 may be used to store various software programs and multiple sets of instructions. The memory 220 may store an operating system, such as an operating system such as Linux. The memory 220 may also store one or more programs, such as programs involved in patch production, such as a compiler and a linker. The memory 220 may also store an implementation program of the patch production method provided in an embodiment of the present application, which may be used to produce a patch file in accordance with the aforementioned patch file protocol and transmit the patch file to the patch distribution server 400.

[0123] CPU210 can also be built with a high-speed cache memory, which can be used to store instructions or data that CPU210 has just used or circulated. If CPU210 needs to use the instruction or data again, it can be directly called from the high-speed cache memory, which can reduce the waiting time of CPU210 and improve program operation efficiency.

[0124] CPU210 may include one or more interfaces, such as an inter-integrated circuit (I2C) interface, an inter-integrated circuit sound (I2S) interface, a pulse code modulation (PCM) interface, a universal asynchronous receiver / transmitter (UART) interface, a mobile industry processor interface (MIPI), a general input output (GPIO) interface, a subscriber identity module (SIM) interface, and / or a universal serial bus (USB) interface, etc.

[0125] The input and output devices 230 may include a display screen, a keyboard, a mouse and other devices, which can be used to receive user input and output program execution results to the user.

[0126] The communication module 240 may include a wired communication module and a wireless communication module. Among them, the wired communication module may support wired communication protocols, such as universal serial bus (USB), serial port, Ethernet and other protocols, and communicate with other devices through physical communication cables. The wireless communication module may include 2G / 3G / 4G / 5G and other wireless communication modules, Wi-Fi communication modules, etc. The wireless communication module receives electromagnetic waves via an antenna, modulates and filters the electromagnetic wave signals, and sends the processed signals to CPU210; the wireless communication module may also receive signals to be sent from CPU210, modulate them, amplify them, and convert them into electromagnetic waves for radiation through the antenna.

[0127] Fig. 9 The illustrated structure does not constitute a limitation on the patch making server 300. The patch making server 300 may include more or fewer components than shown in the figure, or combine some components, or separate some components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0128] The architecture of the patch distribution server 400 provided in the embodiment of the present application may be similar to or the same as the architecture of the patch production server 300, and the composition of the patch distribution server 400 will not be expanded below. However, this does not mean that this article limits the patch distribution server 400 to be the same as the patch production server 300. The two have different functional focuses, and their respective hardware and software compositions may therefore be different. For example, the patch production server 300 may have multiple display screens to facilitate patch developers to make patches; and the display screens may be omitted on the patch distribution server 400. For another example, in Fig. 9 When the device structure shown is implemented as a patch distribution server 400, the memory 220 can store a patch distribution program, which can be used to distribute patch files to one or more terminal devices; the CPU 210 can be used to read and execute computer-readable instructions in the memory 220 to execute the patch distribution method.

[0129] Based on the above-mentioned product for patch repair, the patch repair method provided in the embodiment of the present application is described in detail below.

[0130] Fig.10 The overall process of the patch repair method provided by the embodiment of the present application is shown.

[0131] S31. The patch making server makes a patch file in accordance with the aforementioned patch file protocol.

[0132] The method of making patch files is in Fig.12 This will be described in detail in the embodiments and will not be elaborated here.

[0133] S32. After creating the patch file, the patch creation server may send the patch file to the patch distribution server.

[0134] S33. The terminal device can download the patch file from the patch distribution server.

[0135] S34. The terminal device parses the patch file according to the aforementioned patch file protocol to obtain the protocol header, function description table and binary code of the patch function included in the patch file.

[0136] The function description table may include the running address configured for the original function and its patch function during static linking, as well as the machine code "old cmd". "Old cmd" may be a backup of multiple bytes at the entry of the original function, which will be occupied (overwritten) by jump instructions during subsequent patching. The binary code of the patch function is an independent loading module formed by static linking of the patch function and other functions it depends on. It is independent of the base image loaded into the MCU memory and will not damage the existing base image on the MCU.

[0137] The protocol header may include a field "hot flag", which can be used to indicate the hot or cold mode of patch activation. For example, when the hot flag is set to 1, the server sets the patch activation mode to hot patch mode; when the hot flag is set to 0, the server sets the patch activation mode to cold patch mode. If the patch activation mode indicated by the hot flag is the cold patch mode, the subsequent steps can be executed when the device is restarted, that is, the patch can be applied when the device is restarted.

[0138] S35. The terminal device moves the binary code of the patch function to the patch area.

[0139] The patch area is a section of MCU memory pre-allocated by the patch production server, such as a free ROM space on the MCU. It supports byte addressing of instructions, and the code instructions stored on it can be directly read and run by the CPU. The patch area does not conflict with the storage space occupied by the system image stored on the MCU, so it will not affect the system image on the MCU.

[0140] Generally, before generating a base image for a certain model of MCU platform through static linking, the patch production server has already learned which memories the MCU platform has and how much running address space it can provide, and it needs to complete the relocation operation from symbols to running addresses during static linking, so it also knows which running addresses are occupied by the base image and which running addresses are free and can be used as patch areas. Therefore, when the patch production server generates a patch file through static linking, it can configure the patch function to the specified running address of the patch area. In this way, after the terminal device downloads the patch file, according to the running address of the patch function recorded in the function description table (marked as "newAddr"), the binary code of the patch function can be moved to the patch area, specifically to the running address indicated by "newAddr".

[0141] S36. The terminal device performs a consistency check on the patch file based on the "old cmd" field in the function description table.

[0142] Specifically, the terminal device can read multiple bytes at the original function entry from the original function running address recorded in the function description table, such as an eight-byte or sixteen-byte instruction, and then perform a binary comparison between these multiple bytes and the "old cmd" in the function description table. If the comparison results are consistent, it is determined that the consistency check has passed, indicating that the patch file is used to repair the base image on the MCU; otherwise, it is determined that the consistency check has failed. The length of the multiple bytes read from the original function entry is the same as the length of "old cmd", that is, the same number of bytes are read from the original function entry as the number of bytes of "old cmd".

[0143] S37. If the consistency check passes, the terminal device can synthesize a jump instruction based on the running addresses of the original function and the patch function recorded in the function description table and insert the jump instruction into the binary code of the original function.

[0144] Here, the specific implementation of inserting a jump instruction at the binary code of the original function can be to use the jump instruction to occupy (cover) multiple bytes at the entry of the original function, such as an eight-byte or sixteen-byte instruction, so that once the original function is called, the jump instruction will be executed.

[0145] The implementation of the jump instruction can be based on the LDR instruction under the thumb instruction set, such as "LDR PC, [R1]", where the data stored at the storage address R1 is the running address of the patch function. The LDR instruction can be used to read the data at the storage address R1 (i.e., the running address of the patch function) into the PC register to point to the next instruction of the CPU, i.e., the code instruction of the patch function. Such a jump instruction design only changes the PC register, does not change the values ​​of other registers, does not affect the normal operation of the system, and realizes real-time patching for static link projects.

[0146] Furthermore, in order to achieve the purpose of compact instructions and small space occupation, the running address of the patch function can be stored immediately after the jump bit. For example, of the 8 bytes at the entrance of the original function, the first 4 bytes (also called jump bits) can be used as jump bits (to store LDR instructions), and the last 4 bytes (also called address bits) can be used to store the running address of the patch function to reuse the running address occupied by the original function.

[0147] After the jump instruction is inserted, once the system or program on the MCU calls the original function when running, the jump instruction inserted at the entry of the original function will be executed by the CPU to jump to the patch function stored in the patch area.

[0148] Fig.11 The patch engine patching process and the function operation mechanism before and after patching are exemplified.

[0149] (1) Patching

[0150] like Fig.11 As shown, the patching process may specifically include:

[0151] Step 1. Patch loading: The patch engine moves the binary code in the patch file to the patch area.

[0152] Step 2. Consistency check. The patch engine performs a binary comparison between the machine code "old cmd" recorded in the function description table of the patch file and several bytes at the entry of the original function. If the comparison result is consistent, it is determined that the consistency check has passed, indicating that the patch file is used to repair the basic image on the MCU; otherwise, it is determined that the consistency check has failed.

[0153] For other details about consistency checking, please refer to the previous article, which will not be repeated here.

[0154] Step 3. Synthesize jump instructions.

[0155] The running address of the patch function recorded in the function description table of the patch file is the key to synthesizing the jump instruction. For how to synthesize the jump instruction, please refer to the previous article, which will not be repeated here.

[0156] Step 4. Before inserting the jump instruction, the patch engine stops all running processes and interrupts to ensure that the original function will not be executed when the jump instruction is inserted.

[0157] For example, the patch engine can call the stop machine to stop all running processes and interrupts, and traverse the return value of the stop machine to check whether the original function to be repaired is running. If not, the patch can be safely applied; otherwise, the patch is exited. This is also a precondition detection for patching.

[0158] Step 5. Insert jump instructions. The patch engine inserts jump instructions into the binary code of the original function, specifically replacing several bytes at the entry of the original function with jump instructions.

[0159] (2) Function execution before patching

[0160] When the original function is called, the CPU reads and executes the code instructions from the original function's running address. At this time, the code instructions stored at the original function's running address are the code instructions of the original function, and a separate stack frame is maintained on the call stack for this call to save the function's return address and parameters, temporary variables, and the context of the function call, etc. After the original function is executed, the CPU writes the return value of the original function to the return address recorded in the stack frame.

[0161] (3) Function execution after patching

[0162] When the original function is called, the CPU will still read and execute the code instructions from the running address of the original function, but the code instructions read at this time are jump instructions inserted into the original function, and the execution result is to jump to the patch function. The CPU will still maintain a stack frame for the original function call. After running the patch function, the return value of the patch function is written to the return address recorded in the stack frame. It can be seen that the operation of the patch function also reuses the stack frame maintained by the CPU for the original function. The CPU does not need to be aware of the existence of the patch function, and does not need to perform additional actions for the function jump, and the stack does not need to be specially modified for this purpose.

[0163] Since the binary code of the patch function stored in the patch area is generated by static linking, it already includes the variables referenced by the patch function, as well as instructions that instruct the program counter PC pointer to jump to the running address of the function that the patch function depends on (such as JSR assembly instructions) and other necessary information for static linking. There is no need to rely on or require the kernel to provide dynamic linking, and link to the variables referenced by the patch function and the functions it depends on based on the kernel symbol table. Function-level unconditional jumps can be implemented. For a simple example, suppose the patch function calls function B, and function B calls function C. Fig.12 As shown in the figure, after static linking, the patch function module will record and point to the running addresses of functions B and C that the patch function depends on, such as pointing to functions B and C through the "JSR'L'" and "JSR'M'" instructions, where "L" and "M" are the running addresses of functions B and C respectively. In this way, after downloading the patch file, the terminal device does not need to locate and load other functions and referenced variables that the patch function depends on based on the dynamic linker and kernel symbol table. However, kpatch patching needs to rely on the dynamic link provided by the kernel, and the jump of the new function also needs to rely on the ftrace framework and kernel symbol table.

[0164] Fig.13 The patch making method provided by the embodiment of the present application is shown.

[0165] S51. After the developer modifies a function on the baseline version, the patch making server may incrementally compile the entire modified source code file and identify the difference functions.

[0166] Here, the difference function is the modified function, which may include: the function whose source code is modified, and the function affected by the function whose source code is modified, such as the function that depends on the function whose source code is modified. The function whose source code is modified is the original function repaired by the patch function. In this way, the patch making server can recompile only the modified part of the source code (S52), and statically link to obtain the patch file, which can reduce the patch size.

[0167] The baseline version includes multiple source code files, such as the source code files of the operating system and one or more application programs. The baseline version is a stable version of the software project and is the basis for further development.

[0168] Incremental compilation is relative to full compilation. Incremental compilation means that when a local source program of a software project is changed, the recompilation work is limited to the modified part and the content of the related parts, without the need to compile the entire source code.

[0169] S52. The patch making server may merge the difference file into the baseline version for recompiling to obtain a redirectable target file. The difference file refers to a source code file including a difference function.

[0170] The difference file including the patch function also contains code to redirect the patch function to the specified running address on the terminal device. Therefore, the target file (redirectable target file) of the patch function generated by this recompilation will include the redirection information of the patch function so that the linker can configure the patch function to the specified running address on the MCU.

[0171] S53. The patch making server performs static linking and configures the target file (target module) of the patch function to the specified running address of the MCU during static linking.

[0172] The specified running address is the running address in the patch area, and does not conflict with the running address occupied by the system image on the MCU. The patch area is a section of MCU running address pre-allocated by the patch production server, such as a free address on the MCUROM. It supports byte addressing of instructions, and the code instructions stored on it can be directly read and run by the CPU. The patch area does not conflict with the running address space occupied by the image already stored on the MCU, and will not damage the existing image on the MCU.

[0173] During static linking, the patch production server will configure the running address for each target module through the linker, that is, perform redirection. Since the running address of the patch function is additionally configured by the patch production server before compilation and linking, it is not fully handled by the compiler and linker as in traditional compilation and static linking. Therefore, the patch function can exist independently of the system image and is not coupled to the system image, avoiding the need to re-burn the entire system image. In traditional compilation and static linking, after a function update occurs, the compiler and linker will re-configure the running address for each function in the entire software project based on the running address space on the MCU, which may cause the newly configured running address for each function to be inconsistent with the running address occupied by each function in the base image on the MCU, resulting in the requirement to re-burn the entire system image.

[0174] S54. The patch making server records the running addresses configured for the original function and the patch function during static linking.

[0175] The system image applied to the MCU will be saved as an archive image.

[0176] Before S54, the patch production server can also use the archived image to verify the image generated by the new compilation link (S52-S53) to confirm whether the running address configured for each function in the newly generated image is consistent with the running address configured for each function in the archived image, so as to ensure that the subsequent steps are executed under the premise of consistency, thereby ensuring that: after the patch file is downloaded to the MCU, the patch function can be correctly inserted into the original function, and the functions and referenced variables that the patch function depends on can be correctly located, ultimately ensuring the normal operation of the patch function.

[0177] S55. The patch making server extracts the binary code of the patch function from the statically linked image and generates a patch file. In addition to the binary code of the patch function, the patch file also includes a function description table and a protocol header, wherein the function description table includes the original function recorded in S54, the running address of the patch function, and the machine code "old cmd".

[0178] "old cmd" can be a backup of a section of machine code that will be occupied (covered) by the jump instruction at the entry of the original function. Its length depends on the length of the jump instruction, which is generally several bytes. For the description of the protocol header, please refer to the previous article and will not be repeated here.

[0179] As mentioned above, since the binary code of the patch function is generated through static linking, it already includes the necessary information for static linking, such as the variables referenced by the patch function and the instructions (such as JSR assembly instructions) that instruct the program counter PC pointer to jump to the running address of the function that the patch function depends on. There is no need to rely on or require the kernel to provide dynamic linking and link to the variables referenced by the patch function and the dependent functions based on the kernel symbol table, and function-level unconditional jumps can be achieved.

[0180] The steps of the method or algorithm described in conjunction with the disclosure of the embodiments of the present application can be implemented in a hardware manner, or can be implemented by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in RAM, flash memory, ROM, erasable programmable read-only memory (Erasable ProgrammableROM, EPROM), electrically erasable programmable read-only memory (Electrically EPROM, EEPROM), registers, hard disks, mobile hard disks, read-only compact disks (CD-ROMs) or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and can write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC. In addition, the ASIC can be located in a transceiver or a relay device. Of course, the processor and the storage medium can also be present in a wireless access network device or a user device as discrete components.

[0181] Those skilled in the art should be aware that in one or more of the above examples, the functions described in the embodiments of the present application can be implemented with hardware, software, firmware, or any combination thereof. When implemented using software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium. Computer-readable media include computer storage media and communication media, wherein the communication media include any media that facilitates the transmission of a computer program from one place to another. The storage medium can be any available medium that a general or special-purpose computer can access.

[0182] The above specific implementation methods further explain in detail the purpose, technical solutions and beneficial effects of the embodiments of the present application. It should be understood that the above are only specific implementation methods of the embodiments of the present application and are not used to limit the protection scope of the embodiments of the present application. Any modifications, equivalent substitutions, improvements, etc. made on the basis of the technical solutions of the embodiments of the present application should be included in the protection scope of the embodiments of the present application.

Claims

1. A patch repair method, applied to a terminal device, characterized in that: The terminal device is running a first image, the first image is obtained by compiling and statically linking source code of a first software project, and the method includes: The terminal device downloads a patch file of the first software project from a server, wherein the patch file includes a protocol header, a function description table, and binary data of a patch function; the function description table includes: a running address of the patch function, a running address of an original function to be repaired by the patch function, and N bytes of machine code; the binary data of the patch function includes variables referenced by the patch function, and instructions for instructing a program counter PC pointer to jump to a running address of a function on which the patch function depends; The terminal device moves the binary data of the patch function to a patch area, where the patch area is a running address space and does not conflict with the running address space storing the first image; The terminal device synthesizes a jump instruction based on the running address of the patch function, wherein the jump instruction is used to instruct a PC pointer to jump to the running address of the patch function; The terminal device inserts the jump instruction into the running address of the original function; Wherein, N is a positive integer, and N is equal to the byte length of the jump instruction.

2. The method according to claim 1, characterized in that Before the terminal device synthesizes the jump instruction based on the running address of the patch function, the method further includes: Verify and determine that the N bytes of machine code included in the function description table are the same as the N bytes of machine code read from the execution address of the original function.

3. The method according to claim 1 or 2, characterized in that The method as claimed in claim 1 is characterized in that the jump instruction includes a reserved bit, a jump bit and an address bit stored continuously, wherein the address bit is after the jump bit, the address bit is used to store the running address of the patch function, the jump bit is used to store the second instruction under the first instruction set, and the second instruction is used to read the data stored in the address bit into the program counter PC register.

4. The method according to claim 3, characterized in that The byte lengths of the address bit and the jump bit are the same as the minimum moving byte length of the PC pointer.

5. The method according to claim 3 or 4, characterized in that The first instruction set is a thumb instruction set.

6. The method according to any one of claims 2 to 5, characterized in that The second instruction is a load register LDR instruction: LDR PC, [PC, #0X0].

7. The method according to any one of claims 1 to 6, characterized in that The patch area includes: a first area and a second area; the first area is used to store the initialization data of the patch function, and the second area is used to store the running data of the patch function, the running data is the initial data that is decrypted, decompressed and then moved to the second area; the initial data is the binary data of the patch function included in the patch file.

8. The method according to claim 7, characterized in that The first area is also used to store code instructions of a function PatchRegionInit, and the function PatchRegionInit is used to perform the operations of decryption, decompression, and movement to the second area; The running address of the function PatchRegionInit is recorded in the protocol header.

9. The method according to any one of claims 1 to 8, characterized in that Also includes: When the patch file is withdrawn, the N bytes of machine code in the function description table are written back to the original function running address. The patch area is moved out to store the binary data of the original function.

10. A patch making method, applied to a server, characterized in that: include: The server incrementally compiles the source code of the first software project modified based on the baseline version, and identifies the difference function; The difference function includes a function whose source code is changed and a function that depends on the function whose source code is changed; The server compiles the difference file to obtain a redirectable target file; the difference file refers to a source code file including the difference function, and the difference file includes a first source code file, in which the original function is modified into the patch function, and in which a code for redirecting the patch function to a specified running address on a terminal device is written; The server statically links the redirectable target file to obtain a second image; The server records the running addresses configured for the original function and the patch function during static linking; the running address configured for the patch function is the designated running address; The server extracts the binary code of the patch function from the second image and generates a patch file; Among them, the patch file includes a protocol header, a function description table and binary data of the patch function; the function description table includes: the running address of the patch function, the running address of the original function to be repaired by the patch function, and N bytes of machine code; the binary data of the patch function includes variables referenced by the patch function, and instructions that instruct the program counter PC pointer to jump to the running address of the function on which the patch function depends; the N bytes of machine code are a backup of the N bytes stored at the running address of the original function.

11. The method according to claim 10, characterized in that The designated running address is a running address in a patch area, which is pre-allocated by the server and does not conflict with the running address of the first image running on the terminal device.

12. The method according to claim 10 or 11, characterized in that The first image running on the terminal device is saved by the server as an archive image; Before generating the patch file, the method further includes: The server uses the archived image to verify and confirm that the running address configured for each function in the second image is consistent with the running address configured for each function in the archived image.

13. A terminal device, characterized in that: It includes one or more microcontroller units MCU and one or more memories; wherein, the one or more memories are coupled to the MCU, and the one or more memories are used to store computer program codes, and the computer program codes include computer instructions, and when the MCU executes the computer instructions, the method according to any one of claims 1 to 9 is executed.

14. A server, characterized in that: It comprises one or more processors and one or more memories; wherein, the one or more memories are coupled to the processor, and the one or more memories are used to store computer program code, and the computer program code includes computer instructions, and when the processor executes the computer instructions, the method as described in any one of claims 10-12 is executed.

15. A chip system, the chip system is applied to a terminal device, the chip system comprises one or more processors, the processor comprises a microcontroller unit MCU, characterized in that: The MCU is used to call computer instructions so as to execute the method according to any one of claims 1 to 9.

16. A chip system, the chip system is applied to a server, the chip system comprises one or more processors, characterized in that: The processor is configured to call computer instructions so as to execute the method according to any one of claims 10 to 12.

17. A computer-readable storage medium comprising instructions, characterized in that: When the instruction is executed on the terminal device, the method according to any one of claims 1 to 9 is executed.

18. A computer-readable storage medium comprising instructions, characterized in that: When the instructions are executed on the server, the method according to any one of claims 10 to 12 is executed.

Images