Integrate with syzkaller about buzzer HOT 5 OPEN

Hey @dvyukov

Thanks for opening this, let's pursue this idea!

I was chatting offline with @meadori about how we could achieve this and here are some initial thoughts:

1. From a Buzzer perspective and eBPF generation perspective, the ebpf program generation is already kindof self contained, we think it would make sense to export that as a go module/library that could then be imported and used into syzkaller. While we considered the option of fully integrating buzzer into Syzkaller and deprecating some other features/logic, we think there is a path moving forward where both fuzzers share a common "core" and coexist in harmony :)

2. Thanks for your prototype! I reviewed it quickly and it overall looks good to me. I am still learning how to use the fd_arrays in eBPF but I am confident it would not pose a problem. I can't come up with anything else that would be needed as part of that interface.

3. On the buzzer side, the eBPF generation library needs a bit of work, we would like to increase unit test coverage, refactor into a more easy to use interface, etc. I certainly can squeeze the necessary work to have a syzkaller friendly interface among that work.

4. Regarding map types: Perhaps instead of returning the number of map fds the program uses from fd_array we could return an array of map_types? where each position in the array corresponds to a map_fd and each value represents the expected map type for that fd

@meadori is there anything else you think I am missing from here?

Thanks again for opening this and pursuing this idea!

from buzzer.

@thatjiaozi you covered everything that we talked about. At first glance, the integration steps seem reasonable. I will look more at the specifics this week.

from buzzer.

Re 1: totally fine with me.

Re 2: AFAIU when using the bpf array, the program refers to maps using index (0, 1, 2, ...), and the actual map FDs are supplied in a separate array. This allows the program to be constant regardless of actual FD values.

Re 3: Mostly up to you, but I would prefer earlier integration to parallelize the work and shake our interface details (you provide a trivial implementation early but with the final interface, and then we improve and integrate in parallel).

Re 4: Looks reasonable to me. But I don't know if different map types have significantly different interfaces or not. If they do (program validation will fail too often with wrong map type), then it makes sense.

from buzzer.

Sounds good to me on the point on 3. Let's shake the details of the interface ASAP and then we can split the work.

I'll sync with @meadori on this and submit a PR soon.

from buzzer.

Also I have to admint I had no idea how to use fd_array in ebpf but I just figured out, the documentation is not very helpful but this comment (https://github.com/libbpf/libbpf/blob/master/include/uapi/linux/bpf.h#L1185) gave me all the clues I needed.

After some local hacking I managed to get it to work with buzzer, I think, at the buzzer side, we should entirely ditch the hardcoded map_fd values in favor of fd_arrays as they look way more flexible.

from buzzer.