kernel: selftest below 6.4 is confirmed only under emulated networking

[echemythia]

Status

The sub-6.4 functional gap this issue was opened for is closed. s3tap selftest now
passes end to end on v5.8 and v5.15, all four capabilities (DNS / TCP / TLS-SNI / HTTP),
against a real endpoint. The msg_first_base relocation path below 6.4 is therefore confirmed
by a real capture rather than only by the isolated probe it rested on before.

What remains is narrower, and is why this stays open. See "Remaining gap" below.

What the 5.x runs found

They did not just confirm the expected. Below kernel 5.11 every BPF map is charged against
RLIMIT_MEMLOCK, whose default soft limit is 64 KiB, far too small for this object's maps. Map
creation failed with EPERM even as root, and the error path blamed capabilities
("grant them with sudo s3tap setup, or run under sudo") at a user who already had them. So
s3tap could not load at all on its own documented floor. load_and_attach now raises the limit
before loading.

The kernel matrix could not have caught this. It loads through bpftool, which raises the limit
itself, so a green v5.8 matrix row said the programs VERIFY, not that the agent could load them.
That is the general lesson worth keeping: prefer a selftest run over a matrix row whenever the
question is whether s3tap works, rather than whether the object is accepted.

Remaining gap

Both 5.x runs were under virtme-ng with user-mode (slirp) networking. The round-trip floor
there is an emulator artifact rather than a real network floor: min RTT reads ~0.1 ms and srtt
~1.2 ms.

That is enough to prove every capability fires and every record shape is produced. It is not
enough to trust a latency VERDICT taken there, because every span is judged as a multiple of a
floor that the emulator invented. A run on real hardware would exercise the parts that only a
real path can: a plausible RTT floor, real segment loss and retransmit accounting, and a
handshake that is not synthesised.

What would close it

A s3tap selftest run below 6.4 on real hardware against real S3, with all four
capabilities asserted, recorded in scripts/kernel-compat/BPF-TESTING.md with the kernel
version.

Affected

bpf/src/s3tap.bpf.c (msg_first_base and everything downstream of it),
scripts/kernel-compat/BPF-TESTING.md.

[echemythia]

Partly answered by running s3tap selftest end to end in VMs.

v5.15 and v5.8 both PASS all four capabilities (DNS / TCP / TLS-SNI / HTTP) against a real endpoint, so the sub-6.4 msg_first_base path is confirmed functionally, not just by an isolated probe.

Getting there required a fix, which is the more useful result: below kernel 5.11 every BPF map is charged against RLIMIT_MEMLOCK, default soft limit 64 KiB, so map creation failed with EPERM even as root and the error blamed capabilities. load_and_attach now raises the limit before loading.

The kernel matrix could not have caught this: it loads through bpftool, which raises the limit itself. A green v5.8 matrix row meant the programs verify, not that the agent could load them.

Leaving this open for the remaining gap: these runs used virtme-ng with user-mode networking, so the RTT floor is not a real network floor. A capture on real hardware below 6.4 would close it fully.