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>`.
For most architectures just bpf_probe_read() works, but for those that
have overlapping memory address spaces, like UML, we must use the
specific helper.
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.
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>
eBPF verifier in recent kernels should be smart enough to track map
map types and catch invalid pointer casts. Rust type system makes sure
that the `get` method can return only the same type the map was created
with. Therefore, safe usage of Aya map types shouldn't cause element
type mismatches.
Manual alignment checks (`pointer::is_aligned` or manual pointer
arithmetic operations) cause the following verifier error:
```
bitwise operator &= on pointer prohibited
```
And it extremely unlikely `bpf_map_lookup_elem` ever returns a
misaligned pointer.
`bpf_map_def` is a legacy map definition. To be able to introduce BTF
map definitions, make the `lookup` and `remove` helpers work with
`c_void` and let the callers cast the map types to it.
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.
This doesn't get us to zero copy because the reserve/submit APIs do not
support DSTs for reasons I don't remember.
Now that it is unused in userspace, move `LOG_BUF_CAPACITY` to
`aya-log-ebpf` by making its type `LogValueLength` which obviates the
need for `log_value_length_sufficient`.
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>
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.
