All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Will Deacon <will@kernel.org>
Cc: Tamas Zsoldos <tamas.zsoldos@arm.com>,
	Mark Brown <broonie@kernel.org>,
	kernel-team@android.com, linux-arm-kernel@lists.infradead.org,
	Daniel Kiss <daniel.kiss@arm.com>
Subject: Re: [PATCH 1/3] arm64: vdso: Don't prefix sigreturn trampoline with a BTI C instruction
Date: Tue, 19 May 2020 14:21:01 +0100	[thread overview]
Message-ID: <20200519132100.GD5031@arm.com> (raw)
In-Reply-To: <20200519121818.14511-2-will@kernel.org>

On Tue, May 19, 2020 at 01:18:16PM +0100, Will Deacon wrote:
> For better or worse, GDB relies on the exact instruction sequence in the
> VDSO sigreturn trampoline in order to unwind from signals correctly.

Are you sure?  I'm struggling to find the relevant code in gdb.

> Commit 714a8d02ca4d ("arm64: asm: Override SYM_FUNC_START when building
> the kernel with BTI") unfortunately added a BTI C instruction to the
> start of __kernel_rt_sigreturn, which breaks this check. Thankfully,
> it's also not required, since the trampoline is called from a RET
> instruction when returning from the signal handler
> 
> Remove the unnecessary BTI C instruction from __kernel_rt_sigreturn.
> 
> Cc: Dave Martin <dave.martin@arm.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Daniel Kiss <daniel.kiss@arm.com>
> Cc: Tamas Zsoldos <tamas.zsoldos@arm.com>
> Fixes: 714a8d02ca4d ("arm64: asm: Override SYM_FUNC_START when building the kernel with BTI")
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
>  arch/arm64/kernel/vdso/sigreturn.S | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/kernel/vdso/sigreturn.S b/arch/arm64/kernel/vdso/sigreturn.S
> index 3fb13b81f780..83ac284dae79 100644
> --- a/arch/arm64/kernel/vdso/sigreturn.S
> +++ b/arch/arm64/kernel/vdso/sigreturn.S
> @@ -15,7 +15,14 @@
>  	.text
>  
>  	nop
> -SYM_FUNC_START(__kernel_rt_sigreturn)
> +/*
> + * GDB relies on being able to identify the sigreturn instruction sequence to
> + * unwind from signal handlers. We cannot, therefore, use SYM_FUNC_START()
> + * here, as it will emit a BTI C instruction and break the unwinder. Thankfully,
> + * this function is only ever called from a RET and so omitting the landing pad
> + * is perfectly fine.
> + */
> +SYM_START(__kernel_rt_sigreturn, SYM_L_GLOBAL, SYM_A_ALIGN)
>  	.cfi_startproc
>  	.cfi_signal_frame
>  	.cfi_def_cfa	x29, 0
> -- 
> 2.26.2.761.g0e0b3e54be-goog
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2020-05-19 13:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-19 12:18 [PATCH 0/3] arm64 sigreturn unwinding fixes Will Deacon
2020-05-19 12:18 ` [PATCH 1/3] arm64: vdso: Don't prefix sigreturn trampoline with a BTI C instruction Will Deacon
2020-05-19 12:38   ` Mark Brown
2020-05-19 13:25     ` Dave Martin
2020-05-19 14:35       ` Mark Brown
2020-05-19 14:55         ` Dave Martin
2020-05-19 15:42           ` Mark Brown
2020-05-20  9:48             ` Dave Martin
2020-05-20 10:46               ` Mark Brown
2020-05-20 11:08                 ` Dave Martin
2020-05-19 15:26     ` Will Deacon
2020-05-19 13:21   ` Dave Martin [this message]
2020-05-19 13:29     ` Will Deacon
2020-05-19 12:18 ` [PATCH 2/3] arm64: vdso: Add a comment to justify the mysterious NOP in sigreturn Will Deacon
2020-05-19 13:26   ` Dave Martin
2020-05-19 12:18 ` [PATCH 3/3] arm64: vdso: Fix CFI directives in sigreturn trampoline Will Deacon
2020-05-19 13:09   ` Dave P Martin
2020-05-19 13:39     ` Will Deacon
2020-05-19 13:55       ` Dave Martin
2020-05-19 15:24         ` Will Deacon
2020-05-19 15:30         ` Daniel Kiss
2020-05-19 15:55           ` Will Deacon

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=20200519132100.GD5031@arm.com \
    --to=dave.martin@arm.com \
    --cc=broonie@kernel.org \
    --cc=daniel.kiss@arm.com \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=tamas.zsoldos@arm.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 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.