linux-kernel - Re: Re: 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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <54EC5160.7090400@hitachi.com>
Date:	Tue, 24 Feb 2015 19:24:32 +0900
From:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
To:	Eugene Shatokhin <eugene.shatokhin@...alab.ru>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Re: Kprobes: pre-handler with interrupts enabled - is it possible?

(2015/02/24 15:04), Eugene Shatokhin wrote:
> 24.02.2015 06:47, Masami Hiramatsu пишет:
>> 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).
> 
> Yes, that is why I am asking.
> 
>> 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 think, yes. When a software breakpoint hits, my system decodes the 
> instruction, finds the address that is about to be accessed and tries to 
> place a hardware breakpoint on that memory area.
> 
> There are only 4 hardware breakpoints a CPU can use on x86, so if the 
> software breakpoint hits too often, the system will not be able to 
> process all hits anyway because all HW breakpoints may be already in use.
> 
>> Would you mean sleep on your handler??
> 
> No, I use mdelay(). It is, in essence, a busy-wait loop as far as I 
> know. The delay intervals may vary, the default is 5 jiffies.

Hmm, here I couldn't understand. If mdelay() does busy-wait loop, why
would you like to enable irq??
Other code doesn't work on the core while waiting.

Thank you,


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@...achi.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/