The helpers always return a signed 64-bit r0 value, but the JIT that
translates eBPF into native instructions differs by architecture. On
x86_64 the generated code writes the helper result into a 64-bit
register, so the CPU sign-extends negative errnos automatically. On
aarch64 the JIT frequently uses 32-bit operations (w0) when copying the
helper return and only zero-extends into the upper half of x0.
That results in broken errno codes on aarch64. For example, when a map
operation returns `-ENOENT`, which is supposed to be -2, the i64
representation yields something like `0x0000_0000_FFFF_FFFE`
(4294967294) instead of -2. In short: the ARM64 JIT doesn’t preserve the
sign in the upper half of the 64-bit register, and the error code has to
be cast to a 32-bit integer to make the sign visible.
This makes it awkward for users, because that behavior prevents simply
comparing helper error codes with constants like `libc::ENOENT` without
manual casts.
Given that the maximum error code limit `MAX_ERRNO` in the kernel is
4095, which fits in a 32-bit integer, coerce the error codes to be `i32`
and make all helpers return `Result<T, i32>`.
Modify the btf_map_def! macro to generate flat #[repr(C)] structs
instead of UnsafeCell wrappers. This produces BTF that both aya
and libbpf can parse.
Support type parameters with optional defaults and const generics with
configurable types. Allow trailing commas and improve formatting.
Also remove UnsafeCell traversal code from aya-obj loader since
it is no longer needed with flat struct layout.
The `redirect_sk_lookup` method for SockMap and SockHash
previously required exclusive references.
The documentation for `bpf_map_lookup_elem` makes no
mention of a requirement for exclusive references.
Therefore, `redirect_sk_lookup` has been changed to
receive shared references to SockMap and SockHash.
This follows the #1417 review discussion: by bundling location
+ cookie into a UProbeAttachPoint we get a more idiomatic Into<_>
entry point, keep the one-to-one relationship enforced by the type
system, and make it easier to extend attach with multi-location
support without introducing parallel arrays or a brand new API.
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.
We have started to see errors in CI:
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID[eax=80000001h].ECX.svm [bit 2]
The internet says this is the remedy.
The traits `FromBtfArgument`, `FromRawTracepointArgs`, `FromPtRegs` are
all fancy ways of saying `Argument` - so replace these traits with it.
This also removes the use of `bpf_probe_read` which was introduced in
05c1586202 because I can't reproduce the
need for it.
Debian packages are just nested archives, where the outer one is ar
and the inner one is lzma2 tarball. Use Rust crates to unpack them.
Co-authored-by: Tamir Duberstein <tamird@gmail.com>
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.
`git submodule update` fails when running in a codex sandbox:
```
error: could not lock config file /Users/tamird/src/aya/.git/modules/libbpf/config: Operation not permitted
```
so just avoid it when not necessary.
When preparing the VM initramfs detect the `config-*` file that ships alongside
the vmlinuz/modules in each kernel archive and install it under `/boot` (both
as `/boot/config` and `/boot/config-<version>`). This makes the running
kernel’s configuration available inside the guest for the integration tests.
