linux-kernel - Re: [PATCH -tip v2 1/3] kprobes: Introduce nokprobe annotation for non-probe-able functions

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]

Date:	Fri, 1 Nov 2013 09:55:10 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc:	Ingo Molnar <mingo@...nel.org>,
	"David S. Miller" <davem@...emloft.net>, x86@...nel.org,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH -tip v2 1/3] kprobes: Introduce nokprobe annotation for
 non-probe-able functions

On Fri, 01 Nov 2013 11:25:32 +0000
Masami Hiramatsu <masami.hiramatsu.pt@...achi.com> wrote:

> Instead of __kprobes annotation, introduce 'nokprobe' new annotation
> to annotate that the function is not probed by kprobes.
> 
> Previously the '__kprobes' is used just for avoiding probes on
> kprobes-related functions which will be used from kprobes. However
> nowadays we use it for prohibiting probing the functions implicitly
> invoked from kprobes int3 handler, since that causes infinit-loop
> lockup or sudden reboot. In this case, the annotated functions are
> not limited in the kprobes-related functions, and __kprobes looks
> very confusing. (Moreover, actually, most of control-side kprobes
> functions like as register_kprobes() are safely probed by kprobes)
> 
> Thus, we decide to introduce 'nokprobe' new annotation. We leave
> "__kprobes" just for compatibility but it should be replaced or
> removed eventually.
> 
> New commits must use 'nokprobe' for this purpose.
> 
> Signed-off-by: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
> Cc: Ingo Molnar <mingo@...nel.org>
> Cc: Ananth N Mavinakayanahalli <ananth@...ibm.com>
> Cc: "David S. Miller" <davem@...emloft.net>
> ---
>  include/linux/compiler.h |    6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 92669cd..173c64e 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -353,8 +353,10 @@ void ftrace_likely_update(struct ftrace_branch_data *f, int val, int expect);
>  
>  /* Ignore/forbid kprobes attach on very low level functions marked by this attribute: */
>  #ifdef CONFIG_KPROBES
> -# define __kprobes	__attribute__((__section__(".kprobes.text")))
> +# define nokprobe	__attribute__((__section__(".kprobes.text")))

I wonder if we should have both a __kprobes and nokprobe annotation,
such that we have:

# define __kprobes	__attribute__((__section__(".kprobes.text")))
# define nokprobe	__attribute__((__section__(".nokprobes.text")))

Then use __kprobes for the actual kprobes code, and nokprobe for all
the places that must not be traced by kprobes.

It just seems strange to me grouping kprobes code with non kprobes code.

-- Steve


>  #else
> -# define __kprobes
> +# define nokprobe
>  #endif
> +#define __kprobes nokprobe
> +
>  #endif /* __LINUX_COMPILER_H */
> 

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