Re: Kprobes: pre-handler with interrupts enabled - is it possible?

[Masami Hiramatsu]

Hello,

(2015/02/24 0:04), Eugene Shatokhin wrote:
> Hi,
> 
> 
> First of all, many thanks to the developers of Kprobes! I use both 
> Kprobes and parts of their code a lot in my projects these days.
> 
> As far as I can see, the pre-handlers of Kprobes run with interrupts and 
> preemption disabled on the given CPU, at least on x86 without Kprobe 
> optimization.

Even with kprobe optimization, I also disabled both since it must be
transparently optimized (this means both optimized/non-optiomized kprobes
have to have same behavior).
Note that x86 int3 trap handler automatically disables local interrupts.


> Is it possible, however, to use Kprobes to somehow execute my code 
> before a given instruction but with the same restrictions as the 
> original instruction, at least, w.r.t. the interrupts?

No, that is not allowed. I mean, you can do anything you want to do
on your handler (enabling preemption/irq etc.) but the result may be
not safe (it can crash your kernel, but it's not a kprobes' bug).

Actually, enable interrupts on kprobe handlers can cause reentering
kprobes (by kprobes on interrupt handlers), and currently kprobe skips
all those reentered kprobes.
Is it acceptable that some of your kprobe handlers are not fired when
hitting?

> I mean, if the instruction is executed with interrupts enabled, my code 
> would also execute with interrupts enabled, etc.
> 
> If it is possible, how would you recommend to do that? Without patching 
> the implementation of Kprobes, I mean.
> 
> Same for preemption, but, it seems, Kprobes really need it disabled, at 
> least to be able to use kprobe_running() and other per-cpu data.
> 
> In RaceHound project I am now working on 
> (https://github.com/winnukem/racehound/tree/rh_rework), the breakpoints 
> are used to detect data races in the kernel code in runtime. Software 
> breakpoints for the code, hardware breakpoints for the data that is 
> about to be accessed.
> 
> However, to make it all work, the detector introduces delays before the 
> instructions of interest. I could do this in Kprobes' pre-handlers but 
> the interrupts would always be disabled on the current CPU during the 
> delays, which is no good.

Would you mean sleep on your handler?? No, that is NOT possible. We are
in an exception context, that must not be preempted nor sleep.
How long you need to add delay? Can you use cpu_relax busy loops on it?

> So far, I implemented it using software breakpoints directly, without 
> Kprobes. The pre-handlers are executed then in the same context as the 
> original instructions.
> 
> Still the implementation becomes more and more like Kprobes in some 
> places over time. If there is a way to avoid reinventing the wheel and 
> just use Kprobes, I would do that.
> 
> So, any ideas?

As I said, I recommend you to use some kind of busy-loop wait for making
delays on it. Please don't try to enable irq.

Thank you,

> 
> Regards,
> Eugene
> 


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@xxxxxxxxxxx


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/