On Wed, May 7, 2025 at 11:15 AM Zvi Effron <zeffron@xxxxxxxxxxxxx> wrote: > > > My understanding is that with the Fast-Path termination mechanism, those write > instructions will still be executed and will still update the map. But if the > values they are writing are dependent on the results of any patched function > calls, the values will not be the intended ones which will result in data > corruption. This corruption would not impact the safety of the kernel, but > could cause problems for userspace applications relying on the map data. > > Is that a correct understanding? If so, is that a concern that should be > addressed/mitigated? In broad strokes it's correct. The fast execute approach will not be stubbing out unconditional calls. Like all bpf_rcu_read_lock, bpf_spin_lock, etc will still be executed. Anything that returns OR_NULL will be replaced with NULL. Like bpf_obj_new() will return NULL. Think of it as forced ENOMEM situation where everything that can fail is artificially failing. There surely will be logical bugs in the program, since programmers rarely test the logic in cases of "impossible" failures. The kernel itself is an example. syzbot reports due to failure injection are here to stay. if (kmalloc() == NULL) // just exit quickly is a typical pattern for kernel code and for bpf progs. In the latter case the verifier checks that the kernel is safe, but the code may leave user space in an inconsistent state. The fast execute approach will exacerbate this issue. And I think it's an acceptable trade-off.
