linux-kernel - Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE

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: <CA+b37P3BywWsuNgjVfvxxK2acAbV7qd6R5UJd1UEYdHHuQ56ag@mail.gmail.com>
Date:	Fri, 6 Dec 2013 12:24:29 +0530
From:	Sandeepa Prabhu <sandeepa.prabhu@...aro.org>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	x86@...nel.org, lkml <linux-kernel@...r.kernel.org>,
	"Steven Rostedt (Red Hat)" <rostedt@...dmis.org>,
	systemtap@...rceware.org, "David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and
 fixes crash bugs

>> I am not sure if this question is related, uprobes or ftrace code does
>> not  define __kprobes, so is it safe to place kprobe on uprobes or
>> ftrace code?
>
> Yes, it is "safe" in qualitative meaning. But for ftrace code, it could
> give a performance impact by miss-hitting. Since uprobe is independent
> from kprobe, it should work.
>
>> Is it expected from arch code to support such cases?
>
> Yes, the arch dependent implementation is the key. If it shares some
> code which can be called from miss-hit path, it should be blacklisted.
well, isn't the blacklist only for those routines that can not be
handled or may crash kernel, like the code sections called from
exception kprobes exception handlers etc?
suppose if the probe on routine can miss-hit (probes re-cursing) but
can be handled, it's only a quantitative issue (i.e. performance
impact) so it should be *user's* problem right? I mean, as you said
earlier about having white-list or a performance gatekeeper
(systemtap), one can avoid such cases by white list or removing
miss-hit probes dynamically.  But a blacklisting a symbol means
placing a probe on that *can not be handled* and can crash the system,
is it correct?

Thanks,
Sandeepa

>
> Thank you,
>
> --
> Masami HIRAMATSU
> IT Management Research Dept. Linux Technology 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/