So, yes, assuming we can build the kernel with ARCH=um and run the function under test in a fork-per-run model, that would speed things up significantly. > > I was just looking at what external state (such as the physical memory > mapped) UML has and that would need to be disentangled, and it's not > _that_ much if we can have specific configurations, and maybe mostly > shut down the userspace that's running inside UML (and/or have kunit > execute before init/pid 1 when builtin.) I looked at UML myself around 2023, and back then my impression was that it didn't quite work with KASAN and KCOV, and adding an AFL dependency on top of that made every fuzzer a one-of-a-kind setup. > Did you consider such a model at all, and have specific reasons for not > going in this direction, or simply didn't consider because you're coming > from the syzkaller side anyway? We did consider such a model, but decided against it, with the maintainability of the fuzzers being the main reason. We want to be sure that every fuzz target written for the kernel is still buildable when the code author turns back on it. We also want every target to be tested continuously and for the bugs to be reported automatically. Coming from the syzkaller side, it was natural to use the existing infrastructure for that instead of reinventing the wheel :) That being said, our current approach doesn't rule out UML. In the future, we could adapt the FUZZ_TEST macro to generate stubs that link against AFL, libFuzzer, or Centipede in UML builds. The question of how to run those targets continuously would still be on the table, though.
