Arm + KASAN + syzbot

[Dmitry Vyukov]

On Tue, Jan 19, 2021 at 11:04 AM Mark Rutland <mark.rutland at arm.com> wrote:
>
> Hi Dmitry,
>
> On Mon, Jan 18, 2021 at 05:31:36PM +0100, 'Dmitry Vyukov' via syzkaller wrote:
> > 2. I see KASAN has just become supported for Arm, which is very
> > useful, but I can't boot a kernel with KASAN enabled. I am using
> > v5.11-rc4 and this config without KASAN boots fine:
> > https://gist.githubusercontent.com/dvyukov/12de2905f9479ba2ebdcc603c2fec79b/raw/c8fd3f5e8328259fe760ce9a57f3e6c6f5a95c8f/gistfile1.txt
> > using the following qemu command line:
> > qemu-system-arm \
> >   -machine vexpress-a15 -cpu max -smp 2 -m 2G \
>
> It might be best to use `-machine virt` here instead; that way QEMU
> won't need to emulate any of the real vexpress HW, and the kernel won't
> need to waste any time poking it.

Hi Mark,

The whole point of setting up an Arm instance is getting as much
coverage we can't get on x86_64 instances as possible. The instance
will use qemu emulation (extremely slow) and limited capacity.
I see some drivers and associated hardware support as one of the main
such areas. That's why I tried to use vexpress-a15. And it boots
without KASAN, so presumably it can be used in general.


> IIUC with that, you also wouldn't need to provide a DTB explicitly as
> QEMU will generate one...
>
> >   -device virtio-blk-device,drive=hd0 \
> >   -drive if=none,format=raw,id=hd0,file=image-arm -snapshot \
> >   -kernel arch/arm/boot/zImage \
> >   -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb \
>
> ... so this line could go, too.
>
> >   -nographic \
> >   -netdev user,host=10.0.2.10,hostfwd=tcp::10022-:22,id=net0 -device
> > virtio-net-device,netdev=net0 \
> >   -append "root=/dev/vda earlycon earlyprintk=serial console=ttyAMA0
> > oops=panic panic_on_warn=1 panic=86400 vmalloc=512M"
>
> [...]
>
> > 3. CONFIG_KCOV does not seem to fully work.
> > It seems to work except for when the kernel crashes, and that's the
> > most interesting scenario for us. When the kernel crashes for other
> > reasons, crash handlers re-crashe in KCOV making all crashes
> > unactionable and indistinguishable.
> > Here are some samples (search for __sanitizer_cov_trace):
> > https://gist.githubusercontent.com/dvyukov/c8a7ff1c00a5223c5143fd90073f5bc4/raw/c0f4ac7fd7faad7253843584fed8620ac6006338/gistfile1.txt
>
> Most of those are all small offsets from 0, which suggests an offset is
> being added to a NULL pointer somewhere, which I suspect means
> task_struct::kcov_area is NULL. We could hack-in a check for that, and
> see if that's the case (though I can't see how from a quick scan of the
> kcov code).

My first guess would be is that current itself if NULL. Accesses to
current->kcov* are well tested on other arches, including using KCOV
in interrupts, etc.