All helper functions and context methods are returning `c_long` as an
error. Before this change, aya-template and book examples were adjusting
the error type in `try_*` functionns return type of the program. For
example, for XDP programs programs, which return `u32`, the type
returned by `try_*` functions, was `Result<u32, u32>`.
This approach is forcing people to write boilerplate code for casting
errors from `c_long` to the expected type, like:
```rust
MY_MAP.insert(k, v, 0).map_err(|_| 1u32)?;
```
This change solves that problem by:
* Using `Result<i32, c_long>` as a type for `try_*` functions for
SKB-based programs and then replacing errors with `TC_ACT_SHOT` or
`0` once in the main program function.
* Using `Result<u32, c_long>` as a type for `try_*` functions in `try_*`
funnctions for XDP programs and then replacing errors with `XDP_ABORT`.
* Using either `Result<u32, c_long>` or `Result<i32, c_long>` as types
in `try_*` functions for all other program types where the return value
matters (LSM, sysctl etc.) and replacing the error either with `0` or
`1` (depending on which number means "block the action" for particular
type of program).
* Using `Result<(), c_long` for all other program types where the
return value doesn't matter (kprobe, uprobe etc.).
So errors can be handled without casting, like:
```rust
MY_MAP.insert(k, v, 0)?;
```
The other change is fixing return values of cgroup_skb, sockopt and
sysctl programs (1 means "allow", 0 means "deny").
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
This adds `perf_event` program type as a template entry.
The new entry comes with a skeleton example which register
scheduled events on each CPU at 1 HZ, triggered by the kernel
(based on clock ticks). The corresponding BPF logic logs each
event, and can identify kernel tasks from userland processes.
Users should opt in into `unsafe` when performing particular unsafe
actions (accesing raw pointers, interacting with maps etc.), but
assuming that the whole eBPF program code is unsafe is quite an
exaggeration.
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
That new context type exposes `data` and `data_end` fields for direct
access to the packet payload.
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
eBPF programs cannot be debugged and those ones built with the default
dev profile are often annoying the verifier. Therefore it doesn't make
sense to compile not optimized eBPF objects.
However, we still want to let people to use the dev profile, especially
in the future when we want to get rid of xtask by using cargo binary
dependencies[0]. The trick is to have no real difference between dev and
release profile in eBPF.
This change doesn't affect the userspace part which still is going to
contain debug symbols when built with dev profile.
[0] https://rust-lang.github.io/rfcs/3028-cargo-binary-dependencies.html
Signed-off-by: Michal Rostecki <vadorovsky@gmail.com>
This change removes the differentiation between release and dev profiles
for eBPF programs. There is no way eBPF programs can be debugged and
building them with dev profile just makes them slower and often unable
to be verified. They should be always built with the release profile.
After this change, `cargo xtask build-ebpf` is going to build eBPF
programs with release profile. And the userspace program is going to
include eBPF program bytes from target/release/. Regardless of which
profile is being used in the userspace program.
`cargo xtask build-ebpf` has the --profile argument which can be
optionally used (i.e. for user-defined profiles), but by default the
value of that option is `release`.
Signed-off-by: Michal Rostecki <mrostecki@opensuse.org>
User may specify a program_type by prompt or CLI flag.
We then generate skeleton code to the ebpf program for a noop program of
that type.
Requires cargo-generate@main
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Michal Rostecki
Dmitry Savintsev
Luca BRUNO
Josh Taylor
arctic-alpaca
Tatsuyuki Ishi
Kenjiro Nakayama
Dave Tucker
Marcus Weiner
Michal Rostecki
William Findlay
Alessandro Decina