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

Takashi Ikebe ikebe.takashi at lab.ntt.co.jp
Tue Mar 29 01:38:31 PST 2005

Ralf, I just fix some point which you are worrying, and everyone suggedted.
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 
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 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
- 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 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.

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