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>
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>
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 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.
When `aya::obj` was migrated to be its own crate `aya-obj`, the `obj`
alias was created to preserve existing imports that relied on
`crate::obj`.
This resulted in 3 ways to import `aya-obj` objects:
- `use aya_obj::*`
- `use obj::*`
- `use crate::obj::*`
The `obj` alias is now removed to avoid confusion, and all `obj` imports
are funneled through `aya_obj`.
Fixes#1132.
Note that this change does not add support in the public API for kprobes
or tracepoints, but it's a trivial matter of plumbing.
Along the way, the Uprobe::attach API is cleaned up to make the
attachment location more coherent. The logic being: if we're going to be
breaking the API anyway, may as well clean it up a bit.
Furthermore, the aya::sys::bpf_link_attach function is cleaned up by
properly modeling the the union in the final field with a rust enum.
This commit adds the initial support for TCX
bpf links. This is a new, multi-program, attachment
type allows for the caller to specify where
they would like to be attached relative to other
programs at the attachment point using the LinkOrder
type.
Signed-off-by: astoycos <astoycos@redhat.com>
Co-authored-by: Andre Fredette <afredette@redhat.com>
Co-authored-by: Dave Tucker <dave@dtucker.co.uk>
Co-authored-by: Tamir Duberstein <tamird@gmail.com>
This change allows multiple BPF programs to attach to a cgroup (via the option
`CgroupAttachMode::AllowMultiple`), and allows a program to specify that it can be
overridden by one in a sub-cgroup (via the option `CgroupAttachMode::AllowOverride`).
And BpfLoader to EbpfLoader.
This also adds type aliases to preserve the use of the old names, making
updating to a new Aya release less of a burden. These aliases are marked
as deprecated since we'll likely remove them in a later release.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
This is a breaking change but adds another level of safety to ensure
the file descriptor we receive is valid. Additionally, this allows
aya to internally easily duplicate this file descriptor using std
library methods instead of manually calling `dup` which doesn't
duplicate with the CLOSE_ON_EXEC flag that is standard pratice to
avoid leaking the file descriptor when exec'ing.
This commit reveals but does not address a file descriptor leak in
LircLink2::query. This function returns a list of `LircLink`s where
each of them have a program file descriptor that is not going to be
closed. This commit does not add this leak; it merely makes it louder
in the code.
`ProgramData::fd` is now a `ProgramFd`. This means that `ProgramData`
now closes the file descriptor on drop. In the future we might consider
making `ProgramFd` hold a `BorrowedFd` but this requires API design work
due to overlapping borrows.
Since `ProgramFd` is no longer `Copy`, update methods to take it by
reference to allow callers to use it multiple times as they are
accustomed to doing.
`ProgramFd` is now returned by reference and implements `try_clone` to
allow callers to avoid file descriptor cloning when desired.
This is an API breaking change.
Updates #612.
This is just taking https://github.com/aya-rs/aya/pull/633 to its
logical conclusion. Because `std::os::fd` was only introduced as a
module in Rust v1.66.0 I have also updated the `Cargo.toml` of the
`aya` package to reflect the true MSRV. Note that this commit is *not*
the cause for this MSRV bump, that was done by a previous commit, this
commit is just making it explicit in the `Cargo.toml`
1. Removes OwnedLink
2. Allows Links to be converted into FdLink
3. Introduces a PinnedLink type to handle wrap FdLink when pinned and
support un-pinning
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
This allows access to XdpLink, XdpLinkId etc... which is currently
unavailable since these modules are private
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
Remove LinkRef and remove the Rc<RefCell<_>> that was used to store
type-erased link values in ProgramData. Among other things, this allows
`Bpf` to be `Send`, which makes it easier to use it with async runtimes.
Change the link API to:
let link_id = prog.attach(...)?;
...
prog.detach(link_id)?;
Link ids are strongly typed, so it's impossible to eg:
let link_id = uprobe.attach(...)?;
xdp.detach(link_id);
As it would result in a compile time error.
Links are still stored inside ProgramData, and unless detached
explicitly, they are automatically detached when the parent program gets
dropped.
Map and ProgramData objects had unnecessarily cloned strings for their
names, despite them being just as easily available to external users via
bpf.maps() and bpf.programs().
This commit adds 2 new methods to aya::sys
- bpf_pin_object
- bpf_get_object
Which allow the pinning and retrieval of programs/maps to bpffs.
It adds a `Program.pin` API, such that a loaded program can be pinned.
For map pinning, the user must ensure the `pinning u32` in the
`bpf_map_def` is set to 1, maps will be pinned using a new builder API.
BpfLoader::new().map_pin_path("/sys/fs/bpf/myapp").load_file("myapp.o")
This will pin all maps whose definition requests pinning to path + name.
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
