From: Balbir Singh <balbir@linux.vnet.ibm.com>
To: ananth@in.ibm.com
Cc: Nikanth Karthikesan <knikanth@suse.de>,
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
Subject: Re: [RFC] kreplace: Rebootless kernel updates
Date: Fri, 21 Nov 2008 21:34:43 +0530 [thread overview]
Message-ID: <4926DC1B.1020809@linux.vnet.ibm.com> (raw)
In-Reply-To: <20081121133800.GA5244@in.ibm.com>
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 had a patch for x86 a long time ago in 2005, but I never posted it :(
>> 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?
>
Yes and we need to be careful about licensing, tainting the kernel with such an
implementation.
> 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.
--
Balbir
next prev parent reply other threads:[~2008-11-21 16:08 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 [this message]
2008-11-21 17:29 ` Chris Friesen
2008-11-24 11:07 ` Nikanth Karthikesan
2008-11-24 11:07 ` Nikanth Karthikesan
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=4926DC1B.1020809@linux.vnet.ibm.com \
--to=balbir@linux.vnet.ibm.com \
--cc=ananth@in.ibm.com \
--cc=andersk@ksplice.com \
--cc=contact@ksplice.com \
--cc=davem@davemloft.net \
--cc=jbarnold@ksplice.com \
--cc=knikanth@suse.de \
--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.