Re: arm64 syzbot instances

On Thu, Mar 11, 2021 at 1:33 PM Mark Rutland [off-list ref] wrote:

On Thu, Mar 11, 2021 at 12:38:21PM +0100, 'Dmitry Vyukov' via syzkaller wrote:

quoted

Hi arm64 maintainers,
The instances have KCOV disabled because it slows down execution too
much (KASAN in qemu emulation is already extremely slow), so no
coverage guidance and coverage reports for now :(

The instances found few arm64-specific issues that we have not
observed on other instances:
https://syzkaller.appspot.com/bug?id=1d22a2cc3521d5cf6b41bd6b825793c2015f861f
https://syzkaller.appspot.com/bug?id=bb2c16b0e13b4de4bbf22cf6a4b9b16fb0c20eea
https://syzkaller.appspot.com/bug?id=b75386f45318ec181b7f49260d619fac9877d456
https://syzkaller.appspot.com/bug?id=5a1bc29bca656159f95c7c8bb30e3776ca860332
but mostly re-discovering known bugs we already found on x86.

Likewise, my general experience these days (fuzzing under KVM on a
ThunderX2 host) is that we mostly hit issues in core code or drivers
rather than anything strictly specific to arm64. As my host is ARMv8.1
that might just be by virtue of not exercising many of the new
architectural features.

quoted

The instances use qemu emulation and lots of debug configs, so they
are quite slow and it makes sense to target them at arm64-specific
parts of the kernel as much as possible (rather
than stress generic subsystems that are already stressed on x86).
So the question is: what arm64-specific parts are there that we can reach
in qemu?
Can you think of any qemu flags (cpu features, device emulation, etc)?

Generally, `-cpu max` will expose the more interesting CPU features, and
you already seem to have that, so I think you're mostly there on that
front.

Devices vary a lot between SoCs (and most aren't even emulated), so
unless you have particular platforms in mind I'd suggest it might be
better to just use PV devices and try to focus fuzzing on arch code and
common code like mm rather than drivers.

I don't have any specific SoC in mind. I think we are interested in
covering something more commonly used rather than a driver used only
on 1 SoC.
Testing virt drivers is good, but since we have 3 arm64 instances, we
could make then use different boards to get more coverage.
What about things like pstore, numa, mtdblock, pflash? When I do man
qemu-system-aarch64 for some reason I see help for x86_64, so I am not
sure if these are applicable to arm64.

quoted

Any kernel subsystems with heavy arm-specific parts that we may be missing?

It looks like your configs already have BPF, which is probably one of
the more interesting subsystems with architecture-specific bits, so I
don't have further suggestions on that front.

quoted

Testing some of the arm64 drivers that qemu can emulate may be the
most profitable thing.
Currently the instances use the following flags:
-machine virt,virtualization=on,graphics=on,usb=on -cpu cortex-a57
-machine virt,virtualization=on,mte=on,graphics=on,usb=on -cpu max

With `-cpu max`, QEMU will use a relatively expensive SW implementation
of pointer authentication (which I found significantly magnified the
cost of implementation like kcov), so depending on your priorities you
might want to disable that or (assuming you have a recent enough build
of QEMU) you might wantto force the use of a cheaper algorithm by
passing `-cpu max,pauth-impef`.

The relevant QEMU commit is:

eb94284d0812b4e7 ("arget/arm: Add cpu properties to control pauth")

... but it looks like that might not yet be in a tagged release yet.

Interesting. I need to note this somewhere.

quoted

mte=on + virtualization=on is broken in the kernel on in the qemu:
https://lore.kernel.org/lkml/CAAeHK+wDz8aSLyjq1b=q3+HG9aJXxwYR6+gN_fTttMN5osM5gg@mail.gmail.com/ (local)

--
You received this message because you are subscribed to the Google Groups "syzkaller" group.
To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller/CACT4Y%2BbeyZ7rjmy7im0KdSU-Pcqd4Rud3xsxonBbYVk0wU-B9g%40mail.gmail.com.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel