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.
Change FromRawTracepointArgs::arg to return T rather than *const T which
seems to have been returning a dangling pointer.
Arguably this is not strictly necessary; edition 2024 seems to be
focused on increased strictness around unsafe code which doesn't unlock
new functionality for our users. That said, this work revealed an
apparent bug (see above) that we wouldn't otherwise catch due to
allow-by-default lints.
Per man 2 perf_event_open:
> RETURN VALUE
> On success, perf_event_open() returns the new file descriptor. On
> error, -1 is returned and errno is set to indicate the error.
Bake this into our syscalls so we stop using `_` so much which can hide
information loss. Remove the type parameter to SysResult.
Per man 2 bpf:
> RETURN VALUE
> For a successful call, the return value depends on the operation:
>
> BPF_MAP_CREATE
> The new file descriptor associated with the eBPF map.
>
> BPF_PROG_LOAD
> The new file descriptor associated with the eBPF program.
>
> All other commands
> Zero.
>
> On error, -1 is returned, and errno is set to indicate the error.
Bake this into our syscalls so we stop using `_` so much which can hide
information loss.
Mehnaz Yunus
Tyrone Wu
Dave Tucker
Omri Steiner
Tamir Duberstein
Andres
Michal Rostecki
arctic-alpaca