[kpatch] Kpatch support for my own application on top of redhat kernel

Joe Lawrence joe.lawrence at redhat.com
Thu Aug 8 15:17:52 UTC 2019


On 8/8/19 11:05 AM, Evgenii Shatokhin wrote:
> Hi,
> 
> On 08.08.2019 17:15, Josh Poimboeuf wrote:
>> On Thu, Aug 08, 2019 at 09:12:44AM -0500, Josh Poimboeuf wrote:
>>> On Thu, Aug 08, 2019 at 05:03:50PM +0530, Babu Prasad wrote:
>>>> Hi Team,
>>>>                  I'm running my own application on top of redhat linux, so I
>>>> need give a kpatch support for my applications, can you please help how I
>>>> can build my application to support kpatch.
>>>
>>> Hi Babu,
>>>
>>> kpatch is very specific to kernel patching.  I wouldn't suggest trying
>>> to use it for user space patching.
>>>
>>> A SUSE engineer was working on a user space live patching library, but I
>>> don't know if it's still active:
>>>
>>>     https://github.com/SUSE/libpulp
>>
>> I should also mention that there are other user-space-patching related
>> projects out there, but I don't have the links handy.  Maybe Joe
>> Lawrence will chime in here, he's had more experiences with it.
>>
> 
> There are at least two more such projects I am aware of:
> 
> https://github.com/cloudlinux/libcare
> https://github.com/virtuozzo/nsb
> 
> AFAIK, both did not go very far beyond proof-of-concept: user-space
> patching turned out more difficult than live patching of the kernel.
> 
> Regards,
> Evgenii

Also, CRIU has something called libcompel that they use to inject 
"parasite" code into a given process:
- https://criu.org/Compel

But Evgenii is right, this is a really hard problem, especially if you 
want to support arbitrary, unmodified user programs.

If you only need to update application code (not libc code), you might 
be able to develop some kind of signaling and dlopen/dlclose scheme that 
lets the application manage dynamically linked libraries on the fly. 
Depends on the use case really.

-- Joe




More information about the kpatch mailing list