kreplace: Rebootless kernel updates

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.

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

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 <[email protected]>

---
 arch/x86/kernel/kprobes.c |   18 ++++++++++++++----
 include/linux/kprobes.h   |    5 ++++-
 kernel/kprobes.c          |   37 ++++++++++++++++++++++++++++++++-----
 3 files changed, 50 insertions(+), 10 deletions(-)

arch/x86/kernel/kprobes.c +0 -0

index 6c27679..9e2ea2b 100644
@@ -340,9 +340,13 @@ static void __kprobes fix_riprel(struct kprobe *p)
 #endif
 }

include/linux/kprobes.h +1 -1

index 497b1d1..91e83fb 100644
@@ -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);

Quoted 3 lines · Nikanth Karthikesan

This RFC patch adds support for limited form of rebootless kernel patching even without building the entire kernel.

Quoted 4 lines

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

Quoted 5 lines

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?

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

Undoubtedly, but a good warning is the best way to keep people warned about running such code :) It is a useful thing to have and to run, but running it would take more guts than anything else.

Quoted 1 line · Ananth N Mavinakayanahalli

On Fri, Nov 21, 2008 at 05:20:25PM +0530, Nikanth Karthikesan wrote:

I had a patch for x86 a long time ago in 2005, but I never posted it :(

Yes and we need to be careful about licensing, tainting the kernel with such an implementation.

Quoted 3 lines

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

Undoubtedly, but a good warning is the best way to keep people warned about running such code :) It is a useful thing to have and to run, but running it would take more guts than anything else.

Quoted 3 lines · Nikanth Karthikesan

This RFC patch adds support for limited form of rebootless kernel patching even without building the entire kernel.

Quoted 4 lines

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

Quoted 5 lines

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?

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

Quoted 19 lines

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 <[email protected]>

---
 arch/x86/kernel/kprobes.c |   18 ++++++++++++++----
 include/linux/kprobes.h   |    5 ++++-
 kernel/kprobes.c          |   37 ++++++++++++++++++++++++++++++++-----
 3 files changed, 50 insertions(+), 10 deletions(-)

arch/x86/kernel/kprobes.c +0 -0

index 6c27679..9e2ea2b 100644
@@ -340,9 +340,13 @@ static void __kprobes fix_riprel(struct kprobe *p)
 #endif
 }

arch/x86/kernel/kprobes.c static void __kprobes fix_riprel(struct kprobe *p) · line 349

Quoted 10 lines

arch/x86/kernel/kprobes.c +5 -2

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

...

Quoted 19 lines

include/linux/kprobes.h +3 -1

index 497b1d1..91e83fb 100644
@@ -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);

include/linux/kprobes.h int register_kprobes(struct kprobe **kps, int num); · line 250

Quoted 6 lines

include/linux/kprobes.h +1 -0

 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()?

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.

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

Hi Nikanth,

Nikanth Karthikesan wrote:

Hmm,
Would you like to replace a function to another function? If so, AFAIK, you can do that with kprobe and below pre_handler. (see booster enabled path in setup_singlestep())

pre_handler(...)

{
	reset_current_kprobe();	/* this kprobe doesn't need any more */
	regs->ip = new_function;	/* change IP to new function */
	preempt_enable_no_resched();	/* recover preempt count */
	return 1;	/* No need to setup singlestep */
}

Quoted 9 lines · On Friday 21 November 2008 20:09:52 Masami Hiramatsu wrote:

Hi Nikanth,

Nikanth Karthikesan wrote:

Hmm,
Would you like to replace a function to another function? If so, AFAIK, you can do that with kprobe and below pre_handler. (see booster enabled path in setup_singlestep())

Quoted 9 lines

pre_handler(...)

{
	reset_current_kprobe();	/* this kprobe doesn't need any more */
	regs->ip = new_function;	/* change IP to new function */
	preempt_enable_no_resched();	/* recover preempt count */
	return 1;	/* No need to setup singlestep */
}

So, am I seeing worries to enable something, which is already possible, but just not documented?

Quoted 20 lines · Nikanth Karthikesan

Quoted 9 lines · On Friday 21 November 2008 20:09:52 Masami Hiramatsu wrote:

Hi Nikanth,

Nikanth Karthikesan wrote:

Hmm,
Would you like to replace a function to another function? If so, AFAIK, you can do that with kprobe and below pre_handler. (see booster enabled path in setup_singlestep())

Quoted 9 lines

pre_handler(...)

{
     reset_current_kprobe(); /* this kprobe doesn't need any more */
     regs->ip = new_function;        /* change IP to new function */
     preempt_enable_no_resched();    /* recover preempt count */
     return 1;       /* No need to setup singlestep */
}

Quoted 2 lines

So, am I seeing worries to enable something, which is already possible, but just not documented?

Actually, you can do this with kprobes, but not documented, because the regs->ip setup depends on arch. (above code is only for x86/x86-64).

I think it's easier to just provide above pre_handler for each arch than jprobe-based kreplace approach.

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.

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

[kreplace] is currently a x86_64 only _hack_

Hello,

Quoted 1 line

[kreplace] is currently a x86_64 only _hack_

The point of Ksplice is to be a hot update system that isn't a hack. Ksplice is quite far along at this point; it implements many safety and automation features that kreplace doesn't address. Is there something in particular that discouraged you from using Ksplice?

I suspect that it wasn't mainline?

The usual problem is that it's much easier to get simple patches in than complicated ones.

Hello,

Quoted 1 line

[kreplace] is currently a x86_64 only _hack_

The point of Ksplice is to be a hot update system that isn't a hack. Ksplice is quite far along at this point; it implements many safety and automation features that kreplace doesn't address.

Is there something in particular that discouraged you from using Ksplice?