lkml.org 
[lkml]   [2009]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH -tip v14 03/12] kprobes: checks probe address is instruction boudary on x86
    On Tue, Aug 18, 2009 at 08:19:33PM -0400, Masami Hiramatsu wrote:
    > Frederic Weisbecker wrote:
    > > On Tue, Aug 18, 2009 at 07:17:39PM -0400, Masami Hiramatsu wrote:
    > >> Frederic Weisbecker wrote:
    > >>>> + while (addr < paddr) {
    > >>>> + kernel_insn_init(&insn, (void *)addr);
    > >>>> + insn_get_opcode(&insn);
    > >>>> +
    > >>>> + /* Check if the instruction has been modified. */
    > >>>> + if (insn.opcode.bytes[0] == BREAKPOINT_INSTRUCTION) {
    > >>>> + ret = recover_probed_instruction(buf, addr);
    > >>>
    > >>>
    > >>>
    > >>> I'm confused about the reason of this recovering. Is it to remove
    > >>> kprobes behind the current setting one in the current function?
    > >>
    > >> No, it recovers just an instruction which is probed by a kprobe,
    > >> because we need to know the first byte of this instruction for
    > >> decoding it.
    >
    > Ah, sorry, it was not accurate. the function recovers an instruction
    > on the buffer(buf), not on the real kernel text. :)



    Ah ok. I'll just add a small comment about that then, and apply
    it.



    > >>
    > >> Perhaps we'd better to have more generic interface (text_peek?)
    > >> for it because another subsystem (e.g. kgdb) may want to insert int3...
    > >>
    > >> Thank you,
    > >
    > >
    > > Aah, I see now, it's to keep a sane check of the instructions
    > > boundaries without int 3 artifacts in the middle.
    > >
    > > But in that case, you should re-arm the breakpoint after your
    > > check, right?
    > >
    > > Or may be you could do the check without repatching?
    >
    > Yes, it doesn't modify kernel text, just recover an original
    > instruction from kernel text and backup byte on a buffer.


    Ok.


    > > May be by doing a copy of insn.opcode.bytes and replacing bytes[0]
    > > with what a random kprobe has stolen?
    >
    > Hm, no, this function is protected from other kprobes by kprobe_mutex.
    >
    > Thank you,



    Right, thanks!



    > --
    > Masami Hiramatsu
    >
    > Software Engineer
    > Hitachi Computer Products (America), Inc.
    > Software Solutions Division
    >
    > e-mail: mhiramat@redhat.com
    >



    \
     
     \ /
      Last update: 2009-08-19 02:49    [W:3.658 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site