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.
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.
Retire the use of `CARGO_CFG_BPF_TARGET_ARCH` -- using a `cfg` allows
cargo to properly use a cache per cfg, making `./clippy.sh` much faster.
```
Cold: ./clippy.sh --target x86_64-unknown-linux-gnu -p aya-build 75.38s user 137.28s system 211% cpu 1:40.43 total
Warm: ./clippy.sh --target x86_64-unknown-linux-gnu -p aya-build 4.46s user 3.41s system 71% cpu 11.01 total
```
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.
This crate uses a very old version of `nix` which is preventing us from
adding support for loongarch64.
Make panic-in-panic more uniform while I'm here.
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>