linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Vyukov <dvyukov@google.com>
To: Mark Rutland <mark.rutland@arm.com>,
	maz@kernel.org, Will Deacon <will@kernel.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	 Arnd Bergmann <arnd@arndb.de>
Cc: syzkaller <syzkaller@googlegroups.com>,
	LKML <linux-kernel@vger.kernel.org>
Subject: arm64 syzbot instances
Date: Thu, 11 Mar 2021 12:38:21 +0100	[thread overview]
Message-ID: <CACT4Y+beyZ7rjmy7im0KdSU-Pcqd4Rud3xsxonBbYVk0wU-B9g@mail.gmail.com> (raw)

Hi arm64 maintainers,

We now have some syzbot instances testing arm64 (woohoo!) using qemu
emulation. I wanted to write up the current status.

There are 3 instances, first uses KASAN:
https://syzkaller.appspot.com/upstream?manager=ci-qemu2-arm64
second KASAN and 32-bit userspace test load (compat):
https://syzkaller.appspot.com/upstream?manager=ci-qemu2-arm64-compat
third uses MTE/KASAN_HWTAGS:
https://syzkaller.appspot.com/upstream?manager=ci-qemu2-arm64-mte

Kernel configs:
https://github.com/google/syzkaller/blob/master/dashboard/config/linux/upstream-arm64-kasan.config
https://github.com/google/syzkaller/blob/master/dashboard/config/linux/upstream-arm64-mte.config

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.

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)?
Any kernel subsystems with heavy arm-specific parts that we may be missing?
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

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/

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

             reply	other threads:[~2021-03-11 11:40 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-11 11:38 Dmitry Vyukov [this message]
2021-03-11 12:33 ` arm64 syzbot instances Mark Rutland
2021-03-11 16:56   ` Dmitry Vyukov
2021-03-17 18:45     ` Mark Rutland
2021-03-18  8:32       ` Dmitry Vyukov
2021-03-11 17:11   ` Dmitry Vyukov
2021-03-11 13:30 ` Arnd Bergmann
2021-03-11 17:25   ` Dmitry Vyukov
2021-03-12  6:42     ` Dmitry Vyukov
2021-03-11 17:57   ` Dmitry Vyukov
2021-03-12  8:39     ` Arnd Bergmann
2021-03-12  8:46       ` Dmitry Vyukov
2021-03-12  9:16         ` Arnd Bergmann
2021-03-12  9:21           ` Dmitry Vyukov
2021-03-12 10:10             ` Arnd Bergmann
2021-03-12 10:38               ` Dmitry Vyukov
2021-03-12 10:52                 ` Arnd Bergmann
2021-03-15  9:43                   ` John Garry
2021-03-15 10:01                     ` Dmitry Vyukov
2021-03-15 10:29                       ` John Garry
2021-03-15 10:34                         ` Dmitry Vyukov
2021-03-15 11:11                         ` Arnd Bergmann
2021-03-20 20:43           ` Peter Maydell
2021-03-21 11:52             ` Arnd Bergmann
2021-03-21 11:55               ` Arnd Bergmann
2021-03-21 18:59             ` Arnd Bergmann
2021-03-22 13:51               ` Peter Maydell
2021-03-22 15:42                 ` Arnd Bergmann
2021-03-22 16:34                   ` John Garry
2021-03-22 16:49                     ` Peter Maydell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACT4Y+beyZ7rjmy7im0KdSU-Pcqd4Rud3xsxonBbYVk0wU-B9g@mail.gmail.com \
    --to=dvyukov@google.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=syzkaller@googlegroups.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).