Hot patch management method in passive optical network system, storage medium and electronic device

Abstract

The invention discloses a hot patch management method in a passive optical network system, a storage medium and an electronic device, in a Linux system, a patch management process running in a user mode and a patch management unit running in a kernel mode cooperatively execute, and the method comprises the steps that after the patch management process completes loading of a patch pack, the patch pack is loaded in the user mode; acquiring a patch function address and an original function address in the patch pack to obtain a corresponding relation, and configuring the corresponding relation to a patch management unit; when the original function is called, the original function determines to execute the original function logic or jump to the address indicated by the hook parameter by judging the value of the hook parameter; and the patch management unit registers a corresponding probe for each patch function according to the corresponding relationship so as to trigger a processing function of the probe to execute an operation of modifying the value of the hook parameter into a corresponding patch function address before the original function is executed, so that an execution process is skipped to the patch function when the original function is called, and the original function is called. And managing the function-level hotfix of the kernel mode and the user mode in the same framework.

Description

Technical Field

[0001] This article relates to data processing techniques, and more particularly to a hot patch management method, storage medium, and electronic device in a passive optical network system. Background Technology

[0002] In the field of embedded communication equipment, especially optical line terminating (OLT) equipment, the stability of system software and service continuity are crucial. As the core equipment of fiber optic access networks, OLTs typically need to provide 24 / 7 uninterrupted service. However, during operation in existing networks, situations inevitably arise where software defects need to be fixed or new functions added. Traditional software updates require restarting the entire system or related processes, leading to service interruptions and failing to meet the stringent high availability requirements of modern communication networks.

[0003] Existing hot patching solutions typically treat kernel-mode patches and user-mode patches as two separate technical areas. Kernel-mode patches often employ technologies such as Livepatch and kpatch, while user-mode patches rely on mechanisms like LD_PRELOAD, ptrace, or code injection. This approach requires maintaining two completely different patch management systems, resulting in complex operational processes, increased operational difficulty and error risks, and a lack of a unified patch status management and control interface. Summary of the Invention

[0004] This application provides a hot patch management method, storage medium, and electronic device in a passive optical network system.

[0005] A hot patch management method in a passive optical network system, characterized in that, in a Linux system, it is executed collaboratively by a patch management process running in user mode and a patch management unit running in kernel mode, the method comprising: After loading the patch package, the patch management process obtains the patch function address and the original function address in the patch package according to the patch configuration file in the patch package, obtains the correspondence, and configures it in the patch management unit; wherein the original function is set with a hook parameter, and when the original function is called, the original function determines whether to execute the original function logic or jump to the address indicated by the hook parameter by judging the value of the hook parameter; After receiving the activation command for the patch function, the patch management unit registers a corresponding probe for each patch function according to the correspondence. This triggers the processing function of the probe to modify the value of the hook parameter to the address of the corresponding patch function before the original function is executed, so that when the original function is called, the execution flow jumps to the patch function.

[0006] A storage medium storing a computer program, wherein the computer program is configured to execute the method described above at runtime.

[0007] An electronic device includes a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the methods described above.

[0008] This application embodiment seamlessly manages function-level hot patches in kernel and user modes within the same framework, solving the pain points of fragmented patch technology stacks and complex management in traditional solutions, and significantly reducing operation and maintenance costs. In addition, by passing hook parameters instead of modification instructions, it avoids the atomicity risk and code integrity damage caused by instruction overwriting, so that the hot patch operation itself will not become a new source of system instability. Without relying on a specific CPU architecture instruction set, it can adapt to multiple processor architectures through hook parameters and call context modification mechanisms, greatly expanding its application scenarios, especially suitable for heterogeneous environments such as embedded devices.

[0009] Other features and advantages of this application will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing the application. Other advantages of this application can be realized and obtained by means of the solutions described in the description and the accompanying drawings. Attached Figure Description

[0010] The accompanying drawings are used to provide an understanding of the technical solutions of this application and constitute a part of the specification. They are used together with the embodiments of this application to explain the technical solutions of this application and do not constitute a limitation on the technical solutions of this application.

[0011] Figure 1 This is a flowchart illustrating the hot patch management method in a passive optical network system provided in this application embodiment. Detailed Implementation

[0012] This application describes several embodiments, but these descriptions are exemplary and not restrictive, and it will be apparent to those skilled in the art that many more embodiments and implementations are possible within the scope of the embodiments described herein. Although many possible combinations of features are shown in the drawings and discussed in the detailed description, many other combinations of the disclosed features are also possible. Unless specifically limited, any feature or element of any embodiment may be used in combination with, or may replace, any feature or element of any other embodiment.

[0013] This application includes and contemplates combinations of features and elements known to those skilled in the art. The embodiments, features, and elements disclosed in this application can also be combined with any conventional features or elements to form unique inventive solutions. Any feature or element of any embodiment can also be combined with features or elements from other inventive solutions to form another unique inventive solution. Therefore, it should be understood that any feature shown and / or discussed in this application can be implemented individually or in any suitable combination. Therefore, the embodiments are not limited except by the limitations imposed by the appended claims and their equivalents. Furthermore, various modifications and changes can be made within the scope of the appended claims.

[0014] Furthermore, in describing representative embodiments, the specification may have presented methods and / or processes as a specific sequence of steps. However, the method or process should not be limited to the specific order of steps described herein, to the extent that it does not depend on such a specific order. As will be understood by those skilled in the art, other sequences of steps are also possible. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Moreover, the claims concerning the method and / or process should not be limited to the steps performed in the written order, and those skilled in the art will readily understand that these orders can be varied and still remain within the spirit and scope of the embodiments of this application.

[0015] In this embodiment of the application, the patch package includes a patch code file and a patch configuration file. Wherein: A patch code file contains one or more patch functions that implement new features or fix logic. It can be a kernel module file (.ko) compiled by a kernel-mode patch or a dynamic shared library file (.so) compiled by a user-mode patch.

[0016] Kernel-mode patches are patch code used to repair or replace functions in the kernel. They run in the kernel address space with the highest privilege level and have direct access to hardware and all system resources. Correspondingly, .ko (Kernel Object) files are dynamically loadable module files for the Linux kernel. They contain code that can run in the kernel address space to extend kernel functionality without requiring recompiling or restarting the entire kernel. In this embodiment, they are used to encapsulate and deliver patch code that needs to replace or modify kernel-mode functions.

[0017] User-mode patches are patch code used to repair or replace user-mode functions, running in a non-privileged user address space. Correspondingly, .so (Shared Object) files are dynamic shared library files in Linux systems. They contain code and data that can be loaded and called by multiple user-mode programs at runtime, thus saving memory and disk space and facilitating updates. In this embodiment, patch code is used to encapsulate and deliver the patch code that needs to replace or modify user-mode functions.

[0018] User-mode patches are further divided into function patches for statically linked applications and function patches for dynamic libraries; among which: Static linking of an application means that all the library function code it depends on is copied into the final executable program during the compilation phase, and no external dynamic library support is required at runtime.

[0019] Dynamic libraries are shared library files (.so files) that are loaded into the process's address space only at runtime and can be shared by multiple processes.

[0020] The patch configuration file is a structured file (such as XML or JSON) that includes information for locating the original function and the patch function, thus determining the correspondence between them. Specifically: For kernel-mode patches, the patch configuration file includes the original function name, the name of the module containing the original function, the name of the patch function, and the name of the module containing the patch function. Among them, the original function name and the name of the module containing the original function are used to uniquely identify the original function that needs to be replaced; the name of the patch function and the name of the module containing the patch function are used to specify which function in which patch module should be used to perform the replacement. For statically linked application function patches in user-mode patches, the patch configuration file includes the application name of the original function, the original function name, and the patch function name. Among them: the memory offset of the original function in the application binary file is calculated by using the application name and function name in conjunction with the Executable and Linkable Format (ELF) parsing tool; the patch function name is used to find the address of the patch function in the patch code file.

[0021] For dynamic library patches in user-mode patches, the patch configuration file includes the name of the dynamic library containing the original function, the name of the original function, and the name of the patch function; where: the memory offset of the original function in the .so file is calculated using the dynamic library name and the function name; the patch function name is used to find the address of the patch function in the patch code file.

[0022] The patch package provided in this application not only includes patch code, but also a structured configuration file that clearly specifies the patch category, the location information of the original function and the patch function. This enables the subsequent patch loading, address resolution and mapping configuration to be automated, providing a unified data source for the unified management of kernel-mode and user-mode patches, which is a prerequisite for the automation and large-scale deployment of the entire solution.

[0023] In the embodiments of this application, the improvement of the original function is the introduction of a hook parameter.

[0024] Modify the original function that needs to support hot patching by adding a dedicated hook parameter (e.g., long hook) at the beginning of its parameter list and adding conditional judgment logic at the function entry point.

[0025] This hook parameter acts as a safe and controllable jump switch. During normal calls, passing 0 executes the original business logic; when hot patching is needed, the address of the patch function is passed through a subsequent mechanism, and the execution flow jumps to the new function. This mechanism completely avoids directly modifying the original function's instruction code, fundamentally eliminating the risk of crashes caused by instruction overwriting in a multi-threaded environment. Furthermore, since the jump is implemented through normal function parameters and call flow, rather than writing architecture-specific jump instructions (such as `jmp` for x86 or `b` for ARM), this solution naturally possesses good compatibility across different CPU architectures (such as x86_64, ARM64).

[0026] In this embodiment, the probe processing function is improved based on the improvement of the original function, specifically by dynamically rewriting the calling context. The details are as follows: Before the original function is executed, the probe's processing function modifies the hook parameter to the address of the corresponding patch function, so that when the original function is called, the execution flow jumps to the patch function.

[0027] For example, in the probe's processing function, the calling context passed to the original function is dynamically modified, changing the value of the register or stack memory location corresponding to the hook parameter from 0 to the entry address of the target patch function.

[0028] In the above implementation, the processing function is a callback function executed when the probe is triggered, which is used to modify the function call context.

[0029] In this context, probes refer to kernel probe points registered during the activation phase, including kprobes for kernel-mode patches and uprobes for user-mode patches. They form the technological foundation for intercepting function execution flows. Specifically: The kprobe is a dynamic debugging mechanism provided by the Linux kernel, which allows breakpoints to be inserted at any instruction location within a kernel function. When the execution flow reaches the breakpoint, a predefined handler function is executed first, and then the original execution flow continues.

[0030] The uprobe probe is a dynamic debugging mechanism similar to kprobe, but it operates on user-mode processes and can insert breakpoints at specified instruction addresses in user-mode programs.

[0031] This operation is completed just before the original function is executed, and is transparent to the caller. It cleverly utilizes the Linux kernel's detection mechanism to dynamically change the execution behavior of the original function in real time without modifying any code, achieving hot patching without the business being aware of it.

[0032] like Figure 1 As shown, this application provides a hot patch management method in a passive optical network system, which is executed collaboratively by a patch management process running in user mode and a patch management unit running in kernel mode. Wherein: The patch management process is a control program that runs in the user address space and is responsible for parsing patch configurations, loading patch code, and managing the patch lifecycle. The patch management unit is a core module deployed in the kernel address space that performs patch injection and jump control.

[0033] The method includes the following steps: Step 101: After loading the patch package, the patch management process obtains the patch function address and the original function address in the patch package according to the patch configuration file in the patch package, obtains the corresponding relationship, and configures it in the patch management unit.

[0034] Among them, the address of the patch function is the location in memory of the target function that implements the repair or new function; the address of the original function is the location in memory of the original function that needs to be replaced; and the correspondence is a data structure that records the mapping relationship between the original function and the patch function.

[0035] The original function contains a hook parameter. When the original function is called, it determines whether to execute its own logic or jump to the address indicated by the hook parameter by checking its value. The hook parameter is a special parameter added to the beginning of the original function's parameter list. It receives the address of the patch function; it is passed 0 during a normal call and the address of the patch function when activating the patch.

[0036] Step 102: After receiving the activation command of the patch function, the patch management unit registers a corresponding probe for each patch function according to the correspondence, so as to trigger the processing function of the probe to perform the operation of modifying the value of the hook parameter to the address of the corresponding patch function before the original function is executed, so that when the original function is called, the execution flow jumps to the patch function.

[0037] The activation command is the control instruction that triggers the patch to take effect.

[0038] In step 102, a unified patch activation mechanism was designed. The patch management unit only registers the corresponding probe after receiving the activation command, thereby decoupling the patch configuration and patch activation phases.

[0039] The above process employs an architecture where user-mode processes and kernel-mode units execute collaboratively. This is a best practice based on Linux system permission isolation and functional division of labor, for the following reasons: The patch management process runs in user space, facilitating file operations (such as parsing patch packages and loading .so libraries), managing complex configuration logic, and interacting with system administrators. The patch management unit, on the other hand, runs in kernel space, possessing the necessary permissions to directly modify CPU registers, access the address space of all processes, and manage kernel probes—core operations that user-space processes cannot directly perform.

[0040] Strategic management functions (such as patch lifecycle decisions and configuration resolution) are placed in user space, while high-risk kernel operations (such as registering probes and modifying execution flow) are encapsulated in kernel modules and interacted with through well-defined interfaces (such as ioctl). This design achieves high cohesion and low coupling, ensuring that activated kernel patches can still function normally even if the patch management process terminates unexpectedly, greatly enhancing the system's robustness.

[0041] This collaborative architecture is the cornerstone of the unified management of hot patches in kernel mode and user mode in this embodiment. Whether it is a kernel function or a user-mode function, the control flow of patch activation and deactivation is completely consistent for the upper-level manager. Commands are issued by the user-mode process and executed uniformly by the kernel-mode unit, which simplifies the operation and reduces complexity.

[0042] The method provided in this application seamlessly manages function-level hot patches in kernel and user modes within the same framework, solving the pain points of fragmented and complex management of the two types of patching technology stacks in traditional solutions, and significantly reducing operation and maintenance costs. In addition, by passing hook parameters instead of modification instructions, the atomicity risk and code integrity damage caused by instruction overwriting are avoided, so that the hot patch operation itself will not become a new source of system instability. Without relying on a specific CPU architecture instruction set, it can adapt to multiple processor architectures through hook parameters and call context modification mechanisms, greatly expanding its application scenarios, especially suitable for heterogeneous environments such as embedded devices.

[0043] In one exemplary embodiment, a deactivation mechanism for hot patches is further defined to address the technical problem of patches needing to be quickly rolled back or temporarily disabled.

[0044] When unexpected problems occur in patch functions, or when it is necessary to temporarily restore the system to its original state for problem localization, a safe and fast patch uninstallation solution is provided. Specific implementation methods include: After the patch function is activated, if a deactivation command for the patch function is received, the patch management unit unloads the probe of the patch function so that the original logic is executed when the original function is called.

[0045] The deactivation command can be issued by the user-space patch management process to instruct a specified patch to be switched from an active state to an inactive state. This command is passed to the kernel-space patch management unit through a defined interface (such as ioctl).

[0046] The patch management unit calls kernel-provided interfaces (such as unregister_kprobe and unregister_uprobe) to unmonitor the target function, remove previously set breakpoints, and thus unload the probe. After the probe is unloaded, all calls to the original function will no longer be intercepted or redirected, and the function will fully restore its original, unmodified execution flow and business logic.

[0047] The core improvement of this embodiment lies in the introduction of a reversible patch status control mechanism, expanding hot patch management from a one-way "application" to a two-way "application-reversal" closed loop, thus completing a key link in the patch lifecycle. Unlike existing technologies that require restarting the service or even the entire system to revert a patch, this embodiment can dynamically and in real-time remove patches at runtime through a simple deactivation command, restoring the system to its state before patching, which takes effect immediately and without interrupting business operations.

[0048] In one exemplary embodiment, a probe registration mechanism for different patch types is further defined to address the technical problem that kernel-mode and user-mode functions require different hot patch implementations due to differences in runtime environments, thereby achieving precise location and control of different types of patches. Specific implementation methods include: When the patch function is a kernel-mode patch, the kprobe probe is registered to the original function, wherein the kprobe probe is set at the entry address of the kernel-mode original function; When the patch function is a user-space patch, register the uprobe probe to the original function, where: If it is a function patch in a statically linked application, the uprobe probe is set to the first address, where the first address is the actual virtual address of the target application where the original function is located during this runtime; If it is a function patch in a dynamic library, the uprobe probe is set to the second address, where the second address is the actual virtual address of the target process where the original function is located.

[0049] The entry address of the kernel-mode original function is the memory address of the kernel function that needs to be patched in the kernel address space. This address is usually fixed during system operation.

[0050] The actual virtual address is the function's actual runtime address in the target process's virtual address space, and this address is affected by Address Space Layout Randomization (ASLR). For statically linked applications, it can be located based on the application's own load base address; for dynamic libraries, it can be located based on the dynamic library's load base address in the target process.

[0051] The core improvement of this embodiment lies in establishing a differentiated localization strategy under a unified probe management framework, enabling collaborative work between kernel-mode and user-mode patches within a unified architecture. By incorporating kernel-mode kprobe and user-mode uprobe into the same management framework, and having them uniformly registered and controlled by the patch management unit, the problem of requiring two independent technology stacks for kernel-mode and user-mode hot patches in traditional solutions is avoided.

[0052] Specifically, this embodiment differentiates different patch types under a unified architecture, enabling kernel-mode patches, user-mode static linking patches, and user-mode dynamic library patches to utilize the same management process and control interface, significantly reducing system complexity and maintenance costs. Furthermore, by employing optimal positioning strategies tailored to the characteristics of different patch types, it ensures patches are precisely applied to the target function, avoiding accidental operations on other functions or processes, thus improving system security and reliability. The dynamic address calculation mechanism allows the solution to adapt to different binary file formats and memory layout strategies, maintaining stable operation even when facing security mechanisms such as ASLR, expanding the solution's applicability. In addition, the probe mechanism can intercept and redirect execution flow in real time during function calls, enabling hot patching to take effect without the service being aware, meeting the high requirements of communication equipment for service continuity.

[0053] In one exemplary embodiment, a mechanism for determining the address of user-mode patches is further defined to address the technical problem that the randomization of the user-mode process address space leads to the indeterminate function entry address.

[0054] This embodiment ensures accurate location of the target function even in an ASLR environment by employing an address calculation scheme based on file offsets. Specific implementation methods include: The first address is determined based on the offset of the original function in the executable file of the target application; The second address is determined based on the offset of the original function in the dynamic library file.

[0055] Offset refers to the byte distance of a function's position within its ELF file relative to the beginning of the file. This is a fixed value determined during the compilation and linking phase and is unaffected by runtime memory layout.

[0056] The executable file of the target application refers to the binary file on the disk of the statically linked program that needs to be patched. This file contains all the code and data required for the program to run.

[0057] The core improvement of this embodiment lies in the adoption of a hybrid positioning strategy that combines static addressing based on file offsets with dynamic calculation at runtime, fundamentally solving the technical challenges caused by user-mode address randomization. Specifically, this is reflected in the following aspects: The shift from absolute addresses to relative addresses abandons the traditional approach of relying on fixed virtual addresses and instead uses a stable reference system of offsets relative to the file base address. This shift decouples patch configuration information from the specific memory layout, making it environment-independent. Unified offset calculation paradigm: Although statically linked applications and dynamic libraries differ in their memory mapping mechanisms, this embodiment innovatively adopts the same offset calculation principle; this uniformity simplifies system design, allowing the kernel management module to handle the two types of user-mode patches using similar logic; Precise control of dynamic calculation timing: The offset is provided as static configuration information during the patch loading phase, while the actual address calculation is postponed until the patch is activated. This delayed calculation mechanism ensures that the most accurate real-time memory mapping information of the target process can be obtained.

[0058] In one exemplary embodiment, a process-level precise control mechanism for user-mode patches is further defined to address the technical problem of how to ensure that patches only apply to a specific target process without affecting other processes in complex scenarios of multi-process environments.

[0059] This embodiment achieves precise targeted application of user-mode patches by introducing a process identifier verification mechanism. Details are as follows: For function patches in dynamic libraries: The essential characteristic of dynamic libraries is that they are shared by multiple processes. A single dynamic library may be loaded by dozens or even hundreds of different processes simultaneously. In this scenario, if it's necessary to patch a specific process (such as a malfunctioning process) without affecting other normal processes using the same dynamic library, process identifier comparison is essential. Otherwise, the patch will take effect on all processes loading the dynamic library, potentially causing widespread system instability. Therefore, the proposed solutions include: When the patch function is a function patch in a dynamic library, the patch management unit performs an operation to modify the register value to the address of the patch function when the identifier of the process currently executing the original function is consistent with the identifier of the preset target process.

[0060] For function patches in statically linked applications: While statically linked applications typically run as a single process, in a multi-instance deployment environment, the same application may run multiple process instances simultaneously. For example, a web service program might launch multiple independent processes for different clients or different business lines. When only a specific instance needs patching (e.g., a specific problem occurs in a client's environment), identifier comparison must be used to ensure that the patch only affects the target process, avoiding impact on other normally functioning application instances. Therefore, the proposed handling methods include: When the patch function is a function patch in a statically linked application, if the application runs in multiple processes on the Linux system, the patch management unit performs an operation to modify the register value to the address of the patch function when the identifier of the process currently executing the original function is consistent with the identifier of the preset target process.

[0061] In this embodiment, the patch configuration file records the identifier of the target process.

[0062] In Linux systems, the identifier specifically refers to the process ID (PID), a unique numerical identifier assigned by the kernel to each running process to uniquely distinguish different processes system-wide. The target process identifier is the PID of the specific process that needs to be hot-patched, pre-specified during the patch configuration phase. This information comes from the patch configuration file and is passed to the kernel management module by the patch management process.

[0063] The process currently executing the original function refers to the runtime process environment that actually calls the patched function. When the uprobe processing function is triggered, the kernel can obtain the PID of the process currently executing the function.

[0064] The core improvement of this embodiment lies in establishing a fine-grained process-level patch filtering mechanism, achieving a leap in precise control from the function level to the process level. Specifically, this is reflected in the following aspects: Introducing a dynamic runtime decision-making mechanism: Real-time process identifier verification is added to the processing function of uprobe, so that the decision on whether to apply the patch is made dynamically each time the function is called. This design ensures the accuracy and real-time performance of patch control. Differentiated processing under a unified architecture: Although dynamic library patches and static linking application patches differ in their technical principles, this embodiment innovatively adopts the same identifier verification process, which not only ensures the uniformity of the system architecture, but also meets the precise control requirements in different scenarios. Breaking through the boundaries of traditional patch application: Specifically optimized for multi-process scenarios of statically linked applications, it breaks the traditional limitation that "statically linked patches will inevitably affect all instances" and provides a flexible patching strategy for complex deployment environments.

[0065] This embodiment ensures that the patch only applies to a specific target process by comparing process identifiers, achieving precise control over the scope of the patch's impact, avoiding accidental damage to other normal processes, and significantly improving the security of patch operations.

[0066] In one exemplary embodiment, an adaptive register mapping mechanism across CPU architectures is further defined to address the hot patch compatibility issue caused by differences in function calling conventions across different CPU architectures.

[0067] Specifically, there are significant differences between different CPU architectures. Each architecture has completely different specifications in function calling conventions and register usage methods. For example, the x86_64 architecture uses the RDI register to pass the first integer parameter; the ARM64 architecture uses the X0 register to pass the first integer parameter; and other architectures such as RISC-V have their own register usage rules.

[0068] Traditional solutions typically handle these differences through pre-compiled architecture-specific code, resulting in redundant and difficult-to-maintain code.

[0069] To address this technical problem, this embodiment achieves seamless portability of the hot patching mechanism across different processor architectures through dynamic detection and adaptive mapping. Specific implementation methods include: During kernel module initialization, the patch management unit establishes a mapping relationship between the storage locations of hook parameter values ​​and registers in the current CPU architecture by performing the following steps: Register a test probe to a known interface function; Call the known interface function and pass in a test value; In the processing function of the test probe, the general-purpose register set is traversed to find the register whose value matches the test value, and the target register is obtained. The target register is used as the storage location corresponding to the hook parameter in the calling convention of the current CPU architecture to establish the mapping relationship; The patch management unit configures the storage location corresponding to the hook parameter value for the probe's processing function according to the mapping relationship.

[0070] The technical terms used in this embodiment are explained as follows: Test probes are kprobe probes that are temporarily registered during the kernel initialization phase to perform architecture detection tasks. They can be uninstalled immediately after the detection is completed.

[0071] Known interface function: A pre-defined function in the kernel with defined parameter passing behavior, serving as a reference benchmark for detecting the architecture's calling convention.

[0072] Test value: A pre-set numerical value with a specific bit pattern, used for unique identification in the register set.

[0073] Processing function: The callback function executed when the test probe is triggered, responsible for performing register traversal and numerical matching detection.

[0074] General purpose register set: The set of general purpose registers used for function parameter passing in the current CPU architecture, such as RDI, RSI, RDX, etc. in the x86_64 architecture, or X0-X7 registers in the ARM64 architecture.

[0075] The storage location is used to mark the specific register used by the first function parameter in the calling convention of the current CPU architecture.

[0076] The target register represents the specific register that needs to be modified during the patch activation phase to store hook parameter values.

[0077] This embodiment achieves architecture-independent hot patching through an innovative scheme of dynamic detection and adaptive mapping. Specifically, this is reflected in the following aspects: The shift from static configuration to dynamic detection: abandoning the static configuration method that relies on predefined architecture information in the traditional solution, and instead adopting a runtime dynamic detection mechanism, this shift enables the system to automatically adapt to any supported CPU architecture without manual intervention; The optimization strategy of "one detection, multiple uses" is as follows: the mapping relationship is established only once during the kernel module initialization phase, and all subsequent patch operations reuse this detection result. This design ensures accuracy while avoiding the performance overhead of repeated detection. Unified Register Access Abstraction Layer: By establishing an architectural mapping relationship, a unified register access interface is provided for upper-layer patch management, shielding the differences in underlying hardware and greatly simplifying the implementation complexity of core patch logic.

[0078] As explained above, this embodiment constructs a truly CPU architecture-independent hot-patching infrastructure, ensuring that the same hot-patching code can run seamlessly on different processor platforms, significantly improving the portability and maintainability of the solution. Specific details are as follows: Achieving true cross-architecture compatibility: Through a dynamic detection mechanism, this embodiment can automatically adapt to the function calling conventions of various CPU architectures, so that the hot patching function can run normally on multiple processor platforms such as x86, ARM, and RISC-V without modification.

[0079] Significantly reduced maintenance costs: Eliminating dependencies on architecture-specific code greatly reduces the workload required to support new architectures. When support for new CPU architectures is needed, the system can automatically adapt without modifying the core code.

[0080] Enhanced system deployment flexibility: The same hot patch management system can be deployed on devices based on different processors, providing a unified hot patching solution for heterogeneous computing environments, which is particularly suitable for the diverse hardware environments of modern data centers.

[0081] Ensuring runtime performance: The one-time detection mechanism ensures that no additional detection overhead is introduced during the patch activation phase, and register modification operations are executed directly based on the pre-established mapping relationship, maintaining the efficiency of the patching mechanism.

[0082] Enhance system reliability: Through accurate register mapping, ensure that hook parameters can be modified correctly on different architectures, avoiding system crashes or patch failures caused by register recognition errors.

[0083] In one exemplary embodiment, a differentiated loading mechanism for different types of patches in the patch package is further defined to address the technical problem that kernel-mode code and user-mode code need to adopt different loading methods due to different runtime environments.

[0084] This embodiment achieves secure and efficient loading of different types of patch code through a unified loading management framework. Specific implementation methods include: The steps of the patch management process to complete the loading operation of the patch package include: Identify the patch category of each patch function in the patch package. When the patch category is a kernel-mode patch, call the insmod command to load it into the kernel address space; when the patch category is a user-mode function patch, call the dlopen function to load it into the user address space of the patch management process.

[0085] The technical terms used in this embodiment are explained as follows: The insmod command is a command-line tool in Linux systems used to dynamically insert loadable modules into the running kernel. It loads .ko files into the kernel address space and executes their initialization functions.

[0086] The dlopen function is a library function provided by the Linux dynamic linker. It is used to dynamically load shared libraries into the user address space of the current process at runtime, enabling the program to use the functions and variables defined in the library.

[0087] The user address space of the patch management process is the non-privileged memory region where the patch management process runs, and user-mode patch code files are loaded into the private address space of this process.

[0088] The core improvement of this embodiment lies in establishing a differentiated execution strategy under a unified patch loading management framework, enabling secure and efficient loading of kernel-mode and user-mode patches. Specifically, this is reflected in the following aspects: It achieves a truly unified management experience: although kernel-mode and user-mode patches use different loading mechanisms, all loading operations are completed through a unified patch management process for upper-level users, providing a simple and consistent management interface and significantly reducing the complexity of use; It ensures the system's security boundaries: by strictly distinguishing between the loading methods of the kernel address space and the user address space, it ensures that the patch code runs at the correct privilege level, preventing security issues that may be caused by user-mode code accidentally entering the kernel address space or kernel-mode code executing in the user address space; It provides optimal loading performance: it selects the most suitable loading path for different types of patches, kernel-mode patches directly enter the kernel through system calls, and user-mode patches are loaded in the local process space through the dynamic linker, each using the most efficient loading method; Enhanced system reliability: Differentiated loading strategies ensure that each patch runs in the intended environment, avoiding loading failures or runtime errors caused by incompatible environments, thus improving the stability of the entire hot patching system; Supports flexible patch deployment: This loading mechanism enables the system to manage hot patches in both kernel and user modes simultaneously, providing a comprehensive hot patching solution for complex system maintenance scenarios and meeting different levels of patching needs.

[0089] As can be seen from the above description, the purpose of this embodiment is to build a loading mechanism that can both manage in a unified manner and fully respect the characteristics of different types of patches, so as to ensure that kernel-mode and user-mode patches can be loaded safely and effectively in the most suitable environment, laying a solid foundation for subsequent patch activation.

[0090] In one exemplary embodiment, a state management mechanism for patch functions is further defined to address the technical problem of lacking systematic state control in hot patch lifecycle management.

[0091] This embodiment achieves fine-grained control over the patch lifecycle by introducing complete state machine management. Specific implementation methods include: The patch management unit maintains the state of the patch functions in the corresponding relationship, wherein the state includes at least a loading state, an activation state, a deactivation state, and an unloading state; wherein: Loading Status: The patch function has completed code loading and address mapping configuration, but the probe has not yet been registered, and the patch functionality has not yet taken effect. In this status, the patch management unit has recorded the complete patch mapping relationship, but the system still executes according to the original logic.

[0092] Activation Status: The patch function has completed probe registration, and the patch functionality is officially in effect. In this state, when the original function is called, the execution flow will automatically jump to the patch function, enabling hot patching.

[0093] Deactivated state: The patch function has unloaded the probe, and the patch functionality is temporarily disabled, but the patch code and mapping relationships are still retained. In this state, the system resumes execution of the original function logic, but the patch can be quickly reactivated.

[0094] Uninstallation Status: The patch function has been completely removed, including releasing all related resources and clearing mappings. In this status, the system is fully restored to its original state before the patch was loaded.

[0095] The core improvement of this embodiment lies in establishing a systematic patch lifecycle state machine management mechanism, integrating the originally fragmented patch management operations into an ordered state transition process. Specifically, this is reflected in the following aspects: The shift from discrete operations to state machine management: Traditional hot patching solutions often use simple "apply / remove" binary operations, lacking intermediate state management. By introducing four core states, a complete patch lifecycle management model is constructed. Clear state boundaries and transition rules: Each state has a clear definition and allowed state transition paths, ensuring the orderliness and predictability of patch management operations; for example, a patch must go through the loading state before entering the activation state to prevent direct activation without sufficient preparation. Enhanced fault recovery capabilities: When a patch causes a problem, it can quickly switch from an active state to a deactivated state to achieve a rollback, greatly shortening the fault recovery time and improving the availability and reliability of the system; State persistence and consistency guarantee: The patch management unit is responsible for maintaining persistent storage of state, ensuring that patch state can be correctly recovered even in the event of system anomalies, and guaranteeing state consistency.

[0096] The purpose of this embodiment is to provide a structured patch management method that ensures the controllability, predictability, and security of hot patch operations through clear state division and transition rules, thereby reducing operational risks.

[0097] In one exemplary embodiment, an automatic symbol management mechanism for kernel-mode patches is further defined to address the technical problem that symbol isolation between kernel modules prevents the direct acquisition of patch function addresses.

[0098] This embodiment achieves centralized management of symbol addresses among kernel modules by establishing an automated symbol registration and query system. Specific implementation methods include: When the patch function is a kernel-mode patch, the name of the patch function is set based on a preset naming rule; The method is further executed collaboratively by a symbol management unit running in kernel mode, and the method also includes: The symbol management unit monitors the loading events of kernel modules in the Linux system, and after the kernel module loads a function, it calls a function within the kernel module that conforms to the preset naming rules, so as to record the mapping relationship between function names and addresses in the central symbol table. When the patch management unit receives a query from the patch management process for the address of a kernel-mode patch, it queries the central symbol table of the symbol management kernel module.

[0099] Among them, the preset naming rules refer to the special function naming conventions agreed upon during the kernel module development phase, such as adopting the unified format of "rcolt_function_name_sym_add", which facilitates automatic recognition and processing by the symbol management unit.

[0100] The mapping relationship between function names and addresses records a data structure that shows the correspondence between the names of kernel-mode functions and their actual entry addresses in memory, which is the basis for symbol lookup.

[0101] The central symbol table is a global hash table or similar data structure maintained by the symbol management unit, used to centrally store all kernel function symbols and their address information collected through the automatic registration mechanism.

[0102] Kernel module load events refer to events that occur when a kernel module is loaded into the system via insmod or other means, and are captured and passed by the Linux kernel module notification chain mechanism.

[0103] Due to kernel security design, a module typically cannot directly access the internal symbol addresses of another module. This poses a fundamental obstacle to implementing cross-module hot patching. The purpose of setting up a Symbol Management Unit is to break the default symbol isolation restriction between modules in the Linux kernel. The Symbol Management Unit is a dedicated module running in kernel space, responsible for listening to module load events, automatically extracting symbol addresses, and maintaining the global symbol table.

[0104] The specific improvements are reflected in the following aspects: The shift from manual management to automatic registration: Traditional solutions require manual maintenance of symbol addresses or modification of kernel-exported symbols. This embodiment achieves zero-intervention automatic collection of symbol addresses through preset naming rules and an automatic listening mechanism. Establish a centralized symbol service system: Build a unified symbol query entry point through the symbol management unit to provide standardized query services for all components in the system that need to obtain kernel function addresses; Event-based real-time response mechanism: Utilizes the kernel module notification chain to detect module loading events in real time, ensuring that symbols of newly loaded modules can be immediately identified and registered, thus guaranteeing the timeliness of symbol information.

[0105] Optimize the system initialization process: symbol registration and module loading are completed synchronously, avoiding timing issues that may be caused by delayed registration and ensuring that the system is put into operation in a complete state; It provides excellent system scalability: any new kernel patch module, as long as it follows the preset naming rules, can have its symbols automatically incorporated into the management system, and no modification to the core management logic is required when the system is expanded.

[0106] The purpose of this embodiment is to build an automated, real-time kernel symbol management infrastructure, eliminate symbol access barriers between kernel modules, and provide reliable address lookup guarantees for the smooth implementation of kernel-mode hot patches.

[0107] A storage medium storing a computer program, wherein the computer program is configured to execute the method described above at runtime.

[0108] An electronic device includes a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the methods described above.

[0109] In one exemplary embodiment, the electronic device is deployed in an OLT, wherein: The patch management process runs as a persistent user-space service, responsible for receiving, verifying, and managing patch packages.

[0110] patch_mgt.ko, as a patch management unit, is loaded by the kernel module and provides a unified patch control interface.

[0111] sym_mgt.ko, as a symbol management unit, is loaded by the kernel module to implement automatic registration and query of kernel symbols.

[0112] The specific execution process includes: Secure transmission: Patch packages are transmitted to OLT devices via secure network channels or local storage.

[0113] Layered loading: Patches for user-space processes such as ponsdk and ssp are loaded into the patch management process space via dlopen; patches for kernel components such as kernel network protocol stack and drivers are loaded into the kernel address space via insmod.

[0114] Precise activation: Based on the patch configuration file, precise patch activation is performed on specific processes (such as a business instance) or global functions; CPU architecture adaptive detection is automatically completed during kernel module initialization.

[0115] Status monitoring: Monitor patch status in real time, and record patch activation time, target progress, and effect evaluation data.

[0116] Optionally, the following operations can also be performed before performing tiered loading: Permission verification: The patch management process verifies the digital signature and integrity of the patch package to ensure its reliable origin.

[0117] Implementing this embodiment in an OLT device has the following significant advantages: Zero business interruption: Supports fault repair and function updates during business operation, completely eliminating business interruption time caused by software upgrades and meeting high availability requirements.

[0118] Unified operation and maintenance experience: Provides a single management interface and operation process, covering both kernel-mode and user-mode patch management. Operation and maintenance personnel do not need to master multiple different hot patching technologies, greatly reducing operational complexity and training costs.

[0119] Precise fault repair: Supports precise patch targeting at the process level, especially in multi-instance deployment scenarios, it can repair a single faulty instance without affecting other normally operating business instances.

[0120] Cross-platform compatibility: Through automated architecture detection and register mapping mechanisms, the same patch package can run on OLT devices with different architectures, significantly reducing version management and adaptation workload.

[0121] Rapid fault response: The entire process from fault detection to repair can be completed within minutes, which greatly improves fault repair efficiency compared to the traditional upgrade method that requires scheduling maintenance windows.

[0122] This embodiment is particularly suitable for communication equipment scenarios such as OLTs, which have extremely high requirements for stability and real-time performance. It provides network operators with more flexible and reliable software maintenance capabilities, effectively ensuring the quality of network services.

[0123] It will be understood by those skilled in the art that all or some of the steps, systems, or apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all components may be implemented as software executed by a processor, such as a digital signal processor or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term "computer storage medium" includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and can be accessed by a computer. Furthermore, it is well known to those skilled in the art that communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

Claims

1. A hot patch management method in a passive optical network system, characterized in that, In a Linux system, the method is executed by a patch management process running in a user state and a patch management unit running in a kernel state, and the method comprises: After the patch management process completes loading of the patch package, the patch management process obtains patch function addresses and original function addresses in the patch package according to a patch configuration file in the patch package, obtains a correspondence relationship, and configures the correspondence relationship to the patch management unit; wherein the original function is provided with a hook parameter, and when the original function is called, the original function determines whether to execute original function logic or jump to an address indicated by the hook parameter for execution by judging a value of the hook parameter; After the patch management unit receives an activation command of a patch function, the patch management unit registers a corresponding probe for each patch function according to the correspondence relationship, so that a processing function of the probe is triggered to execute an operation of modifying the value of the hook parameter to a corresponding patch function address before the original function is executed, so that when the original function is called, the execution flow jumps to the patch function.

2. The method of claim 1, wherein, The method further comprises: After the patch function is activated, if a deactivation command of the patch function is received, the patch management unit unloads the probe of the patch function so that the original function is called to execute original logic.

3. The method of claim 1 or 2, wherein: when the patch function is a kernel state patch, a kprobe probe is registered to the original function, wherein the kprobe probe is set at an entry address of the kernel state original function; when the patch function is a user state patch, an uprobe probe is registered to the original function, wherein: if the patch is a function patch in a statically linked application program, the uprobe probe is set at a first address, wherein the first address is an actual virtual address of a target application program in which the original function is located in this run; if the patch is a function patch in a dynamic library, the uprobe probe is set at a second address, wherein the second address is an actual virtual address of a target process in which the original function is located.

4. The method of claim 3, wherein: the first address is determined according to an offset of the original function in an executable file of the target application program; the second address is determined according to an offset of the original function in a dynamic library file.

5. The method of claim 3, wherein, The method further comprises: when the patch function is a function patch in a dynamic library, the patch management unit executes an operation of modifying a register value to a patch function address when an identifier of a process currently executing the original function is consistent with an identifier of a preset target process; when the patch function is a function patch in a statically linked application program, if the application program runs with multiple processes in a Linux system, the patch management unit executes an operation of modifying a register value to a patch function address when an identifier of a process currently executing the original function is consistent with an identifier of a preset target process; wherein the patch configuration file records the identifier of the target process.

6. The method of claim 1, wherein, The method further comprises: In a kernel module initialization process, the patch management unit establishes a mapping relationship between a storage location corresponding to a value of a hook parameter in a current CPU architecture and a register by executing the following steps, comprising: registering a test probe to a known interface function; calling the known interface function and passing in a test value; in the processing function of the test probe, traversing the general register set to find a register whose value matches the test value, obtaining a target register; establishing the mapping relationship between the target register and the storage location corresponding to the hook parameter in the calling convention of the current CPU architecture; wherein the patch management unit configures the storage location corresponding to the value of the hook parameter for the processing function of the probe according to the mapping relationship.

7. The method of claim 1, wherein, The step of completing the patch package loading operation by the patch management process includes: identifying the patch category of each patch function in the patch package, and when the patch category is a kernel state patch, calling the insmod command to load it into the kernel space; when the patch category is a user state function patch, calling the dlopen function to load it into the user address space of the patch management process.

8. The method of claim 1, wherein, The method further includes: The patch management unit maintains the state of the patch function in the correspondence, wherein the state at least includes a loading state, an activation state, a deactivation state and an unloading state.

9. The method of claim 1, wherein: when the patch function is a kernel state patch, the name of the patch function is set based on a preset naming rule; wherein the method is further cooperatively executed by a symbol management unit running in the kernel state, and the method further includes: The symbol management unit listens to the loading event of the kernel module in the Linux system, and after the kernel module loading function operation, calls the function in the kernel module that conforms to the preset naming rule to record the mapping relationship between the function name and the address in the central symbol table; The patch management unit queries the central symbol table of the symbol management kernel module when receiving the query address of the kernel state patch initiated by the patch management process.

10. A storage medium having program instructions stored thereon, the program instructions being executed by a processor to implement the method of any one of claims 1 to 9.

11. An electronic device comprising one or more processors and a memory, the memory storing program instructions that, when executed by the one or more processors, cause the electronic device to perform the method of any one of claims 1 to 9.

Images