Arm + KASAN + syzbot

[Linus Walleij]

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