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: <20131211133423.GB3101@gmail.com>
Date:	Wed, 11 Dec 2013 14:34:23 +0100
From:	Ingo Molnar <mingo@...nel.org>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc:	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Sandeepa Prabhu <sandeepa.prabhu@...aro.org>, 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


* Masami Hiramatsu <masami.hiramatsu.pt@...achi.com> wrote:

> > So why are annotations needed at all? What can happen if an 
> > annotation is missing and a piece of code is probed which is also 
> > used by the kprobes code internally - do we crash, lock up, 
> > misbehave or handle it safely?
> 
> The kprobe has recursion detector, [...]

It's the 'current_kprobe' percpu variable, checked via 
kprobe_running(), right?

> [...] but it is detected in the kprobe exception(int3) handler, this 
> means that if we put a probe before detecting the recursion, we'll 
> do an infinite recursion.

So only the (presumably rather narrow) code path leading to the 
recursion detection code has to be annotated, correct?

> And also, even if we can detect the recursion, we can't stop the 
> kernel, we need to skip the probe. This means that we need to 
> recover to the main execution path by doing single step. As you may 
> know, since the single stepping involves the debug exception, we 
> have to avoid proving on that path too. Or we'll have an infinite 
> recursion again.

I don't see why this is needed: if a "probing is disabled" recursion 
flag is set the moment the first probe fires, and if it's only cleared 
once all processing is finished, then any intermediate probes should 
simply return early from int3 and not fire.

What am I missing?

Thanks,

	Ingo
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ