For some reason, the aarch64 6.1 debian kernel was not compiled with
CONFIG_KALLSYMS_ALL=y, 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.
- .github: pull the corresponding debug packages down as well as regular
kernels
- test: attach the perf_event_bp test breakpoint to the modprobe_path address
in kallsyms if present, or by applying the kaslr offset to the System.map
address if not found
- xtask: preferentially extract the System.map file from the debug package, if
available
Test perf_event breakpoints by attaching a RW breakpoint to
modprobe_path and triggering a read from procfs, asserting that the tgid
of the program triggering the breakpoint matches the test program.
- aya-obj: Generate userspace bindings for HW_BREAKPOINT_* options
- aya: Support PERF_TYPE_BREAKPOINT by adding an optional hardware
breakpoint configuration to PerfEvent::attach() and perf_event_open
functions.
- ebpf: Generate bindings for `struct bpf_perf_event_data` and update
the PerfEventContext to use them instead of a void pointer.
- xtask: Update codegen for constified anonymous HW_BREAKPOINT_* enums
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.
Bundle handling of Debian kernel archives into xtask so callers can pipe
the raw `.deb` paths straight into `cargo xtask integration-test vm …`.
The driver now extracts each archive into `<cache>/kernel-archives`,
locates the matching `vmlinuz-*`, `lib/modules/*`, and config files, and
feeds those into the initramfs build without requiring the user to
pre-run dpkg/tar. With this in place we drop
`.github/scripts/find_kernels.py`, simplify AGENTS.md/CI instructions to
use `find test/.tmp -name '*.deb'`, remove the gnu-tar requirement we no
longer need, and add `tar` as a workspace dependency for the extractor.
This allows us to run virtualized integration tests on macOS hosts.
Bump Ubuntu to 24.04 because we seem to be getting miscompilation on
x86_64 otherwise (when using `x86_64-linux-musl-gcc`). Add `apt install
liblzma-dev` since it doesn't seem to be present in ubuntu-24.04.
Recent changes[0][1] have broken compatibility with macOS; add a patch
to conditionally compile these snippets.
Patch and compile the source unconditionally; caching only the network
portion is good enough and less error prone.
[0] ae18b94099
[1] 97169cd6d9
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.
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.
Friday Ortiz
Friday Ortiz
Tamir Duberstein
Altug Bozkurt
Michal R
dependabot[bot]
Thomas Eizinger
tamird
Adam Schreck