On Mon, Nov 11, 2013 at 10:51:52AM +0000, Masami Hiramatsu wrote:
(2013/11/11 16:54), Masami Hiramatsu wrote:
In fact, how do you avoid a race with hardware breakpoints? E.g., somebody places a hardware breakpoint on an instruction in the kernel for which kprobes has patched in a brk. We take the hardware breakpoint, disable the breakpoint and set up a single step before returning to the brk. The brk then traps, but we must take care not to disable single-step and/or unmask debug exceptions, because that will cause the hardware breakpoint code to re-arm its breakpoint before we've stepped off the brk instruction.
Hmm, frankly to say, this kind of race issue is not seriously discussed on x86 too, since kgdb is still a special tool (not used on the production system). I think under such situation kgdb operator must have full control of the system, and he can (and has to) avoid such kind of race.
Masami,
Hmm I think in same lines, but not sure if we expect kprobes to be able to work fool-proof along with kgdb or hw breakpoints ?
For hw breakpoint, yes, we finally get check each other to safely use it even if one rejects the other one at some points(address). Since the hw breakpoint is already open for normal user via perf, we should do it. But the policy still needs to be discussed.
OK, I've ensured that the hw_breakpoint (from perf) can work with kprobes (from ftrace) at the same address on x86. So if arm64 already support hw_breakpoint on perf, kprobes should work with it.
Single-stepping on x86 is different to the step behaviour on arm64 afaik. On ARM, we have to manually remove the breakpoint, perform a single-step, then add the breakpoint again. If we re-enable debug exceptions in the kprobe handler, the step will complete early and we'll never step off the breakpoint.
Sandeepa: I think you need to retry Masami's test on the arm64 model, since I'm fairly sure it won't work as expected without some additional code.
Will