• Andrii Nakryiko's avatar
    bpf: add iterator kfuncs registration and validation logic · 215bf496
    Andrii Nakryiko authored
    Add ability to register kfuncs that implement BPF open-coded iterator
    contract and enforce naming and function proto convention. Enforcement
    happens at the time of kfunc registration and significantly simplifies
    the rest of iterators logic in the verifier.
    
    More details follow in subsequent patches, but we enforce the following
    conditions.
    
    All kfuncs (constructor, next, destructor) have to be named consistenly
    as bpf_iter_<type>_{new,next,destroy}(), respectively. <type> represents
    iterator type, and iterator state should be represented as a matching
    `struct bpf_iter_<type>` state type. Also, all iter kfuncs should have
    a pointer to this `struct bpf_iter_<type>` as the very first argument.
    
    Additionally:
      - Constructor, i.e., bpf_iter_<type>_new(), can have arbitrary extra
      number of arguments. Return type is not enforced either.
      - Next method, i.e., bpf_iter_<type>_next(), has to return a pointer
      type and should have exactly one argument: `struct bpf_iter_<type> *`
      (const/volatile/restrict and typedefs are ignored).
      - Destructor, i.e., bpf_iter_<type>_destroy(), should return void and
      should have exactly one argument, similar to the next method.
      - struct bpf_iter_<type> size is enforced to be positive and
      a multiple of 8 bytes (to fit stack slots correctly).
    
    Such strictness and consistency allows to build generic helpers
    abstracting important, but boilerplate, details to be able to use
    open-coded iterators effectively and ergonomically (see bpf_for_each()
    in subsequent patches). It also simplifies the verifier logic in some
    places. At the same time, this doesn't hurt generality of possible
    iterator implementations. Win-win.
    
    Constructor kfunc is marked with a new KF_ITER_NEW flags, next method is
    marked with KF_ITER_NEXT (and should also have KF_RET_NULL, of course),
    while destructor kfunc is marked as KF_ITER_DESTROY.
    
    Additionally, we add a trivial kfunc name validation: it should be
    a valid non-NULL and non-empty string.
    Signed-off-by: default avatarAndrii Nakryiko <andrii@kernel.org>
    Link: https://lore.kernel.org/r/20230308184121.1165081-3-andrii@kernel.orgSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
    215bf496
btf.c 220 KB