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
next prev 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox