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

[Eugene Shatokhin <eugene.shatokhin@rosalab.ru>]

Hello,

It took a while to properly implement the technique I wrote about 
earlier but I have prepared a working example. Initially, I did not 
reset the Kprobe properly and that caused difficult-to-debug problems. 
Anyway, it works now.

In this example, Kprobes are used to execute my functions before and 
after the insn of interest, in the same context as the insn w.r.t. the 
interrupts and the preemption. There are some drawbacks and tricky 
points, but still.

I tested this code on my simple modules as well as on the network 
drivers (atl1c, e1000e, e1000) in Ubuntu 14.04 and ROSA R5 (x86, both 32 
and 64-bit).

If you are interested, the source code is here: 
https://abf.io/spectre/kernel-examples#?path=kprobe_lite. Most of the 
logic is in module.c, the details are in Readme.txt.

I will try now to reimplement the relevant parts of our RaceHound system 
using the Kprobes and the technique from the example.

By the way, while working on that code, I found that Kprobes consider 
the following insns as not boostable (can_boost() in 
arch/x86/kernel/kprobes/core.c):

* opcodes c0, c1, d0 - d3 with ModRM.reg != 110(b): ROL, ROR, RCL, RCR, 
SHL/SAL, SHR, SAR (Grp 2-1A)
* opcodes f6 and f7 with ModRM.reg != 001(b): TEST, NOT, NEG, MUL, IMUL, 
DIV, IDIV (Grp 3-1A)
* opcodes fe and ff with ModRM.reg being 000(b) or 001(b): INC, DEC (Grp 
4-1A and 5-1A)
* opcode 0f c7 with ModRM.reg == 001(b): CMPXCHG8B, CMPXCHG16B.

Not sure why Kprobes do so.

Regards,
Eugene