lkml.org 
[lkml]   [2021]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v5 2/2] Documentation: livepatch: document reliable stacktrace
From
Date
Hi,

On 1/18/21 9:39 AM, Mark Brown wrote:
> From: Mark Rutland <mark.rutland@arm.com>
>
> Add documentation for reliable stacktrace. This is intended to describe
> the semantics and to be an aid for implementing architecture support for
> HAVE_RELIABLE_STACKTRACE.
>
> Unwinding is a subtle area, and architectures vary greatly in both
> implementation and the set of concerns that affect them, so I've tried
> to avoid making this too specific to any given architecture. I've used
> examples from both x86_64 and arm64 to explain corner cases in more
> detail, but I've tried to keep the descriptions sufficient for those who
> are unfamiliar with the particular architecture.
>
> This document aims to give rationale for all the recommendations and
> requirements, since that makes it easier to spot nearby issues, or when
> a check happens to catch a few things at once.
>
> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> [Updates following review -- broonie]
> Acked-by: Josh Poimboeuf <jpoimboe@redhat.com>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> Documentation/livepatch/index.rst | 1 +
> .../livepatch/reliable-stacktrace.rst | 309 ++++++++++++++++++
> 2 files changed, 310 insertions(+)
> create mode 100644 Documentation/livepatch/reliable-stacktrace.rst

> diff --git a/Documentation/livepatch/reliable-stacktrace.rst b/Documentation/livepatch/reliable-stacktrace.rst
> new file mode 100644
> index 000000000000..fb123ee33403
> --- /dev/null
> +++ b/Documentation/livepatch/reliable-stacktrace.rst
> @@ -0,0 +1,309 @@

> +4.4 Rewriting of return addresses
> +---------------------------------
> +
> +Some trampolines temporarily modify the return address of a function in order
> +to intercept when that function returns with a return trampoline, e.g.
> +
> +* An ftrace trampoline may modify the return address so that function graph
> + tracing can intercept returns.
> +
> +* A kprobes (or optprobes) trampoline may modify the return address so that
> + kretprobes can intercept returns.
> +
> +When this happens, the original return address will not be in its usual
> +location. For trampolines which are not subject to live patching, where an
> +unwinder can reliably determine the original return address and no unwind state
> +is altered by the trampoline, the unwinder may report the original return
> +address in place of the trampoline and report this as reliable. Otherwise, an
> +unwinder must report these cases as unreliable.
> +
> +Special care is required when identifying the original return address, as this
> +information is not in a consistent location for the duration of the entry
> +trampoline or return trampoline. For example, considering the x86_64
> +'return_to_handler' return trampoline:
> +
> +.. code-block:: none
> +
> + SYM_CODE_START(return_to_handler)
> + UNWIND_HINT_EMPTY
> + subq $24, %rsp
> +
> + /* Save the return values */
> + movq %rax, (%rsp)
> + movq %rdx, 8(%rsp)
> + movq %rbp, %rdi
> +
> + call ftrace_return_to_handler
> +
> + movq %rax, %rdi
> + movq 8(%rsp), %rdx
> + movq (%rsp), %rax
> + addq $24, %rsp
> + JMP_NOSPEC rdi
> + SYM_CODE_END(return_to_handler)
> +
> +While the traced function runs its return address points on the stack points to

too many "points" above.

Otherwise:

Reviewed-by: Randy Dunlap <rdunlap@infradead.org>

Thanks.

> +the start of return_to_handler, and the original return address is stored in
> +the task's cur_ret_stack. During this time the unwinder can find the return
> +address using ftrace_graph_ret_addr().
> +
> +When the traced function returns to return_to_handler, there is no longer a
> +return address on the stack, though the original return address is still stored
> +in the task's cur_ret_stack. Within ftrace_return_to_handler(), the original
> +return address is removed from cur_ret_stack and is transiently moved
> +arbitrarily by the compiler before being returned in rax. The return_to_handler
> +trampoline moves this into rdi before jumping to it.
> +
> +Architectures might not always be able to unwind such sequences, such as when
> +ftrace_return_to_handler() has removed the address from cur_ret_stack, and the
> +location of the return address cannot be reliably determined.
> +
> +It is recommended that architectures unwind cases where return_to_handler has
> +not yet been returned to, but architectures are not required to unwind from the
> +middle of return_to_handler and can report this as unreliable. Architectures
> +are not required to unwind from other trampolines which modify the return
> +address.



--
~Randy
You can't do anything without having to do something else first.
-- Belefant's Law

\
 
 \ /
  Last update: 2021-01-18 20:28    [W:0.064 / U:1.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site