https://github.com/heroickatora/abpfiff
https://github.com/heroickatora/abpfiff
Last synced: about 2 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/heroickatora/abpfiff
- Owner: HeroicKatora
- License: eupl-1.2
- Created: 2023-01-18T17:49:02.000Z (over 2 years ago)
- Default Branch: master
- Last Pushed: 2024-02-19T21:41:19.000Z (over 1 year ago)
- Last Synced: 2025-04-11T10:03:43.558Z (about 2 months ago)
- Language: C
- Size: 77.1 KB
- Stars: 1
- Watchers: 2
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: Readme.md
- License: LICENSE
Awesome Lists containing this project
README
A library to interact with BPF kernel state.
Just simple, pure idiomatic Rust-based bindings to manage user-space state
necessary for interacting with the kernel system. Some little helpers are added
but not beyond the minimalism (avoids generics or extra dependencies).
The name is bacronym for:
> A BPF InterFace Foundation
## Goals
In decreasing order of priority.
* Safer than direct system calls
* Pure Rust code, no C dependency
* Minimal dependencies for OS interaction
* Efficient
Non-Goals:
* Replacement for `libbpf`
* A C interface, to be re-evaluated later
* An `async` style of implementation. It should be possible to achieve all
functionality with synchronous code. However, optional concurrency may be
introduced with `async` where efficient.
* Binary analysis and manipulation of BPF programs
## Implementation
Note that the implementation does _not_ need link directly against any `libc`
functions. Rather, it defines an expected interface in terms of free C
functions (`sys::SysVTable`). The caller can fill it with functions loaded
statically or dynamically from a linker but also with another equivalent
implementation. Unfortunately, the data type definitions will have to be
compatible with the platform `libc` in both cases, but it is a start to avoid
the hell of `LD_PRELOAD` as a stupid, global mechanism for overwriting them.
## Motivation
Depending on `libbpf` is quite heavy when only a fraction of it is needed. In
particular, connecting together networking functionality does not depend on
writing BPF. Also, the library is riddled with C-isms:
* unknown or highly implicit thread-safety
* synchronous resources opened and closed in rapid succession just to hide that
resource management complexity from the caller. No really, a new netlink
socket is created, configured, loop polled and closed for literally each
`libbpf_netlink_send_recv` that's hidden in _a lot_ of operations.
* Code that looks like so:
```c
static int libbpf_netlink_send_recv(...) {
/* ... */
req->nh.nlmsg_seq = time(NULL);
```
They are fucking with us, no?