Linux-RISC-V Archive on
 help / color / Atom feed
From: Dmitry Vyukov <>
To: "Tobias Klauser" <>,
	"Björn Töpel" <>,
	"Paul Walmsley" <>,
	"Palmer Dabbelt" <>,
	"Albert Ou" <>
Cc:, syzkaller <>
Subject: syzkaller on risc-v
Date: Tue, 30 Jun 2020 14:48:31 +0200
Message-ID: <> (raw)

Hello risc-v maintainers,

Few days ago Tobias ported syzkaller (kernel fuzzer) to risc-v arch:
Tobias also provided nice instructions on how to run it using qemu+buildroot:
I tried to run it and it works. I wanted to write down some findings
in a public place. Some may be known, some not, some may be easier to
address, some maybe harder. For now my goal is just to document this.

1. KASAN does not seem to work.
I've tried both v5.8-rc2 and 1590a2e1c681b0991bd42c992cabfd380e0338f2
with/without KASAN and KCOV, both inline and outline and all
experiments point to broken KASAN. Boot gets to "INSTRUCTION SETS WANT
TO BE FREE" banner and then it hangs dead in secondary_start_common,
you may see some details here:
KASAN would be a prerequisite for testing risc-v on syzbot.
The recent KCOV patch works well, though.

2. I've also tried to convert our beefy syzbot config for x86_64, it
includes both lots of debug configs and subsystem configs:
I've passed it via olddefconfig for risc-v, disabled KASAN and tried
to boot and got a similar boot hang. I did not try to bisect the
config further.

3. Running with a small config (defconfig+KCOV) initially I got stack
overflows all over the place. Here are some samples:
I ended up doing:

--- a/arch/riscv/include/asm/thread_info.h
+++ b/arch/riscv/include/asm/thread_info.h
-#define THREAD_SIZE_ORDER      (1)
+#define THREAD_SIZE_ORDER      (2)

This eliminated stack overflows.
KCOV may increase stack usage a bit, but not radically like KASAN. So
I would assume some stack overflows can happen without KCOV as well.
So either we need this, or at least bump stack size under KCOV.

4. In lots of cases I did not get meaningful stack traces.
E.g. WARNINGs don't unwind past the exception, which makes the stack useless:
This also happened a dozen of times for stack overflows:
also rcu stalls did not get stacks past the timer interrupt:
and various kinds of exceptions did not get any meaningful stack traces:
This makes it hard to debug, but stack traces are also required by
proper bug bucketing by syzkaller.

5. Once we have proper stack traces, we will need to extend syzkaller
test case base to include samples of risc-v crashes:
and crash parsing code to properly understand and bucket these crashes:

6. I observed lots of what looks like user-space process memory
corruptions. There included thousands of panics in our Go programs
with things that I would consider "impossible", at least they did not
come up before in our syzbot fuzzing. Also some Go runtime
"impossible" crashes, e.g.:
Maybe it's a known issue? Should we use tip instead of 1.14? Is it more stable?
Though it's not necessary Go b/c kernel contains hundreds of memory
corruptions and we observed kernel corrupting user-space processes
routinely. This is especially true without KASAN because kernel
corruptions are not caught early. However, the ratio and nature of
crashes makes me suspect some issue in Go risc-v runtime.


linux-riscv mailing list

             reply index

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-30 12:48 Dmitry Vyukov [this message]
2020-06-30 12:57 ` Andreas Schwab
2020-06-30 13:26   ` Dmitry Vyukov
2020-06-30 13:33     ` Andreas Schwab
2020-06-30 13:40       ` Dmitry Vyukov
2020-06-30 13:45         ` Andreas Schwab
2020-06-30 13:49           ` Dmitry Vyukov
2020-06-30 13:52             ` Andreas Schwab
2020-07-01 10:42     ` Björn Töpel
2020-07-01 10:43       ` Björn Töpel
2020-07-01 11:34         ` Dmitry Vyukov
2020-07-01 13:52         ` Tobias Klauser
2020-06-30 13:03 ` Andreas Schwab
2020-06-30 13:26   ` David Abdurachmanov
2020-06-30 13:37     ` Colin Ian King
2020-06-30 13:57       ` David Abdurachmanov
2020-06-30 14:55         ` Andreas Schwab
2020-07-06 10:12         ` Colin Ian King
2020-07-14  1:21           ` Palmer Dabbelt
2020-06-30 13:07 ` Andreas Schwab
2020-06-30 13:20   ` David Abdurachmanov
2020-06-30 13:23     ` Dmitry Vyukov
2020-06-30 13:30     ` Andreas Schwab
2020-06-30 13:35       ` David Abdurachmanov
2020-06-30 13:43         ` Andreas Schwab
2020-07-02 22:00           ` Aurelien Jarno
2020-07-06  8:14             ` Andreas Schwab
2020-06-30 15:10 ` Tobias Klauser
2020-07-01 10:03   ` Dmitry Vyukov

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:

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

  git send-email \
    --in-reply-to='' \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-RISC-V Archive on

Archives are clonable:
	git clone --mirror linux-riscv/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-riscv linux-riscv/ \
	public-inbox-index linux-riscv

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone