Skip to content

Milestones

List view

  • Per https://github.com/google/buzzer/issues/19 it would be really nice to integrate the generation of eBPF Programs into Syzkaller. This has several benefits, but the one that is the most attractive is that Syzkaller has a more robust set of features that have been actively developed for a while, the most attractive from an eBPF standpoint is the capability to bring up a number of VMs and fuzz potentially different versions of the kernel. In order to achieve this integration, the code under pkg/ebpf would need to be made accessible to other open source projects. We can potentially achieve this by declaring the ebpf library as a go module (including a go.mod file). Then we also need to expose an interface that Syzkaller can invoke to generate/mutate an eBPF Program (more details on how this interface would be used can be found here: https://github.com/dvyukov/syzkaller/commit/1dadad1614f0d86250db71670ff9bf6b999f6aad#diff-8d970a6b0e2c9160fff3960a55eac00eb7f32fea4608550d7b515d7f346f1eccR435

    No due date
    0/3 issues closed
  • Currently the interface to build ebpf programs is less than ideal, a lot of repeated code and hard to write. We need to create a set of functions that would make it easier for someone to write their own ebpf programs. Additionally, the amount of unit tests we have is very minimal, therefore it is very easy to introduce bugs in the current state of the fuzzer. It would be ideal to increase the coverage of unit tests as well as come up with more complex kinds of testing (e.g integration tests) to make sure things are always working.

    No due date
    9/11 issues closed
  • For the initial launch of Buzzer we are doing very simple operations: random ALU and JMP instructions. However this barely scratches the surface of what eBPF is capable of: loops, helper functions, stack storage, etc. The more operations we support on the fuzzer, the higher the chances to find issues we have.

    No due date