syzkaller UI: sorting/filter by Linux kernel subsystem

[matttbe]

Hello,

First, thank you for maintaining and developing this great tool!

I met @RonjaPonja at FOSDEM recently who suggested continuing the discussion here.

I'm currently using Syzkaller to catch bugs on MPTCP subsystem development version. The main reasons are to catch bug early, before sending patches to netdev, but also to reduce (stressful) new public syzbot bug reports for which we have to rush looking at them, at least to check how bad it is. (I wonder if new issues couldn't be share with us privately, before reaching the public MLs, to reduce stress :) ) → EDIT: discussion moved the ML

In this case, I'm only interested in having Syzkaller exercising a specific subsystem. I then used the enable_syscalls option in syz-manager config:

"enable_syscalls": ["sendfile", "socket", "socketpair", "accept", "accept4", "bind", "connect", "sendto", "recvfrom", "getsockname", "getpeername", "listen", "setsockopt", "getsockopt","syz_emit_ethernet", "syz_extract_tcp_res", "ioctl", "sendmsg", "sendmmsg", "recvmsg", "recvmmsg", "shutdown", "splice", "pipe", "close", "clone", "fcntl", "writev", "poll", "select", "epoll_ctl", "epoll_wait", "epoll_create", "epoll_create1", "epoll_pwait", "syz_genetlink_get_family_id", "syz_init_net_socket", "openat", "syz_open_dev"],

While I'm here: is it a good way to narrow the scope? Anything better for our case where at least one IPPROTO_MPTCP is created and used? More details about my setup are available on MPTCP wiki (don't hesitate to tell us what we can improve :) ). → EDIT: Alexander mentioned the focus_areas option.

From the UI, it is difficult to filter which bugs are linked to which subsystems. Initially, I was looking at the titles, but that was not enough. I then started to open the reports linked to networking areas, but now I find it quicker to grep the logs from the recent bug reports potentially linked to MPTCP, e.g.

find workdir/crashes -name "report*" -newermt "$(stat -c "%y" ../mptcp_net-next/vmlinux)" | xargs -r grep "net/mptcp" | cut -d/ -f1-3 | sort | uniq -c | while read -r N D; do echo -n "$D: $N: "; cat $D/description; done

On Syzbot side, the subsystem is mentioned. Is there a way to get something like that on syzkaller side as well, please?

Eventually, could syzkaller tell us if an issue can be reproduced without root access, or from a userspace namespace? → EDIT: discussion moved to #6813

An extra question: on my side, there are 3 to 4 machines running syz-manager, and one running syz-hub. I understood that it would be better for me to re-use syzbot corpus. Should I regularly replace (or merge?) my corpus.db with ci-upstream-kasan-gce-corpus.db? Is it compatible with my kernel config and the syscalls restriction? EDIT: discussion moved to the ML

(Please tell me if I should create other feature requests for some questions or ideas here, or move the discussion elsewhere)

Thanks!
Matt

[a-nogikh]

Hi Matt,
Thanks for reaching out!

In this case, I'm only interested in having Syzkaller exercising a specific subsystem. I then used the enable_syscalls option in syz-manager config:

I am not well acquainted with the MPTCP subsystem specifically, but FWIW here are the syscalls we enable on our net instances:

				"enable_syscalls": [
					"accept", "accept4", "bind", "close", "connect", "epoll_create",
					"epoll_create1", "epoll_ctl", "epoll_pwait", "epoll_wait",
					"getpeername", "getsockname", "getsockopt", "ioctl", "listen",
					"mmap", "poll", "ppoll", "pread64", "preadv", "pselect6",
					"pwrite64", "pwritev", "read", "readv", "recvfrom", "recvmmsg",
					"recvmsg", "select", "sendfile", "sendmmsg", "sendmsg", "sendto",
					"setsockopt", "shutdown", "socket", "socketpair", "splice",
					"vmsplice", "write", "writev", "tee", "bpf", "getpid",
					"getgid", "getuid", "gettid", "unshare", "pipe",
					"syz_emit_ethernet", "syz_extract_tcp_res",
					"syz_genetlink_get_family_id", "syz_init_net_socket",
					"mkdirat$cgroup*", "openat$cgroup*", "write$cgroup*",
					"clock_gettime", "bpf", "openat$tun", "openat$ppp",
					"syz_open_procfs$namespace", "syz_80211_*", "nanosleep",
					"openat$nci", "ioctl$IOCTL_GET_NCIDEV_IDX", "openat$rfkill",
					"openat$6lowpan*", "openat$pidfd", "openat$tcp*"
				],

You could also try to play with configuring focus areas to tell syzkaller to prefer seeds that touch particular parts of the kernel:

syzkaller/pkg/mgrconfig/config.go

Lines 251 to 257 in 6a673c5

	// FocusAreas configures what attention syzkaller should pay to the specific areas of the kernel.
	// The probability of selecting a program from an area is at least `Weight / sum of weights`.
	// If FocusAreas is non-empty, by default all kernel code not covered by any filter will be ignored.
	// To focus fuzzing on some areas, but to consider the rest of the code as well, add a record
	// with an empty Filter, but non-empty weight.
	// E.g. "focus_areas": [ {"filter": {"files": ["^net"]}, "weight": 10.0}, {"weight": 1.0} ].
	FocusAreas []FocusArea `json:"focus_areas,omitempty"`

Is there a way to get something like that on syzkaller side as well, please?

That should be not super tricky to implement, thanks for the feature request.

hould I regularly replace (or merge?) my corpus.db with ci-upstream-kasan-gce-corpus.db?

It probably makes sense once in a while indeed, but not super regularly: our corpuses are already saturated and it's rare that the fuzzer discovers significant chunks of new coverage.

Is it compatible with my kernel config and the syscalls restriction?

I think it should not be a problem anyway - syzkaller triages its corpus on start, so it will just discard all seeds that did not produce new coverage in your enivronment.

(Please tell me if I should create other feature requests for some questions or ideas here, or move the discussion elsewhere)

Feature requests definitely belong here in GitHub. For questions it may be better to post them to our mailing list: syzkaller@googlegroups.com :)

[matttbe]

Hi Aleksandr,

Thank you for your reply!

In this case, I'm only interested in having Syzkaller exercising a specific subsystem. I then used the enable_syscalls option in syz-manager config:

I am not well acquainted with the MPTCP subsystem specifically, but FWIW here are the syscalls we enable on our net instances:

Thank you, that's very useful!

You could also try to play with configuring focus areas to tell syzkaller to prefer seeds that touch particular parts of the kernel:

Oh, I didn't know about these (hidden? :) ) experimental options! So in my case, I guess I should use

"focus_areas": [ {"filter": {"files": ["^net/mptcp"]}, "weight": 10.0}, {"weight": 1.0} ].

Or without the {"weight": 1.0} to drop everything not touching MPTCP?

Is there a way to get something like that on syzkaller side as well, please?

That should be not super tricky to implement, thanks for the feature request.

Great :)

Should I regularly replace (or merge?) my corpus.db with ci-upstream-kasan-gce-corpus.db?

It probably makes sense once in a while indeed, but not super regularly: our corpuses are already saturated and it's rare that the fuzzer discovers significant chunks of new coverage.

Thank you! I will ask more questions on the ML if any!

Is it compatible with my kernel config and the syscalls restriction?

I think it should not be a problem anyway - syzkaller triages its corpus on start, so it will just discard all seeds that did not produce new coverage in your enivronment.

Good to know, thank you!

(Please tell me if I should create other feature requests for some questions or ideas here, or move the discussion elsewhere)

Feature requests definitely belong here in GitHub. For questions it may be better to post them to our mailing list: syzkaller@googlegroups.com :)

Noted, I will do that, thank you!

[a-nogikh]

Oh, I didn't know about these (hidden? :) ) experimental options!

It's been for quite a while there already, maybe it's the time to move it out of the experimental options list :)

So in my case, I guess I should use
"focus_areas": [ {"filter": {"files": ["^net/mptcp"]}, "weight": 10.0}, {"weight": 1.0} ].

Yes, it looks correct.

Or without the {"weight": 1.0} to drop everything not touching MPTCP?

Exactly.

[matttbe]

Oh, I didn't know about these (hidden? :) ) experimental options!

It's been for quite a while there already, maybe it's the time to move it out of the experimental options list :)

Good idea!

So in my case, I guess I should use
"focus_areas": [ {"filter": {"files": ["^net/mptcp"]}, "weight": 10.0}, {"weight": 1.0} ].

Yes, it looks correct.

Or without the {"weight": 1.0} to drop everything not touching MPTCP?

Exactly.

Great, thank you for your reply!