[cgl_tech_board] Re: [cgl_discussion] Re: [cgl_specs] Use case
- Live patching
ikebe.takashi at lab.ntt.co.jp
Tue Mar 29 17:09:42 PST 2005
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.
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:
>>> Ralf, I just fix some point which you are worrying, and everyone
>>> Please check and tell me your impression.
>>> OSDL CGL specifies that carrier grade Linux shall provide the mechanism
>>> for dynamically replacing the symbols of a running process without
>>> restarting. Dynamic replacement of symbols allows a process to access
>>> patched functions or values without restarting and can improve process
>>> Desired Outcome
>>> Mainline kernel acceptance.
>>> Distro acceptance to increase system availability while staying in
>>> sync with
>>> distro releases.
>>> System administrators setup the requirements on installations.
>>> On operation, application developer/administrators should provide
>>> patch module,
>>> and carrier system administrators apply patch to the carrier system
>>> which designed to use the requirement.
>>> On operation, system administrators apply patch with the requirement as
>>> following scenario;
>>> 1.System administrators obtains patch modules from application
>>> In the case that the application is designed to use the requirement,
>>> system administrators
>>> make patch file from diff file or new version's source code.
>>> 2.System administrators load patch to the process with provided live
>>> patch tool.
>>> 3.System administrators activate patch to the process with provided live
>>> patch tool.
>>> 4.Confirm that the patch is correctly applied or not.
>>> 5.If the effect of patch is not desired, remove/deactivate the patch
>>> with provided live patch tool.
>>> Implementation Notes
>>> The requirement need to have following functions;
>>> - The function which loads the patch file to target process's memory
>>> - The function which overwrites the branch operation code to the patch,
>>> on the entry point of target process's functions which wants to fix by
>>> - The function which restores overwritten branch code.
>>> - The function which unload the patch files.
>>> 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.
>>> Pannus project: http://pannus.sourceforge.net/
>>> Live patching implementation:
>>> Ralf Flaxa wrote:
>>>> Then it should be stated very explicitely that this feature may only
>>>> be used for and by applications and that it is forbidden to patch
>>>> the underlying distro with it.
>>>> I am wondering why the distro then should even provide that
>>>> Why doesn't the app provider take care of this himself then if it is
>>>> meant for his app?
>>>> On Mon, Mar 28, 2005 at 03:19:07PM -0700, Steven Dake wrote:
>>>>>> From the distro perspective, I can understand your serious discomfort
>>>>> with supporting live patching of applications specific to the
>>>>> system (and in the distributor's support domain).
>>>>> The live patching feature, atleast during the specs development, was
>>>>> targetd for use in carrier(and other interested parties) applications
>>>>> which are supported and maintained by the carriers/others. We never
>>>>> stated in the requirements that the distribution itself must support
>>>>> live patching of the entire system. If you point out the specific
>>>>> requirement that requires or implies this, then it is something that
>>>>> needs adjustment in the specification..
>>>>> Perhaps wording of the intended use (for carrier applications, not for
>>>>> distro upgrades) would be helpful.
>>>>> If live patching then becomes a "customer issue", it is really of no
>>>>> concern to a distro whether the customer chooses to patch their own
>>>>> applications or not.
>>> 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
>>> cgl_discussion mailing list
>>> cgl_discussion at lists.osdl.org
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