[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 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 
there.

Anyway, "kernel" is implementation method, so I changed description and 
outcome.
---------------------------------------------------
Description
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.
> 
> -Corey
> 
> Brian F. G. Bidulock wrote:
> 
>> Takashi,
>>
>> 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 
>> application
>> (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
>> both.
>>
>> 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 
>> trick.
>> 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.
>>
>> --brian
>>
>> On Tue, 29 Mar 2005, Takashi Ikebe wrote:
>>
>>  
>>
>>> Ralf, I just fix some point which you are worrying, and everyone 
>>> suggedted.
>>> Please check and tell me your impression.
>>> ---------------------------------------------------
>>>
>>> Description
>>> 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
>>> availability.
>>>
>>> Desired Outcome
>>> Mainline kernel acceptance.
>>> Distro acceptance to increase system availability while staying in 
>>> sync with
>>> distro releases.
>>>
>>> Participants/Roles
>>> 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 
>>> applications
>>> which designed to use the requirement.
>>>
>>> Scenarios
>>> On operation, system administrators apply patch with the requirement as
>>> following scenario;
>>> 1.System administrators obtains patch modules from application 
>>> developer/administrators.
>>> 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 
>>> area.
>>> - 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
>>> patch.
>>> - 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
>>> process.
>>> 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.
>>>
>>> References
>>> Pannus project: http://pannus.sourceforge.net/
>>> Live patching implementation:
>>> http://prdownloads.sourceforge.net/pannus/pannus_en.pdf
>>>
>>>
>>> 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 
>>>> functionality?
>>>> Why doesn't the app provider take care of this himself then if it is 
>>>> just
>>>> meant for his app?
>>>>
>>>>     Ralf
>>>>
>>>> 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 
>>>>> operating
>>>>> 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.
>>>>>
>>>>> Regards
>>>>> -steve
>>>>>       
>>>
>>> -- 
>>> 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
>>> http://lists.osdl.org/mailman/listinfo/cgl_discussion
>>>   
>>
>>
>>
>>  
>>
> 


-- 
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