On Thu, Aug 6, 2020 at 3:39 PM Nathan Huckleberry <nhuck15@xxxxxxxxx> wrote:
>
> Mostly looks good to me. Just a minor nit.
>
> On Thu, Jul 30, 2020 at 3:51 PM Nick Desaulniers
> <ndesaulniers@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx
> > Fixes: commit 6dc5fd93b2f1 ("ARM: 8900/1: UNWINDER_FRAME_POINTER implementation for Clang")
> > Reported-by: Miles Chen <miles.chen@xxxxxxxxxxxx>
> > Signed-off-by: Nick Desaulniers <ndesaulniers@xxxxxxxxxx>
> > ---
> > 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.
Yeah, something fishy is going on if that ever happens. Let me create
a V2 with an additional print.
>
> > + 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
--
Thanks,
~Nick Desaulniers
