[cgl_tech_board] Re: [cgl_discussion] Re: [cgl_specs] Use case - Live patching

Takashi Ikebe ikebe.takashi at lab.ntt.co.jp
Tue Mar 29 22:35:47 PST 2005


Brian F. G. Bidulock wrote:
> Takashi,
> How did live-patching specialized applications turn into live-patching
> glibc?  Or, the kernel for that matter?

Do you mean what is the condition of live patching?

> Also, your fear is that the live-patch context is the target process,
> yet your goal was to include it in the kernel and also have the ability
> to patch the kernel.  Is not then the kernel (patch context) patching
> the kernel (target process)?

Exactly, and seems there is noway to workaround... so I think we can not 
live-patch whole kernel with this method, may be restricted part can be 
patched to satisfy the realtime requirement...

> I am glad that you have removed these implementation specifics, however,
> I think that you still need to scope the use case to user, kernel or
> both.

> --brian

I see,
More Neutral Implementation Notes
The requirement need to have following functions;
- The function which loads the patch modules to target process's memory 
- The function which overwrites the patch module's symbols to target 
- The function which restores overwritten symbols.
- The function which unload the patch modules.
Through above functions, the requirement realize on-line patch to target
The requirement need to provide on-line patch even if the process is
multi-thread model process, or environment is SMP, and stop time of
target process should not over 100 milliseconds.
To improve usability, boot patch function which syncs binary image on
disk to patched image on memory should be provided.

> On Wed, 30 Mar 2005, Takashi Ikebe wrote:
>>The point what we focus is lowering difficulty of application development.
>>Yes you can make it all in user-mode, but we think it makes coding rule 
>>more difficult, If implement it as library base(means live-patch context 
>>is target process itself).
>>Or makes performance worse if implement is as gdb base(means live-patch 
>>context is control process).
>>In our case, we take emphasis on "easy-programing" and "performance", so 
>>we choose kernel base. It's trade-off.
>>Kernel live patching? Not mentioned in this use-case,(because there is 
>>no working open source implementation yet.) however final destination is 
>>Anyway, "kernel" is implementation method, so I changed description and 
>>OSDL CGL specifies that carrier grade Linux shall provide a mechanism and
>>framework by which a custom application can be built so that it can be
>>upgraded by replacing symbols in its live process.
>>Dynamic replacement of symbols allows a process to access upgraded functions
>>or values without requiring a process restart, and in many circumstances can
>>lead to improved process availability and uptime.
>>Desired Outcome
>>Mainline acceptance.
>>Distro acceptance to increase system availability while staying in
>>sync with distro releases.
>>Corey Minyard wrote:
>>>I agree.  You don't have to get the kernel involved and it makes no 
>>>sense to require it.
>>>Brian F. G. Bidulock wrote:
>>>>By why kernel?   It seems that there is a need to patch user-space
>>>>applications the symbols of which are only known to the linked 
>>>>(and perhaps the linker-loader) and completely unknown to the kernel.
>>>>The use case should state whether it is the intention of this 
>>>>mechanism to
>>>>patch a running kernel/kernel modules or just a running user-space 
>>>>process, or
>>>>If it is just the user-space process, a library with simple and
>>>>straightforward use of dlopen, a barrier for protection, and a 
>>>>callback for
>>>>signalling the application of a reconfiguration event should do the 
>>>>That also handles the situation of memory vs. core, because the patch 
>>>>could be
>>>>applied in core and then the application signalled, resulting in a 
>>>>dlopen of
>>>>the new core (and dlclose of the old).
>>>>Use-cases are better if they do not presuppose some form of 
>>>>implementation not
>>>>necessary to the purpose.
>>>>On Tue, 29 Mar 2005, Takashi Ikebe wrote:

Takashi Ikebe
NTT Network Service Systems Laboratories
9-11, Midori-Cho 3-Chome Musashino-Shi,
Tokyo 180-8585 Japan
Tel : +81 422 59 4246, Fax : +81 422 60 4012
e-mail : ikebe.takashi at lab.ntt.co.jp

More information about the cgl_discussion mailing list