Before this change, Aya supported only legacy BPF map definitions, which
are instances of the `bpf_map_def` struct and end up in the `maps` ELF
section.
This change introduces a BTF map definition for arrays, with custom
structs indicating the metadata of the map, which end up in the `.maps`
section.
Co-authored-by: Tamir Duberstein <tamird@gmail.com>
eBPF verifier in recent kernels should be smart enough to track map
map types and catch invalid pointer casts. Rust type system makes sure
that the `get` method can return only the same type the map was created
with. Therefore, safe usage of Aya map types shouldn't cause element
type mismatches.
Manual alignment checks (`pointer::is_aligned` or manual pointer
arithmetic operations) cause the following verifier error:
```
bitwise operator &= on pointer prohibited
```
And it extremely unlikely `bpf_map_lookup_elem` ever returns a
misaligned pointer.
`bpf_map_def` is a legacy map definition. To be able to introduce BTF
map definitions, make the `lookup` and `remove` helpers work with
`c_void` and let the callers cast the map types to it.
Enables creation of Map enum variants directly from MapData instances,
allowing user-space handles to pinned BPF maps without requiring the
original BPF object.
Supports multiple BPF map types.
Motivation:
- Simplifies accessing pinned maps from user space applications.
- Avoids full BPF reloads and potential deadlocks.
- Matches existing ergonomic APIs like LruHashMap::try_from.
- Keeps user code safe and idiomatic.
Closes https://github.com/aya-rs/aya/issues/1305.
Includes test coverage to validate the new API.
The log level implementation in b36cbc3eb8
was incomplete as the verifier could reject programs which exceeded
their instruction limits within logging statements. This commit
addresses this issue by making the log level static variable immutable
(s.t. the compiler puts it in a read-only section) and adds an
additional test which the verifier will reject as an infinite loop iff
it is unable to detect that the static variable would otherwise allow
the logging.
This change implements the `AsFd` trait for the `EbpfLogger` struct.
This allows obtaining a `BorrowedFd` from an `EbpfLogger` instance, which is safer than using `AsRawFd`.
This improves the ergonomics of using `EbpfLogger` with APIs that accept file descriptors.
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
The `Format` implementations for various types were using a wildcard `_`
to match the `None` case on `Option<DisplayHint>`.
This is incorrect as it would also match any `Some(...)` variants that
were not explicitly handled, leading to unexpected behavior.
This commit changes the wildcard `_` to an explicit `None` match to
ensure that only the `None` case is handled, making the matching more
explicit and correct.
Signed-off-by: Xiaobo Liu <cppcoffee@gmail.com>
We've recently added an xtask to bpf-linker (aya-rs/bpf-linker#282),
which resulted in multiple binary targets. Therefore, bpf-linker has
to be installed with the following command:
```
cargo install --git https://github.com/aya-rs/bpf-linker.git bpf-linker
```
The last argument (`bpf-linker`) specifies the binary target.
Rather than support N async runtimes, push this to the user. The
relevant types (`PerfEventArrayBuffer` and `RingBuffer`) implement
`As{,Raw}Fd` which is sufficient with integration with tokio, smol, and
other async runtimes.
`construct_debuglink_path()` returns a `Result`, but it doesn't actually
do anything that can fail. This means callers must do a useless
`unwrap()` to get at the return value.
This fixes the signature to reflect that the function is infallible.
This doesn't get us to zero copy because the reserve/submit APIs do not
support DSTs for reasons I don't remember.
Now that it is unused in userspace, move `LOG_BUF_CAPACITY` to
`aya-log-ebpf` by making its type `LogValueLength` which obviates the
need for `log_value_length_sufficient`.