ci: add scheduled eBPF kernel-compatibility lane

[Eren Arı (ErenAri)]

Description

What this does

Retina's eBPF tests (make test-ebpf, build tag ebpf) currently run only on the GitHub runner's kernel. This adds an advisory scheduled lane that runs those same tests on a spread of other kernels, by booting each one in a disposable QEMU/KVM VM on the hosted runner's /dev/kvm.

It adds no new test logic. It builds the existing per-plugin test binaries with go test -c -tags=ebpf and runs each as root inside each guest, so a verdict comes from Retina's own loader (github.com/cilium/ebpf) and Retina's own assertions — not a third-party loader's opinion of the object files. The per-kernel verdict is the test binary's exit code.

Two files, +200 lines. The lane generates the eBPF objects it needs at run time and commits nothing.

Results

Full run on my fork: https://github.com/ErenAri/retina/actions/runs/32594848147

Plugin	ubuntu 22.04 / 5.15	ubuntu 24.04 / 6.8	debian 12 / 6.1	centos-stream 9 / 5.14	almalinux 8 / 4.18
dns	pass	pass	pass	pass	pass
tcpretrans	pass	pass	pass	pass	fail

almalinux-8-4.18 is marked required: false, so that failure is reported without failing the lane.

The reason is in the uploaded evidence for that run (kernel 4.18.0-553.150.1.el8_10.x86_64) — four tests fail at load:

--- FAIL: TestBPFLoadAndVerify
--- FAIL: TestBPFTracepointAttach
--- FAIL: TestBPFPerfReaderCreate
--- FAIL: TestBPFStopAfterInitWithoutStart

program retina_tcp_retransmit_skb: load program:
bad CO-RE relocation: invalid func unknown#195896080

I have no idea whether EL8 is in scope for Retina. If it isn't, drop that row from the matrix and the lane is all-green. I would rather show it than quietly leave the kernel out.

Scope and honest caveats

• packetparser is excluded. It compiles its BPF program at run time via loader.CompileEbpf, so it would need clang and the source tree inside each guest rather than an embedded object. Addable later as a heavier build-in-guest lane.
• dropreason is excluded from this first pass. Its resolvePayload picks different program sets per kernel (fexit ≥5.5 amd64 / ≥6.0 arm64, kprobe fallback below, plus a Mariner subset). I did not want the lane to duplicate that logic and drift from it. Running its tests is the natural next step if this shape is useful.
• Loading dropreason's objects in a bare guest also needs nf_conntrack present, since the fexit programs target __nf_conntrack_confirm in that module. Worth knowing if those tests ever run outside a real node.
• The lane fails the job if every kernel returns infra_error. A kernel failure is a finding and is allowed to stand, but "the VM never ran the tests" is not a pass and should not be able to look like one.

One thing you may find interesting

getEbpfPayload() has a Mariner / Azure Linux path (IsAzureLinux(), core-kernel-funcs-only subset) that as far as I can tell nothing currently exercises in CI. I added Azure Linux 2.0 and 3.0 kernel profiles to bpfcompat this week, so that path is testable — but Microsoft publishes no public Azure Linux cloud image, so I cannot run it. If someone can point me at an image or a VHD export, I am happy to extend the lane to cover the Mariner branch.

About the tool

bpfcompat is Apache-2.0. The action is pinned by commit SHA (v0.3.6). A comparable lane runs in falcosecurity/libs (#3024, #3061) if it helps to see it in another project first.

The lane is scheduled-only and the validation step is continue-on-error, so it never runs on pull requests and cannot block a merge. Evidence uploads on every run, including failures. Happy to change the kernel list, the schedule, or the scope — or to close this if it is not useful.

Independent test of a public project; not affiliated with or endorsed by Microsoft.

Related Issue

Follow-up to #2460, where I asked whether a per-kernel compatibility matrix would be useful.

Checklist

• I have read the contributing documentation.
• I signed and signed-off the commits (git commit -S -s ...). The commit is signed-off (DCO), but not GPG-signed — I do not have a signing key registered. Happy to re-sign and force-push if that is required to merge.
• I have correctly attributed the author(s) of the code.
• I have tested the changes locally.
• I have followed the project's style guidelines.
• I have updated the documentation, if necessary. The workflow documents itself in a header comment; happy to add a section to the contributing docs if you would prefer the lane described there.
• I have added tests, if applicable. No new tests — the lane deliberately runs the existing -tags=ebpf tests on more kernels.

Testing Completed

Four full rehearsals on my fork. The final one (linked above) is green with evidence uploaded:

• dns passes on all 5 kernels.
• tcpretrans passes on 4 and fails on almalinux-8-4.18 (non-required), with the CO-RE relocation error quoted above readable in the uploaded command.stdout.

Additional Notes

The artifact upload is an explicit allowlist rather than .bpfcompat/runs/**, because the per-run directory also holds the generated guest SSH private key, the cloud-init seed and the disk overlay. I verified the uploaded artifact contains only the named log files and no key material.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.