BPF proposal would let programs fail thousands of kernel calls

Alexei Starovoitov has proposed a build option that would let privileged BPF programs intercept and fail calls into more than 12,000 kernel functions that return errors, so operators can keep user space away from an unfixed security bug until a patched kernel is running.

Today an fmod_ret program, which can skip a call and substitute a return value, is limited to about 1,000 system-call entries, the LSM security hooks, and roughly 20 other functions. That is too narrow for temporary mitigations in networking, filesystems, and memory management. Of 417 fixes in one year that added a failing check, Starovoitov wrote, the function being fixed is a legal attach point only 1 percent of the time. An earlier revision of this idea reached 17 percent. This set would reach about 50 percent, without changing those subsystems by hand.

With the scan enabled, the kernel build reads the linked image, works out which error codes each eligible function can return, and records them. A program holding CAP_BPF and CAP_PERFMON, or a BPF token, may then attach, return zero to let the call proceed, or return one of those errors to skip it. The verifier rejects any other value. On an x86-64 GCC build the scan tagged 12,633 of 78,350 functions. The option defaults to off and is limited to x86-64 and arm64.

The safety rule is deliberately simple, and Starovoitov wrote that it "does not aim at 100 % safety." A caller can already see each listed error without BPF, so a skip is meant to look like a failure the function itself might have produced. Errors are dropped from the list when every path to that return hands a pointer derived from an argument to a function that returns void, the usual shape of an unlock, put, or free. Skipping such a path would leave a lock held. The authors also say loss of function is the point: disabling a piece of netfilter to keep a bug out of reach is working as designed.

It is not a guarantee. A test that skipped one call in each of 4,401 networking, filesystem, and memory-management functions damaged the kernel in about one case in 180. Starovoitov said a name-based deny list can remove those. The analysis also misses inlined unlocks, stack spills, and some callees. The kernel.org BPF CI bot then pointed out further holes, including an x86 push that can make a local's address look like an argument-derived pointer, and an arm64 breakpoint treated as fall-through that could invent a return code.

Anton Protopopov co-developed the series. Attach still does not taint the kernel.