Arm + KASAN + syzbot

[Russell King - ARM Linux admin]

On Tue, Jan 19, 2021 at 12:17:37PM +0100, Dmitry Vyukov wrote:
> On Tue, Jan 19, 2021 at 12:13 PM Russell King - ARM Linux admin
> <linux at armlinux.org.uk> wrote:
> >
> > On Tue, Jan 19, 2021 at 12:05:01PM +0100, Dmitry Vyukov wrote:
> > > But I also spied this in your makefile:
> > >
> > > config-earlydebug: config-base
> > > $(CURDIR)/scripts/config --file $(config_file) \
> > > --enable DEBUG_LL \
> > > --enable EARLY_PRINTK \
> > > --enable DEBUG_VEXPRESS_UART0_RS1 \
> > >
> > > With these configs, qemu prints something more useful:
> > >
> > > pulseaudio: set_sink_input_volume() failed
> > > pulseaudio: Reason: Invalid argument
> > > pulseaudio: set_sink_input_mute() failed
> > > pulseaudio: Reason: Invalid argument
> > > Error: invalid dtb and unrecognized/unsupported machine ID
> > >   r1=0x000008e0, r2=0x00000000
> > > Available machine support:
> > > ID (hex) NAME
> > > ffffffff Generic DT based system
> > > ffffffff Samsung Exynos (Flattened Device Tree)
> > > ffffffff Hisilicon Hi3620 (Flattened Device Tree)
> > > ffffffff ARM-Versatile Express
> > > Please check your kernel config and/or bootloader.
> > >
> > >
> > > What does this mean? And is this affected by KASAN?... I do specify
> > > the ARM-Versatile Express machine...
> > >
> > > Can it be too large kernel size which is not supported/properly
> > > diagnosed by qemu/kernel?
> >
> > It means that your kernel only supports DT platforms, but there was
> > no DT passed to the kernel (r2 is the pointer to DT). Consequently
> > the kernel has no idea what hardware it is running on.
> >
> > I don't use qemu very much, so I can't suggest anything.
> 
> I do pass DT and it boots fine w/o KASAN, so it seems to be poor
> diagnostics of something else.

It is the best we can do at that time. Consider yourself lucky that you
can even get _that_ message since the kernel has no clue what hardware
is available, and there is no standardised hardware.

All that the kernel knows at this point is that (1) the machine ID in
r1 does not match anything the kernel knows about (which are all DT
platforms), and r2 is NULL, meaning no DT was passed to the
decompressed kernel.

There is no further information that the kernel knows. I suppose we
could hexdump random bits of memory space through the serial port or
whatever, but that would be very random.

I'm not sure what else you think the kernel could do at this point.

> It seems to be due to kernel size. I enabled CONFIG_KASAN_OUTLINE=y
> and CONFIG_CC_OPTIMIZE_FOR_SIZE=y and now it boots...

So, likely the DT was obliterated. How are you passing the DT? If
you are passing it via qemu, then qemu's placement of DT is too close
to the kernel.

> ------------[ cut here ]------------
> WARNING: CPU: 0 PID: 0 at kernel/printk/printk.c:2790
> register_console+0x2f4/0x3c4 kernel/printk/printk.c:2790
> console 'earlycon0' already registered

Two "earlycons" or whatever the early console kernel parameter is?

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