All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nikanth Karthikesan <knikanth@suse.de>
To: ananth@in.ibm.com
Cc: linux-kernel@vger.kernel.org, davem@davemloft.net,
	mhiramat@redhat.com, contact@ksplice.com, jbarnold@ksplice.com,
	tabbott@ksplice.com, wdaher@ksplice.com, andersk@ksplice.com,
	Balbir Singh <balbir@linux.vnet.ibm.com>
Subject: Re: [RFC] kreplace: Rebootless kernel updates
Date: Mon, 24 Nov 2008 16:37:26 +0530	[thread overview]
Message-ID: <200811241637.27198.knikanth@suse.de> (raw)
In-Reply-To: <20081121133800.GA5244@in.ibm.com>

On Friday 21 November 2008 19:08:00 Ananth N Mavinakayanahalli wrote:
> On Fri, Nov 21, 2008 at 05:20:25PM +0530, Nikanth Karthikesan wrote:
> > This RFC patch adds support for limited form of rebootless kernel
> > patching even without building the entire kernel.
> >
> > When looking for a shortcut to avoid the rebuild/reboot cycle when
> > hacking the kernel - the ksplice[1] was posted. This patch extends
> > kprobes to do something similar, which would require even lesser time to
> > _experiment_ with the running kernel.
>
> There have been other implementations of this feature, I am sure quite a
> few people would have objections to having this as part of the kernel :-)
>

I think the few would be quiet large ;)

> > This small patch extends jprobes so that the jprobe's handler is executed
> > but skips executing the actual function. But this has its own limitations
> > such as Cannot access symbols not exported for modules (ofcourse hacks
> > like pointers[2] can be used.), problems related to return values[3],
> > etc... This is currently a x86_64 only _hack_.
>
> There are many other issues too... How do you enforce correct usage of this
> infrastrucutre? What prevents people from overriding core-kernel
> functions with their own?
>

I agree, this is incomplete.

> Kprobes themselves provide enough ammunition to users to shoot themselves
> in the foot, but this is way more dangerous than that.
> ...
>

Yes. 

> > The kernel patch for kreplace, an extension to kprobes to do hot
> > patching. Only on x86_64. Do not try this on any other platforms without
> > modifying.
> >
> > Signed-off-by: Nikanth Karthikesan <knikanth@suse.de>
> >
> > ---
> >  arch/x86/kernel/kprobes.c |   18 ++++++++++++++----
> >  include/linux/kprobes.h   |    5 ++++-
> >  kernel/kprobes.c          |   37 ++++++++++++++++++++++++++++++++-----
> >  3 files changed, 50 insertions(+), 10 deletions(-)
> >
> > diff --git a/arch/x86/kernel/kprobes.c b/arch/x86/kernel/kprobes.c
> > index 6c27679..9e2ea2b 100644
> > --- a/arch/x86/kernel/kprobes.c
> > +++ b/arch/x86/kernel/kprobes.c
> > @@ -340,9 +340,13 @@ static void __kprobes fix_riprel(struct kprobe *p)
> >  #endif
> >  }
> >
> > -static void __kprobes arch_copy_kprobe(struct kprobe *p)
> > +static void __kprobes arch_copy_kprobe(struct kprobe *p, int replace)
> >  {
> > -	memcpy(p->ainsn.insn, p->addr, MAX_INSN_SIZE *
> > sizeof(kprobe_opcode_t)); +	if (replace)
> > +		memcpy(p->ainsn.insn, ((unsigned char []){0xc3}), 1);
> > +	else
> > +		memcpy(p->ainsn.insn, p->addr,
> > +				MAX_INSN_SIZE * sizeof(kprobe_opcode_t));
>
> This is limiting - especially since we allow multiple probes at the same
> address. You modify the instruction underneath to always be a ret.
>
> It also breaks existing functionality -- especially aggregate probes and
> return probes.
>

Oh, yeah. And it is possible to implement this correctly in other ways! 

> ...
>
> > diff --git a/include/linux/kprobes.h b/include/linux/kprobes.h
> > index 497b1d1..91e83fb 100644
> > --- a/include/linux/kprobes.h
> > +++ b/include/linux/kprobes.h
> > @@ -202,7 +202,7 @@ static inline int init_test_probes(void)
> >  #endif /* CONFIG_KPROBES_SANITY_TEST */
> >
> >  extern struct mutex kprobe_mutex;
> > -extern int arch_prepare_kprobe(struct kprobe *p);
> > +extern int arch_prepare_kprobe(struct kprobe *p, int replace);
> >  extern void arch_arm_kprobe(struct kprobe *p);
> >  extern void arch_disarm_kprobe(struct kprobe *p);
> >  extern int arch_init_kprobes(void);
> > @@ -240,11 +240,14 @@ int register_kprobes(struct kprobe **kps, int num);
> >  void unregister_kprobes(struct kprobe **kps, int num);
> >  int setjmp_pre_handler(struct kprobe *, struct pt_regs *);
> >  int longjmp_break_handler(struct kprobe *, struct pt_regs *);
> > +int register_kreplace(struct jprobe *p);
> > +void unregister_kreplace(struct jprobe *p);
> >  int register_jprobe(struct jprobe *p);
> >  void unregister_jprobe(struct jprobe *p);
> >  int register_jprobes(struct jprobe **jps, int num);
> >  void unregister_jprobes(struct jprobe **jps, int num);
> >  void jprobe_return(void);
> > +void set_ax(unsigned long);
>
> Please choose a better arch agnostic naming scheme -- set_ret()?
>

I did write more helpers to return values of different sizes, but only their 
function names look good. So, I didnt post them as I wanted to know the 
comments for the idea first.

Thanks a lot for your comments. 

Thanks
Nikanth






  parent reply	other threads:[~2008-11-24 11:06 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-21 11:50 [RFC] kreplace: Rebootless kernel updates Nikanth Karthikesan
2008-11-21 13:38 ` Ananth N Mavinakayanahalli
2008-11-21 16:04   ` Balbir Singh
2008-11-21 17:29     ` Chris Friesen
2008-11-24 11:07     ` Nikanth Karthikesan
2008-11-24 11:07   ` Nikanth Karthikesan [this message]
2008-11-21 14:39 ` Masami Hiramatsu
2008-11-24 11:07   ` Nikanth Karthikesan
2008-11-24 15:15     ` Masami Hiramatsu
2008-11-26  2:48       ` Nikanth K
2008-11-21 20:19 ` Anders Kaseorg
2008-11-22  3:46 ` Jeff Arnold
2008-11-23 19:39   ` Andi Kleen
2008-11-23 20:53     ` Jeff Arnold
2008-11-24 11:07   ` Nikanth Karthikesan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200811241637.27198.knikanth@suse.de \
    --to=knikanth@suse.de \
    --cc=ananth@in.ibm.com \
    --cc=andersk@ksplice.com \
    --cc=balbir@linux.vnet.ibm.com \
    --cc=contact@ksplice.com \
    --cc=davem@davemloft.net \
    --cc=jbarnold@ksplice.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@redhat.com \
    --cc=tabbott@ksplice.com \
    --cc=wdaher@ksplice.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.