live-patching.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: madvenka@linux.microsoft.com
Cc: jpoimboe@redhat.com, mark.rutland@arm.com, jthierry@redhat.com,
	catalin.marinas@arm.com, will@kernel.org, jmorris@namei.org,
	pasha.tatashin@soleen.com, linux-arm-kernel@lists.infradead.org,
	live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v3 1/4] arm64: Introduce stack trace reliability checks in the unwinder
Date: Tue, 4 May 2021 16:50:56 +0100	[thread overview]
Message-ID: <20210504155056.GB7094@sirena.org.uk> (raw)
In-Reply-To: <20210503173615.21576-2-madvenka@linux.microsoft.com>

[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]

On Mon, May 03, 2021 at 12:36:12PM -0500, madvenka@linux.microsoft.com wrote:

> +	/*
> +	 * First, make sure that the return address is a proper kernel text
> +	 * address. A NULL or invalid return address probably means there's
> +	 * some generated code which __kernel_text_address() doesn't know
> +	 * about. Mark the stack trace as not reliable.
> +	 */
> +	if (!__kernel_text_address(frame->pc)) {
> +		frame->reliable = false;
> +		return 0;
> +	}

Do we want the return here?  It means that...

> +
>  #ifdef CONFIG_FUNCTION_GRAPH_TRACER
>  	if (tsk->ret_stack &&
> -		(ptrauth_strip_insn_pac(frame->pc) == (unsigned long)return_to_handler)) {
> +		frame->pc == (unsigned long)return_to_handler) {
>  		struct ftrace_ret_stack *ret_stack;
>  		/*
>  		 * This is a case where function graph tracer has
> @@ -103,11 +117,10 @@ int notrace unwind_frame(struct task_struct *tsk, struct stackframe *frame)
>  		if (WARN_ON_ONCE(!ret_stack))
>  			return -EINVAL;
>  		frame->pc = ret_stack->ret;
> +		frame->pc = ptrauth_strip_insn_pac(frame->pc);
>  	}

...we skip this handling in the case where we're not in kernel code.  I
don't know off hand if that's a case that can happen right now but it
seems more robust to run through this and anything else we add later,
even if it's not relevant now changes either in the unwinder itself or
resulting from some future work elsewhere may mean it later becomes
important.  Skipping futher reliability checks is obviously fine if
we've already decided things aren't reliable but this is more than just
a reliability check.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-05-04 15:51 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <65cf4dfbc439b010b50a0c46ec500432acde86d6>
2021-05-03 17:36 ` [RFC PATCH v3 0/4] arm64: Stack trace reliability checks in the unwinder madvenka
2021-05-03 17:36   ` [RFC PATCH v3 1/4] arm64: Introduce stack " madvenka
2021-05-04 15:50     ` Mark Brown [this message]
2021-05-04 19:14       ` Madhavan T. Venkataraman
2021-05-04 21:52     ` Josh Poimboeuf
2021-05-04 23:13       ` Madhavan T. Venkataraman
2021-05-05  0:07         ` Josh Poimboeuf
2021-05-05  0:21           ` Madhavan T. Venkataraman
2021-05-03 17:36   ` [RFC PATCH v3 2/4] arm64: Check the return PC against unreliable code sections madvenka
2021-05-04 16:05     ` Mark Brown
2021-05-04 19:03       ` Madhavan T. Venkataraman
2021-05-04 19:32         ` Madhavan T. Venkataraman
2021-05-05 16:46           ` Mark Brown
2021-05-05 18:48             ` Madhavan T. Venkataraman
2021-05-05 18:50               ` Madhavan T. Venkataraman
2021-05-06 13:45               ` Mark Brown
2021-05-06 15:21                 ` Madhavan T. Venkataraman
2021-05-05 16:34         ` Mark Brown
2021-05-05 17:51           ` Madhavan T. Venkataraman
2021-05-05 19:30     ` Ard Biesheuvel
2021-05-05 20:00       ` Madhavan T. Venkataraman
2021-05-03 17:36   ` [RFC PATCH v3 3/4] arm64: Handle miscellaneous functions in .text and .init.text madvenka
2021-05-06 14:12     ` Mark Brown
2021-05-06 15:30       ` Madhavan T. Venkataraman
2021-05-06 15:32         ` Madhavan T. Venkataraman
2021-05-06 15:44           ` Mark Brown
2021-05-06 15:56             ` Madhavan T. Venkataraman
2021-05-06 15:37         ` Mark Brown
2021-05-06 15:57           ` Madhavan T. Venkataraman
2021-05-03 17:36   ` [RFC PATCH v3 4/4] arm64: Handle funtion graph tracer better in the unwinder madvenka
2021-05-06 14:43     ` Mark Brown
2021-05-06 15:20       ` Madhavan T. Venkataraman

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=20210504155056.GB7094@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=jmorris@namei.org \
    --cc=jpoimboe@redhat.com \
    --cc=jthierry@redhat.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=madvenka@linux.microsoft.com \
    --cc=mark.rutland@arm.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=will@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).