Rust CI does not provide dynamic libLLVM tarballs for macOS—only static
ones. Since recent versions of bpf-linker require explicit linkage
configuration for libLLVM, enable the `llvm-link-static` feature to
ensure correct static linking.
Make sure bpf-linker's build.rs sees the downloaded LLVM by adding it
to PATH. On macOS, set the `{CXXSTDLIB,ZLIB}_PATH` variables to point
to the brew prefixes with static libraries it needs.
Given that now we link statically all libLLVM's dependencies and macOS
provides only dynamic zlib, we need to install static zlib from brew.
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>
Since a7cfc694bd we are unpacking dpkg
archives in native Rust and since ... we are downloading and unpacking
debug archives which are around 10x larger than kernel archives for the
same version. Thus build with optimizations so we spend less time in
archive extraction.
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.
Rust emits characters like `<` and `>` in name types with generics, that
are not accepted by the Linux kernel.
In theory, the correct place to fix that would be the Linux kernel, but
given that we have to support old kernels and that such change would be
controversial, it's better to fix it up on our side, at least for now.
We used to rely on bpf-linker to fix that up, but given that we want to
support binutils at some point, we need to do it in Aya during the load.
It was never necessary in the first place. There is no place in the
kernel that enforces BTF map structs themselves to be anonymous. Only
pointer types (that are members of BTF maps) have to be anonymous, but
that's currently handled by LLVM[0].
BTF maps work just fine without it.
[0] https://github.com/llvm/llvm-project/pull/163174
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.
Proc maps terminate with a newline so split(b'\n') yields an empty
slice at the end. Filter it out before parsing so the absolute-path
fallback for pid-scoped attach doesn't get short-circuited by a
ProcMap::ParseLine error.
Remove the use of `CARGO_CFG_TARGET_ARCH` in ebpf crate build scripts,
moving it back only to `aya_build::build_ebpf` where it refers to the
userspace crate's target. In the ebpf crates restore the use of `HOST`
as the default compilation target when neither `--cfg bpf_target_arch`
nor `AYA_BPF_TARGET_ARCH` are provided.