Arm + KASAN + syzbot

[Arnd Bergmann]

On Thu, Jan 21, 2021 at 2:49 PM Dmitry Vyukov <dvyukov at google.com> wrote:
> On Thu, Jan 21, 2021 at 2:14 PM Russell King - ARM Linux admin <linux at armlinux.org.uk> wrote:
> >
> > The PC value in the ELF coredump seems to be spinning through a large
> > amount of memory (physical address) and the CPSR is 0x197, which
> > suggests it's taken an abort without any vectors setup.
> >
> > I'm currently struggling to find a way to debug what's going on.
>
> I wonder if qemu has some kind of tracing that may be useful in such cases.
> Some googling shows this, which seems that it can give a trace of all
> PCs (which is a reasonable feature to have), it may show where things
> go wrong:
> https://rwmj.wordpress.com/2016/03/17/tracing-qemu-guest-execution/
> https://github.com/qemu/qemu/blob/master/docs/devel/tracing.txt
> But I never used such heavy-weight artillery myself.

I tend to attach gdb, in one of two ways:

- If the bug is in really early boot, I single-step the instructions to see when
  it goes wrong. Using 'stepi 30000' I see if it's still in a sane state 30000
  instructions into the boot, or if the registers are in an obviously
broken state.
  From there, I can bisect the number of instructions after boot before it
  breaks, which usually doesn't take that long.

- If it crashes after setting up the virtual mapping, I use normal breakpoints
  to see how far it gets, and bisect init/main.c symbolically, starting with a
  breakpoint in start_kernel().

Of course, if it doesn't get into start_kernel, but there are too many
instructions before the crash, neither of the two works all that well.

      Arnd