linux-kernel - Re: [PATCH] Documentation: kprobes: Document jprobes stack copying limitations

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: <20160813084626.06b972afea3814959ab64ebc@kernel.org>
Date:	Sat, 13 Aug 2016 08:46:26 +0900
From:	Masami Hiramatsu <mhiramat@...nel.org>
To:	David Long <dave.long@...aro.org>
Cc:	Ananth N Mavinakayanahalli <ananth@...ux.vnet.ibm.com>,
	Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
	"David S. Miller" <davem@...emloft.net>,
	Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	sparclinux@...r.kernel.org, catalin.marinas@....com,
	daniel.thompson@...aro.org, marc.zyngier@....com,
	Mark Brown <broonie@...nel.org>
Subject: Re: [PATCH] Documentation: kprobes: Document jprobes stack copying
 limitations

On Fri, 12 Aug 2016 16:24:44 -0400
David Long <dave.long@...aro.org> wrote:

> From: "David A. Long" <dave.long@...aro.org>
> 
> Some architectures (i.e.: sparc64 and arm64) make reasonable partial stack
> duplication for jprobes problematic. Document this.
> 
> Signed-off-by: David A. Long <dave.long@...aro.org>

Looks good to me.

Acked-by: Masami Hiramatsu <mhiramat@...nel.org>

Thanks!

> ---
>  Documentation/kprobes.txt | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
> index 1f9b3e2..1f6d45a 100644
> --- a/Documentation/kprobes.txt
> +++ b/Documentation/kprobes.txt
> @@ -103,6 +103,16 @@ Note that the probed function's args may be passed on the stack
>  or in registers.  The jprobe will work in either case, so long as the
>  handler's prototype matches that of the probed function.
>  
> +Note that in some architectures (e.g.: arm64 and sparc64) the stack
> +copy is not done, as the actual location of stacked parameters may be
> +outside of a reasonable MAX_STACK_SIZE value and because that location
> +cannot be determined by the jprobes code. In this case the jprobes
> +user must be careful to make certain the calling signature of the
> +function does not cause parameters to be passed on the stack (e.g.:
> +more than eight function arguments, an argument of more than sixteen
> +bytes, or more than 64 bytes of argument data, depending on
> +architecture).
> +
>  1.3 Return Probes
>  
>  1.3.1 How Does a Return Probe Work?
> -- 
> 2.5.0
> 


-- 
Masami Hiramatsu <mhiramat@...nel.org>