Re: [PATCH bpf-next v4 07/20] bpf: Refuse exception cleanup shapes bpf_throw() cannot dispatch

[Yonghong Song <yonghong.song@linux.dev>]

On 9/21/26 5:30 PM, Eduard Zingerman wrote:
> On Mon, 2026-09-21 at 14:01 -0700, Yonghong Song wrote:
>> The table is on the instructions and the landing pads are in the control
>> flow graph. What is left before bpf_throw() can be taught to dispatch them
>> is to work out what that walk will need, and refuse the shapes it could not
>> handle.
>>
>> bpf_check_cleanup_exceptions() runs after bpf_check_cfg(). Everything it
>> needs is control flow, so it reads what that walk has already worked out
>> rather than working it out again:
>>
>>    subprog_info.might_throw   which subprograms an exception may leave,
>>                               closed over the call graph by
>>                               merge_callee_effects() as the walk pops each
>>                               callee
>>    cleanup_reachability()     what each instruction can reach -- a resume, a
>>                               plain exit, a throw, an indirect jump
>>    cleanup_mark_pad_bodies()  which instructions only ever run with an
>>                               exception already in flight
>>
>> What it refuses:
>>
>>    - a pad that reaches both a resume and a plain exit, or neither: nothing
>>      says whether it is a cleanup pad or a catch pad
>>    - a catch pad, which ends in a plain exit: the walker calls a pad as a
>>      subroutine and cannot hand a frame back its own execution
>>    - a throw in a pad, or a call from a pad to a subprogram that can throw:
>>      a second unwind over frames the first is still discarding
>>    - a bpf_unwind_resume() outside a pad body
>>    - a subprogram that may unwind used as a helper callback: the helper's
>>      own kernel frame would end the walk before it found a boundary
>>    - a tail call, an indirect jump, or an outgoing on-stack call argument in
>>      a pad body, all of which touch a stack the pad does not own
>>    - a BPF_LD_[ABS|IND] in a pad body: a failed load leaves the subprogram
>>      through the hidden exit gen_ld_abs() patches in, and an exit in a pad
>>      is the epilogue, which pops off the walker's stack and returns through
>>      the frame the walk is discarding
>>
>> Signed-off-by: Yonghong Song <yonghong.song@linux.dev>
>> ---
> Why is it necessary to hand-roll a CFG traversal and a separate pass
> for this check? Given that bpf verifier state already maintains
> `unwinding' flag, the instructions properties can be checked from
> do_check_insn(), e.g.:
> - bpf_throw()               -- reject if unwinding
> - call to a throwing global -- reject if unwinding
> - bpf_unwind_resume()       -- require unwinding and the pad-owning frame
> - BPF_EXIT                  -- reject in the pad-owning frame, allow in callees
> - LD_{ABS,IND}              -- reject if unwinding
>
> I think that would take much less code, wdyt?

This is a good idea. Let me try. Thanks!

>
>>   include/linux/bpf_verifier.h |   1 +
>>   kernel/bpf/exception.c       | 404 +++++++++++++++++++++++++++++++++++
>>   kernel/bpf/exception.h       |   2 +
>>   kernel/bpf/fixups.c          |   1 +
>>   kernel/bpf/verifier.c        |   8 +
>>   5 files changed, 416 insertions(+)
> ...