Arm + KASAN + syzbot

[Dmitry Vyukov]

On Thu, Jan 21, 2021 at 2:14 PM Russell King - ARM Linux admin
<linux at armlinux.org.uk> wrote:
>
> On Tue, Jan 19, 2021 at 07:48:27PM +0000, Russell King - ARM Linux admin wrote:
> > My knowledge about this is limited to qemu being used for KVM.
> >
> > Firstly, there is are no block devices except for MTD, USB, or CF
> > based block devices in the Versatile Express hardware. So, the DTB
> > contains no block devices.
> >
> > In your first case above, it is likely that QEMU modifies the passed
> > DTB to add PCIe devices to describe a virtio block device.
> >
> > In this case, because QEMU has no visibility of the appended DTB, it
> > can't modify it, so the kernel only knows about devices found on the
> > real hardware. Hence, any of the "special" virtio devices that QEMU
> > use likely won't be found.
> >
> > I'm not sure how QEMU adds those (you're probably in a better position
> > than I to boot using your first method, grab a copy of the DTB that
> > the booted kernel used from /sys/firmware/fdt, and use dtc to turn it
> > back into a dts and see what the changes are.
> >
> > I suspect you'll find that there's a new PCIe controller been added
> > by QEMU, behind which will be a load of virtio devices for things like
> > network and the "vda" block device.
>
> It may also be of relevance that 5.9 + a revert of the font changes
> boots for me under KVM, but 5.10 does not.
>
> The font changes were:
> 6735b4632def Fonts: Support FONT_EXTRA_WORDS macros for built-in fonts
>
> 5.10-rc1 similarly does not, but bisecting that brings me to:
> 316cdaa1158a net: add option to not create fall-back tunnels in root-ns as well
>
> which seems entirely unrelated, and looks like a false outcome.
>
> I've tried going back to 5.10 and turning off CONFIG_STRICT_KERNEL_RWX.
> Still doesn't boot.
>
> I've tried reverting the changes to the decompressor between 5.9 and
> 5.10. Still doesn't boot.
>
> Asking for a memory dump in ELF coredump format of the guest doesn't give
> anything useful - I can see that the kernel has been decompressed, but
> the BSS is completely uninitialised. It looks like the LPAE page tables
> have been initialised.
>
> 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.