All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	Aleksa Sarai <cyphar@cyphar.com>,
	"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jonathan Corbet <corbet@lwn.net>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Shuah Khan <shuah@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Brendan Gregg <bgregg@netflix.com>,
	Christian Brauner <christian@brauner.io>,
	Aleksa Sarai <asarai@suse.de>,
	netdev@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Subject: Re: [PATCH v3 1/2] kretprobe: produce sane stack traces
Date: Sat, 3 Nov 2018 13:30:21 -0400	[thread overview]
Message-ID: <20181103133021.6676708c@vmware.local.home> (raw)
In-Reply-To: <20181104013430.9d3e91b8ebbae7dcb6860ef1@kernel.org>

On Sun, 4 Nov 2018 01:34:30 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> 
> > I was thinking of a bitmask that represents the handlers, and use that
> > to map which handler gets called for which shadow entry for a
> > particular task.  
> 
> Hmm, I doubt that is too complicated and not scalable. I rather like to see
> the open shadow entry...

It can scale and not too complex (I already played a little with it).
But that said, I'm not committed to it, and using the shadow stack is
also an interesting idea.

> 
> entry: [[original_retaddr][function][modified_retaddr]]
> 
> So if there are many users on same function, the entries will be like this 
> 
> [[original_return_address][function][trampoline_A]]
> [[trampline_A][function][trampoline_B]]
> [[trampline_B][function][trampoline_C]]
> 
> And on the top of the stack, there is trampline_C instead of original_return_address.
> In this case, return to trampoline_C(), it jumps back to trampline_B() and then
> it jumps back to trampline_A(). And eventually it jumps back to
> original_return_address.

Where are trampolines A, B, and C made? Do we also need to dynamically
create them? If I register multiple function tracing ones, each one
will need its own trampoline?

> 
> This way, we don't need allocate another bitmap/pages for the shadow stack.
> We only need a shadow stack for each task.
> Also, unwinder can easily find the trampline_C from the shadow stack and restores
> original_return_address. (of course trampline_A,B,C must be registered so that
> search function can skip it.)

What I was thinking was to store a count and the functions to be called:


	[original_return_address]
	[function_A]
	[function_B]
	[function_C]
	[ 3 ]

Then the trampoline that processes the return codes for ftrace (and
kretprobes and everyone else) can simply do:

	count = pop_shadow_stack();
	for (i = 0; i < count; i++) {
		func = pop_shadow_stack();
		func(...);
	}
	return_address = pop_shadow_stack();

That way we only need to register a function to the return handler and
it will be called, without worrying about making trampolines. There
will just be a single trampoline that handles all the work.

-- Steve


WARNING: multiple messages have this Message-ID (diff)
From: rostedt at goodmis.org (Steven Rostedt)
Subject: [PATCH v3 1/2] kretprobe: produce sane stack traces
Date: Sat, 3 Nov 2018 13:30:21 -0400	[thread overview]
Message-ID: <20181103133021.6676708c@vmware.local.home> (raw)
In-Reply-To: <20181104013430.9d3e91b8ebbae7dcb6860ef1@kernel.org>

On Sun, 4 Nov 2018 01:34:30 +0900
Masami Hiramatsu <mhiramat at kernel.org> wrote:
> 
> > I was thinking of a bitmask that represents the handlers, and use that
> > to map which handler gets called for which shadow entry for a
> > particular task.  
> 
> Hmm, I doubt that is too complicated and not scalable. I rather like to see
> the open shadow entry...

It can scale and not too complex (I already played a little with it).
But that said, I'm not committed to it, and using the shadow stack is
also an interesting idea.

> 
> entry: [[original_retaddr][function][modified_retaddr]]
> 
> So if there are many users on same function, the entries will be like this 
> 
> [[original_return_address][function][trampoline_A]]
> [[trampline_A][function][trampoline_B]]
> [[trampline_B][function][trampoline_C]]
> 
> And on the top of the stack, there is trampline_C instead of original_return_address.
> In this case, return to trampoline_C(), it jumps back to trampline_B() and then
> it jumps back to trampline_A(). And eventually it jumps back to
> original_return_address.

Where are trampolines A, B, and C made? Do we also need to dynamically
create them? If I register multiple function tracing ones, each one
will need its own trampoline?

> 
> This way, we don't need allocate another bitmap/pages for the shadow stack.
> We only need a shadow stack for each task.
> Also, unwinder can easily find the trampline_C from the shadow stack and restores
> original_return_address. (of course trampline_A,B,C must be registered so that
> search function can skip it.)

What I was thinking was to store a count and the functions to be called:


	[original_return_address]
	[function_A]
	[function_B]
	[function_C]
	[ 3 ]

Then the trampoline that processes the return codes for ftrace (and
kretprobes and everyone else) can simply do:

	count = pop_shadow_stack();
	for (i = 0; i < count; i++) {
		func = pop_shadow_stack();
		func(...);
	}
	return_address = pop_shadow_stack();

That way we only need to register a function to the return handler and
it will be called, without worrying about making trampolines. There
will just be a single trampoline that handles all the work.

-- Steve

WARNING: multiple messages have this Message-ID (diff)
From: rostedt@goodmis.org (Steven Rostedt)
Subject: [PATCH v3 1/2] kretprobe: produce sane stack traces
Date: Sat, 3 Nov 2018 13:30:21 -0400	[thread overview]
Message-ID: <20181103133021.6676708c@vmware.local.home> (raw)
Message-ID: <20181103173021.JTZ3Txmlphpw4VIMG7kExmd5-4uURfWIOgfVi1bv7xM@z> (raw)
In-Reply-To: <20181104013430.9d3e91b8ebbae7dcb6860ef1@kernel.org>

On Sun, 4 Nov 2018 01:34:30 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> 
> > I was thinking of a bitmask that represents the handlers, and use that
> > to map which handler gets called for which shadow entry for a
> > particular task.  
> 
> Hmm, I doubt that is too complicated and not scalable. I rather like to see
> the open shadow entry...

It can scale and not too complex (I already played a little with it).
But that said, I'm not committed to it, and using the shadow stack is
also an interesting idea.

> 
> entry: [[original_retaddr][function][modified_retaddr]]
> 
> So if there are many users on same function, the entries will be like this 
> 
> [[original_return_address][function][trampoline_A]]
> [[trampline_A][function][trampoline_B]]
> [[trampline_B][function][trampoline_C]]
> 
> And on the top of the stack, there is trampline_C instead of original_return_address.
> In this case, return to trampoline_C(), it jumps back to trampline_B() and then
> it jumps back to trampline_A(). And eventually it jumps back to
> original_return_address.

Where are trampolines A, B, and C made? Do we also need to dynamically
create them? If I register multiple function tracing ones, each one
will need its own trampoline?

> 
> This way, we don't need allocate another bitmap/pages for the shadow stack.
> We only need a shadow stack for each task.
> Also, unwinder can easily find the trampline_C from the shadow stack and restores
> original_return_address. (of course trampline_A,B,C must be registered so that
> search function can skip it.)

What I was thinking was to store a count and the functions to be called:


	[original_return_address]
	[function_A]
	[function_B]
	[function_C]
	[ 3 ]

Then the trampoline that processes the return codes for ftrace (and
kretprobes and everyone else) can simply do:

	count = pop_shadow_stack();
	for (i = 0; i < count; i++) {
		func = pop_shadow_stack();
		func(...);
	}
	return_address = pop_shadow_stack();

That way we only need to register a function to the return handler and
it will be called, without worrying about making trampolines. There
will just be a single trampoline that handles all the work.

-- Steve

WARNING: multiple messages have this Message-ID (diff)
From: Steven Rostedt <rostedt@goodmis.org>
To: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	Aleksa Sarai <cyphar@cyphar.com>,
	"Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>,
	Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
	"David S. Miller" <davem@davemloft.net>,
	Jonathan Corbet <corbet@lwn.net>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Shuah Khan <shuah@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Brendan Gregg <bgregg@netflix.com>,
	Christian Brauner <christian@brauner.io>,
	Aleksa Sarai <asarai@suse.de>,
	netdev@vger.kernel.org, linux-doc@vger.kerne
Subject: Re: [PATCH v3 1/2] kretprobe: produce sane stack traces
Date: Sat, 3 Nov 2018 13:30:21 -0400	[thread overview]
Message-ID: <20181103133021.6676708c@vmware.local.home> (raw)
In-Reply-To: <20181104013430.9d3e91b8ebbae7dcb6860ef1@kernel.org>

On Sun, 4 Nov 2018 01:34:30 +0900
Masami Hiramatsu <mhiramat@kernel.org> wrote:
> 
> > I was thinking of a bitmask that represents the handlers, and use that
> > to map which handler gets called for which shadow entry for a
> > particular task.  
> 
> Hmm, I doubt that is too complicated and not scalable. I rather like to see
> the open shadow entry...

It can scale and not too complex (I already played a little with it).
But that said, I'm not committed to it, and using the shadow stack is
also an interesting idea.

> 
> entry: [[original_retaddr][function][modified_retaddr]]
> 
> So if there are many users on same function, the entries will be like this 
> 
> [[original_return_address][function][trampoline_A]]
> [[trampline_A][function][trampoline_B]]
> [[trampline_B][function][trampoline_C]]
> 
> And on the top of the stack, there is trampline_C instead of original_return_address.
> In this case, return to trampoline_C(), it jumps back to trampline_B() and then
> it jumps back to trampline_A(). And eventually it jumps back to
> original_return_address.

Where are trampolines A, B, and C made? Do we also need to dynamically
create them? If I register multiple function tracing ones, each one
will need its own trampoline?

> 
> This way, we don't need allocate another bitmap/pages for the shadow stack.
> We only need a shadow stack for each task.
> Also, unwinder can easily find the trampline_C from the shadow stack and restores
> original_return_address. (of course trampline_A,B,C must be registered so that
> search function can skip it.)

What I was thinking was to store a count and the functions to be called:


	[original_return_address]
	[function_A]
	[function_B]
	[function_C]
	[ 3 ]

Then the trampoline that processes the return codes for ftrace (and
kretprobes and everyone else) can simply do:

	count = pop_shadow_stack();
	for (i = 0; i < count; i++) {
		func = pop_shadow_stack();
		func(...);
	}
	return_address = pop_shadow_stack();

That way we only need to register a function to the return handler and
it will be called, without worrying about making trampolines. There
will just be a single trampoline that handles all the work.

-- Steve

  reply	other threads:[~2018-11-03 17:30 UTC|newest]

Thread overview: 137+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-01  8:35 [PATCH v3 0/2] kretprobe: produce sane stack traces Aleksa Sarai
2018-11-01  8:35 ` Aleksa Sarai
2018-11-01  8:35 ` cyphar
2018-11-01  8:35 ` [PATCH v3 1/2] " Aleksa Sarai
2018-11-01  8:35   ` Aleksa Sarai
2018-11-01  8:35   ` cyphar
2018-11-01 15:20   ` Masami Hiramatsu
2018-11-01 15:20     ` Masami Hiramatsu
2018-11-01 15:20     ` Masami Hiramatsu
2018-11-01 15:20     ` mhiramat
2018-11-01 21:13     ` Aleksa Sarai
2018-11-01 21:13       ` Aleksa Sarai
2018-11-01 21:13       ` Aleksa Sarai
2018-11-01 21:13       ` cyphar
2018-11-02  3:04       ` Masami Hiramatsu
2018-11-02  3:04         ` Masami Hiramatsu
2018-11-02  3:04         ` Masami Hiramatsu
2018-11-02  3:04         ` mhiramat
2018-11-02  4:37         ` Aleksa Sarai
2018-11-02  4:37           ` Aleksa Sarai
2018-11-02  4:37           ` Aleksa Sarai
2018-11-02  4:37           ` cyphar
2018-11-03 12:47           ` Masami Hiramatsu
2018-11-03 12:47             ` Masami Hiramatsu
2018-11-03 12:47             ` Masami Hiramatsu
2018-11-03 12:47             ` mhiramat
2018-11-02  0:47   ` Steven Rostedt
2018-11-02  0:47     ` Steven Rostedt
2018-11-02  0:47     ` Steven Rostedt
2018-11-02  0:47     ` rostedt
2018-11-02  5:05     ` Aleksa Sarai
2018-11-02  5:05       ` Aleksa Sarai
2018-11-02  5:05       ` Aleksa Sarai
2018-11-02  5:05       ` cyphar
2018-11-02  6:59       ` Aleksa Sarai
2018-11-02  6:59         ` Aleksa Sarai
2018-11-02  6:59         ` Aleksa Sarai
2018-11-02  6:59         ` cyphar
2018-11-02 13:16         ` Steven Rostedt
2018-11-02 13:16           ` Steven Rostedt
2018-11-02 13:16           ` Steven Rostedt
2018-11-02 13:16           ` rostedt
2018-11-02 15:43           ` Josh Poimboeuf
2018-11-02 15:43             ` Josh Poimboeuf
2018-11-02 15:43             ` Josh Poimboeuf
2018-11-02 15:43             ` jpoimboe
2018-11-02 16:13             ` Steven Rostedt
2018-11-02 16:13               ` Steven Rostedt
2018-11-02 16:13               ` Steven Rostedt
2018-11-02 16:13               ` rostedt
2018-11-03 13:00               ` Masami Hiramatsu
2018-11-03 13:00                 ` Masami Hiramatsu
2018-11-03 13:00                 ` Masami Hiramatsu
2018-11-03 13:00                 ` mhiramat
2018-11-03 13:13                 ` Steven Rostedt
2018-11-03 13:13                   ` Steven Rostedt
2018-11-03 13:13                   ` Steven Rostedt
2018-11-03 13:13                   ` rostedt
2018-11-03 16:34                   ` Masami Hiramatsu
2018-11-03 16:34                     ` Masami Hiramatsu
2018-11-03 16:34                     ` Masami Hiramatsu
2018-11-03 16:34                     ` mhiramat
2018-11-03 17:30                     ` Steven Rostedt [this message]
2018-11-03 17:30                       ` Steven Rostedt
2018-11-03 17:30                       ` Steven Rostedt
2018-11-03 17:30                       ` rostedt
2018-11-03 17:33                       ` Steven Rostedt
2018-11-03 17:33                         ` Steven Rostedt
2018-11-03 17:33                         ` Steven Rostedt
2018-11-03 17:33                         ` rostedt
2018-11-04  2:25                       ` Masami Hiramatsu
2018-11-04  2:25                         ` Masami Hiramatsu
2018-11-04  2:25                         ` Masami Hiramatsu
2018-11-04  2:25                         ` mhiramat
2018-11-03  7:02           ` Aleksa Sarai
2018-11-03  7:02             ` Aleksa Sarai
2018-11-03  7:02             ` Aleksa Sarai
2018-11-03  7:02             ` cyphar
2018-11-04 11:59             ` Aleksa Sarai
2018-11-04 11:59               ` Aleksa Sarai
2018-11-04 11:59               ` Aleksa Sarai
2018-11-04 11:59               ` cyphar
2018-11-06 22:15               ` Steven Rostedt
2018-11-06 22:15                 ` Steven Rostedt
2018-11-06 22:15                 ` Steven Rostedt
2018-11-06 22:15                 ` rostedt
2018-11-08  7:46                 ` Aleksa Sarai
2018-11-08  7:46                   ` Aleksa Sarai
2018-11-08  7:46                   ` Aleksa Sarai
2018-11-08  7:46                   ` cyphar
2018-11-08  8:04                   ` Aleksa Sarai
2018-11-08  8:04                     ` Aleksa Sarai
2018-11-08  8:04                     ` Aleksa Sarai
2018-11-08  8:04                     ` cyphar
2018-11-08 14:44                     ` Josh Poimboeuf
2018-11-08 14:44                       ` Josh Poimboeuf
2018-11-08 14:44                       ` Josh Poimboeuf
2018-11-08 14:44                       ` jpoimboe
2018-11-09  7:26                       ` Masami Hiramatsu
2018-11-09  7:26                         ` Masami Hiramatsu
2018-11-09  7:26                         ` Masami Hiramatsu
2018-11-09  7:26                         ` mhiramat
2018-11-09 15:10                         ` Aleksa Sarai
2018-11-09 15:10                           ` Aleksa Sarai
2018-11-09 15:10                           ` Aleksa Sarai
2018-11-09 15:10                           ` asarai
2018-11-09  7:15                     ` Masami Hiramatsu
2018-11-09  7:15                       ` Masami Hiramatsu
2018-11-09  7:15                       ` Masami Hiramatsu
2018-11-09  7:15                       ` mhiramat
2018-11-09 15:06                       ` Aleksa Sarai
2018-11-09 15:06                         ` Aleksa Sarai
2018-11-09 15:06                         ` Aleksa Sarai
2018-11-09 15:06                         ` asarai
2018-11-10 15:31                         ` Masami Hiramatsu
2018-11-10 15:31                           ` Masami Hiramatsu
2018-11-10 15:31                           ` Masami Hiramatsu
2018-11-10 15:31                           ` mhiramat
2018-11-12 10:38                           ` Aleksa Sarai
2018-11-12 10:38                             ` Aleksa Sarai
2018-11-12 10:38                             ` Aleksa Sarai
2018-11-12 10:38                             ` asarai
2018-11-03 13:23           ` Masami Hiramatsu
2018-11-03 13:23             ` Masami Hiramatsu
2018-11-03 13:23             ` Masami Hiramatsu
2018-11-03 13:23             ` mhiramat
2018-11-02  7:58       ` Aleksa Sarai
2018-11-02  7:58         ` Aleksa Sarai
2018-11-02  7:58         ` Aleksa Sarai
2018-11-02  7:58         ` cyphar
2018-11-02  4:01   ` kbuild test robot
2018-11-02  4:01     ` kbuild test robot
2018-11-02  4:01     ` kbuild test robot
2018-11-02  4:01     ` lkp
2018-11-01  8:35 ` [PATCH v3 2/2] trace: remove kretprobed checks Aleksa Sarai
2018-11-01  8:35   ` Aleksa Sarai
2018-11-01  8:35   ` cyphar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181103133021.6676708c@vmware.local.home \
    --to=rostedt@goodmis.org \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=anil.s.keshavamurthy@intel.com \
    --cc=asarai@suse.de \
    --cc=ast@kernel.org \
    --cc=bgregg@netflix.com \
    --cc=christian@brauner.io \
    --cc=corbet@lwn.net \
    --cc=cyphar@cyphar.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=jolsa@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=naveen.n.rao@linux.vnet.ibm.com \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=shuah@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.