Improving Fuzzing Tools for More Efficient Kernel Testing

Fuzz testing (or fuzzing) is a software testing technique that involves passing invalid or random data to a program and observing the results, such as crashes or other failures. Bamvor Jian Zhang of Huawei, who will be speaking at LinuxCon Europe, realized that existing fuzz testing tools — such as trinity — can generate random or boundary values for syscall parameters and inject them into the kernel, but they don’t validate whether the results of those syscalls are correct.

In his experience, the correctness of arguments passing between the C library and core kernel code is a common problem. And, in his talk — called “Efficient Unit Test and Fuzz Tools for Kernel/Libc Porting,” Bamvor will share some ways to improve the trinity fuzzing tool. We spoke with him to learn more.

Linux.com: Why are syscall issues so common when bringing up a new architecture for the Linux kernel?

Bamvor Jian Zhang: The new porting must fulfill the requirements of the evolving kernel. Usually, there is no standard porting document/reference design. So, porting is always challenging work.

Linux.com: Why don’t existing fuzz testing tools help validate whether syscalls are correct?

Bamvor: Actually, they could do part of the job. Existing fuzz tools focus on the functionality of the syscall not the wrapper. They are useful if the wrapper of the syscall is correct. The wrapper process is done by the porting of kernel and libc. Incomplete or incorrect porting leads to the useless test results with existing fuzz tools.

Linux.com: How did you discover this problem?

Bamvor: We found that trinity could not find the issue even if there are 20 fails in Linux Test Project (LTP). And, we found other issues even after we fixed all the syscall fails in LTP and glibc testsuite. Theoretically, we could add new test cases to existing tools, but this work needs more developers. In the end, the design of ilp32 is evolving. It is hard to catch up on the changes and add new test cases in the limited amount of time.

Linux.com: How can existing tools be improved to help solve the problem?

Bamvor: Generally speaking, we could improve the situation by adding two things to the existing tools. The first thing is to issue the test case of syscall through C library instead of direct syscall. The second thing is to check the argument passing before we execute the real syscall in the kernel.

You won’t want to miss the stellar lineup of keynotes, 185+ sessions and plenty of extracurricular events for networking at LinuxCon + ContainerCon Europe in Berlin. Secure your spot before it’s too late! Register now.