Arm + KASAN + syzbot

[Russell King - ARM Linux admin]

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.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!