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

Tue Mar 29 02:40:40 PST 2005

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

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
bidulock at openss7.org    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦