syz-ci: kernel config minimization

[a-nogikh]

I didn't find similar issues in this repo, please close it if it's actually a dup.

Is your feature request related to a problem? Please describe. We could also minimize kernel configs needed to reproduce the issue. The configs syzbot uses are really huge and take a long time to compile even on fast workstations, let alone simple personal computers.

Describe the solution you'd like Ideally we could bisect the kernel options between the config we used and the defconfig. But for the beginning it could probably be enough to just check defconfig + the sanitizer that catched the bug?

Additional context An interesting question is who and at what point should do it. It's definitely not syz-manager, as it operates on an already compiler kernel.

syz-ci is capable of compiling a kernel and running a repro (it could be another job type). Then the question is at what stage it should happen. If it's something like bisection, we would only know the result after some (possibly long) time. And a minimized config does not seem like a good reason to send additional email notifications.

[dvyukov]

We have config bisection/minimization logic: https://github.com/google/syzkaller/blob/master/pkg/kconfig/minimize.go and baseline configs that can be used for bisection (-base): https://github.com/google/syzkaller/tree/master/dashboard/config/linux and I see this is even wired into bug bisection logic: https://github.com/google/syzkaller/blob/master/pkg/bisect/bisect.go#L130-L131 but we never deployed baseline configs to syzbot. We also don't know how well it works and if it will lead to bisection timeouts.

[a-nogikh]

Oh, interesting!

If it's currently wired into the bisection logic, it means that the user might see the minimized config only if the bisection succeeded, right?

[dvyukov]

I don't remember that it's wired into dashboard/emails, so users won't see anything in either case.

[dvyukov]

Or... maybe they will. But maybe we save config on failures as well? kconfig.Minimize should also yield the exact list of configs that are required to reproduce the bug (on top of the baseline config). E.g. it can say only CONFIG_FOO is responsible. That info may be interesting as well.

[a-nogikh]

FTR in https://github.com/google/syzkaller/pull/3970 kconfig.Minimize was made more useful (it can now determine several guilty configs) and flexible (more options to stop earlier). We'll soon see how useful it is in practice.

Hopefully afterwards we'll only need to move bug reproduction to syz-ci and right there we can also do some limited number of kconfig.Minimize iterations.

[dvyukov]

We minimize configs to some degree now, right? Is this done? Do we plan to do something else? @a-nogikh

[a-nogikh]

We somewhat minimize configs as a part of the bisection process, but this issue is about reporting minimized kernel configs along with syzbot has found a reproducer for the following issue emails. I don't think it's going to happen soon, but let's still keep the issue.

[a-nogikh]

A suggestion from Kent Overstreet (see the whole discussion here):

It might be possible to skip the config bisection if we can come up with
per-subsystem .configs (which would have to be automatic, given the
number of subsystems you have to deal with)

ktest also has some machinery for declarative specification of kconfigs,
which I wonder if you'd find useful.

Maybe it'd be something like - bisect to find a minimized kconfig once
per subsystem, then check if a bug repros with the subsystem minimized
kconfig - if it doesn't, maybe add an an option or two to the subsystem
config?