Implement `PerfEventConfig::Breakpoint`, allowing users to attach
hardware breakpoints. Generate `HW_BREAKPOINT_*` and `struct
bpf_perf_event_data` in support of this feature and update the type of
`PerfEventContext` accordingly.
Add a test exercising R, W, RW, and X breakpoints. Note that R
breakpoints are unsupported on x86, and this is asserted in the test.
Extend the VM integration test harness and supporting infrastructure
(e.g. `download_kernel_images.sh`) to download kernel debug packages and
mount `System.map` in initramfs. This is needed (at least) on the aarch
6.1 Debian kernel which was not compiled with `CONFIG_KALLSYMS_ALL=y`
for some reason, and the locations of globals are not available in
kallsyms. To attach breakpoints to these symbols in the test pipeline,
we need to read them from System.map and apply the KASLR offset to get
their real address. The `System.map` file is not provided in the kernel
package by default, so we need to extract it from the corresponding
debug package. The KASLR offset is computed using `gunzip` which appears
in kallsyms on all Debian kernels tested.
Co-authored-by: Tamir Duberstein <tamird@gmail.com>
This makes it more difficult to mishandle callers of `perf_event_open`.
Change `wakeup_events = 0` to 1; per `man 2 perf_event_open`:
Prior to Linux 3.0, setting wakeup_events to 0 resulted in
no overflow notifications; more recent kernels treat 0 the
same as 1.
This commit extends the EbpfLoader with set_map_pin_path that allows the
caller to associate a named map with a pin path.
One note is that this path is an absolute path, not relative to
`map_pin_path`, and it forces the map to be loaded from that path.
This is the path in which pinned maps are created or resolved. It
isn't actually the path for any specific map itself. This rename
makes way for a method `set_map_pin_path` that actually specifies
the pin path for a specific map.
Add guardrails for when setting event type and config for perf_event
programs. The `PerfEventConfig` enum now defines the event `type` and
`config` of interest.
Remove public re-exports, and add idiomatic Rust types for:
- perf_hw_id => HardwareEvent
- perf_sw_ids => SoftwareEvent
- perf_hw_cache_id => HwCacheEvent
- perf_hw_cache_op_id => HwCacheOp
- perf_hw_cache_op_result_id => HwCacheResult
The motivation behind this is mainly for the `type` and `config` fields
of `bpf_link_info.perf_event.event`. The newly added enums are planned
to also be used in the `bpf_link_info` metadata.
Although `Breakpoint`/`PERF_TYPE_BREAKPOINT` variant exists, it is not
fully implemented. It's only usage at the moment is in link info.
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.
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>
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>
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>
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.
This returns error strings from netlink since they are more informative
than the raw os error. For example:
"Device or Resource Busy" vs. "XDP program already attached".
Signed-off-by: Dave Tucker <dave@dtucker.co.uk>
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.
BPF iterators[0] are a way to dump kernel data into user-space and an
alternative to `/proc` filesystem.
This change adds support for BPF iterators on the user-space side. It
provides a possibility to retrieve the outputs of BPF iterator programs
both from sync and async Rust code.
[0] https://docs.kernel.org/bpf/bpf_iterators.html