linux-kernel - Kprobes: pre-handler with interrupts enabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <54EB4194.7040901@rosalab.ru>
Date:	Mon, 23 Feb 2015 18:04:52 +0300
From:	Eugene Shatokhin <eugene.shatokhin@...alab.ru>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
CC:	linux-kernel@...r.kernel.org
Subject: Kprobes: pre-handler with interrupts enabled - is it possible?

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.

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?

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.

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?

Regards,
Eugene

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