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.
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.
Implements TryFrom for FdLink for CgroupSkb, CgroupSock, CgroupSockAddr
and SockOps program types. This allows support for link pinning for
these program types, aligning with the documentation for FdLink.
Fixes: #739
Co-authored-by: Benjamin Barzen <bbarzen@amazon.com>
Short-circuits `CACHE` to true if the field is non-zero.
This saves from executing the probing logic since the logic essentially
checks if the field can process (or doesn't error) non-zero value.
Cached probed for ProgramInfo fields instead of exposing it through
global FEATURE. Probing occurs on cache miss, which happens when first
accessing the field, *and* if the field is 0.
We have had loaded_links in the API as `#[doc(hidden)]` for a while.
I've been using it in bpfman and it's been fine. This commit does the
minimal work required to make the API stable.
We expose a `LinkInfo` type - similar to `ProgInfo` - which wraps the
generated type. In this case, `bpf_link_info`.
A few accessor functions have been added for `id`, `link_type` and
`program_id`. There are many more fields that could be (eventually)
made public.
As a convenience, `LinkInfo` can be retrieved from an existing FdLink
by using `FdLink::info()`.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
In aarch64, with kernel 5.5, my programs that use `bpf_probe_read_user`
don't work successfully because `aya` is mistakenly re-writting it
`bpf_probe_read` because it falsely detects that the kernel doesn't
support `bpf_probe_read_user`.
I hadn't updated my `aya` version in a while, but while updating it to
fix a separate issue (panics when parsing kernel versions of PVE
kernels) and running my test suite I saw tests failing on aarch64 5.5
kernels. A git bisect led me to this commit:
942ea51906 and further investigation in the
difference of the new and old assembly showed that the only difference
was subtracting 8 vs adding -8. When I put it back as adding 8 (but
without handwritten assembly) then things work as expected. Since it
used to be `BPF_ADD` and the commit that changed it was just about no
longer handwriting assembly without any reason for the switch to
`BPF_SUB` putting it back as `BPF_ADD` seems reasonable.
When using `BPF_SUB` 8, the handwritten program in this function
returns a permission error which is treated by this function as
`bpf_probe_read_kernel` not being supported when it is but for some
reason `BPF_SUB` is not. My guess is that it might be an early verifier
error but I am not 100% sure as I thought verifier errors are normally
`EINVAL` not `EPERM` but I have a vague memory of seeing `EPERM` in the
past for errors that happened very early in the verifier.
Fixes: #1233
clippy complained that cfg_attr is applied to the macro invocation and
therefore will not be expanded. This was a false-positive, however
when playing with cargo expand I did notice that the cfg and cfg_attr
section weren't propagating as I would expect them to.
Adding a meta matcher to the impl_try_from_map macro allows us to
remove the need for AsyncPerfEventArray to be in a separate invocation
of the macro while also making sure that attributes do get propagated
to the generated functions.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Allow for a ProgramInfo to be converted into one of the program types
that we support. This allows for a user of Aya access to reattach,
pin or unload a program that was either, previously loaded, or was
loaded by another process.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
We have previously tried to import traits anonymously where possible but
enforcing this manually was hard.
Since Rust 1.83 clippy can now enforce this for us.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Limit of map names in eBPF is 16 bytes and they have to be NULL
terminated.
Before this change, long names were truncated to 16 bytes.
`MAP_WITH_LOOOONG_NAAAAAAAAME` would become `MAP_WITH_LOOOONG`, which
doesn't contain the NULL byte.
This change fixes that by truncating the name to 15 bytes, ensuring
that the 16th byte is NULL. `MAP_WITH_LOOOONG_NAAAAAAAAME` is truncated
to `MAP_WITH_LOOOON\0`.
In practice this will forbid unused dependencies because we run clippy
with `--deny warnings`.
Workspace lints is a nice place to ratchet up lints through the codebase
all at once and consistently.
Turns out this was actually being used through magic.
Remove mips since it is a tier 3 target that is only supported on
nightly and dtolnay/rust-toolchain doesn't seem to handle installing
targets without std.
Exclude xtask since it depends on `ring` which doesn't build on all
targets.
Fix compilation on armv7 which had rotted.
This reverts commit d92fc95c39.