• David Vernet's avatar
    bpf: Treat KF_RELEASE kfuncs as KF_TRUSTED_ARGS · 6c831c46
    David Vernet authored
    KF_RELEASE kfuncs are not currently treated as having KF_TRUSTED_ARGS,
    even though they have a superset of the requirements of KF_TRUSTED_ARGS.
    Like KF_TRUSTED_ARGS, KF_RELEASE kfuncs require a 0-offset argument, and
    don't allow NULL-able arguments. Unlike KF_TRUSTED_ARGS which require
    _either_ an argument with ref_obj_id > 0, _or_ (ref->type &
    BPF_REG_TRUSTED_MODIFIERS) (and no unsafe modifiers allowed), KF_RELEASE
    only allows for ref_obj_id > 0.  Because KF_RELEASE today doesn't
    automatically imply KF_TRUSTED_ARGS, some of these requirements are
    enforced in different ways that can make the behavior of the verifier
    feel unpredictable. For example, a KF_RELEASE kfunc with a NULL-able
    argument will currently fail in the verifier with a message like, "arg#0
    is ptr_or_null_ expected ptr_ or socket" rather than "Possibly NULL
    pointer passed to trusted arg0". Our intention is the same, but the
    semantics are different due to implemenetation details that kfunc authors
    and BPF program writers should not need to care about.
    
    Let's make the behavior of the verifier more consistent and intuitive by
    having KF_RELEASE kfuncs imply the presence of KF_TRUSTED_ARGS. Our
    eventual goal is to have all kfuncs assume KF_TRUSTED_ARGS by default
    anyways, so this takes us a step in that direction.
    
    Note that it does not make sense to assume KF_TRUSTED_ARGS for all
    KF_ACQUIRE kfuncs. KF_ACQUIRE kfuncs can have looser semantics than
    KF_RELEASE, with e.g. KF_RCU | KF_RET_NULL. We may want to have
    KF_ACQUIRE imply KF_TRUSTED_ARGS _unless_ KF_RCU is specified, but that
    can be left to another patch set, and there are no such subtleties to
    address for KF_RELEASE.
    Signed-off-by: default avatarDavid Vernet <void@manifault.com>
    Link: https://lore.kernel.org/r/20230325213144.486885-4-void@manifault.comSigned-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
    6c831c46
ref_tracking.c 30.8 KB