Arm + KASAN + syzbot

[Dmitry Vyukov]

On Thu, Jan 21, 2021 at 3:52 PM Linus Walleij <linus.walleij at linaro.org> wrote:
>
> On Thu, Jan 21, 2021 at 2:59 PM Dmitry Vyukov <dvyukov at google.com> wrote:
>
> > I think allowing qemu to modify dtb on the fly (rather than appending
> > it to the kernel) may be useful for testing purposes.
>
> Agree.
>
> > In future we
> > will probably want to make qemu emulate as many devices as possible to
> > increase testing coverage. Passing dtb separately will allow qemu to
> > emulate all kinds of devices that are not originally on the board.
>
> At one point I even suggested we extend QEMU with some error injection
> capabilities. For example PCI bridges can generate a lot of error states
> but the emulated bridges are exposing kind of ideal behavior. It would
> be an interesting testing vector to augment QEMU devices (I was thinking
> of PCI hosts but also other things) to randomly misbehave and exercise
> the error path of the drivers and frameworks.
>
> > However, I hit the next problem.
> > If I build a kernel with KASAN, binaries built from Go sources don't
> > work. dhcpd/sshd/etc start fine, but any Go binaries just consume 100%
> > of CPU and do nothing. The process state is R and it manages to create
> > 2 child threads and mmap ~800MB of virtual memory, which I suspect may
> > be the root cause (though, actual memory consumption is much smaller,
> > dozen of MB or so). The binary cannot be killed with kill -9. I tried
> > to give VM 2GB and 8GB, so it should have plenty of RAM. These
> > binaries run fine on non-KASAN kernel...
>
> It looks like Go uses a lot of memory right?
>
> Your .config says:
>
> CONFIG_VMSPLIT_2G=y
> # CONFIG_VMSPLIT_1G is not set
> CONFIG_PAGE_OFFSET=0x80000000
> CONFIG_KASAN_SHADOW_OFFSET=0x5f000000
>
> This means that if your process including children start using close
> to 2GB +/- it runs out of virtual memory and start thrashing.
>
> Yours,
> Linus Walleij


I've set up an arm32 instance (w/o KASAN for now), but kernel fails during boot:
https://groups.google.com/g/syzkaller-bugs/c/omh0Em-CPq0
So far arm32 testing does not progress beyond attempts to boot.