Question: Current state of Rust hotpatching

[Jvlegod]

Hello, I’m exploring hot-patching in Rust and have two main questions:

• It seems so far most work (including this crate) is focused on replacing libraries / shared-objects at runtime, rather than performing full binary patching of ELF executables (i.e., parsing an ELF, rewriting code sections, redirecting functions inside a compiled binary). I’d like to confirm: is that understanding correct? Are there technical/ABI/security reasons why library-level hot-replacement is what’s currently feasible, and full ELF-binary patching is much harder (or not supported) in Rust?

• I came across RFC 2375 (RFC: inherent trait implementation rust-lang/rfcs#2375
  ) in the context of Rust language changes. Could you help clarify where it stands now? Is the RFC accepted/merged, postponed, or still under discussion? If relevant, how this might affect hot-patching support in Rust going forward.

Thanks for any pointers or guidance.

[Shizcow]

1. You are correct; this crate focuses on replacing definitions at runtime. Unless someone else has done it that I don't know about, full ELF-binary patching is not supported in the community only because someone hasn't tried it yet.
2. I've been following this RFC for quite some time. The discussion has been very slow, but some of the road-blockers have been cleared. It is not apparent to me whether or not inherent traits will ever actually be implemented. If these were implemented, the impact is only really syntactic sugar: this crate currently can only hot patch functions, but with inherent traits it may be possible to also hotpatch methods.

Happy to chat more, but note it's been years since I've touched development on this crate.

[Jvlegod]

Thanks for your reply! From my understanding about this crate:

• hotpatch can replace a function implementation at runtime but only if the function has been annotated with #[patchable] ahead of time. This means the program must already “know” which functions may be hotpatched.

Does this imply that "hotpatch" is primarily designed for planned, anticipated dynamic updates (e.g., plugin systems, dynamic feature toggles), rather than emergency hotpatching for unknown vulnerabilities in production? In other words. If we don’t know in advance which function will need to be replaced, is it impossible to use "hotpatch" to patch arbitrary functions in a running binary(e.g., kpatch, ksplice.)?

I’m trying to understand the intended real-world usage scenario:

• Is the goal to support business-level dynamic behavior replacement? Or is it meant to be a general-purpose security hotpatching mechanism? Or somewhere in-between?

[Shizcow]

Does this imply that "hotpatch" is primarily designed for planned, anticipated dynamic updates

Yes, you understand the crate correctly.

Is the goal to support business-level dynamic behavior replacement? Or is it meant to be a general-purpose security hotpatching mechanism? Or somewhere in-between?

Truthfully, there is no goal here -- I don't use this in development myself. I made the crate as a curiosity. This crate sparked a discussion in Bevy about how to hot-reload game engine component functionality without having to bring down the engine. I'm not sure, but I believe they did get that working using an internal implementation.

[Jvlegod]

Thanks for the clarification! That makes a lot of sense.

Truthfully, there is no goal here -- I don't use this in development myself. I made the crate as a curiosity. This crate sparked a discussion in Bevy about how to hot-reload game engine component functionality without having to bring down the engine. I'm not sure, but I believe they did get that working using an internal implementation.

Since the crate originated as an experiment, I’m curious about one more thing:

Given the current design (requiring #[patchable] annotations), do you see a possible future direction where hotpatching could be applied to arbitrary functions without prior preparation?

I'm researching kpatch-style runtime hotpatching for production systems, where patches must be applied to a running binary without any prior preparation.

Do you think Rust’s current compilation model makes such “binary-level hotpatching” feasible? Or is Rust’s current ABI/layout instability fundamentally preventing this approach?

Any insight or opinion would be really valuable — your crate is one of the few that touches runtime function replacement in Rust, so your perspective matters a lot.

Thanks again for your time!

[Shizcow]

Given the current design (requiring #[patchable] annotations), do you see a possible future direction where hotpatching could be applied to arbitrary functions without prior preparation?

Yes, this is possible. This crate already has one level of indirection (de-referencing a function pointer) so modifying the running binary to inject a jump to the new definition would not introduce a performance degradation beyond what is currently in affect. That approach will corrupt the original function definition, however. This crate currently has a restore_default, which would need to be dropped if we implemented annotation-less hotpatching.

Since you're studying runtime annotation-less hotpatching, do you know a better way? I can't speak for GCC/Clang, but MSVC prefers to insert nop instructions at the start of any function that may potentially be hotpatched -- restoring the inserted jump to a nop would preserve the availability of a restore_default. But without any annotation whatsoever, I'm not sure if Rust+LLVM can be coaxed into generating this dead zone at the beginning of every function... and even in that case, an annotation would be cleaner anyway. If I didn't know any better, I'd probably implement such "binary-level" hotpatching this way.

Any insight or opinion would be really valuable — your crate is one of the few that touches runtime function replacement in Rust, so your perspective matters a lot.

If you'd like my two cents, another thought I've had is implementing zero-cost hotpatching via self-modifying parasitic code. AFAIK zero-cost hotpatching hasn't been implemented anywhere yet (I mean anywhere, not just in Rust). If we have a frame pointer, we could theoretically find the jump instruction that was used to call the function, and modify its immediate address value to point to the new instance of the function instead. This re-targeting operation could be triggered whenever the old definition of a patched function is called. This wouldn't work in all cases. This is something I've wanted to try at the LLVM level before, but haven't gotten around to it. This may or may not be relevant to our conversation.