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>`.
Add integration tests to verify that btf_maps generated with the
generalized btf_map_def macro are compatible with libbpf's bpf_map_def.
Also add CI infrastructure for macOS cross-compilation to Linux musl,
including stub headers and autoconf cache variables for libbpf-sys
vendored dependencies.
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>
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.
Before this change, Aya supported only legacy BPF map definitions, which
are instances of the `bpf_map_def` struct and end up in the `maps` ELF
section.
This change introduces a BTF map definition for arrays, with custom
structs indicating the metadata of the map, which end up in the `.maps`
section.
Co-authored-by: Tamir Duberstein <tamird@gmail.com>
The log level implementation in b36cbc3eb8
was incomplete as the verifier could reject programs which exceeded
their instruction limits within logging statements. This commit
addresses this issue by making the log level static variable immutable
(s.t. the compiler puts it in a read-only section) and adds an
additional test which the verifier will reject as an infinite loop iff
it is unable to detect that the static variable would otherwise allow
the logging.
Working with aya in vscode will currently show a number of warnings
along the lines of:
```
found duplicate lang item `panic_impl`
the lang item is first defined in crate `std` (which `aya` depends on)
...
second definition in the local crate (`bpf_probe_read`)
```
This comes from feature unification.
integration-test requires the integration-common user feature, which
requires aya, which in turn brings in std.
For this same reason we avoid running clippy across the whole workspace.
We can avoid this issue by using the panic handler from the another
crate, which implements the same loop {} panic handler we use today.
It seems rustc is happy to conditionally link the panic handler
from an external crate without issuing warnings.
Therefore, we add our own crate - ebpf-panic - for this purpose.
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.
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.
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.
Provide an `arg()` method in `RawTracepointArgs` wrapper of
`bpf_raw_tracepoint_args` and also in `RawTracepointContext`, so
it's directly available in raw tracepoint programs.
The methods and traits implemented here are unsafe. There is no
way to reliably check the number of available arguments, so
requesting a non-existing one leads to undefined behavior.
Unwinding gives us more information, so we shouldn't disable it
globally. It is already disabled for BPF targets via the target configs
in rustc itself.
This complicates the clippy invocation somewhat, so put it in a shell
script for developer as well as CI use.
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>
