How UCloud’s Application Hot‑Patch Framework Enables Zero‑Downtime Fixes

Preface

In the previous two articles we introduced the key technologies of application hot‑patching: fixing runtime functions, loading hot patches into a process, and automatically generating patches. While these form the technical backbone, using hot patches in production also requires addressing modern software attributes, security, and operational management.

Significance of Application Hot Patching

Kernel hot‑patches such as Ksplice, kpatch, kGraft, and livepatch can fix kernel bugs without rebooting. UCloud, as a public‑cloud provider, uses kernel hot‑patches to avoid service interruptions. The next goal is to improve the availability of core components like QEMU, which, despite supporting live migration, still incurs downtime and operational complexity. Application hot‑patches can fix small‑scale issues (e.g., security vulnerabilities) instantly and silently, making them ideal for minimal code changes.

Design Philosophy

Before designing the framework, we identified the following requirements for application hot‑patches on the UCloud platform:

Patch applicability at function‑level (both local and global functions).

Safety: the process state before and after patching must remain consistent.

Support for modern cloud software features such as x86_64 Linux and multithreading.

Tool‑driven generation and management (load, unload, etc.).

Rollback capability and support for multiple patches per process.

Reduced operational difficulty.

Design Approach

To meet these needs we designed a framework consisting of four components: Creator, Loader, Core Runtime, and the hot patch itself. The workflow is: Creator generates a patch from source code and a diff, Loader injects the patch into the target process, and Core Runtime manages the patch lifecycle inside the process.

Framework Components

Creator Generates a dynamic‑link library (ELF) hot patch by parsing the original and patched binaries, extracting function‑level differences, and packaging them with metadata.

Loader Acts as a client program that uses ptrace to stop all threads of the target process, perform safety checks, and load the hot‑patch library via dlopen . It also handles activation, rollback, and unloading.

Core Runtime Runs inside the target process as a shared library, records the state of each loaded patch, backs up original functions, and redirects calls to the new implementations. It also supports rollback by restoring original function entries.

Hot Patch (the patch itself) The patch produced by Creator contains replacement code and metadata (addresses, sizes, redirection info). Once loaded, calls to the old functions are redirected to the new ones.

Implementation Details

Creator

Creator parses ELF binaries, identifies changed or added functions, and builds a shared‑object patch containing the new code and necessary metadata.

Loader

Loader uses ptrace to read/write the target process’s memory and registers, stop all threads, perform consistency checks (ensuring patched functions are not on any thread’s call stack), and then load the patch via dlopen. Thread information is obtained via libthread_db or the /proc/pid/tasks/ directory.

Core Runtime

Core Runtime is loaded once per process. When a patch registers, Core Runtime records its information, backs up original function entries, and rewrites them to jump to the new code. Rollback restores the original entries. Multiple patches are distinguished by name and managed concurrently.

Conclusion

The four components—Creator, Loader, Core Runtime, and the hot patch—work together to provide a reliable, zero‑downtime patching solution for applications such as QEMU. This framework dramatically reduces the effort required to create, inject, and manage hot patches, enabling rapid remediation of security vulnerabilities and defects without service interruption.