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>
Make the xz2 dependency optional to allow building without a C cross
compiler. This allows clippy.sh to be used on e.g. macOS more easily:
```
./clippy.sh --target x86_64-unknown-linux-gnu --exclude-features xz2
```
This removes octorust which takes absolutely ages to compile and also
requires native TLS libraries which in turn require a C toolchain. The
latter is a pain when cross compiling from macOS.
This reverts commit cc2da4a2a4.
The binding for BPF_ADD was missing from codegen.
Use BPF_.* to capture all of these to avoid missing bindings in future.
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
At present, `aya_build` will always use `+nightly` to build the
eBPF kernel. This is problematic in environments such as CI, where
tools always need to be installed first. Installing the current
nightly Rust toolchain gives you a new toolchain every day. This
poisones caches and makes CI jobs non-deterministic.
Resolves: #1226
SergejIsbrecht
dependabot[bot]
Tamir Duberstein
Mehnaz Yunus
Tyrone Wu
Dave Tucker
Omri Steiner
dave-tucker
Andres
Michal Rostecki
Thomas Eizinger