Comments (5)
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:
-
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 :)
-
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.
-
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.
-
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.
Related Issues (20)
- I wonder if the user is free HOT 1
- run with coverage enabled but failed HOT 7
- `bazel build :buzzer` fails on M1 Macs HOT 1
- Add buzzer to ebpf.io landscape project page
- Propose a public interface that external projects can call to use buzzer's ebpf generation capabilities
- Buzzer's ebpf generation library should declare its own go.mod file
- Make eBPF program writing easier HOT 1
- Increase the test coverage of buzzer
- Errors returned from ebpf apis should be exported for better testing/development practices
- Finish implementing all the ebpf operations helper functions HOT 1
- Create a wrapper around ebpf helper functions to make it easier to fuzz them HOT 1
- What does program flaked mean? HOT 3
- More debug information for the metrics server HOT 4
- 404 page not found on my metrics server webpage HOT 3
- Support MovReg64 HOT 2
- Support different types of ebpf programs
- Run buzzer in the vm and get "Fuzzer run no 0" HOT 8
- OOM-killer when RAM is set to 20G or 40G HOT 1
- Clarification on PointerArithmetic Strategy's Boundary Check HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from buzzer.