-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Description
We are in the process of deciding how to integrate KFuzzTest target fuzzing with syzkaller,
when it is eventually upstreamed into the Linux kernel (see related RFC).
In #6280, two approaches are proposed on the syz-manager side:
- Static discovery of targets: a tool is proposed that can systematically generate
KFuzzTest descriptions from a vmlinux binary. These can be checked into the
syzkaller repository, and compiled like any other syzkaller description via
make descriptions. - Dynamic discovery: instead of first generating the descriptions and compiling
them, we do everything at boot and integrate them into the target used by
syz-manager.
The benefit of dynamic discovery is that we can adapt to changes in KFuzzTest targets
in the kernel without manual intervention, as internal kernel function interfaces
are known to change more frequently than syscall interfaces. However, it comes with
two major trade-offs:
- Dynamically discovered targets are internal to syz-manager, and therefore can't be
be easily reviewed, version-controlled, or sanity-checked. - It requires more invasive changes to syz-manager which is not designed to add new
syscalls at runtime.
As a potential middle-ground for syzbot, we could generate the KFuzzTest descriptions
as a build artifact. This would keep the descriptions in-sync with the kernel without
committing them to the main syzkaller repository, and it would avoid the complexity
of dynamic discovery.
TL;DR: For KFuzzTest targets, should we prefer static .syz descriptions committed
to the repo, or should they be discovered dynamically by the fuzzer at runtime? Or
should we treat them as build artifacts?