From: Nathan Huckleberry <nhuck15@gmail.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Russell King <linux@armlinux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Chunyan Zhang <zhang.lyra@gmail.com>,
clang-built-linux@googlegroups.com,
Dmitry Safonov <0x7f454c46@gmail.com>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-mediatek@lists.infradead.org,
Lvqiang Huang <lvqiang.huang@unisoc.com>,
Matthias Brugger <matthias.bgg@gmail.com>,
Miles Chen <miles.chen@mediatek.com>,
stable@vger.kernel.org, Nathan Huckleberry <nhuck@google.com>
Subject: Re: [PATCH 2/4] ARM: backtrace-clang: add fixup for lr dereference
Date: Thu, 6 Aug 2020 17:38:46 -0500 [thread overview]
Message-ID: <CAN=-Rxty=Ux5rj-VQSZH-ryj1RiNJvy7mRE7uyx_YAndGtcq7Q@mail.gmail.com> (raw)
In-Reply-To: <20200730205112.2099429-3-ndesaulniers@google.com>
Mostly looks good to me. Just a minor nit.
On Thu, Jul 30, 2020 at 3:51 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> If the value of the link register is not correct (tail call from asm
> that didn't set it, stack corruption, memory no longer mapped), then
> using it for an address calculation may trigger an exception. Without a
> fixup handler, this will lead to a panic, which will unwind, which will
> trigger the fault repeatedly in an infinite loop.
>
> We don't observe such failures currently, but we have. Just to be safe,
> add a fixup handler here so that at least we don't have an infinite
> loop.
>
> Cc: stable@vger.kernel.org
> Fixes: commit 6dc5fd93b2f1 ("ARM: 8900/1: UNWINDER_FRAME_POINTER implementation for Clang")
> Reported-by: Miles Chen <miles.chen@mediatek.com>
> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> ---
> arch/arm/lib/backtrace-clang.S | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/lib/backtrace-clang.S b/arch/arm/lib/backtrace-clang.S
> index 5388ac664c12..40eb2215eaf4 100644
> --- a/arch/arm/lib/backtrace-clang.S
> +++ b/arch/arm/lib/backtrace-clang.S
> @@ -146,7 +146,7 @@ for_each_frame: tst frame, mask @ Check for address exceptions
>
> tst sv_lr, #0 @ If there's no previous lr,
> beq finished_setup @ we're done.
> - ldr r0, [sv_lr, #-4] @ get call instruction
> +prev_call: ldr r0, [sv_lr, #-4] @ get call instruction
> ldr r3, .Lopcode+4
> and r2, r3, r0 @ is this a bl call
> teq r2, r3
> @@ -206,6 +206,13 @@ finished_setup:
> mov r2, frame
> bl printk
> no_frame: ldmfd sp!, {r4 - r9, fp, pc}
> +/*
> + * Accessing the address pointed to by the link register triggered an
> + * exception, don't try to unwind through it.
> + */
> +bad_lr: mov sv_fp, #0
It might be nice to emit a warning here since we'll
only hit this case if something fishy is going on
with the saved lr.
> + mov sv_lr, #0
> + b finished_setup
> ENDPROC(c_backtrace)
> .pushsection __ex_table,"a"
> .align 3
> @@ -214,6 +221,7 @@ ENDPROC(c_backtrace)
> .long 1003b, 1006b
> .long 1004b, 1006b
> .long 1005b, 1006b
> + .long prev_call, bad_lr
> .popsection
>
> .Lbad: .asciz "%sBacktrace aborted due to bad frame pointer <%p>\n"
> --
> 2.28.0.163.g6104cc2f0b6-goog
>
Thanks,
Huck
next prev parent reply other threads:[~2020-08-06 22:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200730205112.2099429-1-ndesaulniers@google.com>
2020-07-30 20:51 ` [PATCH 1/4] ARM: backtrace-clang: check for NULL lr Nick Desaulniers
2020-08-07 18:07 ` Nathan Huckleberry
2020-07-30 20:51 ` [PATCH 2/4] ARM: backtrace-clang: add fixup for lr dereference Nick Desaulniers
2020-08-01 23:18 ` Sasha Levin
2020-08-03 18:13 ` Nick Desaulniers
2020-08-04 6:27 ` Greg KH
2020-08-06 1:24 ` Sasha Levin
2020-08-06 22:38 ` Nathan Huckleberry [this message]
2020-08-10 22:33 ` Nick Desaulniers
2020-08-20 0:13 ` Nick Desaulniers
2020-08-13 16:25 ` Sasha Levin
2020-08-19 23:56 ` Sasha Levin
2020-08-06 1:24 ` [PATCH 0/4] CONFIG_UNWINDER_FRAME_POINTER fixes+cleanups Sasha Levin
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='CAN=-Rxty=Ux5rj-VQSZH-ryj1RiNJvy7mRE7uyx_YAndGtcq7Q@mail.gmail.com' \
--to=nhuck15@gmail.com \
--cc=0x7f454c46@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=clang-built-linux@googlegroups.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=lvqiang.huang@unisoc.com \
--cc=matthias.bgg@gmail.com \
--cc=miles.chen@mediatek.com \
--cc=ndesaulniers@google.com \
--cc=nhuck@google.com \
--cc=stable@vger.kernel.org \
--cc=zhang.lyra@gmail.com \
/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).