1. 26 Mar, 2023 39 commits
  2. 25 Mar, 2023 1 commit
    • Alexei Starovoitov's avatar
      Merge branch 'Don't invoke KPTR_REF destructor on NULL xchg' · 496f4f1b
      Alexei Starovoitov authored
      David Vernet says:
      
      ====================
      
      When a map value is being freed, we loop over all of the fields of the
      corresponding BPF object and issue the appropriate cleanup calls
      corresponding to the field's type. If the field is a referenced kptr, we
      atomically xchg the value out of the map, and invoke the kptr's
      destructor on whatever was there before.
      
      Currently, we always invoke the destructor (or bpf_obj_drop() for a
      local kptr) on any kptr, including if no value was xchg'd out of the
      map. This means that any function serving as the kptr's KF_RELEASE
      destructor must always treat the argument as possibly NULL, and we
      invoke unnecessary (and seemingly unsafe) cleanup logic for the local
      kptr path as well.
      
      This is an odd requirement -- KF_RELEASE kfuncs that are invoked by BPF
      programs do not have this restriction, and the verifier will fail to
      load the program if the register containing the to-be-released type has
      any untrusted modifiers (e.g. PTR_UNTRUSTED or PTR_MAYBE_NULL). So as to
      simplify the expectations required for a KF_RELEASE kfunc, this patch
      set updates the KPTR_REF destructor logic to only be invoked when a
      non-NULL value is xchg'd out of the map.
      
      Additionally, the patch removes now-unnecessary KF_RELEASE calls from
      several kfuncs, and finally, updates the verifier to have KF_RELEASE
      automatically imply KF_TRUSTED_ARGS. This restriction was already
      implicitly happening because of the aforementioned logic in the verifier
      to reject any regs with untrusted modifiers, and to enforce that
      KF_RELEASE args are passed with a 0 offset. This change just updates the
      behavior to match that of other trusted args. This patch is left to the
      end of the series in case it happens to be controversial, as it arguably
      is slightly orthogonal to the purpose of the rest of the series.
      ====================
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      496f4f1b